calva 2023-02-07 | Slack Archive

pavlosmelissinos16:02:31

Hello! (follow-up from #beginners) A colleague (non-Clojurian) is trying to create an edn file and they made a mistake that I'd expect Calva to catch. In particular they wrote something like this:

{:items [{:foo :bar}] [{:foo2 :bar2}]}

instead of this:

{:items [{:foo :bar}, {:foo2 :bar2}]}

Should I tell them to turn on a clojure-lsp/clj-kondo setting or something or is this something else? Happy to ask for more information if it will help.

ericdallo16:02:52

clj-kondo used by clojure-lsp will report that:

pavlosmelissinos16:02:38

Right, that's what I'd expect, thanks! Should this be working out of the box or does Calva need to be tweaked first?

ericdallo16:02:11

it should work out of the box

pez16:02:51

Recently we've made some changes to how clojure-lsp is activated, this could be a regression.

👍 2

pez16:02:49

See if you can reproduce it with Calva v2.0.328. Which did not have the changes.

🙏 2

pez16:02:02

As for your colleagues, does it work if they start clojure-lsp manually? (The statusbar item is a button, from which the clojure-lsp server can be started manually.)

pavlosmelissinos16:02:14

I already asked them to downgrade and I'm afraid I'm going to scare them away if I ask them to do more than that 😄 I'll install VS Code and Calva on my machine tomorrow and try to reproduce it. In any case I'll let you know when I have any updates! Thanks so much for the help! 💜

🙏 2

pez16:02:46

> I already asked them to downgrade 👀 > I'm afraid I'm going to scare them away if I ask them to do more than that Yeah, I really meant See if you can reproduce 😃

😄 2

pavlosmelissinos17:02:42

Can't find 2.0.328 :thinking_face:

pavlosmelissinos17:02:33

Regardless, I can reproduce the issue with 331 but not with 323

pavlosmelissinos17:02:22

In other words, clojure-lsp doesn't load automatically with 331 and I can't load it manually using the button either. It works out of the box with 323.

pavlosmelissinos17:02:48

~~I can also reproduce it with v2.0.327~~ nevermind, it's just taking a while

pavlosmelissinos17:02:51

I tried 327 on a non-trivial workspace and I got the spinning wheel and no linting for at least 5 minutes (still, I got proper linting with 323 in a snap). I replaced the workspace with a much smaller one and now 327 works as expected. now trying with 330: I'm getting the spinning wheel next to the clojure-lsp button at the bottom again (this time with the smaller workspace) and it's been at least 5-6 minutes after I restarted VS Code already.

pez17:02:23

Don't know why 328 is not there. But 326 is the one before the changes. 327 had the changes.

pez17:02:27

326 and 328 is the same. It was a rollback.

pez17:02:22

But seems we can conclude that this is a regression after 326. cc: @U04HKE0BTC5

pavlosmelissinos17:02:03

It's been a while since that though, someone would have noticed, right? For what it's worth I haven't ruled out user error 😄

pez18:02:42

327 wasn’t all that long ago.

pavlosmelissinos18:02:35

I think I've narrowed it down a bit. On 331, if I start Calva in a workspace with an invalid deps.edn, clojure-lsp fails to load but never recovers and I have to fix deps.edn and then restart VS Code to get the linter working. However, when deps.edn is correct it seems to load as expected.

pavlosmelissinos18:02:26

This is different than OP though. I'm quite sure that my colleague isn't messing with the project's deps.edn but I can't reproduce their issue. I'll try to discuss it with them tomorrow.

pez19:02:56

Please file an issue about that with it never recovers. I think its Calva that loses track of some state.

pavlosmelissinos19:02:42

https://github.com/BetterThanTomorrow/calva/issues/2067

🙏 2

pez19:02:24

Thanks! I added a comment on the issue. It might be upstreams in clojure-lsp things do not recover.

pez20:02:38

Pinging in @U04HKE0BTC5 in this thread also. I think it has clues to where we have regressions in the server start code.

pavlosmelissinos20:02:23

Cool, let me know if you need anything else 🙂

julienvincent11:02:49

Hmm so if the lsp server fails to start for some reason then Calva doesn’t try to restart it when running the “when-project-opened..” setting. I’m not sure what the behaviour was prior? I’m also not sure we should be trying to restart it indefinitely.. though maybe we retry when things like deps.edn change

pez13:02:53

@U04HKE0BTC5 the case with a broken deps.edn is not a regression. Old Calva also fails to recover.

👍 2

lspector18:02:09

If I'm working on a deps.edn project and I add a dependency, is there a way to pull it in short of jacking in again?

seancorfield18:02:16

I use a fork of tools.deps.alpha that has add-libs -- see my dot-clojure repo and the :add-libs alias: https://github.com/seancorfield/dot-clojure/blob/develop/deps.edn#L102 But some variant of this is maybe coming in Clojure 1.12...

Alex Miller (Clojure team)18:02:58

technically it will be coming outside of Clojure, before Clojure 1.12 :)

Alex Miller (Clojure team)18:02:29

and it has a sync-deps feature to sync your runtime to a deps.edn that has been modified

lspector19:02:13

Thanks. I guess for my (beginner) students at the moment, though, I'll say "Jack in again" 🙂

Alex Miller (Clojure team)19:02:45

indeed :)

pez19:02:36

Indeed. 😀 it could be good to know that jacking in again kills the current repl, so there’s no need to figure out how to kill it.

👍 4

2023-02-07

Channels