This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (3)
- # announcements (12)
- # beginners (80)
- # boot (3)
- # braveandtrue (16)
- # calva (3)
- # cider (82)
- # clojure (100)
- # clojure-art (3)
- # clojure-dev (79)
- # clojure-estonia (1)
- # clojure-europe (4)
- # clojure-finland (15)
- # clojure-indonesia (1)
- # clojure-italy (20)
- # clojure-nl (4)
- # clojure-spec (24)
- # clojure-sweden (2)
- # clojure-switzerland (1)
- # clojure-uk (99)
- # clojurescript (145)
- # cursive (8)
- # data-science (7)
- # datomic (26)
- # emacs (4)
- # figwheel-main (20)
- # fulcro (8)
- # graphql (3)
- # hoplon (2)
- # jobs (1)
- # kaocha (5)
- # leiningen (2)
- # liberator (19)
- # off-topic (16)
- # pathom (9)
- # perun (1)
- # portkey (2)
- # re-frame (17)
- # reitit (1)
- # shadow-cljs (26)
- # spacemacs (7)
- # vim (49)
Has anyone ever ran into issues with cider-nrepl hanging when evaluating forms?
I have the exact same Emacs version and configuration/`~/.lein/profiles.clj`/project across 3 different computers (3 Macs, 1 running Linux, and 1 running Windows) and only one of them has this issue (one of the Macs). I cannot figure why it's happening.
Basically when I evaluate a form in
cider-nrepl it will sometimes hang for 10-20 seconds before printing the result. The hanging is happening in the external process because Emacs is still responsive (and
debug-on-exit and the Emacs profiling tools don't really provide useful info).
When I run
lein repl however things work perfectly normally. But if I run
lein repl :headless and
M-x cider-connect to that REPL I run into the hanging again.
The form and the results don't matter -- it hangs equally often and long whether I'm evaluating something simple like
(+ 1 2) or a bigger function that run a DB query and returns a few hundred rows
@camsaul maybe check the heap sizes? the default heap size can vary from computer to computer and memory pressure could cause delays in processing
@pjstadig thanks, I thought it could be that. But
(.maxMemory (Runtime/getRuntime)) gives my 8 GB, so I don't think that's the problem
even when creating a new project and running
cider-nrepl I'm running into the lag.
I've enabled nrepl logging (`(setq nrepl-log-messages t)`) to try to figure out what's going on. It's lagging between sending the form to be evaled to the
nrepl and getting the response.
In the example above I typed
(--> id "17" op "eval" session "af0c00af-7bb8-4382-a6bc-44248c420115" time-stamp "2019-01-17 02:21:58.994293000" code "(+ 2 3)" column 9 content-type "true" file "*cider-repl ~/x:localhost:50767(clj)*" line 8 ns "x.core" print-options (dict ...) printer "cider.nrepl.pprint/pprint" ) (<-- id "17" session "af0c00af-7bb8-4382-a6bc-44248c420115" time-stamp "2019-01-17 02:22:42.249252000" ns "x.core" value "5" )
(+ 2 3)in the REPL and it took almost a full minute to get a response (as recorded in the timestamps). Annoying to say the least! 😓
I thought it could have been some sort of network configuration issue so I tried
127.0.0.1 instead of
localhost but that doesn't seem to make a difference
I think maybe my next step will be to look at the traffic a little more with Wireshark and see what's going on and maybe try to repo some of the queries it's sending manually and seeing if I run into the same lag outside of CIDER
i wouldn't guess it is networking related. have you tried hooking up jvisualvm or something similar to the repl server to see what is happening when its evaluating?
the reason I thought it might have been networking related is there's no lag when running the nrepl directly with
yeah i was thinking the delay in the timestamps indicated a delay in processing as opposed to networking
Yeah, I turned of then firewall and antivirus to see if that was a problem and it didn't make a difference. I'm using the same stuff on the other too Macs however without issue. Another other stuff ran locally like databases in Docker containers or web servers aren't having any issues
so profiling didn't get me very far except for finding out that nrepl is basically spending most of its CPU cycles polling for and writing bytes. Nothing surprising.
What is surprising however is comparing packet capture in Wireshark with the `*nrepl-messages* buffer.
(System/nanoTime) in the REPL at 4:15:15, but didn't see a response for 10 seconds or so.
04:15:15.884979 TCP 324 52718 → 52359 [PSH, ACK] <eval request from cider> 04:15:15.884997 TCP 56 52359 → 52718 [ACK] <ack from nrepl for eval request packet> 04:15:15.890072 TCP 150 52359 → 52718 [PSH, ACK] <nrepl response> 04:15:15.890091 TCP 56 52718 → 52359 [ACK] <ack from cider for response>
(--> id "69" op "eval" session "2c754a30-4bf0-42ba-aa57-b57977f7f2aa" time-stamp "2019-01-17 04:15:15.884446000" code "(System/nanoTime)" column 9 content-type "true" file "*cider-repl ~/x:localhost:52359(clj)*" line 14 ns "x.core" print-options (dict ...) printer "cider.nrepl.pprint/pprint" ) (<-- id "69" session "2c754a30-4bf0-42ba-aa57-b57977f7f2aa" time-stamp "2019-01-17 04:15:24.734444000" ns "x.core" value "55310219931646" ) (<-- id "69" session "2c754a30-4bf0-42ba-aa57-b57977f7f2aa" time-stamp "2019-01-17 04:15:24.735295000" status ("done") )
The really strange thing is that I can see the response being sent by
nrepl about 5 milliseconds after the
eval request is sent, but it doesn't pop up in
*nrepl-messages* or the CIDER REPL until 9 seconds later
In case my Emacs networking was broken somehow I reinstalled it and tried both http://Emacs.app and installing with Homebrew but neither had an effect. FWIW other networking in Emacs seems to be working fine (such as fetching packages) So I'm guessing there's something weird going on in the CIDER networking code itself. I'm going to try to poke around a bit and see if I can find what's going on
Not sure if this is a good idea, but I released this https://github.com/pjstadig/ring-cider-debug
I use C-c M-; (eval-defun-to-comment) a lot so that I can refer back to the output while studying. But if I do something like this
(def words (clojure.string/split example #" ")) and then want to check my output by just putting in
words below it I get the expected behavior when pressing C-c C-e but do not get the expected behavior from C-c M-;. Is there a trick to eval-defun-to-comment if I am using it on only variable names without an s-expression? Not sure if this is too much of a corner case for my use only.
the behavior I get in this case is it evals the next complete s-expression in my source code and inserts the relevant comment for that expression.
you shouldn't need any deps in there. CIDER will inject all of its own depepdencies into a project when you are jacking in
*Messages* buffer it will show the command it uses to start up your process. can you post that here?
Starting server via /Users/jmckitrick/bin/lein update-in :dependencies conj \[nrepl\ \"0.5.3\"\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.20.0\"\] -- repl :headless :host localhost...
error in process filter: user-error: 'nil' requires the nREPL op "classpath" (provided by cider-nrepl) error in process filter: 'nil' requires the nREPL op "classpath" (provided by cider-nrepl)
Ok, this time CIDER did not give me the same warning. However, in the repl in emacs I’m seeing
CIDER requires nREPL 0.4.4 (or newer) to work properly
ok. i think we are closer. maybe check
lein deps :tree to see if anything is bringing in tools.nrepl
Just found this
[org.clojure/tools.nrepl "0.2.12" :exclusions [[org.clojure/clojure]]]
Since I’m running
cider-jack-in inside a project, I shouldn’t need to force nREPL 0.4.4
if you are doing lein deps tree it should show who requires it. if it is "top level" it is just required in your project.clj
excellent. sorry its so weird. things just get crazy when core infrastructure like nrepl gets unfrozen
No problem. I’m really looking for a place to help now. The only catch is I’m not currently in Clojure full time anymore. But I want to contribute something of value…
So for any other projects I want to use, the hard work has been done, right? Upgrade leiningen, clear out .lein/profiles.clj, and that should be it?
pretty much. the only gotcha is that the two versions of nrepl can't coexist right now