Fork me on GitHub

After connecting calva and reveal, all is OK until I happen to edit an edn data file… Then I get an Unhandled REPL handler exception.

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.8.3"} cider/cider-nrepl {:mvn/version "0.25.7"}}}' -A:reveal:config
nREPL server started on port 52491 on host localhost - 
ERROR: Unhandled REPL handler exception processing message {:op info, :ns user, :symbol resources/public/kidney/edn, :id 15, :session 476d9211-b2ba-41c0-b382-65b4c724e4ff}


That ‘Calva Jack-in Clojure CLI’ terminal then continues to log errors even when returning to edit a clj file. The repl and reveal do both continue to work. Errors logged look like this:

ERROR: Unhandled REPL handler exception processing message {:op info, :ns transplants.configure, :symbol , :id 74, :session 476d9211-b2ba-41c0-b382-65b4c724e4ff}
java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to java.lang.ClassLoader 


Do you know if it happens only when used together with reveal?


Still experimenting… comparing 2.0.134 at present - which appears to be working OK with reveal and visiting an EDN file. I’ll upgrade again and try without reveal…


Not sure about 134, but we've added a setting for changing the jack-in versions of dependencies. Thinking it could be something with those...


OK - so it’s possible that EDN is not the trigger. In 2.0.153 again and this time without reveal, and a jack-in gives me:

clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.8.3"} cider/cider-nrepl {:mvn/version "0.25.7"}}}' -A:config -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
WARNING: When invoking clojure.main, use -M
nREPL server started on port 52880 on host localhost - 
ERROR: Unhandled REPL handler exception processing message {:op info, :ns transplants.configure, :symbol separate, :id 7, :session 01f14827-e8e0-4fbb-bd7b-5b336e17facb}


Just weird.


That was when visiting a clj file.


Things are not consistent here so it’s difficult to report. I closed vscode and retried, and there was no problem (without reveal)


Back to reveal. This time jack-in asks ‘Add port to nREPL if localhost’ - it usually doesn’t. I give it the port where nREPL started and reveal connects. No error when visiting EDN. More weirdness 😞


Lots of dependency weirdness,, indeed. But it’s good you have seen it and investigated it some. As more clues are collected we’ll probably figure it out eventually.


Bump @UCCHXTXV4 about finishing his PR about that port prompt. 😃


pr finished, let's merge; that and keybindings one too


Last time I checked there were review issues with the PR. Have you fixed those?


I think so


It says review pending when I check. There’s a file watcher added that is not needed.


Do we want the watcher as a fallback? In case regex yields no port?


Not sure what the pending thing is, I have no feedback there myself.


I continued working with that set up. But later the exception reappeared - I don’t know what triggered it. Ignoring it for now. Here’s the stack trace:


Weird! I wonder if it's something with some code in your project that's causing cider-nrepl/orchard to throw this error


If it keeps up, and you can provide a repro project + steps to make it happen consistently, an issue with that repro project linked would be good. Soon cider-nrepl will be upgraded to 0.25.8 (next release), and was recently upgraded to 0.25.7, so I wonder if there is something that changed to cause that, and I wonder if it'll be resolved after an upgrade


I wondered that too, but the stack trace doesn’t go near my code. All this weird stuff started happening after the Christmas break and when I go back to the pre Christmas release (134 is my favourite) it stops happening.


I think there's been at least a couple upgrades of jack-in deps, maybe some back around that time, so that could be it.


Wondering if this is related to this: I linked your gist there and asked about it

bringe23:01:04 Looks like this is fixed now. Hopefully with the next Calva release which includes a cider-nrepl update, you won't see this error any more.


When I try to evaluate a bad code like this (assoc [] [:foo :bar] 42) I get no feedback at all. In 2.0.152 it works as expected throws an error: ; Execution error (IllegalArgumentException) at zelark.aoc.maze/eval6016 (REPL:26). ; Key must be integer Is it a known issue?


Works for me. Can you give more context?


I get that error in 2.0.153. Not sure what could be going on. Have you tried reloading your VS Code / repl?


After restarting the editor it has gone. Thanks.


But seems like there is some other problem that is related to namespaces switching. I’ll try to reproduce it and make a capture of my screen.

👍 3

I can’t figure out how to make it reproducible firmly, but it happens time to time to me. When I try evaluate some bad code as in the example above, I don’t see any feedback.


  (:require [ :as bar]))
In this case doesn’t exist. When I tried evaluate it, nothing happened.


In the video zelark.maze doesn’t exist.


An important note: after I downgraded to 152, it seems the issue doesn’t appear at all.


Yeah, there was an issue there, that's already fixed in the next Orchard/cider-nrepl release.


In which case you can solve this for your install, @U067R559Q, by using the jack-in dependency settings:


Oh, that’s a good point, I forgot about it. But it’s better to update for all calva users.


Yeah an update to cider-nrepl 0.25.8 is in the dev branch already, will go out next release

✔️ 3
Piotr Brzeziński21:01:03

Hey! Just installed calva and I have run into a weird problem. Getting bunch of unresolved symbol errors. Why could that happen?


You probably didn't configured the :lint-as for that macro with-let

Piotr Brzeziński22:01:01

Oh ok, makes sense. Thank you.

👍 3

Hello and welcome! Glad to see you've got some help.


I feel like this should be in a suggestion box somewhere? It took me unusually long to find the answer to this in regular documentation when I first ran into it. Could, upon the detection of a macro with an unresolved symbol, this trigger some sort of suggestion box? Maybe that's a new feature suggestion for clj-kondo? Just sharing some thoughts


Yeah, I think if anything it would be a clj-kondo concern, but I'm not sure what more could be done to assist. CC @U04V15CAJ


clj-kondo doesn’t provide the lsp here, right? It reports a linting issue. I think the more plausible options for providing tips on how to handel it are clojure-lsp, or Calva, through lsp middleware.


Another option is if we provide a quick-fix suggestion that adds the needed config.


I think adding a link to the docs would best since there is often not one best way to solve a problem. Adding ignores all over the place would maybe prevent people from reading the docs


@U0ETXRFEW If I'm not mistaken the message they're concerned about is from clj-kondo, and the config they're looking for is clj-kondo config. Clojure-lsp is just the middleman here.


Oh, I see you mean lsp would be the thing to provide a quick-fix or something.


I'm not sure what options lsp has to provide any help here, as it's merely providing diagnostics via the protocol structure, and VS Code is the thing that renders the diagnostics in that way.


A quick fix would be a link to the relevant doc


Yeah, I'm just not sure how that could be provided


Unless you mean in the lint warning itself from clj-kondo


But that would seem maybe a bit too much / crowded. I don't know off hand how we can control what pops up there when they hover, is what I mean. Maybe there is a way though. If we were to try to make lsp provide a link via the hover lsp message, then it would need to cross reference diagnostics on the server before providing hover content. Other than than, I suppose maybe Calva could add a hover provider and reference the diagnostics received from lsp. Seems a bit complex for something like this though, but probably doable.