Clojurians Log v2

That error indicate thats you are not compiling the native version of Datalevin, you are compiling the Java version that use JNR

Native Datalevin does not use JNI at all, it uses the GraalVM SDK C API

The decision on which version to use is made in Datalevin using a multimethod, which check whether or not it is running inside a GraalVM image. Even at the image build time, the code should be in GraalVM image so the native binding should be chosen, but somehow, yours is running in regular Java mode

Maybe point me to your repo so I can take a look at how you are compiling native image?

ok, i found your datalevin branch

you are depending on datalevin 0.3.17, which is the release before the work on native compilation, of course it won’t work

I am going to release v0.4.0 today, as I just finished the native command line shell for datalevin

v0.4.0 should work

also, you are right, i should bundle the dtlv.a in the library

i am new to this business of releasing native code, so allow me sometime to get up to speed

Created PR https://github.com/clojure-lsp/clojure-lsp/pull/347

It compiles to native just fine.

Oh that was fast haha! I'm new too don't worry ;)

Thank you for the quick response

I'll test it with the 0.4.0 as soon you release it, excited for that!

Thanks for the help @huahaiy, with your PR merged I'm getting a

java.lang.IllegalArgumentException: No method in multimethod 'open-kv' for dispatch value: :graal

Does the key-value store lmdb work with graal?

you mean when you run the binary?

it looks to me that the graal version of the LMDB binding is not compiled in, did you include datalevin’s reflect-config.json?

ldd ./clojure-lsp linux-vdso.so.1 (0x00007ffcc5ff9000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f57728c4000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f57728a1000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f577289b000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f577287f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f577268d000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f577253e000) /lib64/ld-linux-x86-64.so.2 (0x00007f57790e9000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5772521000)

so liblmdb.so.0 is missing

Yes, I merged the reflect-config json with datalevin one

ok, had this warning, so the release jar doesn’t include graal version

WARNING: Could not resolve datalevin.binding.graal.LMDB for reflection configuration. Reason: java.lang.ClassNotFoundException: datalevin.binding.graal.LMDB.

BTW i'm having the same issue with a JVM version, not graal one but the defmethod warn about the :java one

let me figure out how to include that jar

interesting

https://pastebin.com/sJL5yZEL

> WARNING: Could not resolve datalevin.binding.graal.LMDB for reflection configuration. Reason: java.lang.ClassNotFoundException: datalevin.binding.graal.LMDB. I had this one too

But right now the issue seems to be the defmethod not recognizing the defmulti implementations

i think i know what’s wrong, hold on, let me fix it

please test the updated PR, i tested locally, it seems to include lmdb.so now

Alright, testing it

Thanks for the help @huahaiy,the issue is fixed and it seems to work properly 🙂 I just needed to add the require [datalevin.binding.graal] as well. But probably clojure-lsp will follow a simpler way persisting the db with spit as we just need to persist things and read on time when clojure-lsp initializes. Anyway, thanks for helping on this POC, datalevin seems really cool!

Thanks for trying it out. You gave me some ideas on how to improve the packaging

Glad to hear 😄