Fork me on GitHub

@thheller cider-nrepl doesn’t do anything with sessions, so I guess you mean CIDER itself. However, some pointer to the code would be useful as I’m fairly certain we start a regular Clojure session and just run the ClojureScript init code in it.


So, with shadow-cljs 2.8.65, if you cloned the session after that init code was run, then you would get an unpromoted session. It seemed like that was happening to @lvbarbosa, yesterday. However, shadow-cljs 2.8.66 fixed that, so we can keep cloning the CLJS sessions, even if we should not assume our clones are very isolated from each other. (Which I did, thinking it would work similar to how it is with CLJ sessions.)


@pez Well, how related can they be? After all they’d have a different set of session bindings, right?


Not sure what session bindings mean here. For a lot of bindings, they share them. So, for instance, *1 is shared. Which is not the case for two Clojure sessions.


Hmm, that sounds weird. Each nREPL session is backed by a different thread and has its own thread-local bindings for *1 and friends. I think we copy some of those on clone, but they are independent from one another afterwards.


The user has two CLJS sessions in Calva. One backing the editor, and one for the REPL prompt. Evaluating something in the editor changes *1-3 for the REPL prompt. Is there a similar test that can be carried out for CIDER?


In CIDER we use the same session for the editor and the REPL, but I we can always find some way to test what happens with two different sessions.


i thought we used two different sessions on the same connection

(response-main (nrepl-sync-request:clone client-conn))
         (response-tooling (nrepl-sync-request:clone client-conn t))


We do, but they are not used like @pez is using them in Calva. In CIDER the main session is used for user-triggered evaluations and the second is reserved for tooling commands that are based on evaluating some code. The tooling session exists for two reason - not to block user evaluations and not to overwrite the results (`*1`, etc) in them.


yes. which seems to go right against "we use the same session for the editor and the repl". unless for the editor means evaling from the editor and not the tooling stuff of the editor


i guess i misread it at first 🙂


Then it should be possible to test if *1 is isolated by evaluating something and then trigger the tooling to evaluate something and then evaluating *1.


Getting a strange error all of a sudden: Exception in thread "nRepl-session-17f6fff6-e0c0-4846-a078-f6e5b35df3ec" java.lang.NullPointerException Can't seem to find any more info (no other cider or nrepl buffers other than repl) I did upgrade cider this morning, but getting this now both with cider 0.24.0snapshot/cider-nrepl 0.23.0-snapshot and cider 0.23.0-SNAPSHOT + cider-nrepl 0.22.0/0.23.0-SNAPSHOT. Can anyone point me to where to look to figure out what I've done/what the source exception is please?


context: this happens when running tests within cider with cider-run-project-tests


That’s pretty strange. I don’t recall any related changes recently, but also it’s hard to say what’s wrong without a full stacktrace.

Zac Bir18:10:41

Hi, all. I’m trying to figure out how to integrate the cider debugger with a running quil process. I can debug a function in the repl, having C-u C-M-x it previously, but I typically run the quil sketch with C-c C-k to get it going and any debugging decoration disappears from the source view. I’ve asked in #quil, but it’s pretty low-traffic.

Drew Verlee22:10:11

Arent cider versions usually in sync?

WARNING: CIDER 0.23.0-snapshot requires cider-nrepl 0.22.4-SNAPSHOT, but you're currently using cider-nrepl 0.23.0-SNAPSHOT. The version mismatch might break some functionality!


Not anymore. As many editors are using cider-nrepl we’ve decided to decouple CIDER releases from cider-nrepl releases.