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. 😃

I'm not sure it's quite that simple. 😛 I think it might be that Calva requires that your project is set up in a certain way. I just tried it and nothing happens if I try evaluating from a ClojureScript buffer. Calva also knows about Figwheel, shadow-cljs etc., whereas I don't want my editor plugin to have to know anything about the build tool du jour. Anyway, this topic is quite involved, and I don't want to take up more of your time with my blathering. 🙂

Thanks@pez, Stupidly I’d tried that earlier but with source-paths rather than extra-paths. With extra-paths It no longer barfs about the user namespace, but I’m not seeing the println anywhere. And fair point - my fig alias is now misnamed as its :main-opts moved elsewhere.

I love spending time on talking about these things. 😃 Huge topic. For the record. though. Calvas repl session handling, including cljc toggle, was there long before Calva new anything about the build tool du jour. Pretty sure it is that simple. Haha.

You’re welcome. I’m glad I got to try that out and learn a bit about these settings. As for the printout. Don’t recall where I found them. Maybe in the Jack-in terminal? Maybe in the (wrongly named) Output channel Calva Connection Log…

I believe you. In all likelihood, I'm just doing something wrong, not Calva. Wasn't trying to say that Calva is doing something wrong here. :) I'm not quite sure we're talking about exactly the same thing, though, and I don't know how to use Calva, so... Anyway, I guess my point is that with Clojure, I can just start an nREPL server in the Terminal. In my editor plugin, there is only one option: connect. Once the user does that, they're off. What I'd like to do is that if the user then opens a ClojureScript view, everything would work exactly as well as with Clojure — or as close as possible. Obviously, there are differences we can't really do away with. For example, the user must have a ClojureScript dependency, and they must select the JavaScript runtime environment (Node.js, browser, etc.) at some point. Calva might might work like that already, but there's just something I'm missing. I'll need to look into it at some point, when I'm a bit less busy with work.

I don't have a clear picture in my head about the whole thing anyway, since the ClojureScript world is significantly messier than the JVM world (it seems to me, anyway), so it all's going to take some thinking.

Yes, it is messier. What Calva does is something like so: 1. Create the Clojure REPL session 2. Clone it 3. Promote the clone to a ClojureScript REPL Promoting it is different between tools and also people create their own CLJS repls. What Calva “knows” about these tools is actually just convenience configuration. The users can create their own. We call it Connect Sequences. See https://calva.io/connect-sequences/ where you fid some example configurations at the bottom.

Thank you! I'll definitely take a look. :thumbsup::skin-tone-2:

It can be made a bit simpler than that, I think. Calva takes a bit of a “holding hand” approach- 😃

@brandon.ringe did quite a lot of work to download the clojure-lsp jar dynamically, but had to retract because it made the setup too brittle. Or maybe I remember wrongly what that work was about.

Agree. I felt almost the same when I first knew about Jack-In. I get used to run a repl starting in a separate terminal. But now I often use Jack-In.

Well, if we move to using a graalvm compiled binary, it may be best to move back to that. It did require handling if the download fails, checking if the file exists, etc., and since everyone needed it, it seemed wise to just package it with Calva. But with graalvm binaries we need to run the appropriate one for the OS, and I think going back to that download strategy will be wise. (Discussed this with Eric. Lsp-mode downloads clojure-lsp I think). So maybe it would be wise to do with bb too :man-shrugging:

We can have that as a todo if we start bundling more bb:s. 😃

Incremental steps are good, indeed ✅

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 😄