This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (12)
- # announcements (7)
- # aws (6)
- # babashka (36)
- # beginners (161)
- # boot (1)
- # calva (6)
- # cider (21)
- # clj-kondo (13)
- # cljs-dev (28)
- # cljsrn (1)
- # clojars (3)
- # clojure (13)
- # clojure-colombia (1)
- # clojure-europe (10)
- # clojure-spec (12)
- # clojure-uk (47)
- # clojuredesign-podcast (2)
- # clojurescript (67)
- # datascript (8)
- # datomic (21)
- # duct (3)
- # emacs (6)
- # events (1)
- # fulcro (6)
- # graalvm (98)
- # jobs (1)
- # kaocha (18)
- # luminus (1)
- # malli (7)
- # off-topic (56)
- # pathom (5)
- # re-frame (18)
- # reagent (3)
- # reitit (9)
- # remote-jobs (3)
- # rewrite-clj (10)
- # ring (1)
- # shadow-cljs (155)
- # spacemacs (2)
- # sql (5)
- # tools-deps (27)
- # vim (86)
- # xtdb (2)
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...
> With the major update to the 19.3 version, we announce the first release of GraalVM based on JDK 11
> 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.
> a preview of GraalVM Community Edition on JDK 11 for ARM64 architecture. It includes the support for all JVM languages.
> 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
does the arm64 thing mean there's a better chance of some of your stuff working on android?
there was also an issue posted at babashka: https://github.com/borkdude/babashka/issues/71 about Android. if anyone's interesting in maintaining that
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
first attempt with Graal jvm 11 19.3.0:
Could not resolve java.lang.UNIXProcess for reflection configuration.
yes, I tried that first. the issue has already been found now (see #native-image on GraalVM slack)
some more words on 19.3.0 release: https://medium.com/graalvm/graalvm-19-3-0-dfdb6f4ec8ed
> 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 🙂
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
@sogaiu now that they seemed to have fixed static linking for Windows, maybe it's worth a try for clj-kondo again
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.
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
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.
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.
in 19.3.0, it looks like arguments to native-image that include = need to be wrapped in double quotes
e.g. it appears one must write something like:
where before the following would work:
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
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.
i used powershell, powershell core, windows command prompt and windows 7.1 sdk prompt (probably just command prompt with customizations)
ok, so I don't have anything to correct in clj-graal-docs yet as we are all bash-ful there currently.
This happens on AppVeyor now:
Looks good to me
C:\projects\clj-kondo>echo (inc 1) | clj-kondo --lint - linting took 14ms, errors: 0, warnings: 0
This is the relevant artifact if anyone has Windows and wants to try it out: https://ci.appveyor.com/api/buildjobs/cvvynbmt0w2183o9/artifacts/clj-kondo-2019.11.08-SNAPSHOT-windows-amd64.zip
@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)
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
There is still something wrong with the resource configuration though:
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)
C:\projects\clj-kondo>echo (inc) | clj-kondo --lint - linting took 16ms, errors: 0, warnings: 0