The pl/nrepl {:mvn/version,\"1.1.1}, part looks broken (unmatched \")

I did notice that, so the error made sense to me, but I don't know the process for starting the REPL, so I'm not sure how to work around this.

Looks like a quoting incompatibility with whatever shell is trying to run the jack-in command. I see a Windows file path there. See https://clojure.org/reference/clojure_cli#quoting for the additional complexity that cmd and PS cause. @U0ETXRFEW How does Calva determine the platform in order to provide the correct quotes here?

also fyi https://github.com/clojure/clojure-site/issues/678

^^ pwsh 7.3 changes not yet accounted for in the docs

Iirc Calva quotes for cmd.exe and Jack-in should be using cmd.exe. But I could have that wrong. @U0DTU8J83, what you can try is to use the command Calva: Copy Jack-In Command Line to Clipboard and then use that command line in a cmd.exe shell. If that works, then maybe what happens is that Powershell somehow gets to handle the command line. I usually have a Windows machine I can spawn in the cloud to test on, but I don’t at the moment.

I did what you suggested. I got back the same command line as the message said: pushd c:\Users\fadrian\Projects\mocktserv & java -jar ".calva\deps.clj.jar" -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""1.1.1""},cider/cider-nrepl {:mvn/version,""0.47.1""}}}" -M:dev -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]" & popd When I ran this command line manually, rather than erroring out, it started two tasks and seemed to terminate without an error. I have no issue with doing this each time I restart the REPL, if it gets me going again. Is there any way to connect to one of these tasks to provide REPL functionality?

Is taks the same as processes/programs? The clojure process shouldn’t terminate. If one of those tasks is still running and is indeed the clojure process, you should be able to connect Calva to it with the command Calva: Connect to a Running REPL Server in the Project.

Starting the server manually and then connecting to a running REPL works.

Then maybe Calva doesn’t make sure that jack-in runs in cmd.exe. I’ve tried to convince it to do this in this build of Calva: • https://output.circle-artifacts.com/output/job/1c124d51-c394-441b-b118-879fe53a81ed/artifacts/0/tmp/artifacts/calva-2.0.452-jack-in-win-cmd-exe-34bb11a4.vsix Can you install and see if jack-in starts to work for you, @U0DTU8J83? You find the option to install from VSIX in the topmost meatballs menu of the Extensions pane. When downloading the package it sometimes changes extension to .zip, and then you need to change it back to vsix for VS Code to allow you to install it.

I got my hands on a Windows machine today and could reproduce the problem two times. Then it started to work consistently, unfortunately, so I didn’t really have a chance to fix it.

I created an issue for this: https://github.com/BetterThanTomorrow/calva/issues/2549

that looks like a manually initiated stack dump?

but it’s orchard.java.parser > “Source and docstring info for Java classes and members. > Parses :docs using Markdown. > This ns is automatically discarded if orchard.java.parser-next can be loaded.”

Yes, I was exploring this using jps. It makes my CPU very busy and I’m trying to figure out how to suppress it if possible.

@U0ETXRFEW any ideas?

I have 29 send-off threads total in my thread dump. 17 of them are busy with something like above.

It became unusable to connect to REPL from vscode. When I ran it standalone (from command line) this doesn’t happen.

yeah. you’ll need help from #C0617A8PQ or #CBE668G4R. Seems like lots of background processing. Not sure how to inhibit that

It's started over here https://github.com/clojure-emacs/cider-nrepl/blob/79611e47615bc00ea00fe9c265da896976324ae0/src/cider/nrepl.clj#L75-L77 While it has its uses in CIDER, most likely it doesn't have much/any in Calva.

In my computer (8-core intel MBP), while there' s an initial spike, that's it basically. Anyway, I don't think we parallelize this - fairly certain of that since the underlying Java code is thread-unsafe. In order to proceed please: • create an issue in Calva • cc/ me • Attach gists with all thread dumps from all relevant threads. ◦ Highly valuable since I never heard of this workload being parallelized. Thanks!

From -Stree it looks like we must be using a much older version of this code: cider/cider-nrepl {:mvn/version "0.28.5"}.

That's right, Orchard (as seen in the stacktrace) is also at a very old version Then scratch what I said

Do you have the JDK sources in your project? Probably older Orchard and cider-nrepl combinations are bad at handling those

You mean Java source files? Yes we do.

I guess it is a good reason to bump the versions.

> You mean Java source files? Yes we do. From the JDK itself, yes

Hmm, not sure what that is. We do have a bunch of java files, but that what we generate. Not JDK ones.

I guess vscode allows to jump into JDK sources, maybe that could trigger something like that?

Maybe. Anyway I can only respond for (latest-version) cider and orchard and don't know much about Calva stuff 😬

That shouldn’t trigger any stacktraces in the app. At least I can’t see how that happens.

Try run it with the nrepl log active and see if you can spot which op is triggering the behaviour.

Very likely it's "info" since the stacktrace hits $info_reply

Interesting, I have 40 error responses to a single calva nrepl request ‘14’ which looks like related to this, but I didn’t capture the request itself. I’ll try again.