rutledgepaulv / clj-embed Goto Github PK

Because clojure itself is loaded in a separate classloader it means that non-primitives don't transmit across the class loader boundary in a consumable way. By providing a hook on the root and the runtime side I should be able to let users define their own serialize/parse hooks per data type if they need to send results back and forth. Minimally, this library could take care of it for core clojure data types.

An example of this problem can be seen in this:

(with-runtime runtime :dummy)
=> #object[clojure.lang.Keyword 0x6358bfef ":dummy"]

(keyword? (with-runtime runtime :dummy))
=> false

Thank you for this great library!

Do you plan to support custom Maven repositories for dependency resolving?

If it helps, I tried it at this fork:
develop...daslu:develop

From the example I'm a little confused:

• Is runtime a bound var? Or should it be r like the surrounding context
• I'm not fully certain of the intention of it, from the given example. I think it has access to dynamic vars or something, but I'm really not clear.

https://stackoverflow.com/questions/7684656/clojure-eval-code-in-different-namespace

For some reason the loader can't find these while loading the clojure sources, but io/resource works. So I think it's either ShimDandy's loading strategy or the fact that clojure.lang.Compiler/LOADER is bound to an incorrect classloader.

After initializing a new runtime, I should inject the clj-embed namespace into it so that you can nest them.

Could I determine what is being referenced in the local context but not present in the target runtime and then map them and their deps into the runtime? That would simplify the process of setting up the runtime to handle some particular piece of code that involves functions and libraries, etc.

Ideally you could start with the same classpath as the project invoking the new runtime. Probably best if you can always spawn a clone of the "current" runtime (root or otherwise).

The majority is actually off heap metaspace. This is tunable with some JVM parameters but it might mean there is no leak, it's just the consequence of loading and unloading a lot of classes.