Clojure CLI =========== 1st run, without ./.cpcache:

❯ rm -rf .cpcache/ ; time clojure -M:test:dev -e 1
1
clojure -M:test:dev -e 1  4.60s user 0.21s system 280% cpu 1.714 total

❯ time clojure -M:test:dev -e 1 
1
clojure -M:test:dev -e 1  1.40s user 0.08s system 201% cpu 0.734 total

❯ rm -rf .cpcache/ ; time deps -M:test:dev -e 1
1
deps -M:test:dev -e 1  3.97s user 0.26s system 248% cpu 1.703 total

> because it seems to run just as slow/fast as the Clojure CLI. The benefit is that you can use it as a binary on Windows which solves some problems that exists there with Powershell. When you have an already running JVM, and load this as a library, then it would still be "just as fast" as the clojure CLI since the startup time of the bash CLI or deps binary is neglectible. A JVM is started once to calculate the classpath / download deps but for the same set of dependencies it is cached.

but in the examples above, i didn't have an already running JVM and didn't have .cpcache either, yet running clojure took about the same amount of time (`1.7s`) as running deps. which is a pretty good time, but I remember clojure taking a lot longer in the past...

i have the feeling that my test methodology is flawed somehow

clojure and deps are expected to be roughly equally as fast. the most time taken is by the jvm is launched, the rest is just shell or executable checking the cache and starting java, which takes just a few ms

good to know about the windows support of deps. I'm consciously avoiding Windows, but if I ever need to program on it again, deps.clj will certainly be the 1st thing I install on it! :)

or babashka, right away :)

for the sake of completeness, here is a baseline run of clojure on the same 2020 M1 Mac mini, where the execution times above came from:

❯ rm -rf ./.cpcache ; time clojure -M -e 1
1
clojure -M -e 1  0.49s user 0.05s system 165% cpu 0.327 total

❯ time clojure -M -e 1
1
clojure -M -e 1  0.50s user 0.05s system 164% cpu 0.337 total

waaaait a second, deps is not an ARM binary!

❯ file $(which deps)
/Users/onetom/bin/deps: Mach-O 64-bit executable x86_64

@U086D6TBN Ah good call. Try bb clojure instead, there is an arm binary for that. deps doesn't have one at the moment, but could be made (if enough people ask)

bb clojure ...

deps ...

indeed with bb clojure, instead of deps, the runtime is 0.4s/`0.2s` less:

❯ rm -rf .cpcache/ ; time bb clojure -M:test:dev -e 1
1
bb clojure -M:test:dev -e 1  4.73s user 0.28s system 364% cpu 1.375 total

❯ time bb clojure -M:test:dev -e 1 
1
bb clojure -M:test:dev -e 1  1.16s user 0.08s system 215% cpu 0.577 total

Cursive actually doesn’t do any caching of the classpath for run configs at the moment, although it’s something that I’m planning. It does do it for deps project sync, but not for lein.

if you have a script that reformats your file, you can always set that up as an “after save” hook in intellij

look for “Actions on save” in the settings menu

Ah, that's not quite what I meant, I think cursive's indentation is pretty good, I want to run it or something equivalent as a command line hook.

IntelliJ does support a command line formatter, see https://www.jetbrains.com/help/idea/command-line-formatter.html. However it starts a whole IntelliJ instance to do it, so it may not be a great option for what you want. A better option would probably be to come up with the corresponding cljfmt config, and just run that.

Hmm, ok I'll dig into cljfmt, thanks @cfleming! Out of curiosity, does cursive's indenter use the same approach or is it compatible with cljfmt? I quite like what you're doing / options you offer, so being able to do something similar would be good.

There is also zprint: https://github.com/kkinnear/zprint#get-zprint Which has a graalvm binary that starts in under 50 ms if you want fast(er) feedback..

I haven't tried either myself

So Cursive doesn’t use the same approach as cljfmt, but I believe they should be able to be made pretty compatible. Let me know if there are things you’d like to achieve but can’t. zprint is also an option, although it’s extremely configurable - philosophically, I think it’s too much and prefer tools with the minimum of config required to achieve a sane result.

some related tickets: 1. https://github.com/cursive-ide/cursive/issues/2721 2. https://github.com/cursive-ide/cursive/issues/2533 and i think there was one more at least. i tried jetbrains gateway, when it came out and it didn't support opening the REPL window at that time and i doubt it has changed.

Thanks, 2721 sounds like the issue I'm facing. Will watch the ticket.

I haven’t had a chance to get to this yet, sorry.

@cfleming the following announcement might trigger more interest https://blog.jetbrains.com/idea/2022/10/remote-development-in-jetbrains-ides-now-available-to-google-cloud-workstations-users/ possibly making it worthwhile fixing this problem. Thanks.