This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # aws (13)
- # babashka (31)
- # beginners (102)
- # calva (46)
- # cider (16)
- # clj-kondo (1)
- # cljs-dev (3)
- # clojars (1)
- # clojure (396)
- # clojure-argentina (1)
- # clojure-australia (4)
- # clojure-europe (64)
- # clojure-nl (2)
- # clojure-uk (8)
- # clojurescript (20)
- # conjure (5)
- # cursive (4)
- # datomic (15)
- # emacs (48)
- # graalvm (69)
- # graalvm-mobile (1)
- # jobs (4)
- # jobs-rus (1)
- # lsp (6)
- # malli (15)
- # meander (2)
- # observability (11)
- # off-topic (10)
- # pathom (2)
- # portal (4)
- # re-frame (19)
- # reitit (1)
- # remote-jobs (3)
- # sci (1)
- # shadow-cljs (51)
- # tools-deps (11)
- # vim (12)
- # xtdb (13)
Btw has anyone benchmarked the performance changes in 21.2?
@ericdallo I've helped @chandru89new by making sqlite compile in a native-image using your "fix" library. https://github.com/borkdude/clj-sqlite-graalvm-native I had to change a couple of clojure-lsp specific config things. But after compiling I still get:
$ ./tt foo Exception in thread "main" java.lang.UnsatisfiedLinkError: org.sqlite.core.NativeDB._open_utf8([BI)V [symbol: Java_org_sqlite_core_NativeDB__1open_1utf8 or Java_org_sqlite_core_NativeDB__1open_1utf8___3BI] at com.oracle.svm.jni.access.JNINativeLinkage.getOrFindEntryPoint(JNINativeLinkage.java:153) at com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallAddress(JNIGeneratedMethodSupport.java:57) at org.sqlite.core.NativeDB._open_utf8(NativeDB.java) at org.sqlite.core.NativeDB._open(NativeDB.java:78) at org.sqlite.core.DB.open(DB.java:195) at org.sqlite.SQLiteConnection.open(SQLiteConnection.jav ...
@ericdallo @chandru89new found the issue, PR coming
the issue is that you should not do any queries on the top-level in a namespace, since those run at build time and this causes strange problems.
Good catch! Also, I remebered I created this sample project using that fix lib: https://github.com/ericdallo/sqlite-graalvm-sample
This PR fixed it: https://github.com/chandru89new/clj-sqlite-graalvm-native/pull/2/files
I still think it's better to generate some JSON files and put that into resources/META-INF of your fix library @ericdallo, that works equally well and doesn't give these incompatibilities with graalvm versions
I tried to do that one time for clojure-lsp to avoid using that lib but it didn't work 😅 I probably missed something
So a question. How is it that Eric’s sample (https://github.com/ericdallo/sqlite-graalvm-sample) works without any of those META-INF files?
you can see I manually add the graalvm flags here as well: https://github.com/ericdallo/sqlite-graalvm-sample/blob/master/graalvm/native-unix-compile.sh#L14-L29
so part of the config comes from the fix lib and other is manually added via this script
@borkdude your PR#2 fixed it and things are working great now! Cant tell you how thankful I am to you, @ericdallo and @karol.wojcik for all the help.
I should perhaps add sqlite to https://github.com/babashka/babashka-sql-pods as well :)
this one does work with bb already https://github.com/babashka/pod-babashka-go-sqlite3
@ericdallo it seems like forking xerial yourself to make it static might be better, then try it out a while and then PR the changes back?
yes, but then that lib doesn't work with non-gcc environments. I'm not sure if what you want is possible at all
this is why using a pure Java library has some benefits here (h2, hsqldb), none of these problems
Yeah, I can't believe we don't have that, android is made in Java and use that all the time haha
btw, the xerial one, we could also port that to use the GraalVM C API, then it would work statically I think
@chandru89new do you know babashka?
Not really, @borkdude. In my quest to find a way to write clojure and use sqlite for this small project, I did stumble on your repo and precisely the sql-pods repo and had to back out coz I didnt find sqlite in the list.
ok, babashka is a clojure scripting environment that runs in a native binary with instant startup
it doesn't have any sql drivers but this is where pods come in: there are pods for every major db and you can still have access to those dbs via the pods
but it's nice to have pods to be statically compiled so they work in "every" linux: alpine, nixos and ubuntu
This pod: https://github.com/babashka/pod-babashka-go-sqlite3 works with sqlite from babashka.
Also see https://babashka.org/ and #babashka
Oh wow. Would this be like some super-charged version of doing
node index.js except that I dont need the environment or anything because bb comes with the SCI? Plus, faster?
so you can do most things that you will need for scripting, but there are some limitations