Clojurians Log v2

@borkdude - I have avclj compiling down into a graal native executable that generates video - https://github.com/cnuernber/avclj

is the main Idea using the stuff in JDK-16 instead of jna?

Graal native has literally nothing to do with JDK-16 or JNA.

congrats :)

I'm just curious how the c ffi is done.

I wrote a new dtype-ffi driver.

One second, doing a release because I missed some files in the check-in.

It takes the same library definition as before but outputs a static class. That uses all the graal native C stuff in order to cause the system to link with the libraries when graal builds the executable.

oh ok. I haven't look at JDK-16, but it seemed plausible that its cffi might be graalvm compatible.

Not in the least.

Not even closely compatible at this time. Maybe in the future.

JDK-16 is way better and more flexible.

https://github.com/cnuernber/avclj/blob/master/native_test/avclj/main.clj

i saw some jdk.incubator.foreign classes, so does it rely on some jdk16 features?

No not at all. My graal install is jvm 1.8

The system will automatically use what is installed favoring JNA over JDK-16. But for this pathway I hardcoded it for https://github.com/cnuernber/avclj/blob/master/native_test/avclj/main.clj.

since tech.v3.datatype.ffi.graalvm only works for graalvm, i believe, one has to have write another ffi if running on jvm?

i saw that you asked in graalvm channel if they are going to unify these, that’s what I wanted to know as well.

otherwise, it’s a pity having to write two versions of ffi every time, which is what i am doing in datalevin right now