This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (31)
- # beginners (38)
- # biff (1)
- # calva (10)
- # clj-kondo (10)
- # clj-otel (9)
- # clojure (9)
- # clojure-europe (4)
- # clojure-norway (4)
- # clojurescript (25)
- # cursive (1)
- # datahike (3)
- # datomic (4)
- # emacs (6)
- # inf-clojure (2)
- # missionary (11)
- # nbb (3)
- # off-topic (9)
- # portal (17)
- # re-frame (16)
- # reagent (1)
- # releases (3)
- # shadow-cljs (5)
- # tools-build (17)
- # tools-deps (2)
- # xtdb (6)
I have a library that is specified in the
deps section of bb.edn with its git url. It seems the go to definition does not work for these kinda of git downloaded packages.
I'm not sure how calva implements go to definition (cc <!subteam^S03BGSAUPTQ|@calva-team>) - it could be a combination of lsp + REPL, or only lsp? Not sure.
Calva uses clojure-lsp for this. In theory we should fall back on nrepl if lsp fails, but we might have a bug there.
right, so what could he happening is that the clj-kondo analysis of that dep doesn't recognize the thing you navigate to, or lsp fails for some other reason, or the fallback to nrepl fails, or the bb nrepl server itself is missing something
> It seems the go to definition does not work @UGC0NEP4Y What happens when you try to go to definition? Does VS Code appear to just hang with a sort of pending animation above the editor? If so, that might be related to this issue: https://github.com/BetterThanTomorrow/calva/issues/1782. A workaround is to use an older version of clojure-lsp by downloading it from the clojure-lsp repo’s releases and setting the path to it in Calva’s settings.
> If it just says there’s no definition found, then it’s probably not related. Yes. That is the case.
Note that for jar include packages (compared to the git included one), the issue does not exist.
Find out it does NOT work when the project is not the root project. For example, if I open the project foo in calva and open some file in foo/subproject
then the jump to definition does not work.
foo/subproject where foo/subproject has a bb.edn
It has nothing to do with git imported libs, jump to definition on builtin in libs like clojure.string etc do not work too.
Just checking in to say that working with text generation and shelling out to stuff with babashka is a pure joy. Being able to compose small Clojure scripts with other Unix tools is awesome. ❤️
Seems like babashka/process might not be clojure 1.9 compatible https://github.com/babashka/process/blob/d7331aa5522c44bcd5be74abacf11dbf3903d764/src/babashka/process.cljc#L497?
Works fine on 1.10+
$ clj -A:1.9 Clojure 1.9.0 user=> (resolve 'org.graalvm.nativeimage.ProcessProperties) ClassNotFoundException org.graalvm.nativeimage.ProcessProperties java.net.URLClassLoader.findClass (URLClassLoader.java:476)
Clojure 1.10.3 user=> (resolve 'org.graalvm.nativeimage.ProcessProperties) nil
Does resolve work differently in clojure 1.10, more forgiving when class isn't found? cc @U064X3EF3
I can reproduce that locally
[email protected] /tmp/foobar $ clj -A:clj1.9 Clojure 1.9.0 user=> (resolve 'org.graalvm.nativeimage.ProcessProperties) ClassNotFoundException org.graalvm.nativeimage.ProcessProperties java.net.URLClassLoader.findClass (URLClassLoader.java:445) user=> [email protected] /tmp/foobar $ clj -A:clj1.10 Downloading: org/clojure/clojure/1.10.0/clojure-1.10.0.jar from central Clojure 1.10.0 user=> (resolve 'org.graalvm.nativeimage.ProcessProperties) nil
We can fix this with another try/catch around the resolve, but it's an interesting difference