Clojurians Log v2

Does it consistently happen? How large is your project?

the project has about 50k LOC. I havent been able to use cider to find fn refs so far. my setup works for non polylith projects.

50k is a fair bit 🙂 I'd try, just as an experiment, (setq nrepl-sync-request-timeout 300) , retry the feature, and see if it works / remains slow

will give it a shot. already increased that value from 10 to 30, but one more zero cannot hurt :P

increasing the timeout helped. I was able to get the results eventually. thanks for your help @vemv

Cheers. I did some work on this feature last year. If it remains slow/problematic, you can create a ticket in cider-nrepl

just curious. I am using cider-load-all-project-ns in my polylith project. is that the correct way to do that? cause I am still not sure if I am getting correct list of refs

You invoke cider-load-all-project-ns and then use the xref feature? That would seem OK to me Although I don't use cider-load-all-project-ns myself. xref doesn't care about how the code was loaded (`cider-load-all-project-ns` , repl evaluation, tools.namespace, etc), so it shouldn't affect performance

> I am still not sure if I am getting correct list of refs simplest thing you can do is - if you detect something that should be there but isn't, check if the code is loaded if it's not, then you need to make cider-load-all-project-ns work for you

50k LOC doesn't seem very big to me -- we have about three times that. I'm using clojure-lsp and, in VS Code, that shows references as inline annotations and is very fast. Maybe look at using clojure-lsp with Emacs?

There isn't anything particularly slow about the xref implementation. I'd appreciate having the chance of diagnosing issues, all projects have corner cases and I don't go around telling people to switch tooling :)

I am using both LSP and cider, just looking to improve my knowledge on both.

You can tell what cider-nrepl is doing by: • running it from the CLI • Hitting Ctrl+\ That will print a stacktrace dump of all threads. If an op keeps taking N seconds, you could hit that combination a few times to get a representative sample of what's going on. (an alternative being creating a Yourkit report - that's paid software) If you have the chance to create such a report, issue welcome.

will try to put something together. but it seems that I'm just doing something wrong when it comes to polylith workspace loading

I don't recall the exact terminology (it's been a few years since my last pro Poly project), but the normal thing would be to create a 'dev' project that depends on all your projects. If you like the tools.namespace ("Reloaded") approach, in that dev project you would explicitly set the refresh-dirs Something like this:

(set-refresh-dirs ["../foo/src" "../bar/src" "../foo/test"])

(let [paths (->> (clojure.tools.deps/create-basis {:aliases #{:dev :test}})
                      :classpath-roots
                      (remove (fn [^String s]
                                (or (.endsWith s ".jar")
                                    (.endsWith s "resources"))))
                      (remove (fn [^String s]
                                (let [f (File. s)]
                                  (or (.isFile f)
                                      (not (.exists f))))))
                      (distinct))]
  (apply set-refresh-dirs paths))

Classic REPL-driven development is perfectly fine as well of course.

> I'd appreciate having the chance of diagnosing issues, all projects have corner cases and I don't go around telling people to switch tooling :) I only meant that I wouldn't expect it to be slow on that sized codebase and perhaps check whether clojure-lsp is also slow, just to provide a baseline for CIDER. It certainly makes sense to see why CIDER is slow since that seems unusual...