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