Clojurians Log v2

When I start Calva in that project, with Docker up, I get this warning:

LSP classpath lookup failed when running `/usr/bin/lein with-profile +test,+dev classpath`. Some features may not work properly if ignored. Error: OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release. Retrieving lein-clr/lein-clr/0.2.0/lein-clr-0.2.0.pom from clojars Retrieving lein-clr/lein-clr/0.2.0/lein-clr-0.2.0.jar from clojars Retrieving org/clojure/clr/tools.nrepl/0.1.0-alpha1/tools.nrepl-0.1.0-alpha1.pom from clojars

Other than that, it all worked as advertised. I jacked in. I evaluated some code. Works just like the JVM 🙂

Thanks for the help, @seancorfield ! I think there are some issues mentioned recently in this channel about lsp.

I'm very excited by this. Both the docker example and the report on Calva/clr.tools.nrepl. I still have to do the work to hook up to Calva, but it looks now more like a victory lap.

Tried the instructions, get a docker error. On the command line:

PS C:\work\clojure\clojure-clr-mini> docker-compose exec -it dotnet-clojure /app/docker/start-repl.sh
service "dotnet-clojure" is not running container #1

2023-05-11 00:00:09 clojure-clr-mini-dotnet-clojure-1  | exec /app/docker/entrypoint.sh: no such file or directory

Sounds like it didn't mount the filesystem at startup? Missing -v option?

Although I would have expected that to be taken care of by the yml file config... I ran the command in wsl not Windows tho' so maybe the config isn't portable...

I'll jump into WSL and try it. Tomorrow. Thanks.

I was able to get the Docker stuff running on Windows (PS). But I can't get Calva to jack-in on Windows -- I see this error in the Window log:

2023-05-10 22:34:52.443 [error] Unable to resolve filesystem provider with relative file path 'c:\Users\seanc\clojure\clojure-clr-mini/.calva/output-window': Error: Unable to resolve filesystem provider with relative file path 'c:\Users\seanc\clojure\clojure-clr-mini/.calva/output-window'
    at e.ExtHostCommands.h (c:\Users\seanc\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:98:125669)

If I try to connect to the running nREPL server instead of jacking in, I get this error:

2023-05-10 22:38:59.237 [error] [Extension Host] Error writing to results doc: Error: cannot open c:%5CUsers%5Cseanc%5Cclojure%5Cclojure-clr-mini/.calva/output-window/output.calva-repl. Detail: Unable to resolve resource c:%5CUsers%5Cseanc%5Cclojure%5Cclojure-clr-mini/.calva/output-window/output.calva-repl
    at e.MainThreadDocuments.$tryOpenDocument ()

I really should spend some time with Calva on Windows. Though that looks unrelated to the REPL connection error.

The docker-compose exec -it dotnet-clojure /app/docker/start-repl.sh command works for you, @seancorfield?

Yes, just ran that on PowerShell and it displayed the following and waited:

Started nREPL server at localhost:6667

And it creates the .nrepl-port file in the docker folder.

Jacking-in on WSL works. And I can tell it's really .NET because I can eval (System.Environment/GetEnvironmentVariable "HOME") => "/root" 🙂

Happy to try stuff out to debug on Windows (although it's "bedtime" here) @pez

But connecting to that repl doesn’t work?

Doing it all on WSL2 (Ubuntu) works. Doing it all on Windows (Powershell) fails at the jack-in/connect step, with the error about the incorrect path.

I believe /.calva/output-window should be \.calva\output-window when run on Windows but I don't know how Calva builds that path?

I assume it's this code: https://github.com/BetterThanTomorrow/calva/blob/published/src/results-output/results-doc.ts#L49-L53

Which sure looks like it should work -- unless my VS Code thinks it is on Linux instead of Windows for some reason?

Can you connect to some other REPL, like a minimal deps project?

I'll have to create a Windows project to test that... just a sec...

It seems to just hang on Launching REPL using deps.edn

Hmm,

pushd c:\Users\seanc\clojure\minimal & java -jar ".calva\deps.clj.jar" -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""1.0.0""},cider/cider-nrepl {:mvn/version,""0.28.5""}}}" -M -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]" & popd
Clojure tools not yet in expected location: C:\Users\seanc\.deps.clj\1.11.1.1273\ClojureTools\clojure-tools-1.11.1.1273.jar
Downloading  to C:\Users\seanc\.deps.clj\1.11.1.1273\ClojureTools\tools.zip
Unzipping C:\Users\seanc\.deps.clj\1.11.1.1273\ClojureTools\tools.zip ...
Successfully installed clojure tools!
Error building classpath. Error reading edn. Map literal must contain an even number of forms (c:\Users\seanc\clojure\minimal\deps.edn)
Jack-in process exited. Status: 1

I think that's a shell quoting issue?

Ah, it doesn't like a deps.edn file that contains {} -- which ought to work...

Hmm, it doesn't seem to matter what is in my deps.edn file -- it doesn't like it

Wow, that’s strange.

I updated it to contain {:deps {org.clojure/clojure {:mvn/version "1.10.0"}}} and now it complains: Error building classpath. Error reading edn. Invalid file, expected edn to contain a single value. (c:\Users\seanc\clojure\minimal\deps.edn)

Does the Getting Started REPL work?

Yes.

So deps.clj actually works. It’s like the jack-in is happening from the wrong directory.

Well, it's pointing at the "correct" deps.edn file but not liking it...

Ugh! Wonky file encoding.

It was UTF-16 LE and that broke things. OK, let me get Docker stuff back up...

Back to the CLR project (now that we've confirmed Calva works in a minimal project!)

That’s a big relief. There are a lot of Windows Calva users out there.

Nope, that fails because of this error

2023-05-10 23:30:11.010 [error] Unable to resolve filesystem provider with relative file path 'c:\Users\seanc\clojure\clojure-clr-mini/.calva/output-window': Error: Unable to resolve filesystem provider with relative file path 'c:\Users\seanc\clojure\clojure-clr-mini/.calva/output-window'
    at e.ExtHostCommands.h (c:\Users\seanc\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:98:125669)

In that minimal project. Do you see that same error, maybe?

I’m wondering if that is the real problem…

The minimal project works.

i.e., a minimal deps.edn project I created.

Yes, that’s why I wonder about the error message 😃

The CLR project does not.

Can you connect some other nrepl client to the server started in the CLR project?

Something like:

clojure -Sdeps '{:deps {reply/reply {:mvn/version "0.5.1"}}}' -M -m reply.main --attach 6667

That looks like a linux command, not Windows?

And I don't have nREPL up in the CLR docker because Calva cannot jack-in

I can try to manually start that nREPL on the Windows side...

I’m a Windows noob. Yes probably needs to look different on Windows.

That docker compose exec command seemed to start the nREPL server.

I’m thinking that maybe it isn’t exposed correctly on 127.0.0.1:6667. So that’s why reply might help in testing that.

OK, if I manually start that repl in a powershell window, I can connect to it from that REPLy command (from linux):

-> clojure -Sdeps '{:deps {reply/reply {:mvn/version "0.5.1"}}}' -M -m reply.main --attach 6667
: Can't set!: *print-length* from non-binding thread user
clojure.lang.TypeNotFoundException: Unable to find type: nrepl.core user

Error loading namespace; falling back to user
#object[Namespace 0x86c47 "user"]nil
user=> WARNING: cat already refers to: #'clojure.core/cat in namespace: net.cgrand.parsley.fold, being replaced by: #'net.cgrand.parsley.fold/cat

And to confirm it's really the CLR repl:

user=> (System.Environment/GetEnvironmentVariable "HOME")
"/root"
user=>

I'm pretty sure the problem is the / in those file paths.

The very first thing Calva tries to do when you jack-in is create that file -- before it even runs any commands -- and that creation fails so jack-in fails.

Makes sense. Though why would it differ between the minimal project and this one…

I don't know how VS Code figures out what separator to use...

Hmmm, yes, actually there is a difference, in that the connect sequence pretends that the mini-project is a Leiningen project…

Might be that we construct some path differently then. I’ll have to check.

If I change the auto connect settings to false and jack-in and select the ClojureCLR Starter, it fails like this:

2023-05-10 23:55:23.251 [error] spawn docker compose exec -it dotnet-clojure /app/docker/start-repl.sh ENOENT: Error: spawn docker compose exec -it dotnet-clojure /app/docker/start-repl.sh ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:285:19)
    at onErrorNT (node:internal/child_process:497:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

(I tried with the original docker-compose but that failed too, so I wondered if it wanted docker compose but apparently not)

What a boring error message…

Done. Thanks again!

The example project is now updated for the increased Dx enabled by the fixes in latest Calva: https://clojurians.slack.com/archives/CBE668G4R/p1683968626977079 It should support the no-prompts jack-in, as well as REPL auto-connect-on-worskpace open. Please scrutinize the README and see that it makes sense. @dmiller you will need to update the workspace settings. Pulling the changes is enough, but you can also just paste the new settings into .vscode/settings.json in the project. Please let me know how you fare. 🙏

Smooth as butter! I reset the repo and did git pull. I built & started the Docker setup. I started VS Code, reloaded to get the new Calva, opened hello.cljr and jacked in -- all worked as expected! Nice work @pez!!!

That’s super nice to hear, @seancorfield! Did you also try to close the workspace and open it again? It should reconnect the REPL automatically.

I'd shutdown Docker, so it left the .nrepl-port file behind -- and Calva tried to connect to port 6667 and hung up. I restarted Docker and jacked-in and that worked. Closing and reopening VS Code now...

...and, yes, that worked with Docker still running. So maybe you need some cleanup code to remove .nrepl-port if Docker is shutdown?

I think your entrypoint.sh script could catch the SIGKILL and rm the file?

I haven't tried it, but this seems to suggest you can... https://stackoverflow.com/questions/42564155/gracefully-stopping-docker-containers

If you shut down the Docker container the port file should be removed. Does that not happen for you?

Nope. Otherwise that would have worked above 🙂

Oh, I missed that comment. Strange…

I tried adding trap to entrypoint.sh with a handler to rm /app/docker/.nrepl-port but that didn't seem to work either (for SIGTERM and SIGKILL)

I do that in the start-repl.sh script already. And it seemed to work when I tried it.

Hmmm, no that’s not what I tried. I hit ctrl+c on the docker exec command. That removes the file. Seems it doesn’t get the signal when the container is shut down.

Right, if you jack-in, there's no exec command to interrupt.

Ah, maybe SIGINT -- let me try that...

Well, killing the jack-in process should be that. But it doesn’t do it either.

I tried adding the following to the YAML file:

stop_signal: SIGINT
    stop_grace_period: 30s

term_handler() {
  echo "Stopping..."
  rm -rf /app/docker/.nrepl-port
  exit 0
}

trap 'term_handler' SIGTERM
trap 'term_handler' SIGKILL
trap 'term_handler' SIGINT
trap 'term_handler' EXIT

There might be some clues here: https://web.archive.org/web/20220318211951/https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/

Until fixed a note in the README will have to do. 😃

I'll testify to the "smooth as butter" re connecting. It is amazing to see suggested completions after having typed (System/ 🙂 And for everyone's reference

(Environment/TickCount)  => 203604339

What’s the significance of the TickCount?

Nothing in particular. I just wanted to evaluate (System/<something>) to provie I was talking to ClojureCLR.

(System.Environment/GetEnvironmentVariable "HOME") instead of (System/getenv "HOME") 🙂

A great way to prove you are running the CLR on not-WIndows. 🙂

(Environment/GetFolderPath (System.Environment+SpecialFolder/UserProfile))

Dot Net is very verbose 🙂

> to prove I was talking to ClojureCLR 😃 I do this often with ClojureScript (js/alert).

https://github.com/microsoft/vscode/issues/109209

Looks similar...

And https://github.com/BetterThanTomorrow/calva/issues/825 (was linked from the Calva issue ref'd in that VS Code issue)

So maybe this has broken again in some situations?

Seems like that, for sure.

Also, Calva doesn't seem to download/run LSP correctly on Windows right now. I end up with these files in the extension folder:

-rwxrwxrwx 1 sean sean 25642392 May 11 00:09 clojure-lsp-native-windows-amd64.zip
-rwxrwxrwx 1 sean sean 26545152 May 11 00:09 clojure-lsp.exe

what clojure-lsp.exe command would display the version or some help or something?

Anyways, after midnight here... really bedtime!

It is the autoSelectFor… in the workspace settings that exposes the error. If I remove that and thus get to select the connect sequence manually, it works. I’ll update the project. Much more boring howto-instructions, but it will serve as a incentive for me to fix the problem in Calva.

I could reproduce the problem in a (painfully slow) Azure machine. Now updated the project. Hopefully temporarily. It doesn’t fix the problem that @dmiller had though. Which I couldn’t reproduce.

I'm not sure where all this stands at this point. I'm out for the next few hours, so I'll tune back in later. On my end, my Docker installation might have had some problems. I was getting errors a while back, never did anything about. So I uninstalled Docker (which cause a bluescreen -- not a good sign), reinstalled. Will do some tests when I get back and try again.

@pez I changed those autoSelect... settings to false and tried to manually select the connect sequence but it produced that "spawn" error I posted above. Is something else needed?

I updated the README of the project. See if those instructions work. Or maybe, that’s what you did, @seancorfield? @dmiller, we’re at where there’s a bug (at least one) in Calva which trips the setup up. Manually starting the nREPL server (with docker compose exec -it dotnet-clojure /app/docker/start-repl.sh) and then connecting an nREPL client to that server should work. The project is updated with Calva settings that should avoid the bug on Windows. And the Calva stuff in the README is also updated. Hopefully it should work now, following those instructiions, but who knows.

Regardless if you people get it working or not, please scrutinize the scripts in there a bit. The readme declares that I do not know what I am doing, which I don’t. I guess it’s the cheap-deps.sh script that is the funky one. Can we expect that to work as people add dependencies to their project?

@pez I can confirm that those modified instructions work for me, with the ["docker", ".nrepl-port"] change as well.

On Windows, I can't manually jack-in via that connect sequence: that throws the spawn docker ... error. If I manually run the start-repl.sh command and then connect via that connect sequence it works. Just to clarify.

LMK if you want me to run any other tests.

Thanks, @seancorfield! I’ll be trying to fix the most glaring of the Jack-in bugs there. Might send Calva dev versions your way at some points. 😃

Problem with starting continues.

@dmiller So, just to check, you clone the repo, cd into it, run docker compose build and that works, but when you run docker compose up, it fails? (if you run it without -d you'll see more log output indicating perhaps something useful).

docker compose up -d appears to work:

PS C:\work\clojure\clojure-clr-mini> docker compose up -d
[+] Running 1/0
 ✔ Container clojure-clr-mini-dotnet-clojure-1  Running

2023-05-11 15:26:41 clojure-clr-mini-dotnet-clojure-1  | /app/docker/entrypoint.sh: /app/docker/cheap-deps.sh: /bin/bash^M: bad interpreter: No such file or directory
2023-05-11 15:26:41 clojure-clr-mini-dotnet-clojure-1  | /app/docker/entrypoint.sh: /app/docker/cheap-deps.sh: /bin/bash^M: bad interpreter: No such file or directory
2023-05-11 15:26:41 clojure-clr-mini-dotnet-clojure-1  | /app/docker/entrypoint.sh: line 4: /app/dependencies/load-path.sh: No such file or directory

Ah, interesting. It should be unix line endings there. I wonder what can have happened… Anyway, will fix that right away. Good find!

git config can affect that -- so it could be linux line endings in the repo but git can check files out with crlf on windows.

It’s all unix line endings when I look at the file locally:

od -c docker/cheap-deps.sh
0000000    #   !   /   b   i   n   /   b   a   s   h  \n  \n   o   r   i
0000020    g   i   n   a   l   _   c   l   a   s   s   p   a   t   h   =
0000040    $   (   l   e   i   n       c   l   a   s   s   p   a   t   h
0000060    )  \n  \n   n   e   w   _   c   l   a   s   s   p   a   t   h
0000100    =   "   "  \n   I   F   S   =   "   :   "  \n   f   o   r    
0000120    p   a   t   h       i   n       $   o   r   i   g   i   n   a
0000140    l   _   c   l   a   s   s   p   a   t   h   ;       d   o  \n
0000160                    i   f       [   [       $   p   a   t   h    
0000200    =   =       *   .   j   a   r       ]   ]   ;       t   h   e
0000220    n  \n                                   j   a   r   _   b   a
0000240    s   e   n   a   m   e   =   $   (   b   a   s   e   n   a   m
0000260    e       "   $   p   a   t   h   "       .   j   a   r   )  \n
0000300                                    t   a   r   g   e   t   _   d
0000320    i   r   =   "   /   a   p   p   /   d   e   p   e   n   d   e
0000340    n   c   i   e   s   /   $   j   a   r   _   b   a   s   e   n
0000360    a   m   e   "  \n                                   m   k   d
0000400    i   r       -   p       "   $   t   a   r   g   e   t   _   d
0000420    i   r   "  \n                                   u   n   z   i
0000440    p       -   q       -   o       "   $   p   a   t   h   "    
0000460    -   d       "   $   t   a   r   g   e   t   _   d   i   r   "
0000500   \n                                   n   e   w   _   c   l   a
0000520    s   s   p   a   t   h   =   "   $   n   e   w   _   c   l   a
0000540    s   s   p   a   t   h   :   $   t   a   r   g   e   t   _   d
0000560    i   r   "  \n                   e   l   s   e  \n            
0000600                        n   e   w   _   c   l   a   s   s   p   a
0000620    t   h   =   "   $   n   e   w   _   c   l   a   s   s   p   a
0000640    t   h   :   $   p   a   t   h   "  \n                   f   i
0000660   \n   d   o   n   e  \n  \n   e   c   h   o       "   $   {   n
0000700    e   w   _   c   l   a   s   s   p   a   t   h   #   :   }   "
0000720   \n                                                            
0000721

I forget what the default behavior is.

Maybe @dmiller has git configured to checkout files with CRLF even from Linux repos?

Fixing the line endings on cheap-deps.sh took me one step deeper. Error message not appearing in Docker Desktop. Now I'm at at this point:

PS C:\work\clojure\clojure-clr-mini> docker-compose exec -it dotnet-clojure /app/docker/start-repl.sh
/app/docker/start-repl.sh: line 3: /app/dependencies/load-path.sh: No such file or directory
Execution error (FileNotFoundException) at System.Diagnostics.StackFrame/ (NO_FILE:0).
Could not locate user with extensions .cljr, .cljc, .cljr, .cljr.dll, .cljc.dll, or .clj.dll on load path.

Full report at:
/tmp/clojure-c6458361-e6ac-44eb-baf0-822b7b476500.edn

{:clojure.main/message
 "Execution error (FileNotFoundException) at System.Diagnostics.StackFrame/ (NO_FILE:0).\nCould not locate user with extensions .cljr, .cljc, .cljr, .cljr.dll, .cljc.dll, or .clj.dll on load path.\n",
 :clojure.main/triage
 {:clojure.error/class System.IO.FileNotFoundException,
  :clojure.error/line 0,
  :clojure.error/cause
  "Could not locate user with extensions .cljr, .cljc, .cljr, .cljr.dll, .cljc.dll, or .clj.dll on load path.",
  :clojure.error/symbol System.Diagnostics.StackFrame/,
  :clojure.error/source "NO_FILE",
  :clojure.error/phase :execution},

Can the repo specify line endings overriding local configs?

My git config is always is a source of wonder and mystery.

I can maybe fix that when copying in the files into the Docker container.

core.autocrlf=true I believe this is what is suggested for Windows users.

If you do docker-compose exec -it dotnet-clojure Clojure.Main and examine CLOJURE_LOAD_PATH, what gives?

Hmmm, sorry, that’s not a good test. Hang on…

docker-compose exec -it dotnet-clojure bash

source /app/dependencies/load-path.sh
echo CLOJURE_LOAD_PATH

> core.autocrlf=true I guess this means I need to take care of it when copying in the files.

root@d4174c2efbe2:/app# source /app/dependencies/load-path.sh
bash: /app/dependencies/load-path.sh: No such file or directory

When the container starts. You should see the dependencies directory created on the host machine. Do you?

I have pushed a .gitattributes file to the repo which looks like:

docker/*.sh text eol=lf

I'm back to seeing this in Docker Desktop:

2023-05-11 15:26:41 clojure-clr-mini-dotnet-clojure-1  | /app/docker/entrypoint.sh: /app/docker/cheap-deps.sh: /bin/bash^M: bad interpreter: No such file or directory
2023-05-11 15:26:41 clojure-clr-mini-dotnet-clojure-1  | /app/docker/entrypoint.sh: /app/docker/cheap-deps.sh: /bin/bash^M: bad interpreter: No such file or directory
2023-05-11 15:26:41 clojure-clr-mini-dotnet-clojure-1  | /app/docker/entrypoint.sh: line 4: /app/dependencies/load-path.sh: No such file or directory

I'll reclone, kill everything over on Docker , and start again. 👍

Very good that you were using that setting! 😃

Miracle of miracles:

PS C:\work\clojure\clojure-clr-mini> docker-compose exec -it dotnet-clojure /app/docker/start-repl.sh
Started nREPL server at localhost:6667

Looks like ctrl+alt+c ctrl+alt+j did the trick

It did? I can’t get that to work yet on Windows. Anyway that’s the command for starting the REPL. Since you have started it manually you should do Connect instead: ctrl+alt+c ctrl+alt+c should work.

The idea with the repo is that people should use the editor they know how to use, so you are a special case. 😃

Well, no, it didn't work. False alarm.

ctrl+alt+c ctrl+alt+c worked! I have officially evaluated (+ 2 3). (More advanced than (+ 1 2).)

Double the advanced!

🎉

To evaluate stuff in the files, use alt+enter for top level forms, and ctrl+enter for “current” form.

That much I got. But that's all. I have a lot to learn about Calva. But compared to the last 14 years of using Notepad++ and the command line to do my dev work on the Clojure-y aspects of ClojureCLR -- all those ported libs! -- I'm looking forward so much to the reduced friction.

Oh, wow, am I talking to a potential Calva user? 😃

Totally. (I ceased being an Emacs purist some 40+ years ago. Literally. 🙂 )

Back then I was using ed and vi.

Emacs on the VT-220, plus whatever we had available on our Vaxen. I was never "semper vi". But my first lisp was a maclisp (I think) clone running on a DEC-10 on a DECWriter pushing through green-bar fanfold paper. But perhaps TMI. 🙂

I wish I had found lisp long ago. But I am also happy i finally found it.

Back again with asking for help. 😃 I decided to use tools.deps instead of Leiningen for the cheap-deps handling. It works on my machine, but I don’t trust my testing enough. Please help me ensure that I didn’t break it. I also renamed the project so now it is found at https://github.com/PEZ/clojure-clr-starter If you’ve tested the previous versions, probably the most reliable way to test this one is to clone it to a fresh directory.

I can get the docker image up and running. I seemed to have hosed my Calva installation somehow. Need to go figure out what I'm doing wrong. Or just take the day off. It's not starting well.

We’re happy to help in #calva.

Thanks. I should probably spend some time going through the tutorials first.

Basic build/start/jack-in worked here. Closed & restarted VS Code and it auto-reconnected.

Still leaves the .nrepl-port file behind after docker compose down.

I got it connected.

@pez if you change defn main to defn -main your example can be run directly (on Windows with .NET etc installed):

$Env:CLOJURE_LOAD_PATH='src'; Clojure.Main -m starter.hello

Fixed.

Now I’ve switched from clojure to Babashka for the dependency management. 😃

A problem with using .cljr for the extensions is that clojure-lsp does not help with them then. I wonder if this is maybe configurable.

Fixed so that the nREPL port file is deled when the container is shut down. There’s still an issue with the REPL being kept running when Calva Jack-in is killed, but that is probably a Calva issue.

Starting the REPL manually with docker compose exec -it dotnet-clojure /app/docker/start-repl.sh and then exiting that, stops the REPL and removes the port as it should.

I think the .clj files should be .cljr files - or at least .cljc files?

https://github.com/BetterThanTomorrow/calva/issues/2194 😃

(for them to be runnable with Clojure.Main)

But, yes, .cljc I could have used.

Hmm, I changed them to .cljr (to run them) and thought they were still treated as Clojure by Calva... But maybe I'd also changed that association in the settings?

VS Code has a language setting for each editor pane. I think that if it was Clojure and then changes to “nothing” it might keep Clojure associated.

Oh... and I already had the files open! Got it!

3194 is merged to dev but not published yet, am I understanding the workflow correctly?

Yes, I should publish it.

That wasn't a prompt, it was a question! 🙂

Haha. I meant it like: Yes, you understand the workflow correctly. I really should publish it. It’s the press of a button and with zero risk involved.

And once that's out there, you can update the starter project to use .cljr extensions and maybe add a note about running the main function on cmd/powershell 🙂

It's very cool that this all works so smoothly! Major props to you for that!

Will do.