Clojurians Log v2

What's the state of graalvm (20.3.0) and any clojure programs that do a requiring-resolve?

Is it known to work?

@dharrigan requiring-resolve = require + resolve, both are problematic when used in a dynamic fashion. you should try to get rid of these and do require + resolve only on the top level (not in function bodies)

Thank you. Unfortunately, can't easily do that. I'm using juxt clip to manage some dependencies, and it uses requiring-resolve

A pity, for because the first time today I managed to get my entire app to compile

they do work when you put a top-level require before those are executed (but they will lead to slightly more bloated binaries)

(using rc1 of clojure)

Was excited, until it tried to load in a clojure file and it fell over 😞

@dharrigan you want to execute clojure dynamically in a graalvm binary?

this is what I've made sci for: https://github.com/borkdude/sci

More like I have a system that uses juxt clip to manage injection of dependencies, like a database (connection), a kafka connection) etc..

it works fine as-is, with the standard jvm and an uberjar

clojure.core/eval doesn't work in a graalvm binary, since it needs the Clojure compiler and dynamic classloading

Does that mean things like the component system by Stuart Sierra wouldn't work either?

(or mount etc...)

@dharrigan it depends. :P

🙂

@dharrigan I don't see why it wouldn't work

Just looking over the source code

We are using component just to start/stop things, not to dynamically require things

right right

And as I said, if you statically require those things beforehand, it should still work when you dynamically require those things

It's just that clojure.core/eval doesn't work dynamically

That's interesting. Let me try that out

bbl

making some progress indeed by requiring them

it's slow progress, will keep plugging away at it.

some libs work better than others with graalvm (depending on what they do).

I'm hopeful 🙂