Clojurians Log v2

Dear Calva friends. Now I need help testing a rather central refactoring of the jack-in feature. This VSIX should work launching your projects, just like before if I haven’t messed something up. I’ve tested it on Mac and Windows on a lot of different test projects that I have. But even if I have quite a few of those, I still could have missed something. The whole reason for making the changes is for windows users with deps.edn projects to be able to jack-in more reliably. This VSIX bundles babashka, and uses it for jack-in of these projects. I’d especially appreciate @plexus’s help to see if this works better than the currently released Calva. https://10624-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.157-1000-deps-launcher-setting-d01ecb63.vsix

Please consider testing and reporting your findings (wether good or bad) on the PR: https://github.com/BetterThanTomorrow/calva/pull/1004

I've been implementing a Clojure editor plugin from scratch for the past nine months or so. I would love to support plain socket REPL or prepl, but I ended up going with nREPL for these reasons: - nREPL has structured input and structured output. Socket REPL has neither, prepl only has structured output. - Crucially, nREPL is easily extensible. Things like symbol lookup and auto-completion support are much easier to implement. Also, since it supports sideloading, there's no need for a jack-in type of thing any more since editors no longer need to presume that the server is running a certain set of middleware. I just run clojure -M:nrepl, connect to the server from my editor, and off we go. - nREPL uses Bencode by default. Implementing a streaming Bencode encoder/decoder from scratch is trivial. Supporting EDN would take a lot more work (a subset of EDN might suffice, though). - nREPL has interruptible evaluations. I agree that the capability to "upgrade" a socket REPL or a prepl connection into an nREPL connection would be really cool, though.

My point is that even though the Socket REPL and prepl exist, there are still good reasons to go with nREPL.

I know you guys probably already know this, but since nREPL now supports sideloading middleware, you could have Calva sideload the middleware it needs after connecting to the nREPL server. I've been doing that in my plugin for a while now and I really like how it works.

It's going to be a bit of work, though, of course. 🙂

(It'l also affect the size of the deliverable, because you'd need to vendor in all the middleware you want to load.)

I've looked into it just a bit. Totally cool feature. But, yeah, quite some work. What's your use case?

Well, I wanted an editor plugin that can connect to a "plain" nREPL server. (Ideally, it'd be a socket REPL or prepl server, but that's not viable for a bunch of reasons.) Basically, it works like this: - User starts an nREPL server from the command line (by running the equivalent of clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "RELEASE"}}}' -M -m nrepl.cmdline) - User connects to the server from the editor. The editor plugin doesn't know anything about how to start an nREPL server. - The editor plugin sideloads the middleware it needs (e.g. for clojure.test integration) - Off we go. For any subsequent connections, the middleware is already there, so no need to load it again or anything.

nREPL is wonderful. Super smart design enabling a tool smith to super quick get down to deliver user value.

It's great, except for ClojureScript. 😛

Piggieback takes care of a lot of that for me. And shadow-cljs comes with its own middleware for it. It's super smooth to work with ClojureScript in Calva.

Linux: • plain deps ok • plain lein ok • deps + fig main ok (that's all I have)

Well, we already discussed this a bit earlier elsewhere, but to me, even with Piggieback or shadow-cljs, the ClojureScript experience is a far cry from the Clojure experience. But this is somewhat of an expansive topic. 🙂 Ideally, I'd want ClojureScript evaluation to "just work", like Clojure does. If I have a ClojureScript view open in my editor, the editor should send my evaluations to ClojureScript automatically, instead of having to switch between ClojureScript and Clojure REPLs manually. clojure.test integration should work. The auto-completion and symbol lookup features built into nREPL should also work with ClojureScript. And so on.

> The load-file nREPL operation will only load the state of files from disk. This is in contrast to "regular" Clojure nREPL operation, where the current state of a file's buffer is loaded without regard to its saved state on disk. Also, that is a big problem with Piggieback, in my view.

Is there a way to avoid downloading the 69mb bb.exe binary on linux?

A post-install hook that downloads it off github on win only?

Maybe. I somehow doubt it.

So for me ClojureScript evaluation just works. With cljs files in the CLJS REPL, with cljc files I have need to toggle if the cljc repl isn’t the cljs one, but that is quite rare, because reasons. auto-complete works, symol lookup too, even JavaScript symbols. Also code navigation and signature help and about everything. The only whole thing lacking is the test runner. But I get by with just evaluating things like (cljs,test/run-test) . Haven’t even noticed that load-file difference, but it is probably my workflow. I seldom save files, so evaluate them form by form after having loaded them. (From disk apparently).

"Our mileages may vary" is probably a good summary here. 🙂

Haha. Have you tried it in Calva?

Not yet. I've no doubt things work better in Calva, but I don't (want to) rely on the CIDER middleware stack. Ideally, I'd like ClojureScript support be better out of the box. I'll give it a try, though -- I'm quite curious about how switching between ClojureScript and Clojure evaluation works.

Calva keeps two REPL sessions open. From cljs files the cljs repl is used. That’s the full story. 😃

Calva friends. Here’s another version of the Windows + deps.edn jack-in fixes: https://10629-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.157-1000-deps-launcher-setting-014dc881.vsix This one bundles deps.clj.jar instead of bb.exe. Trading 65 megabytes for a few seconds of startup time. Please help test it even if you are not using Windows, or not using deps.edn on Windows.

Hello. Long time ago Calva-fmt was a separate plugin and can be installed independently from Calva. But nowadays they both are merged into one. Can you suggest me standalone formatter for Clojure in VSCode, which can format inside the current block only and by pressing customisable hotkey or Tab?

Works fine on manjaro (arch) linux, using deps.edn

I think the easiest way here would be to compile calva-fmt to a VSIX and install that in vscode. https://github.com/BetterThanTomorrow/calva-fmt See the wiki tab for instructions on how to compile it. You’ll need vsce to package the vsix (`npm install-g vsce` will do it).

Found out, that build version 0.0.37 (and below) works standalon. Thanks for such nice software!

799 stars in two years. That is pretty amazing. https://starcharts.herokuapp.com/betterthantomorrow/calva

👍

Hey @pez and @brandon.ringe you may want to take a look on this later 🙂

I was talking with @brandon.ringe that if GraalVM binary really works, Calva would need to download the correct binary checking the OS

Awesome stuff! Great work 🎉

Calva version 2.0.157 is released! 🎉 :calva: • https://github.com/BetterThanTomorrow/calva/pull/995 • https://github.com/BetterThanTomorrow/calva/issues/950 • https://github.com/BetterThanTomorrow/calva/issues/986 • Fix: https://github.com/BetterThanTomorrow/calva/issues/1000

Here we go!

Thanks 😄