Fork me on GitHub
#graalvm
<
2019-11-20
>
sogaiu14:11:03

still no sign of land, how long is it? 33 days, sir. errm, i guess a .tar.gz and .zip count as releasing? haven't found release notes yet though...

sogaiu16:11:18

> With the major update to the 19.3 version, we announce the first release of GraalVM based on JDK 11

sogaiu16:11:18

> GraalVM 19.3 switched to using the JDK native code instead of manual substitutions. For GraalVM Native Image this switch to Java Native Interface (JNI) platform enabled the possibility to provide support for JDK 11 and extended support for Windows OS. It has no impact on startup time or memory footprint, and eliminates the need for shipping JDK libraries such as libsunec.so along with native images that use Java crypto services. GraalVM now ships with statically linkable version of the JDK libraries. > > Note that the sunec native library of SunEC provider gets statically linked into an image if required (see #951). Thus native images do not depend on the sunec shared library anymore at runtime.

sogaiu16:11:17

> a preview of GraalVM Community Edition on JDK 11 for ARM64 architecture. It includes the support for all JVM languages.

sogaiu16:11:21

thanks -- got the url wrong -- the pattern changed ๐Ÿ™‚

borkdude16:11:36

yeah, it seems they just released it when I looked ๐Ÿ™‚

sogaiu16:11:00

he he i lose ๐Ÿ™‚ btw, there are now java 8 and java 11 separate downloads i guess

borkdude16:11:21

> Note that the sunec native library of SunEC provider gets statically linked into an image if required (see #951). Thus native images do not depend on the sunec shared library anymore at runtime. Wow, that's great news for babashka

sogaiu16:11:04

it seems like it would be beneficial at least for all things that use ssl?

borkdude16:11:28

I'll try it out

sogaiu16:11:35

does the arm64 thing mean there's a better chance of some of your stuff working on android?

sb16:11:39

I think, they solve https://gluonhq.com/ they use GraalVM

sb16:11:49

Im not sure.. but maybe.. I read that

sogaiu16:11:38

thanks for the link -- will take a look

sb08:11:19

Ok, still under progress.

borkdude16:11:55

I guess so? @sb was already trying this on ARM I think?

sb16:11:54

yes, on aarch64 works fine

sb16:11:04

compile flow and use too

sb16:11:19

I tested on Raspberry PI4

sogaiu16:11:22

that would be great -- would love to be able to do some things on a tablet locally

borkdude16:11:20

maybe using sci there could be a CLJ repl on Android again

borkdude16:11:32

just for playing around

sogaiu16:11:39

yes! have been waiting so many years for this

borkdude16:11:49

wasn't there one years ago?

borkdude16:11:31

there was also an issue posted at babashka: https://github.com/borkdude/babashka/issues/71 about Android. if anyone's interesting in maintaining that

sb16:11:58

That is a great idea! ๐Ÿ‘ Unfortunately I donโ€™t have Android phone.. just a very old..

sogaiu16:11:33

i used to do clojure on android dev, yes, but various drawbacks

sogaiu16:11:00

afaik, getting java to work with termux has not been successful

sogaiu16:11:08

perhaps that has changed recently

borkdude16:11:29

but babashka can be compiled to native architecture. I don't know what it entails exactly to get this into termux, I'm unfamiliar with it

sogaiu16:11:08

iirc, their packaging format is based on .deb

borkdude16:11:09

first attempt with Graal jvm 11 19.3.0:

Could not resolve java.lang.UNIXProcess for reflection configuration.

gklijs17:11:38

If you use java 11 you get the same?

borkdude17:11:22

yes, I tried that first. the issue has already been found now (see #native-image on GraalVM slack)

borkdude17:11:27

it's an error in 19.3.0

sogaiu18:11:40

@lee tnx for that

sogaiu18:11:26

> GraalVM Native Image functionality now also supports Java 11 code as an early adopter technology feature so expect problems with java 11 stuff i guess ๐Ÿ™‚

sogaiu18:11:32

ah, the builds are now under a different repository's releases section

borkdude18:11:16

upgrading to JVM 8 worked now, there is a problem when you have a reflection config for all methods of Thread ,since that also makes deprecated methods accessible and they try to link those

๐Ÿ‘ 4
borkdude19:11:07

@sogaiu now that they seemed to have fixed static linking for Windows, maybe it's worth a try for clj-kondo again

sogaiu19:11:29

indeed -- i am unexpectedly away from my windows dev env for much longer than expected. i will investigate what i can cobble together with what i've got at hand.

borkdude19:11:09

I'll try upgrading clj-kondo to 19.3.0 and see what appveyor makes of it

sogaiu19:11:35

๐Ÿคž

lvh20:11:56

I feel like they buried the lede there, Iโ€™m on my way to Conj so I canโ€™t check right now but it looks like they fixed https://github.com/oracle/graal/issues/1336

borkdude20:11:43

@lvh Yes, trying this out for babashka now (see #babashka)

borkdude20:11:47

It seems to work

lvh20:11:58

Praise Graal!

borkdude20:11:48

@taylor ^ no more SSL trouble for clojurl as well when you upgrade to 19.3.0

taylor20:11:24

Nice! Will update repo

lread21:11:48

Heya, unrelated to the 19.3.0 release, I've been looking at why my rewrite-cljc tests bloat native-image RAM usage (so much so I can't run them on circleci). I've been experimenting with hello world GraalVM apps. What I see is that clojure.test discovers what tests it will run at runtime using functions such as ns-interns. When I brought an ns-interns call into my hello world GraalVM app, it exhibited similar bloat and exe size to my hello world test GraalVM app. To avoid the bloat, I'm thinking a cljs test approach could work. If I understand, out of necessity, cljs builds up tests to run at compile time via macros.

lread21:11:24

By the way (might be old news to the more experienced, but), I find GraalVM's native-image expert option -H:+PrintAnalysisCallTree useful in figuring out what it being brought into a native image.

borkdude21:11:44

I've never used it, but it seems useful indeed! Maybe something for clj-graal-docs?

lread21:11:51

good idea, will do!

sogaiu22:11:54

in 19.3.0, it looks like arguments to native-image that include = need to be wrapped in double quotes

sogaiu22:11:45

e.g. it appears one must write something like:

"-H:Name=constdin" ^
where before the following would work:
-H:Name=constdin ^

lread22:11:17

I shall review clj-graal-docs, thanks for the tip @sogaiu.

๐Ÿ‘ 4
sogaiu22:11:36

borkdude encountered a (possibly) related issue with glob / wildcard (?) expansion -- a query has been made at the graalvm slack, so may be we'll have an answer on that before too long

sogaiu23:11:40

it's a bit early to tell, but: https://github.com/oracle/graal/issues/1469 may have been addressed. have only tested briefly, but i'm not seeing the problems i saw before.

lread23:11:31

What OS did you find the double quote issue on @sogaiu?

sogaiu23:11:46

we were both trying windows 10 i think

sogaiu23:11:01

borkdude was using appveyor and i'm trying a vm

lread23:11:48

oh I see... so macOS and linux are likely ok?

sogaiu23:11:59

haven't tried ๐Ÿ™‚

lread23:11:08

I'll give it a go on macOS and linux

sogaiu23:11:36

i think borkdude may have tried building babashka -- so he may know about macos

borkdude23:11:55

I didn't see problems with a non-Windows

lread23:11:22

what shell are you two using on Windows?

sogaiu23:11:49

i used powershell, powershell core, windows command prompt and windows 7.1 sdk prompt (probably just command prompt with customizations)

sogaiu23:11:07

i think the warning message is generated by native-image

lread23:11:08

so not a bash shell

sogaiu23:11:12

definitely not ๐Ÿ™‚

borkdude23:11:04

no matter how many quotes I add, the warning stays there

sogaiu23:11:39

first i got the warning, and the build failed

lread23:11:47

ok, so I don't have anything to correct in clj-graal-docs yet as we are all bash-ful there currently.

sogaiu23:11:49

then i added quotes, still got the warning, but the build succeeded

borkdude23:11:12

This happens on AppVeyor now:

C:\projects\clj-kondo>echo (inc 1)   | clj-kondo --lint - 
linting took 14ms, errors: 0, warnings: 0
Looks good to me

sogaiu23:11:57

@lee perhaps you're right -- i don't have data for running on linux yet as i'm waiting on the arch linux package (the maintainer was making some queries at the graalvm slack)

lread23:11:10

fwiw, I have used the git bash shell on Windows https://gitforwindows.org/

sogaiu23:11:01

that's what i've got too -- iiuc, at least the last i checked, native-image building won't work unless you use the windows 7.1 sdk prompt

sogaiu23:11:16

this may have changed in recent times, but that was the case originally

lread23:11:44

ah, ok, I was using it for cljs work, not graal work...

sogaiu23:11:08

i use it for "things-other-than-graal" ๐Ÿ™‚

borkdude23:11:40

There is still something wrong with the resource configuration though:

C:\projects\clj-kondo>echo (inc)   | clj-kondo --lint - 
linting took 16ms, errors: 0, warnings: 0
This simply means that clj-kondo could not find the transit file that has all the information about clojure.core (and thus the inc function)

borkdude23:11:57

This is probably not a new problem though

sogaiu23:11:58

i'll do some digging about .*