Clojurians Log v2

I was having this issue awhile back and it turned out that somehow the keyboard shortcuts had gotten disabled in the settings! Perhaps it's worth a look...

Yes, that was actually the case. Calva has a keyboard shortcut defined for disabling its keyboard shortcuts… @brandon.ringe has removed it for the next Calva release, fortunately.

Calva version 2.0.143 is out with the following changes. Windows users, please try out navigating into a jar dependency (Go to Definition), and try out one of the new https://calva.io/refactoring/, and let us know if you have any issues. • Update clojure-lsp to include https://github.com/clojure-lsp/clojure-lsp/issues/223 • Fix: https://github.com/BetterThanTomorrow/calva/issues/911 • https://github.com/BetterThanTomorrow/calva/issues/815

Is there a way to disable clojure-lsp in Calva? I just updated Calva and am experiencing several Gb of RAM being used by the clojure-lsp process on one project. The project code is not that complicated although I believe the 4 dependencies have quite a few dependencies themselves. It seems to be taking quite a time to process too, although at least its not blocking.

No way to disable it currently, @jr0cket. Please file an issue about it.

@jr0cket I've been thinking lately this would be requested due to memory usage, and maybe some people just don't want it to start for certain projects

I think a simple setting would be good to enable/disable. Haven't thought it through yet though

We could also add a flag in clojure-lsp to do not scans jars early (which take most of the time to start)

@pez ouch, its not very welcoming to add a feature that consumes large amound of memory with no option to disable. I'll downgrade Calva to an earlier version for now until its possible to run without clojure-lsp

That's an interesting idea

But if a user tries to navigate to a jar dep after lsp has started, but before the dep has been scanned, what would/should happen?

THat's what we need to test it 😅

We weren’t quite aware of the memory consumption, @jr0cket. But we try to be quick to fix problems we create by being quick to develop Calva. We’re not like Facebook. It’s rather Move fast. Be quick to fix things if they break, 😃

I am afraid this gives me less confidence in recommending Calva

@pez oh, I though it was a well known problem with clojure-lsp. I've discussed this many times with people using clojure-lsp with Emacs, which is a far worse situation as clojure-lsp didn't run as a background process. Although clojure-lsp is a very promising approach, for myself I consider it an optional tool until it matures and becomes more efficient. I was going to invest time to learn Calva better in 2021, but not if "have" to use clojure-lsp without a choice, sorry.

Good news, I tested and reduced a lot the startup time... I'll try to find the drawbacks of doing this.. Another aproach is no async crawling jars using clojure.async

Thanks for the feedback, @jr0cket. You have very valid points, and I'm going to prioritize this.

Sweet

Thank you. I dont like to be negative, but feel this is a big change to the Calva experience and wouldn't want anything to detract from the amazing work done so far. Thanks again.

I started this issue to track the memory issue https://github.com/clojure-lsp/clojure-lsp/issues/229

Well, I managed to make the crawling jars async using clojure.async , I'm adding it behind a flag async-scan-jars-on-startup? . While the jars are not scanned, it's not possible to go to a jar or something like that, but I think it's more important for users to scan the project and then later scan the jars... wdyt?

I was wondering also if the default of this flag should be true or false

I have plans in the future to improve this code later to use more clojure core async to crawl source dirs and clj-kondo

I think making it false by default (like current behavior) would be good for now at least

Ok, I'll open a PR soon, would you mind helping test with Calva also?

Sure, np

:reviewplease: https://github.com/clojure-lsp/clojure-lsp/pull/230

sweet, I'll get to this when I can, it may be a little while

Happy New Year, friends! (We just celebrated here in Sweden). 2021 is the year of Clojure, I am sure. And the Calva team shall be here, offering VS Code people tools they need to join and enjoy the ride. Cheers!

@pez Same wishes to you

happy new year