Fork me on GitHub
#rewrite-clj
<
2019-06-17
>
sogaiu08:06:25

@lee @borkdude i have been trying out rewrite-cljs-playground (cljc-spike-2 branch) in a couple of projects that use native-image. a few things i've noticed are: 1) the resulting binary is close to 40 MB, while with a slightly patched rewrite-clj, the results are between 12-14 MB 2) i have not succeeded in building with native-image with the cljc-spike-2 branch with clojure 1.10, though 1.9 works 3) using the slightly patched rewrite-clj leads to successful native-image builds with clojure 1.9 and 1.10

borkdude08:06:54

what did you slightly patch?

borkdude09:06:32

this is probably one reason I’m conservative in adopting alternative implementations of rewrite-clj: right now I know it works with GraalVM. minimal changes could break or bloat the binary 😕

borkdude09:06:00

and if it works, I don’t expect that many changes, because Clojure moves slowly

lread10:06:07

Interesting @sogaiu, thanks for sharing! Am I right in saying that supporting GraalVM is a bit of a black art? With GraalVM growing in popularity, I suppose a popular library should support it.

borkdude10:06:59

there are some issues in clojure 1.10 regarding locking. there’s a JIRA issue for it. some functions use locking which causes an error

borkdude10:06:21

if you use clojure 1.9 that error goes away. I’m just hoping they will add that patch to 1.11, because it’s holding me back from using things like spec in GraalVM

sogaiu22:06:35

@lee my impression is that graal-related stuff is evolving. some factors i've noticed that make it (and getting windows parts to work) challenging include: 1) clojure is quite dynamic and from reading the issues on github for graal, my sense is that there may be no clojure-familiar folks involved on the dev side, and they didn't really consider the clojure use case (or at least didn't prioritize for it) -- having said that, the graal folks seem fairly receptive. i'm hoping their future activities try to take clojure-like uses more in to account 2) windows development lags for both clojure (e.g. the clj / clojure tool) and graal, maknig windows support for native-image a fair bit more work than for os' with unix origins 3) generally windows doesn't seem as geared toward dev out-of-the-box (or with a small out of tweaking) as unix-based things, so getting things working for devs seems to be a fair bit more effort than with say, macos or whatever distribution of linux. traditionally, i've found automating things on windows to be quite a bit more work than unix-based things, and we have odd hacks like autohotkey and friends. in recent times, with things like powershell core, it seems there may be some improvements, but i'm only starting to pay attention again after years of not looking -- didn't even know there was a "developer mode" which i guess gets you among other things the ability to create symlinks without a huge amount of hassle. i'm guessing we're all familiar with these points, but it seemed worth putting them down together. ah, i think i posted the following summary of native-image + clojure on windows to #clj-on-windows, but fwiw: https://gist.github.com/sogaiu/e079cd770051685c46ab24b6658effcf

sogaiu22:06:42

@borkdude @lee i don't know how to get to the bottom of why the cljc-spike-2 branch seems problematic with the native-image + clojure 1.10 combination, but it would be nice to understand why. may be that info would be useful in the context of considering the future of rewrite-clj*

sogaiu22:06:17

@borkdude thanks for the clojure 1.10 + locking info. i also hope a patch will be added to clojure...or that graal changes appropriately 🙂 is it what's mentioned in the 2nd paragraph of this? http://insideclojure.org/2019/04/19/journal/#clojure-1101