Fork me on GitHub

is it possible to show the value of a binding at the point of exception in CIDER?


is it possible to set :jvm-opts for the the main deps tree in deps.edn, or must i manually pass them with each clojure / clj invocation? the docs talk about including them for aliases, but not for the root case

Alex Miller (Clojure team)12:03:17

It’s only used with an alias right now but that’s a good point - feel free to file a TDEPS ticket


how would i use -J with the jvm opt -Dlogback.configurationFile=resources/logback.xml ? -J-Dlogback.configurationFile=resources/logback.xml doesn’t seem to work.

Alex Miller (Clojure team)12:03:08

That should work - if it doesn’t file a bug


I’ll confirm it’s not working due to tools.deps and not due to poor logback config, and file if confirmed, thanks!


@tbaldridge tbh I am not sure why it would be worse in the plugins section? I guess I am lacking knowledge and would happy if you explain your thought process there.


solved it for myself by making deps.edn aliases for each case that includes a jvm-opts, which is likely the intention of the lib author 🙂


Any idea what's cooking for Clojure 2.0? 🙂


What's next on the language roadmap....


We barely know about the roadmap for 1.10. Most new things happen behind the scenes until it drops on git. There are a few hints you can pick up in podcasts/chats here and there but that's it

Alex Miller (Clojure team)11:03:39

We haven’t even had a discussion about a 1.10 roadmap yet


How mysterious :)


I'm staring at the integer literal pattern regex for Clojure:

is there any way to actually reach the 0[0-9]+ at the end? Won't that always be caught by the octal pattern 0([0-7]+)?


in that case I don't understand why this doesn't work:

user=> 09
NumberFormatException Invalid number: 09  clojure.lang.LispReader.readNumber (


Does anyone know of a tutorial for writing IntelliJ plugins in Clojure? On Google, all my results are either about Cursive (the IDE) or La-Clojure (which has bden deprecated in favor of Cursive).


@qqq As far as I know, parts of Cursive is implemented in Clojure, so maybe you could ask @cfleming for any pointers?


afaik it’s mostly written in kotlin


It’s a mix - @qqq, feel free to drop me a mail on <mailto:[email protected]|[email protected]>.


Here’s a canned response from a previous mail I wrote to someone who asked about it - this probably warrants a blog post:


However the summary of my opinion on using Clojure in IntelliJ plugins right now is that I wouldn’t advise it unless you’re extremely keen. In particular, if you’re planning a plugin for wider distribution, the Clojure startup time is a killer. For boring class loader reasons, it’s very hard to avoid loading Clojure eagerly at startup, and that adds several seconds to IntelliJ’s startup time. It’s something that JetBrains have mentioned to me several times since it comes up continuously in their performance testing before releases. They’re concerned about it because that badly affects their users’ perception of IntelliJ’s startup time, i.e. they’ll get the blame and the associated angry blog posts/tweets even if it’s a plugin’s fault. I actually run a fork of Clojure (see here: so I’m hoping to be able to fix this in my fork, but I haven’t done so yet because I have more eager loading to fix first. But in any case, any plugin should be a mix of Clojure and something else because even if you can defer that loading until a Clojure class is loaded, some classes from your plugin are loaded at startup. I used to write those in Java, now I write them in Kotlin. All this is annoying enough that I would recommend just writing the whole thing in Kotlin or Java unless you’re totally, absolutely sure it needs to be Clojure. Kotlin is really lovely, and its Java interop is much nicer than Clojure’s (see here: Since it’s made by JetBrains and they’re switching most of their new development over to it, it’s becoming a well-trodden path with lots of examples and doc.


@cfleming Two potential complaints: 1. clojure startup time is slow 2. for some weird interop, Kotlin works better than Clojure I initially thought the reason would be 2. However, from your post, it seems to be 1. Thus, my question: 1. I rarely restart "boot repl" 2. I expect to restart IntelliJ even less 3. I can see the 2-3 second delay frustrating to non-Clojure users, but why would it effect Clojure users? We're all used to the boot/lein repl delays.


@qqq It depends on the target audience for your plugin. Will it be something internal, or something you distribute? If it’s something you’ll distribute, then lots of people will install it and just forget about it even if they never use it. It’ll add ~5 sec+ to their IDE startup time, and some of them might start to complain online about how slow IntelliJ is to start. That’s what Jetbrains want to avoid.


2 is also a problem, which I mitigate in my case by using a Clojure fork. Clojure is spectacularly bad at extending abstract classes, which you have to do a lot when writing plugins.


It’s not exactly an esoteric niche case, it’s idiomatic in Java to expect that to be easy.


However even that is annoying, since those classes are created via an IoC container. Clojure gives very little flexibility over the classloader used to load Clojure classes, unless you can control the TCCL at the point they’re instantiated. In this case you can’t, since the IoC container does the instantiating.


I’m planning to modify my fork to improve that.


Clearly I need to write a blog post about this.

👍 4

I’m trying to create a socket server that accepts an initial command, and then pipes stdout to the client


this seemed like a pretty good use-case for clojure.core.server, but I’m actually struggling with the first bit - receiving the initial message from the client


I see lots of examples of receiving input from stdin (e.g. (read-line)), but I’m not really looking for that much interactivity


ahhh, I see - I can use just a single (read-line) and it will receive the first message. seems weird but works with my current way of testing with netcat echo asdf | nc localhost 1234