This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-18
Channels
- # announcements (1)
- # babashka (39)
- # babashka-sci-dev (59)
- # beginners (60)
- # calva (14)
- # circleci (1)
- # clj-kondo (16)
- # clj-on-windows (1)
- # clojure (95)
- # clojure-europe (5)
- # clojure-norway (2)
- # clojurescript (34)
- # conjure (2)
- # core-async (55)
- # datomic (4)
- # emacs (54)
- # holy-lambda (5)
- # hyperfiddle (2)
- # interop (4)
- # lsp (8)
- # malli (3)
- # nrepl (4)
- # off-topic (34)
- # polylith (5)
- # reitit (3)
- # releases (2)
- # shadow-cljs (85)
- # specter (2)
- # testing (8)
- # tools-deps (12)
Re: https://clojurians.slack.com/archives/CLX41ASCS/p1650269317966249 Does this warrant a trial with graalvm 17?
@rahul080327 I already had JVM 17 once but we decided to hold off since it added 5mb to the native image size without any significant new features.
yeah i remember that, im not sure adding socat and netcat for convenience is warranted on the docker image
but feel free to experiment locally to see if that solves some problem. last time we tried the java.net.http stuff didn't work yet with the unix socket stuff.
yeah thats what i concluded with
> last time we tried the java.net.http stuff didn't work yet with the unix socket stuff do you remember what it was exactly? i think apart from the image bloat there should not be an issue. we still would need curl to do http over unix sock though
jdk 17 would just enable code like https://nipafx.dev/java-unix-domain-sockets/ which essentially is what socat is solving
anyways, will try building a bb 17
right, will try to find it
yeah this is expected hence we need curl
this is still not addressed til now, not sure when it would be
seen this error before @borkdude? https://app.circleci.com/pipelines/github/babashka/babashka-sql-pods/281/workflows/a9f1b767-05d5-4a68-a9fc-4ebf4f8fd66a/jobs/2081
and prior to this commit stuff still worked, so you might be able to see how it ran then
seems to happen only on the arm instances
so we still still stick to static only also on arm?
okay, this was new to me
right, need to add to the compile script
thats what we are doing in bb right? static + -H:+StaticExecutableWithDynamicLibC
?
yeah meawhille shell doesnt seem to like the +
i guess, trying to quote it
what could be causing https://app.circleci.com/pipelines/github/babashka/babashka-sql-pods/283/workflows/7bbb2389-6698-49a6-b322-e1eeec53318a/jobs/2100 ?
this is just from me adding that flag into args
right, as for the failure only thing i can think of is the graal cache we are doing has gone bad somehow
its failing right at the gu install
cannot reproduce this at all locally
maybe the amd64 cache is used by the arm machines
finally, holy shit, was a nightmare
moral of the story: add arch to the cache key too
is seems for postgres and mysql, the drivers we are using doesnt like linux aarch 64: • https://app.circleci.com/pipelines/github/babashka/babashka-sql-pods/285/workflows/0942206a-878f-4f65-b60b-bd21763174c8/jobs/2145 • https://app.circleci.com/pipelines/github/babashka/babashka-sql-pods/285/workflows/0942206a-878f-4f65-b60b-bd21763174c8/jobs/2139 Any suggestions?
updating them, seem to have support now, but the api has bunch of breaking changes 😕
the test lib functions of embedded pg lib we are using
from 1.0 they have all arch support and the builder api has totally changed
and it needs docker too now it seems, not sure i understand how it works