for Clojure and ClojureScript, we consider https://ask.clojure.org to be the front line place to file issues (which I then turn into jiras). We generally reserve jira accounts for people providing patches as there are some limits on user count in the instance we're using

Thanks Alex. I’ll have the README for the project updated to reflect that 👍

in case it helps, https://clojure.org/dev/dev and https://github.com/clojure/clojure/blob/master/CONTRIBUTING.md might be good places to steal from

oh, for sure! thanks 😃

If you specify use of the ClojureCLR category on http://ask.clojure.org, I can monitor that one explicitly. The last entry was in 2021, so it's not exactly a go-to place at this point.

Not anymore 😉 https://ask.clojure.org/index.php/12524/slurp-without-encoding-prints-erroneous-warning

If you want me to, I’ll submit another PR tonight to align the contributors doc with the one from Clojure, with some changes for ClojureCLR

yes, please.

@U064X3EF3 if you don’t mind a meta question, do people “accept” an answer when it’s been acknowledged/logged, or when the issue has been resolved?

people do both, it's not consistent

generally when we release a fix for an issue, I try to close the question

👍 I’ll mark it as accepted then, as I’ll fix this myself if @U45FQSBF1 doesn’t beat me to it 🙂

if someone needs more rights in http://ask.clojure.org, it is possible for me to elevate user privileges for specific categories to mark certain people as "experts" etc. also, there are category-specific RSS feeds if those become useful for tracking

that’s useful, thanks 👍

To make my question more specific, what directories are searched for when import is called, and what type of files are looked for (`.dll`s I would assume, but maybe also .so for native dependencies)?

I would think there would be a local directory where project specific libraries are stored and a global directory where system-wide libraries are stored, as I believe this is how Clojure handles Java dependencies iirc

where import searches: Not well documented (common problem). I have to double-check the source to remember. The bigger problem is knowing what assembly to load in order to handle an import. the actual code could be a resource in an assembly that does not have the same name. If you look at how Clojure libraries up on nuget are packaged, the dll will have all the clj files from the library are embedded resources. I have thought about adding an extension to the ns macro to allow one to declare the assemblies that need to be loaded. Putting the assembly-load calls before the ns statement is how we handle it now, but that is problematic for some of the source code analysis software that looks for the ns as the first form in the file.

Loading dependencies that themselves have dependencies is a very tedious problem at the moment that lein-clr does not handle well. And, as far as I know, there's no straightforward way to handle it with dotnet or by hand beyond manually finding the necessary dependencies or having dotnet or lein-clr find nested dependencies and manually calling assembly-load-from in the correct order, which becomes very tedious and often results in long troubleshooting of "method not found" or "assembly not found" type exceptions.

All of this becomes much harder as soon as native dependencies are added to the mix.

I guess another option could be to have some convention for a pre-load namespace, which is called before main? Although it would have to be understood by tooling too. IIRC shadow-cljs has something like that.

@U03AU2X8TD5 hmmm, I'm not sure I follow

You can probably ignore that… having spent some days looking into it, it seems to be more complex 😅

Not an IntelliJ user myself but I think this is a great idea. Unfortunately the state of ClojureCLR REPL usage is limited to either a simple CLI REPL or using inf-clojure if you're on emacs, at the moment. Despite this, I still think providing a guide to getting ClojureCLR setup for new users is a good resource

You may be able to add the script that @U03AU2X8TD5 provided https://clojurians.slack.com/archives/C060SFCPR/p1672867422822429 in your guide, to make the REPL experience better at least from the CLI

I believe @U45FQSBF1 is actively working on getting nrepl support for ClojureCLR, but this is an arduous process from what I understand

From there, Cursive integration for ClojureCLR would likely be plausible, but I'm not 100% sure

I am working on nrep quite actively. Again this morning, in fact. 'Arduous' is a fair description. I actually have basic client/server evaluation back-and-forth going, but disconnecting client and server is causing an exception that I have not yet figured out how to deal with properly. but progress is still being made.

Are disconnects a frequent thing? If not it sounds like something I could live with until fixed 😄

@U03K7Q0EF8D nREPL support would go a long way, but there’s a lot of Java(Script) stuff that seems to be taken for granted in Cursive… which I suppose is to be expected since it’s not targeting ClojureCLR

Ok thanks. Apparently .NET isn't supported in IntelliJ itself due to the different build system. (Jetbrains has a separate IDE for .NET)

We can probably do without .NET support as long as we’re able to eg ignore errors in imports and such

(Since IntelliJ/Cursive will think that’s Java)

Yeah, if IntelliJ can support ClojureScript, I'm sure it can support ClojureCLR

I assume a lot of that .NET support is for building C#/F# projects, which you can always do by hand

Not sure how often disconnects occur. And it's just a warning that comes out on *err*. So, yes, one way or another, we will move forward. I need to get some of the other pieces of middleware tested. Some will require some thought on how to deal with, such as things that are ClassLoader or classpath oriented. And that may be optional to getting started.