Clojurians Log v2

Yes, I took a look at that and I am aware of the C bits. I think the tricky part is to map memory layouts between Clojure and the type signatures of Julia. @chris441 I have heard that you have already thought about this?

that’s what jna helps you do

yes. are you working with it?

I’ve been using JNA to integrate with c libraries, but not julia

I’ve been using jna via https://github.com/Chouser/clojure-jna/, but it looks like libpython-clj uses their own clojure wrapper over jna, https://github.com/techascent/tech.jna

@whilo - I am down to work with someone to take a crack at it. I also want to see julia access from Clojure but i havent put any real time in.

I think it is doable, I think it is a moderate amount of work, and I think Julia is really visionary with a lot to offer.

Another tack you could take would be Clojurists together funding. But my assumption is that it will take some pretty in-depth C knowledge as did libpython-clj.

Right, that makes sense. I think it would be cool if it would be integrated with pyjulia as well, so you can share the same objects between Python and Julia, effectively being able to mix and match libraries from Clojure. Do you think this would be feasible?

The best way to do that is to use pyjulia. Maybe file an issue with and we can look at it. Bespoke bindings would be best in the siruation where you do not want python involved.

I just tried pyjulia and it isn't stable when used via python-clj. That should be an issue like I said but tracking it down may be really tough. This is why bindings to julia that don't involve python would be wise if we really want have julia in the ecosystem.

Julia also isn't stable itself when loaded via jna. It fails on the initialize call. Julia support for the JVM appears to be a research project at this point. =

Got past the intialize code if I use the binary distribution from http://julia.org and not the system installation. Still crashes on shutdown but I can run strings. It isn't clear that you can, for instance, register a foreign function although the pathway for that may be using the julia system to 'find' the function...

@chris441 Hmm, interesting. Is your code for this experiment somewhere?

That sounds already useful enough to play around and try out deeper integrations.

https://github.com/cnuernber/julia-clj. It will always crash given time. Unless we get help from the julia team this can't go anywhere. The use stack manipulations that are incompatible with the JVM. I filed an issue on this that didn't get a response; the next step is to compile julia with some custom flags and see if that mitigates or eliminates the issue.

are you hanging onto return values referenced from the clj side?

otherwise, the jvm will think noone is using those values and garbage collect them

oh didn’t realize you had also worked on libpython-clj and probably run into a million of those issues. nvmd. :homerdisappear:

Yep, and this is simple calling `jl_init__threading` which doesn't return anything and then calling System/gc a few times_._ Once `jl_init__threading` is called *for sure* the jvm will crash at some undefined time in the future. My current guess is this is because Julia does something really fancy with stack frames and so does the jvm. This may have to come in via graal native and currently our entire ml stack would need to be changed somewhat to support graalnative so I am not in a rush to go there.

the other type of crash I’ve seen when creating bindings for exotic libraries is issues with both environments adding signal handlers. see https://bitbucket.org/chromiumembedded/java-cef/issues/355/crash-on-cef-init-due-to-signal-handlers for an example. julia does have handlers for SIGBUS, SIGSEGV, but I’m not sure if this is related to the crash you’re seeing or is a problem in this case.

I found this java library that provides embedded julia bindings https://github.com/rssdev10/julia4j . if I have some time, it would be interesting see if they run into the same issues, and if not, maybe that will provide a clue as to workaround. however, just browsing through the code seems like they aren’t doing anything special.

this also looks interesting, https://github.com/JuliaInterop/JavaCall.jl

@smith.adriane I think julia4j is mostly using Swig bindings and is not doing anything beyond that. I assume that integrating the GCs properly will be a lot more work. Thanks for the pointer about signal handlers.

i thought the issue was whether julia and the jvm could even share the same process without stepping on eachothers toes. if the swig bindings work, then it seems like that is at least possible

@chris441 Thanks, playing with your repo now. Where did you post the issue?

I see, I have not tried the Swig bindings.

me neither. they might have the same problem