Clojurians Log v2
lsp
Hey!
The idea came from my experience working on CPU-intensive calculations—I used to catch these issues only after deploying or compiling the library.
To address this, I started using warn-on-reflection and warn-on-boxed in every namespace, but that means the library consumer ends up with those dynamic vars bound by default, which isn’t ideal.
I’m working on an API to find reflection warnings and boxed math usage for a given namespace symbol, with possible exclusions of namespaces outside of the paths found in deps.edn.
Do you think this would be useful to integrate into LSP or clj-kondo? If so, what data shape would work best for the analysis output?
One thing to note: the code uses the Clojure compiler and load, so it can’t run in a GraalVM binary. LSP would need to shell out to a Java JAR to get the analysis.
Let me know what you think @ericdallo, cc @borkdude
The way the compiler works, it installs default bindings for those vars before every file load and pops the result afterwards, so if you put the set! calls just after the ns forms like here https://git.sr.ht/~hiredman/machinate/tree/master/item/src/com/manigfeald/machinate/platform.clj#L16 then they are set when loading that namespace and then popped after the ns is loaded, effectively isolating those settings
The pushing and popping of bindings for those vars is something the compiler does when you ask it to load a file(using load), if instead of doing that you eval each form from a file you don't get that behavior, so if you are seeing set! of those vars effecting the compile time environment of other namespaces whatever tooling you are using maybe not be handling files well
Thanks for the detailed reply. Maybe I was hallucinating, or it has something to do with the monorepo and the development of multiple dependencies at the same time. 🤷
Btw, I didn’t see you on Clojure channels for a long time. I’m glad you’re back 🤣 😆
Hi! I'm using clojure-lsp as a library in a clojure project. I can get all the data that I need by calling clojure-lsp.api/dump, but as I need to collect data from more than one project, i had to (reset clojure-lsp.internal-api/db* nil) to make dump return fresh data. Is there a more elegant way to do this?
Hey Rui! hm, so you call dump passing multiple project roots I suppose?
There is no other way besides reseting the db as you do currently, but we should not cache different project roots
yeap, i need to reset anyway because i need to account for changes in a project, but if i tested correctly dump does cache different project roots, maybe i'm using too old version ("2024.03.31-19.10.13")?
nope, upgraded to "2025.02.07-16.11.24" and same case, this does not affect me, anyway, just letting you know
What you mean with account for changes? and could you elaborate whats your use case for dump?
Dump is a feature supposed to take a snapshot of current project analysis and structure
in practice for me, this is only affecting testing in the repl, if i change the code that my test calls dump for, i always get the cached result
I see, so yeah we could have a function to clean up but in practice we would do that reset