This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-22
Channels
- # adventofcode (12)
- # announcements (17)
- # babashka (46)
- # beginners (105)
- # calva (7)
- # chlorine-clover (7)
- # cider (9)
- # clj-kondo (41)
- # cljsrn (16)
- # clojure (67)
- # clojure-australia (1)
- # clojure-europe (24)
- # clojure-france (6)
- # clojure-germany (10)
- # clojure-italy (1)
- # clojure-losangeles (3)
- # clojure-nl (4)
- # clojure-uk (11)
- # clojurescript (8)
- # cursive (8)
- # data-oriented-programming (1)
- # data-science (1)
- # datomic (11)
- # defnpodcast (4)
- # events (1)
- # fulcro (34)
- # graalvm (6)
- # helix (3)
- # jackdaw (19)
- # jobs-discuss (1)
- # leiningen (9)
- # luminus (2)
- # malli (15)
- # mathematics (2)
- # meander (5)
- # mental-health (1)
- # off-topic (4)
- # pathom (23)
- # podcasts-discuss (1)
- # polylith (4)
- # quil (3)
- # re-frame (81)
- # react (1)
- # reagent (19)
- # reitit (4)
- # releases (1)
- # reveal (11)
- # shadow-cljs (54)
- # specter (14)
- # tools-deps (16)
- # vscode (2)
- # xtdb (3)
@chris441 @huahaiy possibly interesting: https://www.blog.akhil.cc/static-jni
Thanks. This is JNI specific, but what would be really cool is to make the substrateVM API available for regular JVM, because it is direct native access , much faster than JNI, and the API is nice to use too. Statically linking native libraries with substrateVM API is not a problem. I am already doing that in Datalevin.
That post links to an issue that will hopefully result in formal support for that pathway.
The article about Multi-tier compilation in GraalVM https://medium.com/graalvm/multi-tier-compilation-in-graalvm-5fbc65f92402