Fork me on GitHub
#lsp
<
2022-04-05
>
andrewzhurov14:04:54

Hi, guys! I'm trying to play around clojure-lsp, so far I did not manage to get it running. Running clj -A:test from within cli results in java.lang.ClassNotFoundException: clojure_lsp.feature.test_tree.TestTreeParams . Same while trying to load a cli's ns via cider. Tried adding src-java in :paths - same story.

andrewzhurov14:04:02

Same happens for different recent releases, so I suppose the issue is on my end.

ericdallo14:04:19

You need to use the Makefile

ericdallo14:04:22

try make test

ericdallo14:04:37

because we have custom classes that need to be compiled from src-java

ericdallo14:04:10

most/all actions should work via make something

ericdallo14:04:12

it's failing when trying to compile clojure-lsp classes, what's your java version?

andrewzhurov14:04:57

> java -version
openjdk version "1.8.0_161"
OpenJDK Runtime Environment (IcedTea 3.7.0) (guix build 1.8.0_161-b12)
OpenJDK 64-Bit Server VM (build 25.161-b12, mixed mode)

ericdallo14:04:34

maybe related with java 1.8, not sure, it works on CI, could you try java 11?

andrewzhurov14:04:50

I'll try to following the instructuions from that development page. Missed them, sorry. 😅

andrewzhurov14:04:15

I may try java 11 and get back with the results after.

andrewzhurov14:04:27

Thanks for the help. 🙂

ericdallo14:04:38

just want to highlight that java8 is expected to work, we have CI that uses java8, so not sure your issue is related to the java version, just asked to try java11 to make sure is not related

andrewzhurov08:04:12

yup, the problem been in my environment, fixed it, compiles fine

ericdallo11:04:49

So the issue was on jdk17 or something to be fixed on clojure-lsp?

andrewzhurov13:04:03

nono, clojure-lsp side is fine, the problem was in my setup, I had jre without jdk, it seems. after explicitly installing jdk17 - compiles fine

👍 1
snoe16:04:36

> cache kondo analysis per file based on sha > @UKFSJSM38 this makes sense but I don't think it would help completion and other query speeds, right? So I was thinking we can keep separate project/external analysis in db. The only reason I can think of to keep them together is because we don't know what namespaces we have, where. If we cached/indexed external namespace->file we could keep project small and queryable and only ever access external per file.

snoe16:04:16

That could be done during normalization i think.

ericdallo16:04:10

> this makes sense but I don't think it would help completion and other query speeds, right? Yes, but would make startup time incredibly fast, not only editor, but CLI/API too, which is critical to be used on CIs or as lint tooling Yes, I was talking with @U07M2C8TT about having something like this on db:

{:external [...]
 :internal [...]}
That would already improve multiple places speed where we need to filter those.

👍 1
emilaasa16:04:33

I really like that ya'll seem pretty focused on performance - one of the main reasons I stick with simple text editor + lsp is that it is fast!

🚀 1
🙏 1
ericdallo18:04:58

@U07M2C8TT @U0BUV7XSA I'd like to mention something I noticed after some time developing the CLI and using at Nubank as the primary lint tool (yay) There are few huge projects with not that many external deps but lots of LOCs (> 180K lines of clojure code), for those projects, it's pretty hard to make lint achieve less than 4-5mins, here's why: When I say lint I mean: run clojure-lsp on all project source making it clean-ns , format and bring all diagnostics , there were already lots of improvements regarding those tasks, one example is that on clean-ns and format we don't lint external deps anymore, as it's not needed at all, leaving the performance issues to 3 points: • (95%) the project analysis: this is just like clojure-lsp startup but for project sources only, for those huge projects this is the most expensive task, the SHAs idea probably would easily fix this completely • clean-ns: This is usually fast enough for single files usages on editor or smal/medium projects, but when you have more than 1000 ns (1940 in a nubank project) that could increase easily • format: the same as clean-ns, probably worst as cljfmt performance is not that good

jacob.maine18:04:51

I’ll add to that… even smaller projects can feel slow because the CLI can only do one task at a time. See for example, make lint-fix . It’d be nice if you could ask it to clean-ns and format at the same time. Or not even at the same time, just without re-initializing.

ericdallo19:04:53

yep, we do have support for that for lein-clojure-lsp which we use at nubank, since lein uses same process and we check if the analysis are already filled and works great, but no way for deps.edn projects

snoe19:04:38

The analysis sha check makes sense and I worry less about caching project analysis than I do about indexing names that can move around and reference each other. Give it a shot, remember that you have on disk bytes and in buffer bytes - maybe didOpen files get reanalyzed. Full project lint/format is pretty weird to me. Why not just look at changed files from a commit (or a series) ? I also worry that the cli leads to a conflict of interest. Are we optimizing for in-editor experience, or CI tools? You could add a lot of asynchronous clj-rewrite processing for the latter, at the risk of less immediate feedback or incorrectness of the former.

ericdallo19:04:40

we do already support linking only specific files like git changed ones, even so, a lint/format config change could cause the need to lint whole project, that's why we lint the whole project. About the optimization, I agree, but every tune we are making until the moment is applies for both usages, if we face a issue on only one place we should probably re-think that, but seems ok for now. Also, lots of async proccess means more CPU, I already spent some time/manual tests with that and the CPU spike is not good when linting manually on your PC. But yeah, that could be configurable to be applied only on CI for example