announcements 2026-09-17

Releasing https://github.com/flybot-sg/rct-clr - https://www.flybot.sg/posts/25 RCT runs on the JVM only. It reads your source with rewrite-clj, which has no CLR port. So rct-clr extracts the ^:rct/test blocks on the JVM and writes a plain deftest file. That file runs on the CLR. Use cljr -X:test on https://github.com/clojure/clojure-clr, or nos test on https://github.com/flybot-sg/magic. Nine of our libs rely on RCT. They run on the JVM server and on the Unity frontend, hence the initiative. Caution: it follows https://github.com/robertluo/rich-comment-tests of RCT, not matthewdowney's original. Four differences: • throws=>> catches an expected exception • => takes the expected value on the left, matching (is (= expected actual)) • A namespaced keyword resolves correctly • A ;=> expectation evaluates as code. Write '(0 1 2) or [0 1 2] to compare a seq as data

🎉 1

oooo rewrite-clj support for cljr is a great idea. maybe i can take a crack at that

👍🏻 1

yes it could be a good idea and that should unlock the ClojureCLR side. (I mean you could port directly rct without having to resort to our trick to generate a deftest out of the blocks, but it works fine to do so) Also the transitive deps tools.reader is already ported by David Miller as clr.tools.reader. Sadly it reads record literals through clojure.lang.Reflector (and Magic does not allow reflection at runtime so all code can run on il2cpp in Unity). From what I see rewrite-clj has probably around 100 reader cond :cljr branches to add and a few of them might not be trivial.