Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-10-19

Channels

#calva
<
2021-10-19
>
Zach Mitchell00:10:35

I've noticed that Calva isn't picking up aliases in my deps.edn. For instance, I have a :dev alias that only defines :extra-paths ["dev"], but when I print out the classpath I don't see dev in there: 

(doseq [p (seq (.getURLs (java.lang.ClassLoader/getSystemClassLoader)))]
    (println (str p)))
Output: 
file:/Users/zmitchell/code/clojure_web_dev/cardmates/src/
file:/Users/zmitchell/code/clojure_web_dev/cardmates/resources/
file:/Users/zmitchell/.m2/repository/cider/cider-nrepl/0.26.0/cider-nrepl-0.26.0.jar
file:/Users/zmitchell/.m2/repository/integrant/integrant/0.8.0/integrant-0.8.0.jar
...
This is my full deps.edn: 
{:paths   ["src" "resources"]
 :deps    {org.clojure/clojure        {:mvn/version "1.10.3"}
           ring/ring                  {:mvn/version "1.9.4"}
           metosin/ring-http-response {:mvn/version "0.9.1"}
           metosin/muuntaja           {:mvn/version "0.6.7"}
           metosin/reitit             {:mvn/version "0.5.11"}
           selmer/selmer              {:mvn/version "1.12.31"}
           integrant/integrant        {:mvn/version "0.8.0"}}
 :aliases {:run-m {:main-opts ["-m" "zmitchell.cardmates"]}
           :run-x {:ns-default zmitchell.cardmates
                   :exec-fn    greet
                   :exec-args  {:name "Clojure"}}
           :build {:deps       {io.github.seancorfield/build-clj {:git/tag "v0.4.0"
                                                                  :git/sha "54e39ae"}}
                   :ns-default build}
           :dev   {:extra-paths ["dev"]}
           :test  {:extra-paths ["test"]
                   :extra-deps  {org.clojure/test.check               {:mvn/version "1.1.0"}
                                 io.github.cognitect-labs/test-runner {:git/tag "v0.5.0"
                                                                       :git/sha "48c3c67"}}}}}
When I jacked-in I selected the :dev alias, but I don't see dev in the terminal output from the jack-in either: 
clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version,"0.8.3"},cider/cider-nrepl {:mvn/version,"0.26.0"}}}'  -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
WARNING: Implicit use of clojure.main with options is deprecated, use -M
nREPL server started on port 50084 on host localhost -
I'm on 2.0.218 for context.

Zach Mitchell00:10:40

Well, I feel silly. It looks like there's a checkbox that wasn't getting checked next to the alias in the dropdown during jack-in. I was navigating with my keyboard and was just hitting enter on the highlighted alias.

pez00:10:22

You are not silly. That VS Code Ux is silly. Trips a lot of people up.

👍 1
☝️ 1
Hukka05:10:23

Hm. Starting calva today (after reboot) gives me "Couldn't start client Clojure Language Client" in a small toast in the corner. Not sure yet what is affected, and can't see anything weird in "Calva says"

Hukka06:10:57

Heh, ok. I tried to jack in, and it says clojure cannot be found. Seems like for some reason it has lost the relevant folders from PATH

Hukka06:10:20

A problem completely outside Calva, but perhaps the original error could be made more explicit about clojure not being found?

pez06:10:26

clojure is not used to start clojure-lsp

Hukka07:10:23

Fixing the path (and it didn't bring anything except clj and clojure) did get rid of that error, though

pez07:10:34

In any case it is hard to report on clojure as missing when it is not involved in the error. 😃 clojure-lsp is a binary. No idea why it would need clojure or clj on the path. In fact I don’t think it does. I could be wrong, of course.

bringe02:10:33

I think clojure-lsp uses clojure/clj to get the classpath during initialization for deps.edn projects. @UKFSJSM38 Do you think a more detailed error could be given from clojure-lsp when initialization fails?

pez06:10:14

Maybe it should use deps.clj instead? Maybe it could be used as a library by clojure-lsp even? WDYT, @U04V15CAJ?

borkdude08:10:01

@U0ETXRFEW Perhaps as a fallback when clojure cannot be found? Perhaps @U8ZQ1J1RR is on Windows? /cc @UKFSJSM38

pez08:10:08

What would be the point of not using it regardless and not bother to check for clojure?

borkdude09:10:19

Perhaps people have installed a newer (or older) version of clojure specifically for some bug fixes or so

borkdude09:10:36

So it would maybe be good to put this behind a flag or use as fallback or so

pez10:10:07

Then it is probably better to just do it as a fallback. Then clojure-lsp would just work even before clojure is installed, and also when it is installed.

ericdallo12:10:43

clojure-lsp should start even without clojure, the clojure command is used only for detecting classpath of deps.edn project and clojure-lsp logs the error on it's log file

borkdude12:10:35

yes, and when clojure is missing it can't, that is what @U0ETXRFEW is referring to

borkdude12:10:57

see beginning of thread: "clojure not found"

ericdallo12:10:37

Is it possible to get the classpath only with deps.clj?

borkdude12:10:47

just call (borkdude.deps/-main "-Spath")

borkdude12:10:54

it accepts the same args as the clojure CLI

ericdallo12:10:52

It seems we could just drop the clojure command so? And rely on deps.clj?

borkdude12:10:24

I'd be fine with that

ericdallo12:10:52

It seems we would remove a external dependency that may not be available for user and rely only on the deps.clj lib, it sounds good to me, please open an issue

pez12:10:00

But @U04V15CAJ also expressed reasons to only use deps.clj as a fallback in this same thread. Not sure if you saw that, @UKFSJSM38?

borkdude12:10:08

yeah the reason would be that the installed clojure version might be using a different tools jar version (and hence tools deps alpha) because something was broken in a newer or older version.

ericdallo12:10:37

Hum, I see, yeah so maybe we could just silently fallback and log that

borkdude12:10:07

yes, and/or apply configuration setting in .lsp/config.edn to use the built-in deps stuff

👍 1
pez12:10:12

Seems unnecessary to burden the user with this setting, imo,

borkdude12:10:33

But what if they want to opt-in to this instead of using their installed version

borkdude12:10:55

could also be handy for triaging when people have problems with the installed one

pez13:10:07

Yeah, but also makes for more documentation that most people don’t need to read. It’s a trade-off, of course. Settings/configuration need to carry their weight, I think. I’m a Getting Real kind of guy, Make the call 😃 https://basecamp.com/gettingreal/06.4-avoid-preferences

borkdude13:10:53

I don't really agree with that take. You can have options but hide them on the first glance. You can make a section with more advanced options for example where people only need to look in case of these triaging issues.

borkdude13:10:59

It comes down to: when shit hits the fan, give yourself options. (like: yes, a REPL in production)

borkdude13:10:27

It's different from: let clients choose 100 different colors for their outer parens

pez13:10:44

Yep, Lots of possibilities. 😃 Still, settings need to be maintained. I try to avoid them as long as I can, and only add when I need to.

pez13:10:57

> It’s different from: let clients choose 100 different colors for their outer parens Calva users can. 😃

borkdude13:10:31

Sure. But in a case like this, you don't want to mess with how dependencies are downloaded unless users explicitly agree, I think

pez13:10:18

We agree on deps.clj only being used as a fallback. I’m only questioning the make-it-a-setting part.

borkdude13:10:52

Even if you use it as a fallback, you might want to have the option to "force" using it, e.g. when there is something wrong with the fallback logic, or otherwise (clojure / powershell install is detected, but doesn't work for some reason).

borkdude13:10:36

Also people might want to opt into deps.clj not as a fallback, because it has some options (e.g. selecting a different tools jar)

pez13:10:45

Yes, not disagreeing there either. It is a trade-off.

Hukka17:10:45

Didn't quite read the thread, but no, heh, I'm not on Windows. deps.edn projects on Linux, though that error comes before I try to jack in so I don't know if that really matters

bringe03:10:26

@U8ZQ1J1RR It’s not related to jack-in, just FYI. It’s related to clojure-lsp initializing when you open a Clojure project in VS Code. The deps.clj fallback sounds like a good idea. I don’t think it would solve the problem of a similar issue happening with a lein project, but at least it fixes the deps.edn project issue.

ericdallo12:10:28

Yeah, could you open an issue on clojure-lsp?

Hukka16:10:38

Sure, though I don't quite understand which parts are calva and which lsp, but at least you know the context from here

pez08:10:14

Calva v2.0.219 out. It updates the syntax grammar to better match the semantic tokens we get from clojure-lsp and also provides mappings token->grammar so that the semantic aware themes knows how to style the tokens to match the grammar. To the user this translates to much less visual flicker when clojure-lsp is started and when new files are opened. See https://clojurians.slack.com/archives/CBE668G4R/p1634586719164700 for the longer story.

🎉 5
Hukka12:10:10

Something very odd has happened with the repl output. Before, a lazy seq of maps pretty printed the maps (each key-value on a separate line etc) and only printed some values. Now it all gets out, in one long stream without any formatting

Hukka12:10:58

Coloring seems to depend on data size. Just a couple of lines worth of data gets the usual colors of blue kws, red strings etc, but longer output is just white

Hukka12:10:20

Seems like .216 still pretty printed, but .217 not anymore

bringe02:10:33

I’ve confirmed this. It may be related to this change: https://github.com/BetterThanTomorrow/calva/pull/1342. CC @U0ETXRFEW

bringe03:10:20

@U0ETXRFEW, if I click the button in the status bar to turn pretty printing off, then click it again, pretty printing works. Before that, though, pretty printing does not work even though it’s enabled.

bringe03:10:51

(At least, it looks enabled in the status bar.)

pez06:10:19

Thanks for reporting, both of ya! As for coloring. VS Code doesn’t syntax highlight lines above a certain length, for performance reasons. I think that is what might explain the whiteness. You can confirm that, @U8ZQ1J1RR, by decreasing the limit dramatically and throw evaluation that result in short ranges of forms at the REPL.

Hukka17:10:55

That makes sense, I guess, and I don't really have a need to highlight that long lines anyway. They are already unreadable

cjsauer14:10:38

Hey everyone. I’ve noticed that I’m not longer getting the helpful auto-creation of the namespace header, eg (ns my-new.file) , upon creation of a new file. Is this a setting that I may have accidentally disabled?

cjsauer14:10:38

Seems like it’d be an issue with clojure-lsp: https://calva.io/namespace-form-auto-creation/

cjsauer14:10:38

I’m on 2021.09.30-15.28.01 of clojure-lsp, I have it set to “latest”

pez14:10:49

Hi! Are you on Windows, perhaps? There is also this clojure-lsp related issue: https://github.com/BetterThanTomorrow/calva/issues/1350

pez14:10:51

I think that one could be a regressions from when we upgraded the language client dependencies.

cjsauer14:10:23

I’m on Mac

cjsauer14:10:31

Ah okay, that would make sense

cjsauer14:10:53

Anything you’d like me to try?

pez15:10:34

You can try with version 216 of Calva and see if it works there. If it doesn’t, then this could be clojure-lsp itself somehow and you could try with some older version of that.

cjsauer17:10:23

Will do, ty

leoiacovini15:10:55

Hey folks, recently I have been experiencing this problem on multiple different projects, where when I try to Calva JackIn (or connect to a running REPL) the Output Panel hangs and does not connect properly, hanging in the ; Jacking in... phrase. Usually I need to Quit and re-open the VSCode to be able to JackIn with success again, not sure exactly when it started to happen, but I believe it was about a month ago or so. Anything that changed that could be related to this problem?

vncz15:10:34

I have the exact same problem and have not been able to figure that out @leoiacovini

pez15:10:59

I can’t recall anything special changing in Calva that would cause that. It would be great if you could test that. Check the Changelog for info about where to start some bisecting. VS Code makes it easy to use older versions of an extension, but of course, it is quite a lot of work. It needs to be done on a machine where we can repro this, though….

vncz15:10:29

Yeah we talked about this already. There is not really a precise way to replicate this, and I cannot tell whether is the nrepl that is not working or Calva that’s struggling to connect to the nrepl

vncz15:10:46

I do recall when trying to connect Calva manually to the allegedly running Repl I received a socket error or something like that

pez15:10:49

I’m thinking: If you run with an older version of Calva a couple of days, and this doesn’t happen, then we might have an indication that this is a change in Calva causing it.

leoiacovini17:10:43

I will try to run some bissections, but its kinda hard to get this tested because the error is intermittent and seems to happen just after the VSCode is opened for some time (dirty state? ENV/Creds caching?). Anyway, I will try to dig a bit deeper

🙏 1
pez19:10:05

Yes, very tricky to catch this one. And there is still the possibility that it is something outside that has changed, that we can’t catch by bisecting Calva versions…