Fork me on GitHub
#calva
<
2022-06-01
>
chucklehead21:06:58

I have a couple issues with Calva/clojure-lsp that I've been working around due to having a weird device (Surface Pro X - Windows aarch64 that can emulate Win x86/x64 and Linux aarch64 via WSL): • When opening projects in Windows, Calva downloads the amd64 build of clojure-lsp which runs fine due to emulation, but gives weird behavior that I assume is something classpath-related to clojure running under windows-arm64 jdk and clojure-lsp running as windows-amd64. • When opening projects in WSL, Calva downloads the linux-amd64 build of clojure-lsp which doesn't work at all because the x86/x64 emulation only works for Windows apps For Windows I've been using the standalone jar for clojure-lsp and setting the clojure-lsp path in Calva to a batch file that runs the standalone jar. For Linux I've been manually downloading the linux-aarch64 build of clojure-lsp and setting clojure-lsp path in Calva. I was bored today so I worked on an update that: • uses platform and architecture to determine download url • downloads clojure-lsp-standalone.jar version if platform/arch doesn't match an available native build • if the clojure-lsp path is a JAR file, runs it using system java So now for me on Windows Calva downloads and runs the standalone jar using the windows-arm64 java and on Linux downloads the native linux-aarch64 build. I think this might also be useful for people using M1 Macs but can't test that myself. I was looking at the issues and it seems most relevant to #1590 and #1598 for a PR, but wasn't sure if you'd prefer that I open a new issue for it.

ericdallo22:06:50

Use the native binaries is the recommended and fastest way, if something is not working, we should try to fix it

chucklehead23:06:27

I don't think anything in this update contradicts that goal. There are platforms where no native binary exists, and it would be nice to use Calva without manual configuration and updating of clojure-lsp.

pez06:06:38

PR welcome, @U015879P2F8. Would be nice if we could close both those issues!

jvanderhyde23:06:05

Has anyone run into a problem like this? I am writing a macro that takes a binding vector as one of the parameters. When I use the macro, Calva (through the clj-kondo linter, I assume) flags the binding vector as an error. The code is valid Clojure and works as I intend, but the error flag is annoying. I would like it to work the same way macros like defn work.

(defmacro m [bindings coll action]
  `(map (fn ~bindings ~action) ~coll))

(m [x] [1 2 3] (println x))

seancorfield23:06:39

You need to tell clj-kondo how to lint your macro. {:lint-as {your.namespace/m clojure.core/let}} should be enough configuration for that.

seancorfield23:06:15

@U2426AJTW Have you done any configuration of clj-kondo yet? You should find .clj-kondo/config.edn in your project.

jvanderhyde01:06:53

Thank you very much. I had never tried configuring clj-kondo. In this case fn worked better than let. I should have called the parameter “params,” not “bindings,” because I’m not binding the symbols.

1