This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-31
Channels
- # adventofcode (15)
- # announcements (3)
- # babashka (38)
- # beginners (121)
- # calva (29)
- # cider (21)
- # circleci (1)
- # clojure (177)
- # clojure-europe (7)
- # clojure-france (2)
- # clojure-nl (7)
- # clojure-spec (3)
- # clojure-switzerland (5)
- # clojure-uk (4)
- # clojurescript (10)
- # code-reviews (1)
- # conjure (19)
- # deps-new (2)
- # emacs (5)
- # fulcro (52)
- # graalvm (13)
- # kaocha (1)
- # malli (1)
- # off-topic (6)
- # pathom (5)
- # re-frame (17)
- # reagent (14)
- # remote-jobs (1)
- # rewrite-clj (5)
- # robots (1)
- # shadow-cljs (13)
- # sql (38)
- # tools-deps (16)
- # xtdb (99)
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.
@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)
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?
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
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 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
@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
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.
Thanks for the feedback, @jr0cket. You have very valid points, and I'm going to prioritize this.
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