Fork me on GitHub

Hello Calva friends. I've been working on making Calva use the graalvm-compiled native binaries for clojure-lsp. I've tested this vsix on Manjaro Linux and Windows 10 Pro. If anyone could give it a bit more testing that would be great. With these changes, the appropriate clojure-lsp binary for your OS will now be downloaded by Calva then started. Startup time is much faster, though initial startup with a given project still takes a bit (faster than before though). CPU usage and memory usage should be lower as well.

👍 11
🎉 7
clojure-lsp 7

The PR is here: Please on the PR if you've tested and for what OS. Quick test: 1. Install the vsix and reload vscode 2. See the "Downloading clojure-lsp" then "Initializing..." messages in the status bar 3. Once clojure-lsp has started, try operations like Go to Definition, verify that linting is working, try a Calva Refactor command or two, etc.


I’m testing this from the branch and notice a significant time lag when navigating to code in my project. Never seen it before, but that could be because I am always jacked-in and nREPL is blistering fast. Will try with dev as well now.


It's not like this in the dev branch. It's in my work project. A cljs mobile app. Not huge, but not tiny either. Navigating to a project file when lsp is finished initializing takes several seconds (maybe five) on this branch, but is instant on dev. Navigating to the same file again is instant on both branches. Which might mean the lag is happening in clojure-lsp? @ericdallo


So, it’s only with project sources. Clojure core and libraries are instant. Also documentation hover is quick. Definition hovers are also quick, interestingly enough. And even after having looked at that the navigation is slow. That indicates that finding and reading the file is still quick, and something is going on between that and opening the file in vscode.


Yes. there it is. Actually not about looking it up a second time, but about opening the editor.


Never saw this lag @U0ETXRFEW do you have a repro? Also we can check the clojure-lsp request/response to check the time between them


I can’t reproduce it in a some test project at least. Where do I find the logs?


@U9A1RLFNV may know better but I think for Calva there is a log output called clojure-lsp or something


maybe you need to enable some debug flag


I know I have had that log before. 😃


Trying here on MacOS, and the “Go/Show to Definition/Parameters” actions stopped working, I always get the no definition found for 
. error “Find references” in the other hand is working fine, confusedparrot A Clojure (lein) project medium size


Check clojure-lsp log file


Where Can I find it? I was looking into:

and on the VSCode console with "clojure.trace.server": "verbose" But I am not sure what I am looking for


You can pass a :log-path to clojure-lsp config to always log to the same file


Seems to be the file I am looking at, but I found no errors log, should I try to look for something specific?


So no errors, you should check the same log I told PEZ to find, the request/response log between client<->server


I know you can get it via Calva, I just don't remember know, @U9A1RLFNV will know how to access it


The request/response log is in an Output channel called Clojure Language Client


Thanks for all this testing, everyone. Indeed, some things could be a result of updating clojure-lsp. Maybe I should have just stuck with the same version from the currently released Calva for this testing...


To isolate issues


I don’t have that output channel anymore. Not with dev either. Sticking to the same version as with dev sounds like a good idea.


I tried to replace the clojure-lsp binary inside the extension to the 2021.02.10-03.01.19 version (the one that was being used before), and it still is failing to navigate About the output channel I was able to get it’s logs when setting "clojure.trace.server": "verbose" on VsCode settings


@U95713QV7 try to remove the .lsp/sqlite.db file and restart the server


Already did, no deal. Reverting back to the master version of Calva, makes things work again I am trying to bisect the problem, but it seems more related to the PR itself than to clojure-lsp. I am going to try to bump just the lsp version with Calva master and checks if something breaks


Yeah, just updating the JAR version of clojure-lsp still works fine


I added a section to the clojure-lsp doc about enabling and viewing the logs:


@U95713QV7 Nice investigation :thinking_face:


I think it should log by default.


Would you mind putting your findings on the PR, so I can track them better?


Nice investigation indeed!


I think I was following the path of the other trace servers by not enabling the logging by default. The html, json, and typescript server tracing is off by default. Maybe in our case it does make sense to enable it by default, though.


Anyway, the lag with opening files that I experience is not there if I use 2021.02.10-03.01.19 in config.ts

👍 3

Good to know it's not related to a code change in Calva


Yes, now back to latest clojure-lsp and the issue is back. Here’s a log from a navigation with the lag:

[Trace - 11:14:00 PM] Sending request 'textDocument/definition - (21)'.
[Trace - 11:14:00 PM] Received response 'textDocument/definition - (21)' in 10ms.
[Trace - 11:14:00 PM] Sending notification 'textDocument/didOpen'.
[Trace - 11:14:00 PM] Sending notification 'textDocument/didClose'.
[Trace - 11:14:01 PM] Sending request 'textDocument/definition - (22)'.
[Trace - 11:14:01 PM] Sending request 'textDocument/codeAction - (23)'.
[Trace - 11:14:03 PM] Received response 'textDocument/definition - (22)' in 2668ms.
[Trace - 11:14:03 PM] Received response 'textDocument/codeAction - (23)' in 2608ms.
[Trace - 11:14:03 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 11:14:03 PM] Sending notification 'textDocument/didOpen'.
[Trace - 11:14:03 PM] Sending request 'textDocument/codeAction - (24)'.
[Trace - 11:14:03 PM] Sending request 'textDocument/documentSymbol - (25)'.
[Trace - 11:14:03 PM] Sending notification '$/cancelRequest'.
[Trace - 11:14:03 PM] Sending request 'textDocument/documentSymbol - (26)'.
[Trace - 11:14:04 PM] Sending request 'textDocument/codeAction - (27)'.
[Trace - 11:14:04 PM] Sending notification '$/cancelRequest'.
[Trace - 11:14:04 PM] Sending request 'textDocument/codeAction - (28)'.
[Trace - 11:14:04 PM] Sending notification '$/cancelRequest'.
[Trace - 11:14:06 PM] Received response 'textDocument/documentSymbol - (25)' in 2845ms. Request failed: The request (id: 25, method: 'textDocument/documentSymbol') has been cancelled (-32800).
[Trace - 11:14:06 PM] Received response 'textDocument/codeAction - (24)' in 2856ms. Request failed: The request (id: 24, method: 'textDocument/codeAction') has been cancelled (-32800).
[Trace - 11:14:06 PM] Received response 'textDocument/codeAction - (27)' in 2626ms. Request failed: The request (id: 27, method: 'textDocument/codeAction') has been cancelled (-32800).
[Trace - 11:14:06 PM] Received response 'textDocument/documentSymbol - (26)' in 2848ms.
[Trace - 11:14:06 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 11:14:06 PM] Received response 'textDocument/codeAction - (28)' in 2514ms.
[Trace - 11:14:07 PM] Sending request 'textDocument/codeAction - (29)'.
[Trace - 11:14:07 PM] Received response 'textDocument/codeAction - (29)' in 147ms.


I think we would need the request and response params from the textDocument/definition that is not working


Oh, wow. @ericdallo Received response 'textDocument/documentSymbol - (25)' in 2845ms - those documentSymbol and codeAction responses are taking a really long time


Yeah, would be helpful. Can set logging to verbose for that.


Oh I see request failed too. hmm


still the documentSymbol should not block a textDocument/definition on client side, but yeah, it's weird to take that time, maybe you have a huge buffer/file content?


The files are not huge, if the question was for me.


I see, could you provide a minimal repro with that bug? So I can test it with emacs client and understand the issue


Before we go down the rabbit hole further, @U0ETXRFEW do you think I should just keep the clojure-lsp version set to one that works fine for this PR? We can still investigate this, but maybe separately.


Updating macos now (for completely other reasons) so can't test anything right now.


@U9A1RLFNV what clojure-lsp version Calva master is using?


Yes, the PR seems fine otherwise.

👍 3


👍 3

@U0ETXRFEW you mean 2021.02.10-03.01.19 ?


I see, there was some fixes and features on some releases after that, @U9A1RLFNV maybe we should try to investigate those issues to bump Calva to latest clojure-lsp


@U9A1RLFNV maybe the problems that @U95713QV7 is experiencing are not due to clojure-lsp version?


Yeah, it seems so. In any case I just set the version back to 2021.02.10-03.01.19 in the PR, so at least we can isolate issues better.

👍 3

@ericdallo We'll definitely want to work out those issues with later versions, but after the PR is merged would be better, I think.


And that's all, really. Just want to make sure it downloads and starts properly on other systems


And of course, thanks to @ericdallo for his work on the graalvm compilation for clojure-lsp.

❀ 11
calva 10
clojure-lsp 10

Ok, here's a new vsix in which the clojure-lsp version is set back to the one currently in use, so we can isolate any issues to being related to the PR, and not changes to clojure-lsp, aside from switching from a jar file to a binary file.


Now with this VSIX I'm having issues with navigation and hovers not working... Back to the drawing board! Just to clarify, it's an issue with cljs/js interop that I thought I worked around, but it's popped up again.


I can't test right now. Will do first thing tomorrow.

👍 3