Clojurians Log v2

Happy that you are putting this to some testing, Sean! I don’t think we support auto-starting more than one connect sequence yet. My un-educated guess is that it shouldn’t be too hard to support that. But you should definitely be able to have your regular repl auto-connected and then manually connect the development bb repl targeting its own directory tree. primary and secondary refers to when the same repl connection supports a secondary repl. Today this only pertains to ClojureScript repls spawned off of Clojure repls, so it is not relevant for your setup. Your development connect sequence should specify: • replSessionFilePatterns a map, in there specify primary , and patterns. Pattersn can be a single string, so you probably can get away with using "development/**/*.{clj,edn}" . If you want this repl to also help with the default bb/ and scripts path that the built-in babashka sequence handles, then use an array of patterns. (Or glob in a single string). There are some more fancy stuff you can do here, but it doesn’t sound like you need that for this project. • defaultPort: You may not need to, maybe it inherits default port from the babashka projectType, but anyway, if it doesn’t, then specify the port. • Optionally replSessionNames, if you want something else than bb, specify that at the primary key of this map. Let me know how you fare, please!

Okay, if that explanation was in the docs, I'd have figured it out 🙂

Yeah, what I've gone for is to keep my old workflow / connect sequences and have it auto-reconnect for the main (JVM Clojure) REPL since that is otherwise slow to start and I want to retain state across window reloads, and then I jack-in to Babashka when I'm working in the development tree. I think part of my frustration comes with not being able to avoid the project root selection menu unless I have auto select enabled, and then I can only connect to that REPL because it suppresses both the project root menu and the project type menu. Perhaps a solution to that would be a variant of connect that circumvented the auto select, and offered just the connect sequence / project type menu? But I really want a way to suppress the project root menu without being forced to auto select...

I've ended up with this in my work project settings.json (unchanged from my previous approach):

"calva.replConnectSequences": [
    {
      "name": "World Singles Backend (Connect)",
      "projectType": "deps.edn",
      "cljsType": "none",
      "autoSelectForConnect": true,
      "projectRootPath": ["."]
    }
  ],

"calva.replConnectSequences": [
      {
        "name": "Loaded deps.edn Jack-In",
        "projectType": "deps.edn",
        "cljsType": "none",
        "autoSelectForJackIn": false,
        "projectRootPath": ["."],
        "menuSelections": {
          "cljAliases": ["1.12", "dev/repl", "portal", "test", "no-main"]
        }
      },
      {
        "name": "Assumed deps.edn Connect",
        "projectType": "deps.edn",
        "autoSelectForConnect": true
      }
    ],

I'll have a think about possible ways to improve this. I think having a per-project calva.projectRootPath (outside of the connect sequences) that suppressed the project root menu would alleviate most of my current frustration. And perhaps a way to flag a (user-level) connect sequence as a "fallback", so it is only considered if there are no project-level connect sequences. Thoughts on those two options?

I’m not sure I am completely following, but it sounds like there may be a bug around how project root is handled (wouldn’t surprise me, this stateful thing has caused a lot of troubles in the past and we have never really got in full control of it). And then a second bug in how the user level sequence interferes. I’d like to understand if there are bug there and if so fix them, and then we can definitely discuss further refinements. (An out-of-sequence project root sound pretty good to me, btw.)

All my connect sequences specify "projectRootPath": ["."] but I'm in a Polylith project so there are hundreds of deps.edn files -- and without auto select enabled, Calva always asks me for a project root when connecting.

The out-of-sequence projectRootPath would help in Polylith projects. In other multirepos a setting to suppress the project root menu, assigning the closes deps.edn match could make sense.

I think part of the conceptual disconnect here is that a REPL connect sequence has a single projectType? I can only have one connect sequence marked as autoSelectForConnect tho', right? And if I don't have that autoSelectForConnect set, then I get prompted for a project root (even tho' I have projectRootPath set in all my connect sequences!) before I get prompted for which connect sequence to use 😞

I also don't understand what primary and secondary are for a connect sequence, since it can only have one type of REPL?

From the student: "My MacBook is running on the latest update: macOS Sonoma 14.8.3. I tried downloading VS Code Insiders and running the specific Calva command (create a mini Clojure project), but I get the same error messages. Also, I downloaded the deps.edn mini project you posted on Moodle, and that works." So, total mystery to me what's going on, but since the student can use the mini project I posted it's not a huge problem for us at this point.

Extend my gratitude to your student for investigating it so deeply and trying all the things. We download things from GitHub which has some special networking behaviors. E.g. the Simple Browser in VS Code doesn’t work on pages from GitHub, while it works for virtually all other sites on the planet. The solution may be to host the template projects at some other place.

(that won't help with clojure-lsp tho' nor, I suspect, deps.clj if that needs to download things?)

deps.clj, like clojure, downloads from an environment separate from VS Code, so I don’t think it has the problems. Downloading deps.clj itself probably runs in to the problem, but we don’t see it, because Calva bundles the latest version that existed when the Calva release was packaged. We used to do this for clojure-lsp too, but the .jar build is too heavy on many machines, so we changed to downloading the binary at runtime instead. But clojure-lsp is not crucial for Calva’s operation, even while it is providing many very nice things.

Ah, good to know. Weird that regular downloads from GH work for tools like deps.clj but not for VS Code itself. Maybe it's a thing in the latest macOS then?

Sonoma is pretty old. But, yes, it could be some combo with OS and GitHub and VS Code. The certificate stuff is pretty high up in the OSI stack, I imagine, so VS Code/Electrone/Node could be implementing it and the JVM too.

Truly horrible. Interesting that it is both clojure-lsp and the project templates. I think both are being downloaded from GitHub, so it could be something with the TSL handshake to GitHub in particular that glitches. The hotspot test rules out a lot of things, I imagine. The screenshot is from VS Code proper, so it was never a Cursor thing, like could be suspected with the other, similar, report. In that case it worked from VS Code on the same machine where Cursor failed, so it could also be that something gets cached client side that short circuits the whole connection attempt. Very hard to debug without being able to reproduce it. Your student could try with downloading VS Code Insiders and using that instead. There is a slight possibility things will work then, even if it is a shot in dark.

I wonder if the student has some network proxy set up on their computer? Are they on Mac/Windows? Are they using WSL on the latter? What versions of each? (I know you can't tell this until you get on the student's machine -- or get them to relay all of this stuff)

FYI the student 1) asked me to thank you for looking into this! and 2) reports that the same behavior persists after updating to macOS Tahoe 26.2. Since my shared mini-project seems to behave properly, we can proceed, but FWIW something still seems to be amiss.

Thanks! I assume the student was on the campus network, but I'll check, suggest that they try a phone hotspot or something else if they can, and if it really is a problem with the campus network then I'll ping our IT people about it. I haven't actually tried doing this on the campus network myself in a while, and I'm not there at the moment to try...

Here's a report from the student after trying a hotspot: > Yes, I tried using my phone's hotspot, but the issue persists. I also have the same issue with downloading the Clojure-lsp server. But in the meantime, I can evaluate and see the results of Clojure expressions in the file Leiningen makes. > This is the error that I get whenever I use the command line (I probably should've sent this earlier)

I ran into a similar issue a while back with one of my computers and it turned out my ISP was hijacking DNS to perform "bad website filtering". I ended up having to configure a DNS proxy to get around it. I don't know why it only affected one computer (out of several here). If the student is on a laptop, maybe they can try while connected to a completely different network, just to rule out ISP issues?

We had a similar report some month ago, downloading clojure-lsp. On that computer Cursor had the problem, but not VS Code, iirc.

https://clojurians.slack.com/archives/CBE668G4R/p1765300767601739