Clojurians Log v2

It seems that initialize-at-build-time is required for the hello world example, I think it was mentioned elsewhere as an optional optimization.

no, it's mandatory for all Clojure GraalVM programs afaik

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

@dominicm You can set run time initialization per class

--initialize-at-run-time=<the class>

e.g.: https://github.com/babashka/babashka-sql-pods/blob/5d04e7fce699741e1b5e8488cf0a8f70843a3e2e/script/compile#L49

@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.

ah right. sometimes this can be solved by wrapping things in a delay

Not my code unfortunately, it's in Lettuce.

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

No redis in there unfortunately, but jedis works fine :)

@dominicm I agree that the wording under that section is confusing.

@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?

I think that's a better wording yes, I don't know the details of why this is needed

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!

@lee Why did you upload the README of clj-graal-docs to TCHECK-157?

uh.

wha…

hm maybe that's an automated thing when you mention the issue in a git repo?

I do have slippery fingers sometimes.. but…

Nice improvements btw, table of contents

oh maybe I did upload it accidentally… I was previewing the README in firefox and might have dragged it over… which… hmmm.. oops…

ya that must be it… sorry about that! Not sure how to delete it now.

if you hover over those files, a trash can will appear

ah had to go to jira “old view”. got it, tx!

there's still one left :)

got it! tx!

yeesh, I can be dangerous!

interesting way to promote the info in that README for sure :)

As in “may you drag and drop in interesting ways”. :-)

Pondering about an idea to leverage clojure git libs for (GraalVM or other) binaries: https://github.com/babashka/babashka.pods/issues/19