Fork me on GitHub
#babashka-sci-dev
<
2022-04-18
>
borkdude09:04:29

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

lispyclouds09:04:31

yeah i remember that, im not sure adding socat and netcat for convenience is warranted on the docker image

borkdude09:04:36

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.

borkdude09:04:43

no, they can just make their own derived image

lispyclouds09:04:57

yeah thats what i concluded with

lispyclouds09:04:21

> 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

lispyclouds09:04:15

jdk 17 would just enable code like https://nipafx.dev/java-unix-domain-sockets/ which essentially is what socat is solving

lispyclouds09:04:58

anyways, will try building a bb 17

borkdude09:04:15

it was a java 17 bug

lispyclouds09:04:43

right, will try to find it

lispyclouds09:04:22

yeah this is expected hence we need curl

lispyclouds09:04:47

this is still not addressed til now, not sure when it would be

borkdude09:04:58

pretty silly

borkdude12:04:43

I haven't but maybe upgrade to 22.0.0.2

borkdude12:04:57

and prior to this commit stuff still worked, so you might be able to see how it ran then

lispyclouds12:04:20

seems to happen only on the arm instances

borkdude12:04:45

you cannot use musl with aarch, use mostly static there

lispyclouds12:04:30

so we still still stick to static only also on arm?

borkdude12:04:40

yeah, mostly ststiv

borkdude12:04:51

this works better on raspberry

borkdude12:04:02

as it then doesn't need anything libz etc on there

lispyclouds12:04:04

okay, this was new to me

borkdude12:04:29

so on aarch you need to pass the static-except-glibc flag

borkdude12:04:23

else it will link against the build system glibc and that's never what we want

lispyclouds12:04:54

right, need to add to the compile script

borkdude12:04:25

I don't know if passing --static + mostly-static works

borkdude12:04:00

Either way, that's not according to the docs

lispyclouds12:04:06

thats what we are doing in bb right? static + -H:+StaticExecutableWithDynamicLibC ?

borkdude12:04:37

you're right

borkdude12:04:40

then it should work

lispyclouds12:04:06

yeah meawhille shell doesnt seem to like the + i guess, trying to quote it

borkdude12:04:21

that would surprise me

lispyclouds12:04:57

this is just from me adding that flag into args

borkdude12:04:03

$ bb -e '(babashka.tasks/shell "echo" "1+1")'
1+1

borkdude12:04:53

try the script locally

borkdude12:04:00

and debug locally

borkdude12:04:07

fastest way

borkdude13:04:49

with newer babashka you no longer need to prepend that .cmd thing in windows

lispyclouds13:04:58

right, as for the failure only thing i can think of is the graal cache we are doing has gone bad somehow

lispyclouds13:04:08

its failing right at the gu install

lispyclouds13:04:32

cannot reproduce this at all locally

lispyclouds13:04:14

maybe the amd64 cache is used by the arm machines

lispyclouds13:04:22

finally, holy shit, was a nightmare

lispyclouds13:04:10

moral of the story: add arch to the cache key too

borkdude14:04:29

Afk, will look when home

lispyclouds14:04:02

updating them, seem to have support now, but the api has bunch of breaking changes 😕

lispyclouds14:04:08

the test lib functions of embedded pg lib we are using

lispyclouds14:04:32

from 1.0 they have all arch support and the builder api has totally changed

lispyclouds14:04:35

and it needs docker too now it seems, not sure i understand how it works

borkdude14:04:12

That's weird