babashka 2025-11-16

I have a https://github.com/frenchy64/fully-satisfies/blob/main/src/io/github/frenchy64/fully_satisfies/requiring_resolve.cljc for https://clojure.atlassian.net/browse/CLJ-2735 (a critical bug in requiring-resolve) but it needs access to clojure.lang.RT/REQUIRE_LOCK to be most effective. It's effectively the official borkdude.dynaload/dynalock that everyone should acquire when loading code. Could we expose this in bb? While we're at it, we could also use it for dynalock to help avoid loading races.

@ambrosebs have you come across a situation where this was a real problem? I'd love to learn more

so then races between requiring-resolve and dynaload are serialized because they're using the same lock

We could expose it in bb, but why would you need to?

no, that's theoretical but I can sketch a reproduction if needed. I mentioned dynaload only because I thought it might interest you, but the situation I'm really interested in is requiring-resolve incorrectly racing with itself, which is trivially reproducible (see ticket). the way to fix it it to reimplement requiring-resolve in bb, but that needs RT/REQUIRE_LOCK in order to be serialized with the original requiring-resolve and any future enhancement to it. without RT/REQUIRE_LOCK we can still implement something but it won't be compatible with other dynamic loading situations. an ideal future IMO is if dynaload, requiring-resolve and any workarounds to it all use the same lock, which is only possible if RT/REQUIRE_LOCK is exposed.

TIL about dynaload. I’m a little confused though - the readme says it returns a delay, but the example doesn’t seem to deref it. Looking at the code, it seems to return something that implements IFn. Does it only support function vars?

It's a lazy "var" which supports both IFn and deref

I’m eager to see if it helps reduce graalvm binary sizes for my mcp-tasks project 🙂

if you are using require, requiring-resolve or resolve at runtime, it might

It looks like claude is as confused as I was about the returned value be a delay.

From the readme: “The macro returns a delay that will either contain a value or will throw upon deref”

The macro actually doesn't return a delay but an IDeref it looks like. I've written this code once 5 years ago, I'm not up to date with it either and I'm jetlagged ;)

Sorry - I don’t mean to be critical, just trying to understand 🙂 Hope you had a good conj.

no problem ;) what return value did you (or maybe rather, claude?) expect

I definitely had a good conj. Had a good time talking to Nathan too

👍 1

I just think the doc misleads by saying it returns a delay, but then the example never derefs. Probably just me being pedantic or obtuse, or both.

ah yes, the thing return something which is both a Deref and an IFn similar to vars. So yeah, the README could use an update. Perhaps you can tempt Claude to do so? ;)

Looks like the binary went from 85M to 38M

and I bet compilation time went down as well

I created a PR to fix a bug in the babashka implementation

🙏 1