This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (12)
- # babashka (42)
- # beginners (45)
- # calva (60)
- # cider (6)
- # circleci (1)
- # clj-kondo (18)
- # clojure (21)
- # clojurescript (36)
- # conjure (13)
- # cursive (2)
- # datahike (5)
- # datomic (4)
- # depstar (17)
- # emacs (4)
- # fulcro (3)
- # honeysql (2)
- # jobs (2)
- # jobs-discuss (9)
- # lsp (98)
- # malli (32)
- # off-topic (36)
- # other-languages (2)
- # overtone (4)
- # re-frame (5)
- # reveal (7)
- # rewrite-clj (47)
- # shadow-cljs (25)
- # spacemacs (4)
- # vim (7)
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. https://12178-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.180-use-clojure-lsp-native-binaries-ee3e554f.vsix 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.
The PR is here: https://github.com/BetterThanTomorrow/calva/pull/1043. 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
@U9A1RLFNV may know better but I think for Calva there is a log output called clojure-lsp or something
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,
A Clojure (lein) project medium size
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
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
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...
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: https://calva.io/clojure-lsp/#troubleshooting
@U95713QV7 Nice investigation :thinking_face:
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
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
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?
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.
@U9A1RLFNV what clojure-lsp version Calva master is using?
@U0ETXRFEW you mean
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.
@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.
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. https://12178-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.180-use-clojure-lsp-native-binaries-ee3e554f.vsix
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.