Clojurians Log v2

I can review and merge @lee ‘s PR

already done, looks simple enough. @rahul080327 can you verify if the bug in your PR also occurs with graalvm CE (vs the Oracle one)?

Yeah will try that. Wanted to narrow down to a piece of code that causes it too

Fails on ce at the same place

i think the ce build time was much less too, less optimisations maybe 😛

Yes, see -O1 remark before in this thread, this is closer to what CE does and yields even a smaller binary and less compile time with the Oracle version compared to CE. Already known, also see issue

Perhaps -O1 also avoids the error because perhaps it’s due to an optimization

but ce aslo shows this error with the usual build flags

Hmyeah ok

im trying to run the tests for io.replikative/hasch (one of the libs i think causes this) bb.edn

{:deps {io.replikativ/hasch {:mvn/version "0.3.7"}}
 :tasks {test {:extra-paths ["test"]
               :extra-deps {io.github.cognitect-labs/test-runner
                            {:git/tag "v0.5.1" :git/sha "dfb30dd"}}
               :task (exec 'cognitect.test-runner.api/test)
               :exec-args {:dirs ["test"]}}}}

i get this:

~/code/repos/babashka/bb test 
Running tests in #{"test"}

Testing exec-bcc5a671-8961-4ca5-a03c-baa5387d69ed

Ran 0 tests containing 0 assertions.
0 failures, 0 errors.

im missing something stupid, why cant this find the tests?

also that Testing exec line is nowhere

got it running with https://book.babashka.org/#_running_tests and can repro the issue. homing in now. something is off with cognitect test runner

> Im missing something stupid, why cant this find the tests? Because the regular tools namespace doesn't look for .bb files perhaps?

not sure if there are any in that project

this is enough to cause this: bb -Sdeps '{:deps {io.replikativ/hasch {:mvn/version "0.3.7"}}}' -e "(require '[hasch.core])"

at least now down to a single ns 😄

nice, progress :)

this code specifically: https://github.com/replikativ/hasch/blob/main/src/hasch/platform.clj#L175

aha

I'll try locally too

on a side note, native image comes bundled now, no need for gu install ... removing that too. there is no gu btw

please don't remove it if it's not necessary, so it keeps working with older graal versions

oh yeah, if gu is missing, that won't work for 21+ then

i can keep it, there is a benign if check, will only fail if the native image bin is missing somehow

ah nice

please keep then, keep PR minimal with only relevant changes (haven't checked the PR yet btw)

bit jetlagged, literally no sleep last night on the plane ;)

yeah understandable. pretty much trying to nail this mystery bug now

alright, I got it compiled locally with 21

repro:

./bb -e '(defprotocol Foo (barf [_])) (extend (Class/forName "[B") Foo {:barf (fn [^bytes this])})'

nice

see if it can be smaller

bb -e '(Class/forName "[B")'

gotcha

./bb -e '(Class/forName "String")'

also same issue

so seems to be an issue with Class for Name then, perhaps it's possible to reproduce this in Java as well. What is done in SCI: look up the method forName reflectively on the Class class and then invoke it with the argument

I'll try a bit too

yeah the stack trace hints at reflection too

Can repro using this example:

public class ReflectionIssue {
    public static void main(String [] args) throws NoSuchMethodException, IllegalAccessException, java.lang.reflect.InvocationTargetException {
        var clazz = Class.class;
        var meth = clazz.getMethod("forName", String.class);
        var stringClazz = meth.invoke(null, "java.lang.String");
        System.out.println(stringClazz);
    }
}

compile with native image and then same error

nice, do we post on the Graal Slack?

I can start the convo

I think it's better to make a small github repo first with the problem, a script to compile the java + native image, given that $GRAALVM_HOME is set to 21, describe how to run it in the README. Then start convo, but I'm fairly certain they will ask you to just create the github issue so you might just want to do that

i'll make a repo

and then paste the github issue link in their slack

Also make sure to include a reflect config.json with String in there, else you can't reflectively call String

it's interesting that 20 also already had this problem

graalvm-jdk-20.0.1+9.1

ah interesting

maybe something useful in the release notes?

I'd just try every version until you find a version that works. Currently bb still uses 19

yeah we didnt update or we wouldve seen it

i meant if they changed something in the release notes of native image re: reflection

yeah

do you have the reflection.json at hand for this?

check resources/META-INF/native-image/babashka/babashka/reflect-config.json on your local system and only extract the String entry

These changes in 20 seem relevant:

Improved reporting of missing metadata in Native Image by throwing special exceptions. Native Image does not distinguish between missing reachability metadata and exceptions that were thrown by the Reflection API. For example, the ClassNotFoundException that is thrown when a class is not on the classpath, or when the metadata for a class is not present. Now Native Image users can catch metadata exceptions and debug their programs using the option -XX:ExitOnMissingMetadata to guarantee that all metadata entries are correct. Read more here. This is an experimental feature and is not on by default.
Introduced safe composition of Reflection and Resources metadata in Native Image. For example, reflective methods such as java.lang.Class#getDeclaredMethodsreturn are based on the reachability of other reflective elements. Adding new metadata makes more elements reachable and can change the program functionality. Thanks to the safe composition of metadata optimization, the native-image builder now ensures that every reflective call on java.lang.Class requires a metadata entry. Read more here.

so this is something we need to config?

define "this"?

as in something we need to add to the reflect config json or something?

not sure what metadata here refers to?

class metadata

I think it's just about error reporting when native image fails to find class data at runtime

right, so this is a bug i suppose

I'm not sure where to put that flag and I'm not sure if this has anything to do with the bug, but it could very well be

that flag = -XX:ExitOnMissingMetadata

i'll try this with the java code

https://github.com/lispyclouds/graalvm21-reflection-issue

if this looks okay will post it

when all this dust settles, wanna play with the G1 GC, pgo etc optiions too on the Oracle build, looks nice and could speed things up!

Interesting tidbit: The GraalVM install instructions don't mention GRAALVM_HOME anymore, just JAVA_HOME.

@rahul080327 I made a fix (workaround) for Class/forName in SCI + bb. Both branches are called prefab-static-methods but you can just use the branch of bb which will set the right SCI branch when using submodules (as CI does). you could try to merge this branch within your upgrade branch

running libtests locally with 21:

Ran 26 tests containing 93 assertions.
0 failures, 0 errors.
{:test 2323, :pass 14605, :fail 0, :error 0}

./bb -e '[(Class/forName "java.lang.String") (System/getProperty "java.version")]'
[java.lang.String "21"]

not sure yet about the new SCI feature, I think I'll also add the class as the first argument. It works like this:

{:classes {'java.lang.Class {:class Class :static-methods {'forName (fn [^String the-name] (Class/forName the-name))}}}

when a static method is provided via the config, the configurator is responsible for handling all the interop for you

so reflection is avoided

all tests pass, pulled in the latest process changes

the windows path is still an issue, need some help there

[linux-aarch64-static - graal21@f6ef5da75f902650df7609b1f3102a7485bb54a1 - 108115200]: https://37276-201467090-gh.circle-artifacts.com/0/release/babashka-1.3.185-SNAPSHOT-linux-aarch64-static.tar.gz [macos-amd64 - graal21@f6ef5da75f902650df7609b1f3102a7485bb54a1 - 92640304]: https://37279-201467090-gh.circle-artifacts.com/0/release/babashka-1.3.185-SNAPSHOT-macos-amd64.tar.gz [linux-amd64-static - graal21@f6ef5da75f902650df7609b1f3102a7485bb54a1 - 94472944]: https://37278-201467090-gh.circle-artifacts.com/0/release/babashka-1.3.185-SNAPSHOT-linux-amd64-static.tar.gz [linux-amd64 - graal21@f6ef5da75f902650df7609b1f3102a7485bb54a1 - 108993504]: https://37275-201467090-gh.circle-artifacts.com/0/release/babashka-1.3.185-SNAPSHOT-linux-amd64.tar.gz ~20M size increase. quite something

I already said a few times that using -O1 will reduce the image siZe and also cuts compilation time :)

Why did you revert classes.clj? It contains a workaround for the Graal bug

-O1 is closer to what CE does by default. I want to use that setting until we try what effect PGO has

Does

> Why did you revert classes.clj? It contains a workaround for the Graal bug i thought it was a merge goof up, putting it back

No it contains essential changes. No need to upgrade process though, it’s not related to this PR at all

yeah forgot it was from another branch, was surprised when comparing with master 😛

the process update fixes the java regex test

Aah ok then

How?

Anyway it’s fine then

https://github.com/babashka/process/commit/7b25a686121b2732072c63881402cc42adb8f976

https://github.com/babashka/process/commit/7b25a686121b2732072c63881402cc42adb8f976#diff-e4778d21b890a951f5e8825167d7ce5ddc2dcea8b3824faaa958c85da1ce038dL177

The vcvars thing in Windows isn’t necessary anymore I think, I saw a tweet about it by Fabio Niehaus

will try removing it

That is what fails the build right? I’m chatting from pho e right now

yeah that path doesnt exist

might be good to look up that tweet and docs

pushed without it, wont be any worse than now

Add -O1 to the Graal arguments too until we PGO

also do we try G1 GC?

This yields a 10mb smaller binary than before on macOS

Not yet, I want to keep things the same which is the point of O1

Don’t change too many thing in one PR if you don’t knkq what you’re doing, with G1 we can play around but I don’t know how to test that, different issue

removing that path helps appveyor

You forgot Windows O1 ;)

It’s really fast compilation if you compile with O1 on Mac m1/m2, like 1 minute or so compared to 3 or 4

> with G1 we can play around but I don’t know how to test that i can possibly come up with a (ThePrimeagen inspired) stress test to make the GC work with lots of objects living at different lifetimes

Ok different branch though after this one

yeah after this is merged

To me startup size and performance matter but in that order probably

Don’t know how G1 affects that, but needs to be included in benchmark

can do a different release with G1 if promising

will hammock a bit on a GC specific benchmark, dont think we have one right?

Indeed. Start with a problem statement maybe ;)

There, 10mb less instead of 20m bloat

and cirrus ran 2x faster

Told you ;)

changes look good from my side, lemme know if the way im downloading and setting the vars looks okay

Ok I’ll look tomorrow. First gonna merge those SCI changes

Thanks so far!

FYI: While setting up my Windows VM yesterday, I got an error about failing auto-setup of windows build env. While looking for the error msg, https://github.com/oracle/graal/blob/69f247be3fab0a7ca71a8059c4366713aefb3d5a/substratevm/src/com.oracle.svm.driver/src/com/oracle/svm/driver/WindowsBuildEnvironmentUtil.java#L61-L127. Looks like it is fine if you want call vcvars bat file yourself, but if you don't native-image will try to do it for you.

I wouldn’t be surprised if there was something in the changelogs about this since I also saw a tweet about it

Ya probably. Somewhere!

https://x.com/fniephaus/status/1622595666827436034?s=20

Also he has a tweet about a new build time feature, perhaps relevant to graal build time

I haven't been on X since it was Twitter. Maybe I'm missing out.

I wonder if he was talking about something related to: https://clojurians.slack.com/archives/CAJN79WNT/p1695137870805729?thread_ts=1695136706.616289&cid=CAJN79WNT

ok, change "/latest/" in the url to "/archive/" and we should be good

according to Niephaus

pushed those changes

merged

awesome! 😄

nice, with pgo, the loop examples becomes almost 2x faster:

$ ./bb -e '(time (loop [val 0 cnt 10000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val)))'
"Elapsed time: 318.995125 msecs"
10000000

$ /tmp/bb -e '(time (loop [val 0 cnt 10000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val)))'
"Elapsed time: 584.00275 msecs"
10000000

and the binary is equal in size

seems like a win

beauty

this is better than -O2/3?

keeping the size aside

pgo uses -o3 automatically

nice

it does mean that we have to compile the binary twice on CI, once for instrumentation, once for optimizing

not sure if I find that worth the hassle to be honest

we can do this only on the master branch

unless the .iprof file can be shared over multiple builds

the lib tests run in 27 seconds with the pgo optimized binary and 29 with the -O1 binary. I think for typical scripts people won't notice a damn difference

but it's nice to know that this works

for fun I'm just going to try to re-use the iprof file on CI and see what happens...

I bet you can't re-use the same iprof file for different builds, so I expect things to blow up

or can use it on a linux vm and the windows build locally?

i can try the linux one here if that can be uploaded

I'll share the iprof file through dropbox

https://www.dropbox.com/scl/fi/nkid0nr91bxpg9su9i6gi/default.iprof?rlkey=nxliwcarxcsksiwau2emazn2a&dl=0

curl -L works on that link

and then compile with

script/uberjar && script/compile --pgo=default.iprof 

I'm going to try this on cirrus only in a branch

compiling, hasnt complained yet

CPU on fire

on thinkpad?

yeah

guessed so ;)

compiled

heh:

bb -e '(time (loop [val 0 cnt 10000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val)))'
"Elapsed time: 769.122283 msecs"
10000000
./bb-pgo -e '(time (loop [val 0 cnt 10000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val)))'
"Elapsed time: 259.723079 msecs"
10000000

ooh nice, and sizes?

we can reuse it

(compare pgo to the graalvm21 one without pgo)

du `which bb`
64508   /usr/local/bin/bb
du ./bb-pgo
61968   ./bb-pgo

i run bb from master

nice, this sounds about right

ok, I guess we'll just do the re-use of the pgo then ;)

its VERY noticeable, the perf difference on my machine

as in?

the pgo one is much faster with the loop, feel wise, not just numbers

that isn't scientific ;)

well, that gives more joy

this could be done in the gen-ci.clj right? the reuse

I guess I could make a repro to upload the iprof file periodically

*repo

gen-ci would only work for circleci stuff

yeah

I want to not do any extra builds whatsoever

need to pull from a common place, repo should be okay

does the pgo beat python even more?

tadaaa https://github.com/babashka/pgo-profiles/releases/tag/2023.09.27

yes, python is like 850ms or so on my machine

see my slides of strangeloop, it's in there

also we could compare with uclj too 😛

bb is already faster than uclj ;)

in most cases

but of course, could always try harder ;)

i'll look into hooking in the iprof file into the CIs

I'm already on that in a branch

called pgo

nice

guess we just make it part of the compile script right?

I guess the nix folks are going to not like it perhaps

yeah, maybe download it externally and supply to the script instead of the script downloading it?

or perhaps we could use git deps or so..?

or we use pgo only iff there is a pgo file locally

and then display a warning if there isn't

the pattern of compile --pgo=... looks okay right? people will add it when they need to?

we can add it in our CI

yes, so CI adds the arguments, not part of the script

makes sense

yes

that's what I also wanted to do for O1 but perhaps O1 is nice enough as a default for people compiling locally

yeah doesnt change much from whats released

they would be using Rust or Haskell if they wanted to warm their rooms by default

$ ./bb -e '(time (loop [val 0 cnt 10000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val)))'
"Elapsed time: 312.083 msecs"
10000000

since perhaps those pgo profiles refer to OS-specific things somewhere

possibly. interestingly my linux amd64 binary runs faster than the macos aarch64 one?

also clojure builds aren't reproducible, class names are using random numbers, but it doesn't really seem to affect things

how much faster?

oh yes, I seee

*see

that is very interesting

since m1 is generally faster

then this is like ... 3x faster than the previous bb on linux amd64 haha

yeah from an pgo on mac

haha

wild

i should really work on the GC stressing thing, wanna see if G1 is nicer

yeah, I think there was an xml example once where bb really didn't do well, because of all the laziness + GC

lemme know of it if you have it handy

trying to find it, but I can't

having an example where bb does terrible with GC would be good

yeah ThePrimagen's code to screw with V8's GC should work well i think

I guess I could also tune clj-kondo by linting a shitload of code during instrumentation

and clojure-lsp...

bb has been influencing their build pipelines anyways 😉

ok added the profile to all the builds now: https://github.com/babashka/babashka/tree/pgo

btw circle is deprecating their macos x64 gen1 environments by october 2. I moved most of the stuff to gen2 which will be deprecated in january or so, the next step is to just use their aarch mac machines then and use rosetta to build for x64. I've already tested this and works fine

the bottom line is that mac x64 hardware is disappearing

I wonder if that will affect github actions too, but perhaps they bought their own crap

hmm on Windows it says:

Graal compiler: optimization level: 1, target machine: x86-64-v3, PGO: off
 

probably because script.bat doesn't pass arguments yet

the joys of .bat scripts. perhaps I should finally move those scripts to bb as well :P but no, nostalgia prevails ;)

my Windows computer stopped working btw :(

a 3k machine, but can't power it up anymore

Maybe it has Covid?

it happened before, then it miraculously worked again, and then it didn't again :(

> the joys of .bat scripts die die, bat bash all die

maybe we need to target some Windows confs too with bb scripting

To compete with the .NET folks with a weird JVM lisp scripting language? Makes total sense

Less weird than bat and powershell

Is it a hardware or software issue @borkdude? Can you reinstall Windows?

Hardware unfortunately, doesn’t power on

Oh... so you can't even run one of those bootable hardware testers... that sucks!

I opened it recently and then it randomly started working again

Loose cable or chip maybe?

Yeah something like that probably

Does someone know how to scroll to the end of a thread on slack mobile? It’s taking about a minute now

maybe always go to the Threads menu first instead of the thread directly and then it should be towards the end? hit the answer button there then

PR welcome, I'm curious to what effect it has on the binary size. The -O1 setting yielded the best results locally for me. Not sure if I'm immediately merging it, but preparation in a PR / branch seems good.

There is a script/bump-graal script, but this only updates a version number. All the urls have changed now though, so this is where the PR would be valuable

Did you find comfort with the perhaps more restrictive Oracle license or are you going to more cautiously stay with the Community Edition?

And lemme know if you want help bumping bb process native test.

I had dinner with Thomas Wuerthinger last night and he said it's only limiting when you sell the binary but this has been the case with CE too. No problems

@lee sure!

Ah very good to know! What if one were to use bb in a paid service without distributing? Still ok?

yes

Should we try the enterprise one then?

Thomas told me "tell me whatever you'll need in GraalVM and we'll get it done" with a smiling face, I had some good laughs with that guy ;)

yeah

let's just move to Oracle version, then I'll be able to try PGO as well which should make the loop example faster and the binary smaller as well

And I too made acquaintances with Alina in Oslo too, all set with the graal team now 😆

Ah nice :)

Maybe we should visit more Java conferences then. I tried JFall in the Netherlands, but unfortunately their CFP closed a few days before. I should set reminders or so

Sneaking in bb scripting in a Java/non clojure conf is always appreciated I’ve seen 😆

Rather bashing on bash talks/workshops

You two are mega connected! You got swagger! You need bling. To wear some GraalVM chains and rings!

One of the keynote speakers here at STL (Julia Evans who makes amazing little comics) did a pretty good job of bashing on bash. I should just refer to that section of her talk in the README of bb when the talk comes out

As soon as @borkdude designs some for the merch shop

Btw, I've got some GraalVM stickers now to hand out to people, I think I'm being assimilated too by Thomas now ;)

Run Thomas, it’s a trap!

trap is also something in bash

(https://www.linuxjournal.com/content/bash-trap-command)

Oh you are in deep, sir!

Hey, Oracle should def sponsor your work @borkdude, you could tell Thomas, he could make it happen maybe.

https://twitter.com/borkdude/status/1705553812289716617/photo/1

I wouldn't be against that but Oracle has provided me with GraalVM native-image which is already a pretty awesome thing to give away :)

It is a win-win.

according to https://www.graalvm.org/downloads/ and https://github.com/graalvm/graalvm-ce-builds/releases/tag/jdk-21.0.0 GraalVM doesnt seem to have its "own version" now? its just jdk21?

am i understanding it right? and we dont need the GRAALVM_VERSION var any more?

or the version now is jdk-21.0.0?

Yes, the version now matches the JDK. I described this a bit here: https://github.com/clj-easy/graal-docs#graalvm-version-scheme-change

I think they still use the old version scheme for their jars though (what else could they do, right?). Example: https://mvnrepository.com/artifact/org.graalvm.sdk/graal-sdk

I see why they did what they did, but it is all a bit awkward for users to adapt.

well i'll have to wrangle some bash which downloads it, one time headache

I would say the new env var should contain at least 21

I did some https://github.com/babashka/process/blob/d24961a8b101ee1a95569256c9ddb260d0f9bb36/.circleci/config.yml#L105. Made use of the https://github.com/babashka/process/blob/d24961a8b101ee1a95569256c9ddb260d0f9bb36/script/circle_ci.clj#L17-L27. Not sure if that is of any use to you. Have not updated to GraalVM JDK 21 yet, will do so soon.

https://github.com/babashka/babashka/pull/1624

had to move some bits around, lemme know if there is a better way. also not sure if the windows one has better way to extract

does this mean we dont need cirrus? https://discuss.circleci.com/t/macos-intel-support-deprecation-in-january-2024/48718

Yeah probably

But I’m going to actually use circles Mac aarch to build for x64 via Rosetta, as described in the issue

No need to change cirrus imo, never had any problems so far with them. If it works don’t touch it

better cond seems to have an interesting error:

Testing better-cond.core-test

Ran 1 tests containing 11 assertions.
0 failures, 0 errors.
Fatal error: Cannot invoke method that has a @CallerSensitiveAdapter without an explicit caller

or something else is failing, one of the libs?

Doesn’t ring a bell. Does it fail consistently on every OS/arch? I’m about to board a flight

failed in all, running again now, trying to dig deeper

i  SP 0x00007fff619a04d0 IP 0x00005607b743617e size=32    com.oracle.svm.core.jdk.VMErrorSubstitutions.shutdown(VMErrorSubstitutions.java:148)
  i  SP 0x00007fff619a04d0 IP 0x00005607b743617e size=32    com.oracle.svm.core.jdk.VMErrorSubstitutions.shouldNotReachHere(VMErrorSubstitutions.java:141)
  A  SP 0x00007fff619a04d0 IP 0x00005607b743617e size=32    com.oracle.svm.core.util.VMError.shouldNotReachHere(VMError.java:90)
  A  SP 0x00007fff619a04f0 IP 0x00005607b73e5c44 size=64    com.oracle.svm.core.reflect.SubstrateMethodAccessor.invoke(SubstrateMethodAccessor.java:112)
  i  SP 0x00007fff619a0530 IP 0x00005607b8e28d7a size=144   java.lang.reflect.Method.invoke(Method.java:580)
  A  SP 0x00007fff619a0530 IP 0x00005607b8e28d7a size=144   sci.impl.Reflector.invokeMatchingMethod(Reflector.java:172)
  i  SP 0x00007fff619a05c0 IP 0x00005607b8e38e4c size=160   sci.impl.interop$invoke_static_method.invokeStatic(interop.cljc:104)
....

Could be. Hopefully we’ll be able to reduce it down to something we could report to Graal

i'll try to repro locally, feels like a Graal hiccup

also if a windows user can help: https://ci.appveyor.com/project/borkdude/babashka/builds/48109114 updated visual studio to 2022, min required for Graal 21, not sure of the path

Taking off new to New York ✈️

have fun!

To transfer back home actually

same tests passes on my intel linux machine

Cool is it aarch specific you think ?

fails in all the os+arch on circle

You did use the 21 version right?

it might have used my system bb, checking properly

./bb -e '(System/getProperty "java.version")' 
"21"

yes failed now

Tests from these libs causes the issue: • meander • cli matic • hasch • binf • aviso/pretty • portal • cljc.java-time • malli • clj-yaml • prismatic/schema • core-match finding more...

if you remove the tests progresses. all have the same Cannot invoke method that has a @CallerSensitiveAdapter without an explicit caller feels like some code here triggers some reflection path in sci?

added all of this to the PR

FWIW, all went very smoothly for babashka/process bump: https://github.com/babashka/process/pull/145

I'll take a look probably in a few days after recovering from the amazing Strange Loop

im getting a bit confused by the merge conflicts when merging master, some help would be nice @borkdude

the sci submodule things specially

already done

awesome!

i wanna do one more change in the Dockerfile

I added a comment about getting rid of the version in the directory

I wonder if we could get stuck with older graalvm versions this way accidentally?

perhaps not, just double checking :)

I'm trying to ask how to get a more specific version of graalvm via a link in their slack now

I'd also be fine to hardcode 21+35.1 for now, and we can change it manually once it changes

yeah saw it now, it seems comparing SHAs is an option according to their docs

since I expected these version number to only change every 6 months and at least I'm aware that something changes

the 35.1 could change more frequently than 6 months i think

thats probably some security patches etc

lemme try to factor in this version

I have tried manually but I couldn't get it to work

e.g.: curl -vLO

yeah dont think its there

should we say GRAALVM_VERSION=21+35.1 when downloading? making the URL from this is harder

?

what is the GRAALVM_VERSION var that we should set in the CI? i use that to make the download url

It used to be 22.3.1

but they moved to a new version scheme

yeah and it lined up with download url too

to align with openjdk

this different version inside the tar is complicating it. i could call it something and hardcode it somewhere

those graalvm people are in an inside conference though (I was invited for it, but I suspected something like covid would happen)

so they won't reply until Thursday or so

right, lemme put something together in the PR

this is their example URL for a more specific version:

so I'd expect curl -vLO or so to work

but it doesn't

yeah was anticipating this and thought its either crappy scripts or some loss of precision

if there is some endpoint to query the specific version, could be useful too

I have bad experiences with upgrading to newer versions of graalvm so I don't trust this to happen automatically

this is why I want the specific version

set two vars GRAALVM_MAJOR_VERSION and MINOR_VERSION? use them to make the URL and untarring?

we first should know what the url is, I still dont' knwo

well i dont see anything more specific than the ones we found, can wait til they answer back too

ok

let's wait

https://github.com/oracle/graal/discussions/7498

interestingly https://download.oracle.com/java/21/latest/jdk-21_linux-x64_bin.tar.gz doenst have that subversion when untarring

another idea, we could reverse engineer the graalvm action to see what its constructing

looking at it

Is the +35 something that ever gets bumped independently? This downloads: https://download.oracle.com/graalvm/21/archive/graalvm-jdk-21_linux-x64_bin.tar.gz

yeah my feeling is with something > 35 the URL could be the same

Archive implies a static thing, but I guess we don't know until we know.

21 is definitely not a full number so they imply 21.latest

I can't find any useful info in that javascript code

they seem to be looking at git tags

https://github.com/oracle/graal/tags

They oddly did not specify minor and patch for this 21 release, which makes it all the more confusing.

@rahul080327 those tags are for CE

there is vm and vm-ce

21 is the JDK version number, they aligned with OpenJDK versioning which releases every 6 months

not sure if that matters?

those tags are for CE and EE, not relevant here since we are upgrading to Oracle GraalVM which is neither CE or EE

ah

unfortunately we're redirected to some oracle download url and we can't inspect what lives on that server

i thought EE was the Oracle one? otherwise we cant use the official action to install the oracle one?

the readme links to the oracle one from EE

no, it isn't. EE used to be the commercial version, Oracle GraalVM is not EE

you cannot use EE in production without paying

so let's not go there

right

the builds are failing with the graalvm21 branch btw

oh it's that process thing

let me fix that

ah the process submodule updates isnt there

pushed

I can finally fix this issue too now with that new SCI feature:

./bb -e '(Thread/sleep (/ 1 2))'
----- Error --------------------------------------------------------------------
Type:     java.lang.IllegalArgumentException
Message:  No matching method sleep found taking 1 args
Location: <expr>:1:1

----- Context ------------------------------------------------------------------
1: (Thread/sleep (/ 1 2))
   ^--- No matching method sleep found taking 1 args

https://github.com/babashka/babashka/issues/1513

the seem to ignore all the dir nesting https://github.com/graalvm/setup-graalvm/blob/main/src/utils.ts#L87C21-L87C21

yay it works:

borkdude@m1 ~/dev/babashka (issue-1513*) $ ./bb -e '(Thread/sleep (/ 1 2))'
borkdude@m1 ~/dev/babashka (issue-1513*) $ ./bb -e '(Thread/sleep (/ 1 2) 234)'
borkdude@m1 ~/dev/babashka (issue-1513*) $ ./bb -e '(Thread/sleep (/ 1 2) (/ 1 234))'
borkdude@m1 ~/dev/babashka (issue-1513*) $ ./bb -e '(Thread/sleep (java.time.Duration/ofSeconds 1))'

@lee remember that issue we had with etaoin and Thread/sleep + bb? it's now properly solved :) (see issue 1513 where there's a reference to etaoin)

Even with Covid, you remain productive! simple_smile