babashka

2025-11-16T03:59:03.561709Z

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.

borkdude 2025-11-18T09:25:21.252479Z

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

2025-11-18T00:31:36.725719Z

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

borkdude 2025-11-16T11:41:22.163359Z

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

2025-11-19T16:39:29.824689Z

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.

2025-11-16T12:40:29.794679Z

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?

borkdude 2025-11-16T12:42:53.932219Z

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

2025-11-16T12:54:06.294129Z

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

borkdude 2025-11-16T12:54:51.065279Z

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

2025-11-16T13:01:20.569519Z

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

borkdude 2025-11-16T13:03:51.032629Z

a delay?

2025-11-16T13:04:36.751109Z

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

borkdude 2025-11-16T13:06:09.622619Z

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 ;)

2025-11-16T13:07:24.594349Z

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

borkdude 2025-11-16T13:07:46.919009Z

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

borkdude 2025-11-16T13:08:12.096509Z

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

👍 1
2025-11-16T13:11:05.128029Z

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.

borkdude 2025-11-16T13:12:26.817019Z

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? ;)

2025-11-16T13:13:12.727589Z

sure

✅ 1
2025-11-16T17:31:48.270639Z

Looks like the binary went from 85M to 38M

borkdude 2025-11-16T17:32:42.436329Z

🎉

borkdude 2025-11-16T17:34:06.481459Z

and I bet compilation time went down as well

2025-11-16T18:32:42.225279Z

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

🙏 1