Clojurians Log v2

I do think it would be nice if certain parts of Calva could be made available as separate projects/libraries. However, this is a ton of work and not a priority at all, with everything else that is a priority. If we expose things, even if we say the API is subject to change, when we do change it and break others' workflows/projects, then we likely will hear about it. It's just not something we want to spend time worrying about or managing at this point in time. If you feel that you'd like to pull some things out of Calva for your own use, then please feel free to do so. Or, if you want to just keep a forked version of Calva with some customizations for yourself, you could do that too and keep it up to date with Calva's published branch. And for some things you desire that make you want these features exposed, there may be other solutions within Calva rather than exposing those features.

To echo your comment a bit, @eric.uitbeijerse- I started learning Clojure mid last year, then that project fell aside for the usual kinds of reasons, and now I'm having another crack at it. I was a slightly unlikely Calva user. I had once been an Emacs enthusiast, then switched to IntelliJ Idea & Appcode mainly because of the kinds of projects I was working on. I came to really love the Jetbrains platform, and had never thought much of VSCode, so Cursive was a natural fit. I tried it out and found it great (Colin Fleming has done a terrific job with it). I had a nagging feeling though that I would like to be able one day if I had time & ability to to contribute to the clojure IDE I was using. Given VSCode's reach and Calva being open source, I tried the VSCode/Calva solution for a while. Liking IntelliJ so much, I fully expected this to be a bit of a sacrifice. Well it wasn't. Sure, it had some bugs and missing features (what doesn't?), but it was generally pleasant to use and development was proceeding fast. Now coming back to learning Clojure after a few months, I find Calva development still going really strong. Anyway that's a huge preface (sorry if it's a tad indulgent) to thanking @pez and @brandon.ringe (the 2 names I've noticed - I'm sure there are others) for Calva. It must be a ton of work, which we get the benefit of. And VSCode's growing presence in the developer community makes Calva genuinely significant. Thanks! :spock-hand::skin-tone-2:

Thanks @cb.lists and @eric.uitbeijerse! It's a pleasure to be a part of providing a good Clojure experience in VS Code, and a pleasure to be part of this dev community.

is it possible to customize the command line invocation that Calva uses to jack-in?

I'd like to test if replacing powershell.exe with pwsh.exe would help with this issue, but it seems the only way to do so is to create a custom Calva build... is that right? https://github.com/BetterThanTomorrow/calva/issues/997

Not currently, @plexus. I have planned to make the windows executable configurable, because of the two versions of powershell. However, it is very easy to build Calva and experiment with this.

ok, thanks

At a computer now. Did you find where this is configured, @plexus? It’s here, at line 282. https://github.com/BetterThanTomorrow/calva/blob/05a9c08d3a9e16427e4a9f36a0b7691a2e8d4fd0/calva/nrepl/project-types.ts

I’m looking at how to make it configurable by the user. It doesn’t really fit in the custom repl connect sequences, where I first thought it would go. We could add a setting that is just calva.powerShellExecutable, but it is still a bit hard to discover. The whole #clj-on-windows story is complicated as hell… I’ve spent 100+ hours getting the quoting right, and it still fails on some machines. Maybe it is better to advice people to use WSL2 instead? I think that is what @seancorfield does when he helps people in #beginners.

@plexus if you have bb installed on Windows, you can also invoke bb.exe --clojure which doesn't need powershell (same as deps.exe basically)

I usually just cider-connect instead of cider-jack-in

Hmm. Maybe we should bundle bb.exe....

@pez or just the deps.clj uberjar, since you already use Java. I'm just not certain if people will appreciate Calva using a custom tools.deps runner ;)

I guess you could also re-implement deps.clj to CLJS and invoke it using node :P

PR to make it .cljc welcome ;)

That might actually not be a bad idea, because any JS based editor can then use this to invoke clojure

I think it may fall in that we do not get command line argument parsing that clojure gives us.

I mean as a means to jack in.

The command line argument parsing is implemented in deps.clj itself.

What deps.clj does is basically replace the bash/powershell with JVM Clojure, but porting it to Node CLJS would be a logical next step

but of course, feel free to bundle bb / deps.exe

just make people aware they are using a different non-official tool

non-official as in: not the official cognitect one

The jack-in story has two sides to it: 1. As a beginner with Clojure it gets a bit too much to also need to understand the concept of editor dependencies. 2. Cooperation in a project gets easier if Calva doesn't demand changes to the project dependencies. It seems to mostly work. 70% or so of the repl sessions are started using Calva jack-in. Windows keep giving us grief. I think that might be why Windows exists.

Cool. We can make it a project type. So at the gate you would make the choice (as a user). Also, I have plans for babashka in Calva, regardless. 😍

I've always used cider-connect, as I do not want my dev process to die when my editor restarts

Me too. We are adding a way to copy out the jack-in command line to the clipboard for this purpose.

That said Vscode restarting is very rare. I have uptimes of several months sometimes.

Huh, that's not my experience. Often when an extension is updated or disabled it wants a restart

And things can crash. I just don't find this reliable.

Things can crash. It is just not common.

Haha, optimist

📣 calva-extras.backspacePositional added to https://github.com/clyfe/calva-extras :calva:

Not ideal because it does not account for string context (https://clojurians.slack.com/archives/CBE668G4R/p1611839273287100 as Calva).

But does the job for me at the moment.

So, I can now launch it on windows using a bundled bb.exe. Makes quoting easier as well. Question is if it will be allowed on all machines… It is a bit hard to make it an option because the quoting is different and some other process settings as well…

@pez to make it easier, you don't have to invoke bb --clojure from the command line. you can do this from a script as well: script.clj:

(some-> (babashka.deps/clojure ["-Sdescribe"]) (babashka.process/check))

$ bb script.clj

if used from a script that is

so you could emit some temporary file that contains the invocation to not have to go through the command line

Thanks. The thought has crossed my mind. There’s a bit of a point with having it on the command line though. It makes it transparent what command is being issued and people can copy that and use it for starting their project in a Calva friendly way.

I've switched to using connect from all the Clojure editors I use (calva, cider, conjure) Using connect is much easier and far more flexible, especially with Clojure CLI tools. You don't need editor specific configuration to do anything interesting. Using a separate repl is really easy with some nice aliases in the user-level configuration for Clojure CLI tools. Using connect also make it easier to collaborate via a shared REPL on a remote server. And as others mentioned it's not tied to an editor, so I can use what ever tool is right for the task at hand. In some cases I have used a mixture of terminal UI and a couple of different editors to get things done effectively.

I think we are a lot of people who generally use connect instead of jack-in. It’s easy when you get an understanding for how things work, not so easy for beginners. The vast majority of Calva users use jack-in, and that is good and as it should be. We need to make that work as well as we possibly can.

I think jack-in harms beginners -- because they don't start out by understanding the REPL: they just see it as something their editor "does". I think we adopt "easy" approaches far too readily instead of sticking with "simple" and teaching beginners how things actually work.

I have yet to see a beginner harmed by this.

Does jack-in require a project context?

That is, can I just open a new file and jack-in to start a repl? Not at a computer right now to try it

I kinda agree with @seancorfield here

I was pretty confused for a while "$%?!? this jack-in thing ?!". The name is good for cider dev, less so for user. Better name "repl-in".

@alexmiller currently it does require a project context. But there is no particular reason it does. We should fix it. Please chime in on this issue: https://github.com/BetterThanTomorrow/calva/issues/855

I know you do. And I think you are both wrong. 😃

What a terrible world it would be if we all agreed on everything... 🙂

Indeed. 😃

For the record, even if I am working hard with getting jack-in right, the connect story is also important and never forgotten.

My experience is that I used to spend 90% of Calva support with helping people to get the editor dependencies right, constantly worried about all those who gave up without asking for support. Since releasing jack-in I instead spend the support time with helping people using their connected REPL. It is so much better.

Done

I don’t think jack-in vs connect is inherently problematic. A beginner needs to understand they are “connecting to Clojure” but whether that’s in process or out of process is not really much different. Imo not needing to understand project context is more important (at first). We (Rich and others) have been working through better getting started directions for the Clojure site and I think a focus of that has been getting people to “editor with connected repl” first (not repl only - where nothing is persistent, that’s a dead end), and not project context (not needed, can be additive to what you’re doing later)

Jackin is nice in being able to keep you “in the tool” and defer needing to understand the details. I like that Calva is explicit about seeing the command and what’s happening there even if you’re launching in process

That at least sets the stage for learning more about how that works

I agree. It's awesome too that there's an effort by you and Rich and the others to improve the getting started directions for the Clojure site.

Now we are talking!

To make an analogy (hopefully not a terrible one), learning to drive with an automatic transmission doesn't necessarily make it harder for you to learn to drive with a manual transmission.

@brandon.ringe Pretty much every tutorial starts with a plain REPL started from the command-line and has beginners typing directly into the console REPL -- so most users have the "start a REPL" experience under their belt before they try moving to a connected editor. But "typing directly into the console REPL" is also problematic in its own ways. I think both jack-in and type-in-console are bad for beginners. Overall, we do a terrible job of getting beginners up to speed with a "good" REPL-based workflow.

The problem with jack-in -- based on my observations over the years watching beginners here and elsewhere -- is that it "magics over" how the editor/REPL integration actually works -- and gives an (incorrect) impression that editor integration and command-line REPL are somehow two completely separate things. And when they run into problems with jack-in, especially around figuring out how to persuade the editor to start the REPL exactly like they do from the command-line, it becomes a very editor-specific and somewhat archaic process to debug and fix.

And the weird thing (from my p.o.v.) is that historically we used lein repl to get started at the command-line and it already starts a network REPL that most editors could connect to so we've missed the opportunity to simplify the overall process -- and decomplect the editor/REPL integration.

@brandon.ringe In England, if you pass your test on an automatic transmission, you are not licensed to drive a manual transmission -- or at least that used to be the case. You have to take your test on a manual transmission in order to drive a manual (and you are also licensed to drive an automatic at that point).

I agree with you on some of this. Though, I think the issue you speak of around jack-in isn't necessarily a problem with jack-in but with either how it's implemented or the supporting docs. We can provide a tool for making getting started easier while also educating them on what's happening, and how to perform the process themselves. Hopefully @alexmiller and others publish improved getting started material on http://clojure.org as he mentioned. I'm looking forward to that.

(and I can't resist seeing automatic transmission = easy vs manual transmission = simple 🙂 )

I agree with you with the easy vs simple argument, but we don't have to see easy as always bad. That makes sense to me, the separate driving tests, but I don't think it detracts from my previous statement.

(just to be clear: if you learn on manual and take a test on manual, you're licensed for both manual and automatic; if you learn/test on automatic, you can't drive manual until you've also taken a test on manual -- not sure if that was how you read it, given your "separate driving tests" comment?)

And, yes, our goal should be to make the simple path also be easy. Or easy enough.

I see, but I think it's good to give the user (driver) a choice like that.

I think the concept of jack-in is what makes the simple path easy, but like I mentioned before, how that's done is what's important.

Editor integrations requiring nREPL is part of why jack-in appeared and why it is "easy" -- especially when you switch from lein to the Clojure CLI. Another reason I think our reliance on nREPL is unfortunate by this point. Side-loading of nREPL into a plain Socket REPL will help, when that happens.

we have come to see "Pretty much every tutorial starts with a plain REPL started from the command-line" as bad and we should stop doing that

because there's nowhere to go from there. you're backing to starting over to get into an editor / files / projects /repl connected editor / structural editing

we should just be getting them to repl-connected editor and start in a file - everything from there is additive. (and just never type directly into a repl)

I find Clover with it's absence of even having a repl that takes stdin to be actually good in this regard - you have to eval from your editor if you want to do anything

@alexmiller Agreed. I keep repeating Stu's comment about "I'm always baffled when I see people typing into their REPL" (or whatever his exact wording was).

Yes, I also like Chlorine/Clover for that: no more typing into a REPL!

and that startup process you see with Clover/Calva could be even easier if you could easily launch a non-project REPL and jack-in to it

I see - so this more so can be boiled down to an issue with reliance on nREPL, at least in your mind. I know others might echo that sentiment, and I can't say I have a strong stance on that one way or the other. I'm much newer to Clojure than yourself though. 😄

But the elephant in the room at this point is nREPL: nearly all editors need it to talk to a REPL and while lein repl and boot repl start nREPL servers, the Clojure CLI doesn't.

(and jack-in kind of papers over that by adding nREPL as a dependency behind the scenes)

well I have my own preferences there, but I think that is not important to a beginner (it's important to implementors of course :)

ideally I want any editor to support both, even if the experience is not the same

If we'd had the Socket REPL built into Clojure from day one, I think we might never have seen nREPL, and all editors would happily connect to a plain Socket REPL and perhaps side-load some affordances (such as unrepl/unravel). But... at this point we'll never know 🙂

I think it's highly unlikely that we're going to recommend any getting started path on http://clojure.org that doesn't work with clojure cli

Yup, definitely. Clover/Chlorine support a wide variety of REPLs now -- including nREPL -- but also as simple as lumo etc.

I've been using Clover some this week too and I do like the structure of that

So, I created a feature request about helping people with those first Clojure steps. https://github.com/BetterThanTomorrow/calva/issues/1003 Please chime in, Calva friends.

but I realize all that stuff is hard from editor impl pov (I'm glad I'm not working on it and can just make unreasonable requests of others :)

props to my oss maintainer brethren

It seems that the main things people want from editor integration that Socket REPL/pREPL don't provide out of the box are: 1) a way to interrupt long-running evaluation and 2) a way to manage evaluations that produce infinite (or very large) results. That's my perception, mostly based on talking to a few of the integration folks, so I don't know if that's the entire story.

I have to admit I also like that about Clover, the lack of ability to type into the "repl" window. I think part of the reason @pez has kept this is related back to the getting started tutorials. If we didn't allow that then beginners might be confused, ask questions, request we add it, etc., because they got started this way and may think that's the "repl-driven" experience people discuss (another issue with tutorials). I think in time it could be done away with though, and this would make maintenance of the repl window a bit easier too.

when I work (in Cursive primarily) I almost entirely "work" from my editor, but I do use the repl window to do a few things (mostly (pst *e) because I leave the repl window sitting in user with clojure.repl referred).

There are different kinds of beginners - really there's very little in common between (say) a beginner-to-programming and a java-programmer-beginner-to-lisps. As an experienced developer starting with clojure I haven't found jack-in confusing. I naturally ignored the 'type into the REPL' instructions and started with a blank slate project in a connected editor. Over time as I've figured out the tooling (somewhat) I've backpedaled to using a manually-started REPL and then connecting. But jack-in was very handy to get a frictionless start with.

beginner-to-programming is a special case and not one that we as a Clojure core team is trying to satisfy. I think there is a great deal of commonality between new-to-a-lisp though

The Calva REPL window is really just an editor (vs code speak for what Emacs calls a buffer), just like any other editor. It would be a bit strange if it didn’t allow evaluations just like the other files. When I first created it, I tried not giving it a prompt. But VS Code wouldn’t really let me. I needed a way to display the current namespace… Anyway, we try to encourage people to stay in their files. We’re Stu’ed like that. 😃

I can quite see a total beginner not being a major case in point @alexmiller. I was assuming @seancorfield’s comments about the 'magic' of jack-in inhibiting gaining understanding of the real tooling story was about complete beginners. It's hard to imagine a reasonably experienced programmer falling into that?

It's not hard for me to imagine based on what I've seen here (and in other forums) over the years 🙂