Debugger entered--Lisp error: (args-out-of-range #(" \n => at clojure.lang.Compiler.analyze(Compiler.ja..." 0 1 (cursor 0) 2 903 (face (cider-error-overlay-face default))) 0 981) cider--make-result-overlay("at clojure.lang.Compiler.analyze(Compiler.java:699..." :where 4310 :duration command :prepend-face cider-error-overlay-face) cider--display-interactive-eval-result("at clojure.lang.Compiler.analyze(Compiler.java:699..." error 4310 cider-error-overlay-face) cider--maybe-display-error-as-overlay("compile-syntax-check" "Syntax error compiling at (/Users/akiz/Projects/BI..." 4310) #f(compiled-function (buffer err) #<bytecode 0x87b2cc905f1b98b>)(#<buffer product_persistence_test.clj> "Syntax error compiling at (/Users/akiz/Projects/BI...") #f(compiled-function (response) #<bytecode 0x63054d184a9e8af>)((dict "err" "Syntax error compiling at (/Users/akiz/Projects/BI..." "id" "3742" "session" "12543fd1-a35d-4551-a261-0ba6260324c6")) nrepl--dispatch-response((dict "err" "Syntax error compiling at (/Users/akiz/Projects/BI..." "id" "3742" "session" "12543fd1-a35d-4551-a261-0ba6260324c6")) nrepl-client-filter(#<process nrepl-connection> "ompiler.java:6933)\n\11at clojure.lang.Compiler.eval(...") nrepl-send-sync-request(("op" "analyze-last-stacktrace" "nrepl.middleware.print/stream?" "1" "nrepl.middleware.print/print" "cider.nrepl.pprint/pprint" "nrepl.middleware.print/quota" 1048576 "nrepl.middleware.print/buffer-size" 4096 "nrepl.middleware.print/options" (dict "right-margin" 70)) #<buffer *cider-repl BIM/backend-api:localhost:49729(clj)*>) cider--error-phase-of-last-exception(#<buffer product_persistence_test.clj>) #f(compiled-function (buffer err) #<bytecode 0x87b2cc905f1b98b>)(#<buffer product_persistence_test.clj> "Error in thread Thread[nREPL-session-12543fd1-a35d...") #f(compiled-function (response) #<bytecode 0x63054d184a9e8af>)((dict "err" "Error in thread Thread[nREPL-session-12543fd1-a35d..." "id" "3742" "session" "12543fd1-a35d-4551-a261-0ba6260324c6")) nrepl--dispatch-response((dict "err" "Error in thread Thread[nREPL-session-12543fd1-a35d..." "id" "3742" "session" "12543fd1-a35d-4551-a261-0ba6260324c6")) nrepl-client-filter(#<process nrepl-connection> "d3:err82:Error in thread Thread[nREPL-session-1254...")

The 20s thing should have been fixed with cider-nrepl 0.43.0. Could you check which are you currently using? The elisp error is unfortunate, we should get it fixed Which exact command were you using for evaluation?

1. I use 0.43.0 2. I have tried cider-eval-last-sexp and cider-load-buffer And what about that exception showing in red box inside a file’s buffer instead of special cider buffer I got before?

Was that 20s error related to GccEmacs only?

error handlng slowness was happening cider-nrepl to all consumers were subject to it

> And what about that exception showing in red box inside a file’s buffer instead of special cider buffer I got before? That can be toggled. Anyway, before that - do you have the chance to share the buffer that caused this issue? That would be greatly helpful

It is any buffer, for example

(ns backend-api.d)

(d d)

nrepl-send-sync-request: Sync nREPL request timed out (op eval code (ns backend-api.d)
) after 30 secs

Alright, that end state is also weird, but is a separate problem. Were those the original buffer contents? If possible I need an exact buffer, given the args-out-of-range error

And now I don’t… hmph

Unfortunately I cannot share the first buffer. The point is that either all buffers have a timeout problem (even in the first case I got a timeout if I disabled debug-on-error) or it works but it still seems slower than is usual.

I will try to reproduce it with some public code tommorow.

I'll work on the slowness. Probably I killed most of it recently, but I can think of additional ways in which this slowness can show up

But i never had the slowness.. So it must be - new version of cider or GccEmacs probably.

(It is code base with I work daily for 1,5 year)

Yeah we've been changing stuff, of course we don't make stuff slower on purpose, but it can happen 😬 It's all at the cider-nrepl, Orchard and Haystack levels

I wonder if the args-out-of-range error happened simply because you modified the buffer during the 20s (which is a totally natural thing to do - we aren't supposed to be that slow). If you are able to restart Emacs and not perceive the args-out-of-range in particular, that would confirm it. I'll work on the slowness in the meantime :)

I've accelerated a release https://clojurians.slack.com/archives/C0617A8PQ/p1699381762708279 - the issue should be more rare now. I'll keep refining things!

1. i just tried normal (no GccEmacs) Emacs and the problem is still there, it seems even worse (I am stil on 0.43.0). 2. I can’t reproduce args-out-of-range error but your explanation sounds reasonable. 3. The first error in any buffer always take a long time and basically it a. doesn’t appear anywhere but Messages buffer b. or ends with timeout

Debugger entered--Lisp error: (error "Sync nREPL request timed out (op analyze-last-stac...")
  signal(error ("Sync nREPL request timed out (op analyze-last-stac..."))
  error("Sync nREPL request timed out %s after %s secs" ("op" "analyze-last-stacktrace" "nrepl.middleware.print/stream?" "1" "nrepl.middleware.print/print" "cider.nrepl.pprint/pprint" "nrepl.middleware.print/quota" 1048576 "nrepl.middleware.print/buffer-size" 4096 "nrepl.middleware.print/options" (dict "right-margin" 70)) 30)
  nrepl-send-sync-request(("op" "analyze-last-stacktrace" "nrepl.middleware.print/stream?" "1" "nrepl.middleware.print/print" "cider.nrepl.pprint/pprint" "nrepl.middleware.print/quota" 1048576 "nrepl.middleware.print/buffer-size" 4096 "nrepl.middleware.print/options" (dict "right-margin" 70)) #<buffer *cider-repl BIM/backend-api:localhost:49254(clj)*>)
  cider--error-phase-of-last-exception(#<buffer test.clj>)
  #f(compiled-function (buffer err) #<bytecode -0x129ce78186562875>)(#<buffer test.clj> "Syntax error compiling at (src/clj/backend_api/lin...")
  #f(compiled-function (response) #<bytecode 0x253168fadcbf2f0>)((dict "err" "Syntax error compiling at (src/clj/backend_api/lin..." "id" "12" "session" "d20cbf25-8170-40fe-a8ed-26c230d03feb"))
  nrepl--dispatch-response((dict "err" "Syntax error compiling at (src/clj/backend_api/lin..." "id" "12" "session" "d20cbf25-8170-40fe-a8ed-26c230d03feb"))
  nrepl-client-filter(#<process nrepl-connection> "d3:err119:Syntax error compiling at (src/clj/backe...")

With 0.43.1 - no improvement (or maybe a small). It must be something that has been changes in last 30 days (rough guess :-)).

How can i disable showing error in buffer temp overlay? I guess this is a new functionality so i just want to see if disabling it makes any difference.

Yeah I fixed something but the fix can be more comprehensive, will happen this week. You can disable the feature by setting :

(setq cider-clojure-compilation-error-phases nil)

If you wish to give it one last try as-is, make sure to use a newer JDK (16, 17 or greater)

openjdk 17.0.8.1 2023-08-24 OpenJDK Runtime Environment Homebrew (build 17.0.8.1+0) OpenJDK 64-Bit Server VM Homebrew (build 17.0.8.1+0, mixed mode, sharing)

@U45T93RA6 Ha, when i set

(setq cider-clojure-compilation-error-phases nil)

Which is great. Anyway, the configuration doesn’t disable the overlay..

Thanks, I'll have a look at that too! We don't mean to inform of the same given error twice.

Thanks @U45T93RA6. I just tried more projects and it looks to be a consistent problem. I recorded a video: https://www.loom.com/share/4faa2779e503421eacb892b38bdf3a13 1st part with cider-clojure-compilation-error-phases set to nil. And the second one (>00:30) with cider-clojure-compilation-error-phases set to true, it gets blocked for ~30 secs and it ends with an error in a REPL. I am attaching the file I have used for this..

Thanks much! Keep in mind, one of the first things we now do when starting up cider-nrepl is warming up some caches https://github.com/clojure-emacs/cider-nrepl/blob/5b62ae3d478fd17d1c455758841c7e65475f59af/src/cider/nrepl.clj#L70-L72 This can take 20-60 seconds. So, while your demo is on point, I'd also expect that if you restart the repl and wait about 1 minute, the performance will feel much different. I believe most real-world usages will be like that. Note that all this slowness is all "one-time" - once cached, we have these computations there forever.

...the wrong number of arguments shouldn't be there though. If the nrepl request timed out, it may have to do with that. Please check if it also disappears if waiting ~1m at startup before evaluating errors. Truth be told, even as of cider-nrepl 0.43.0 I was experiencing 12 seconds at most https://github.com/clojure-emacs/cider-nrepl/issues/828#issuecomment-1789628829 . I'm using a 2019 intel MBP. This code isn't parallel though (it cannot) so the core count isn't much relevant. There could be other sources of hardware slowness - LMK if you think what it could be!

Thanks, i will try some things today. I am using M1 Pro - and yeah, I never experienced these problems. Do you know how can I downgrade Cider with Straight.el (or maybe just NREPL)? Do you have some example maybe? I tried to pin specific git commit hash but for some unknown reason it always downloaded the latest version of Cider. I would like to figure out when problems started. Is cache related to cider-clojure-compilation-error-phases? When this is disabled, everything is fast.

cider-clojure-compilation-error-phases is meant to be customized (it's a defcustom) so I'd recommend that path instead, so that you can keep getting bugfixes, performance improvements, etc I also understand that you had a bad experience yesterday, but you can consider that after 1m or so (depending on the machine / setup; it was 12s in mine) you won't perceive a problem at all. All caching is performed for you at startup, in the background. So it would seem sensible to decouple that initial surprise from most real-world usages. Which doesn't mean we'll stop optimizing this area - we totally will 🙂

In specific terms, our library named Haystack could request less info to our Orchard lib. The info that is culrpit for the slowness is not even used for these errors. It's a refactoring that could take just a few days to get shipped. I do appreciate highlighting the importance of these issues.

I waited for 3 minutes and really - the error appeared in like 5 seconds. But when I evaluated the same buffer for the second time then I got timeout on 30s again.

I would use is cider-clojure-compilation-error-phases but right now it sabotages my daily work so I can’t 🙂

> But when I evaluated the same buffer for the second time then I got timeout on 30s again. (edited) Weird. I wonder if it's a different/compound issue. Sorry you're having this experience.

> I would use is cider-clojure-compilation-error-phases but right now it sabotages my daily work so I can’t I didn't understand this. Wouldn't setting it in your .emacs.d avoid all issues for now?

Thank you. It is not a big issue right now because - yes, when it is disabled I got no issues . I try to summarize my experience to avoid confusion 🙂. Good scenario: 1. I disabled cider-clojure-compilation-error-phases 2. I evaluated the failing buffer i shared 3. I get an error Unable to resolve symbol: defz in this context in a temp overlay, in echo-area and in cider-error buffer. 4. When I evaluate the buffer for the first time (even after waiting >1 minute before that), it takes some time to show cider-error buffer (while the overlay and echo-area errors are almost instant). 5. When I evaluate the buffer for the second time, the cider-error buffer is almost instant. Bad scenario: 1. I enable cider-clojure-compilation-error-phases 2. I evaluate the buffer and I get: a. timeout b. OR error in echo area. Sometimes I see the overlay as well but it is much less consistent than when cider-clojure-compilation-error-phases is disabled. So currently, I see no advantage of having that enabled. But I still need to take a further look into what this configuration really does 🙂 .

Yes, of course, when something is buggy it's of no use 😄 Happy that you have something workable, from what I see. I'll work on the meantime on optimizing this stuff once and for all. As mentioned in https://clojurians.slack.com/archives/C0617A8PQ/p1699429900779769?thread_ts=1699372329.796729&cid=C0617A8PQ , fortunately I have a plan by now. Hope to have a bugfix release around Monday.

Great. Btw. I just noticed another bug.. It should be specs.alpha if i am right It was also hard to locate the error as i didnt get the cider-error buffer I am used to tbh..

Oh, I get the cider-error buffer but it took about 2 minutes 😯. I will probably need to downgrade something or move to another IDE for now.

At this point you can permanently set cider-enrich-classpath nil in your .emacs.d It's a coarse-grained measure, but it will avoid all the slow paths (NOTE: it's not enrich-classpath itself that is slow, but other components enabled by it that are. In particular, we use official JDK facilities for parsing .java files which are surprisingly slow)

Sorry, my mistake, I was sure it is disabled but i left it enabled after some tests 🥵. I was able to work for some hours with it being enabled, nice. And thanks again…

No issue! Hope to be able to leave things nicer in multiple fronts soon.

As promised 🙌 https://clojurians.slack.com/archives/C0617A8PQ/p1699741115891019

@U45T93RA6 Thanks, I installed it yesterday and I tested it on small projects - looks much better. But today I’ll work with the behemoth, so we’ll see :-).

Still problematic but faster 🙂, thank you. The most common error after evaluating buffer with (defz) is error in process filter: Wrong type argument: listp, t then red error blinks for second, so basically there is no error report at all and sometimes it is followed by something like error in process filter: Sync nREPL request timed out (op analyze-last-stacktrace nrepl.middleware.print/stream? 1 nrepl.middleware.print/print cider.nrepl.pprint/porint nrepl.middleware.print/auota 1048576 nrepl.middleware.print/buffer-size 4996 ….) after 30 secs

Are you sure that you're running the latest cider-nrepl there? Maybe it's different for your largest project

Startup: bash /Users/akiz/.emacs.akiz/straight/build/cider/lein.sh /opt/homebrew/bin/lein update-in :dependencies conj \[nrepl/nrepl\ \“1.0.0\“\] -- update-in :dependencies conj \[refactor-nrepl/refactor-nrepl\ \“3.9.0\“\] -- update-in :plugins conj \[refactor-nrepl/refactor-nrepl\ \“3.9.0\“\] -- update-in :plugins conj \[cider/cider-nrepl\ \“0.43.3\“\] -- update-in :plugins conj \[mx.cider/lein-enrich-classpath\ \“1.18.4\“\] -- update-in :middleware conj cider.enrich-classpath.plugin-v2/middleware -- repl :headless :host localhost

As for error in process filter: Wrong type argument: listp, t, I'd suggest performing M-x toggle-debug-on-error right after starting Emacs, before doing anything else, then connecting to cider and hopefully you'll get a stacktrace

As for the second issue, I'm at a loss, however we have another improvement in the radar (https://github.com/clojure-emacs/orchard/issues/211) that would speed up everything - removing the need for any workarounds or bug hunting. As we observed last week, disabling enrich-classpath in a given project is a reasonable measure (although coarse-grained).

@U45T93RA6 This is the stacktrace for the first issue.. By the way, what are the benefits of the new changes (enrich-classpath = true)? I wonder if it is worth such a slow down (compared to the older versions of the cider / nrepl).

Debugger entered--Lisp error: (wrong-type-argument listp t)
  cider--handle-stacktrace-response((dict "id" "4896" "session" "775c92ac-42a1-45ba-b66b-b1..." "status" ("done")) ((dict "class" "java.lang.RuntimeException" "compile-like" "false" "id" "4896" "message" "Unable to resolve symbol: ..." "phase" nil "session" "775c92ac-42a1-45ba-b66b-b1..." "stacktrace" (... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...)) (dict "class" "clojure.lang.Compiler$Comp..." "column" 1 "compile-like" "false" "data" "#:clojure.error{:phase :co..." "file" "/Users/akiz/Projects/BIM/b..." "file-url" "file:/Users/akiz/Projects/..." "id" "4896" "line" 234 "location" (dict "clojure.error/column" 1 "clojure.error/line" 234 "clojure.error/phase" "compile-syntax-check" "clojure.error/source" "/Users/akiz/Projects/BIM/b...") "message" "Syntax error compiling at ..." "path" "src/clj/backend_api/linya/..." "phase" "compile-syntax-check" "session" ...)) "compile-syntax-check")
  #f(compiled-function (response) #<bytecode 0x166c9102bbfdcec2>)((dict "id" "4896" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d" "status" ("done")))
  nrepl--dispatch-response((dict "id" "4896" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d" "status" ("done")))
  nrepl-client-filter(#<process nrepl-connection> "r:file:/Users/akiz/.m2/repository/nrepl/nrepl/1.0....")
  nrepl-send-sync-request(("op" "analyze-last-stacktrace" "nrepl.middleware.print/stream?" "1" "nrepl.middleware.print/print" "cider.nrepl.pprint/pprint" "nrepl.middleware.print/quota" 1048576 "nrepl.middleware.print/buffer-size" 4096 "nrepl.middleware.print/options" (dict "right-margin" 70)) #<buffer *cider-repl BIM/backend-api:localhost:60875(clj)*>)
  cider--error-phase-of-last-exception(#<buffer product_group_persistence.clj>)
  #f(compiled-function (buffer err) #<bytecode 0xa914e4e3c0d9d0b>)(#<buffer product_group_persistence.clj> ".session$session_exec$main_loop__26354$fn__26358.i...")
  #f(compiled-function (response) #<bytecode 0x630342b53c192af>)((dict "err" ".session$session_exec$main_loop__26354$fn__26358.i..." "id" "4891" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d"))
  nrepl--dispatch-response((dict "err" ".session$session_exec$main_loop__26354$fn__26358.i..." "id" "4891" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d"))
  nrepl-client-filter(#<process nrepl-connection> "1.0.0/nrepl-1.0.0.jar!/nrepl/middleware/session.cl...")
  nrepl-send-sync-request(("op" "analyze-last-stacktrace" "nrepl.middleware.print/stream?" "1" "nrepl.middleware.print/print" "cider.nrepl.pprint/pprint" "nrepl.middleware.print/quota" 1048576 "nrepl.middleware.print/buffer-size" 4096 "nrepl.middleware.print/options" (dict "right-margin" 70)) #<buffer *cider-repl BIM/backend-api:localhost:60875(clj)*>)
  cider--error-phase-of-last-exception(#<buffer product_group_persistence.clj>)
  #f(compiled-function (buffer err) #<bytecode 0xa914e4e3c0d9d0b>)(#<buffer product_group_persistence.clj> "ng.AFn.applyTo(AFn.java:144)\n\11at clojure.core$appl...")
  #f(compiled-function (response) #<bytecode 0x630342b53c192af>)((dict "err" "ng.AFn.applyTo(AFn.java:144)\n\11at clojure.core$appl..." "id" "4891" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d"))
  nrepl--dispatch-response((dict "err" "ng.AFn.applyTo(AFn.java:144)\n\11at clojure.core$appl..." "id" "4891" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d"))
  nrepl-client-filter(#<process nrepl-connection> "d18:changed-namespacesde2:id4:48919:repl-type3:clj...")
  nrepl-send-sync-request(("op" "analyze-last-stacktrace" "nrepl.middleware.print/stream?" "1" "nrepl.middleware.print/print" "cider.nrepl.pprint/pprint" "nrepl.middleware.print/quota" 1048576 "nrepl.middleware.print/buffer-size" 4096 "nrepl.middleware.print/options" (dict "right-margin" 70)) #<buffer *cider-repl BIM/backend-api:localhost:60875(clj)*>)
  cider--error-phase-of-last-exception(#<buffer product_group_persistence.clj>)
  #f(compiled-function (buffer err) #<bytecode 0xa914e4e3c0d9d0b>)(#<buffer product_group_persistence.clj> "Syntax error compiling at (/Users/akiz/Projects/BI...")
  #f(compiled-function (response) #<bytecode 0x630342b53c192af>)((dict "err" "Syntax error compiling at (/Users/akiz/Projects/BI..." "id" "4891" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d"))
  nrepl--dispatch-response((dict "err" "Syntax error compiling at (/Users/akiz/Projects/BI..." "id" "4891" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d"))
  nrepl-client-filter(#<process nrepl-connection> "d3:err761:.session$session_exec$main_loop__26354$f...")
  nrepl-send-sync-request(("op" "analyze-last-stacktrace" "nrepl.middleware.print/stream?" "1" "nrepl.middleware.print/print" "cider.nrepl.pprint/pprint" "nrepl.middleware.print/quota" 1048576 "nrepl.middleware.print/buffer-size" 4096 "nrepl.middleware.print/options" (dict "right-margin" 70)) #<buffer *cider-repl BIM/backend-api:localhost:60875(clj)*>)
  cider--error-phase-of-last-exception(#<buffer product_group_persistence.clj>)
  #f(compiled-function (buffer err) #<bytecode 0xa914e4e3c0d9d0b>)(#<buffer product_group_persistence.clj> "Error in thread Thread[nREPL-session-775c92ac-42a1...")
  #f(compiled-function (response) #<bytecode 0x630342b53c192af>)((dict "err" "Error in thread Thread[nREPL-session-775c92ac-42a1..." "id" "4891" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d"))
  nrepl--dispatch-response((dict "err" "Error in thread Thread[nREPL-session-775c92ac-42a1..." "id" "4891" "session" "775c92ac-42a1-45ba-b66b-b1f43316248d"))
  nrepl-client-filter(#<process nrepl-connection> "d3:err82:Error in thread Thread[nREPL-session-775c...")

For most people it's not nearly as slow to what you've experienced, so that came as a surprise. I don't know much about your environment - maybe something makes it peculiar. Note that it's disabled by default - later in the year I'll have gained full confidence. https://github.com/clojure-emacs/orchard/issues/211 looks like the last step. The benefits are described in https://docs.cider.mx/cider/config/basic_config.html#use-enrich-classpath (as hinted the problem is not in Enrich itself; but in the Java parser that we had around for years and turned out to have this surprisingly bad performance)

Anyway, thanks for the stacktrace and the overall input, it helps me prioritize things!

Ah, I thought everyone suffered from that problem. So I wondered if the benefits were worth it and if I was missing out on something big. I see. Thanks. I’ve got Chemacs, so I’ll try a second config this week with just cider and maybe I’ll find the root of it.

And sorry, I am mixing things up - enrich-classpath is enabled on my side and I have no issues. The issues are there only when (setq cider-clojure-compilation-error-phases t) 🙂

> I’ve got Chemacs, so I’ll try a second config this week with just cider and maybe I’ll find the root of it. Probably all the slowness is JVM-side so it may have to do with specific project dependecies, JVM opts, Docker stuff, anything like that

The stacktrace though may be an easy fix :) please create an issue for it so that you'll get notified

Here it is 🙂 https://github.com/clojure-emacs/cider/issues/3582

@U45T93RA6 Hi, just to add some info. Yesterday, I have updated my JDK from OpenJDK 17 -> to Temurin 21. I have also updated FlowStorm to latest version + its Clojure compiler. As you said - it is not fastest and there is a room for improvement but it seems to be in much better state than a week ago. Hard to say what exactly caused extremely long hang-ups I got.

Thanks!