This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-26
Channels
- # announcements (3)
- # babashka (23)
- # beginners (54)
- # calva (9)
- # cider (8)
- # clj-kondo (18)
- # cljsrn (25)
- # clojure (69)
- # clojure-australia (1)
- # clojure-europe (7)
- # clojure-spec (13)
- # clojure-uk (1)
- # clojurescript (122)
- # conjure (8)
- # cursive (15)
- # defnpodcast (9)
- # deps-new (2)
- # emacs (22)
- # fulcro (10)
- # graalvm (36)
- # luminus (5)
- # meander (5)
- # minimallist (1)
- # observability (6)
- # off-topic (54)
- # reagent (8)
- # reitit (2)
- # releases (1)
- # reveal (25)
- # shadow-cljs (21)
- # tools-deps (50)
- # vrac (1)
- # xtdb (2)
It seems that initialize-at-build-time is required for the hello world example, I think it was mentioned elsewhere as an optional optimization.
https://github.com/lread/clj-graal-docs#class-initialization > For Clojure programs it is often actually feasible (unlike in a typical Java program) to change it back via --initialize-at-build-time to achieve yet faster startup time. Gave me the impression of optional. It's a bit of a pain because somehow this is causing Netty's PooledByteBuffer to be loaded at build time, which then fails. But Graal can't trace the loading class for me 🤕 This native stuff is hard
@borkdude the problem is that PooledByteBuffer is forced to be runtime (by the netty config), but then something which is initialized at build time, is initiailizing PooledByteBuffer. I don't know what something is, and graal can't tell me in this specific scenario.
I suspect Lettuce is incompatible with build time flag, and the initialization tracing doesn't work when it's loaded via the configs.
Maybe check https://github.com/BrunoBonacci/graalvm-clojure for similar examples that do work
@borkdude, I think we are simply trying to convey that we need to initialize at build time, but one can still defer specific classes to initialize at runtime?
btw, Clojure 1.10.2-alpha2 has a few fixes that came from @borkdude related to reflection in case that helps y'all
@alexmiller Thanks for accepting those patches. Two relevant other patches: - https://clojure.atlassian.net/browse/CLJ-2582 - https://clojure.atlassian.net/browse/TCHECK-157
The TCHECK one is relevant if one is going to generate random data in a graalvm native binary e.g. using spec
Thanks @borkdude and @alexmiller, I shall update our little clj-graal-docs repo!
oh maybe I did upload it accidentally… I was previewing the README in firefox and might have dragged it over… which… hmmm.. oops…
Pondering about an idea to leverage clojure git libs for (GraalVM or other) binaries: https://github.com/babashka/babashka.pods/issues/19