This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-04
Channels
- # announcements (5)
- # beginners (56)
- # calva (2)
- # cider (30)
- # circleci (2)
- # cljsrn (90)
- # clojars (3)
- # clojure (18)
- # clojure-dev (9)
- # clojure-europe (3)
- # clojure-greece (14)
- # clojure-ireland (6)
- # clojure-italy (6)
- # clojure-nl (7)
- # clojure-norway (1)
- # clojure-spec (1)
- # clojure-sweden (3)
- # clojure-uk (14)
- # clojurescript (52)
- # cursive (5)
- # data-science (9)
- # datomic (3)
- # emacs (26)
- # expound (11)
- # figwheel (3)
- # figwheel-main (6)
- # fulcro (24)
- # garden (1)
- # graalvm (101)
- # liberator (1)
- # mount (1)
- # off-topic (1)
- # pathom (27)
- # portland-or (2)
- # reagent (13)
- # reitit (2)
- # ring (1)
- # shadow-cljs (10)
- # spacemacs (11)
- # sql (6)
regarding that, i read somewhere that it can help to label the issue appropriately. in this case i guess substratevm might be a good tag.
this is where i saw it: https://github.com/dundalek/closh/issues/93#issuecomment-428124839
feel free to make a small repro yourself, if you want, I'm not able to run Windows at the moment on this borrowed laptop
I'd say: - make a small leiningen project code:
(defn -main [& args]
(println (slurp *in*)))
- add instructions how to build an uberjar
- compile the uberjar in linux and windows
- show that the windows version behaves differently / incorrectly
- attach a link to the repo + the uberjar itself (so they don't have to build it if they don't want to) to the issueI think they're going to be looking at the uberjar .class files directly, and they don't care too much if it was built with Java or Clojure. That's my assumption but I could be wrong
i will consider. btw, i tried the following variation of the code above and found the produced native image binary on windows works in all 4 shells (cmd.exe, sdk cmd.exe, windows powershell, powershell core):
(defn -main [& args]
(binding [*in* (java.io.InputStreamReader. (java.io.FileInputStream. "project.clj"))]
(println (slurp *in*))))
what if you wrap that in a LineNumberingPushbackReader
like Clojure itself does?
final static public Var IN =
Var.intern(CLOJURE_NS, Symbol.intern("*in*"),
new LineNumberingPushbackReader(new InputStreamReader())).setDynamic();
You mean like this?
(defn -main [& args]
(binding [*in* (LineNumberingPushbackReader. (java.io.InputStreamReader. (java.io.FileInputStream. "project.clj")))]
(println (slurp *in*))))
for the console, i have tried that combo and the thing that made a difference was setDynamic -- i haven't tried for a on-disk file yet, though so i will
Maybe test for stdin:
(defn -main [& args]
(let [in (clojure.lang.LineNumberingPushbackReader. (java.io.InputStreamReader. System/in))]
(println (slurp in))))
to see if the problem is with binding dynamic vars, or with LineNumberingPushbackReaderwhat about:
(defn -main [& args]
(binding [*in* (java.io.InputStreamReader. System/in)]
(println (slurp *in*))))
i tried your let version and same results -- no stacktrace, worked fine. will try your latest binding code
same results for latest binding code. i tried various combinations before (and have taken notes). the main difference i've noticed so far is the combination of in with its default leading to problems, but also defining a dynamic var and setting it to match what in gets initialized to leads to the stacktrace. what is quite noticeable is that the stacktrace happens in some of the shells, but interestingly, not all of the shells.
my latest candidate for repro code is:
(defn -main [& args]
(println "started")
(slurp *in*)
(println "finished"))
this leads to stacktraces in some shells.@sogaiu and if you rebind *in*
to (java.io.InputStreamReader. System/in)
, what happens?
yeah, so:
(defn -main [& args]
(println "started")
(binding [*in* (java.io.InputStreamReader. System/in)]
(slurp *in*))
(println "finished"))
i can get a reproduction of the problem if i def a separate var as dynamic and assign it what in is assigned.
how does this behave?
(defn -main [& args]
(println "started")
(binding [*in* *in*]
(slurp *in*))
(println "finished"))
i just pulled your latest commit and built. running w/o arguments, i get no output for: windows powershell, cmd.exe, and a fresh sdk cmd.exe however, in the sdk cmd.exe that i built clj-kondo.exe in, it runs w/o the help output...
i just tested that one and found: works: powershell core, sdk cmd.exe that i did a build with doesn't work: fresh sdk cmd.exe, windows powershell, cmd.exe
maybe it's a dll dependency problem again, but I don't know enough about this to solve it
i got a side-by-side private assembly to work for clj-kondo.exe -- that means it skips the traditional dll search order
as far as i understand, there is only one dll that clj-kondo.exe needs that doesn't get supplied by a windows 10 system, and that's what comes with the vs c++ redit 2010 -- msvcr100.dll. i haven't been testing with the side-by-side thing, but i can do that in a bit.
what we ultimately want is to be able to build on appveyor (or circle in case @marc-omorain is watching) and then combine that with some redistributable dll in an installer (like scoop, chocolatey, whatever works)
yes, i understand that automating the builds is important. i think it'd be worth having a conversation with the graal folks about whether they have either recommendations for doing that sort of thing with their current tools, or if that doesn't work so well with their current setup, whether they might be willing to make some changes in that direction going forward.
yeah, that's what this issue is about essentially: https://github.com/oracle/graal/issues/1407
i believe it's in their interest too that people try their stuff and for that, automated builds help -- or put another way, without it, it's quite a disincentive to working on at least the windows portions because of the sheer amount of manual time that gets sucked away ๐
I wonder if there are any other clojure projects like clj-kondo that distribute binaries for different platforms
the static stuff is also along those lines, because it should eliminate dll loading issues as well as ease deployment.
it would be effective if we could make repros that are clear and post them to graal, but this is difficult to do right now with Windows problems
i have been reluctant to post because the results i get seem inconsistent and it's hard to find someone else who can reproduce
what would be great is someone who knows clojure well working on the graal team...i can dream, can't i? ๐
I'd say let's focus on a standalone cmd.exe (no SDK installed). if that works, using some redistributable, then I think it's good to look at VSCode on Windows. if that works, then Powershell as a nice to have
hmm...well, i've been finding that which shells produce better results seem to vary with the releases, unfortunately
didn't try, since I'm running Windows in a VM. Running Docker inside of that is too taxing on my machine
@borkdude here's a draft repos: https://github.com/sogaiu/constdin
very good! now I would post the text in the README with a link to your repro repo and the jars.
Hello, I try to use GraalVM on my macbook.. long time ago I didnโt use.. and now I added the new Graal for OSX.. 1.8.0_212, x86_64: "GraalVM EE 19.1.0" /Library/Java/JavaVirtualMachines/graalvm-ee-19.1.0/Contents/Home
.. and I get every time that error.. at test projects too.. eg https://www.astrecipes.net/blog/2018/07/20/cmd-line-apps-with-clojure-and-graalvm/ or cljtree
Exception in thread "main" java.lang.ExceptionInInitializerError
at com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:290)
at java.lang.Class.ensureInitialized(DynamicHub.java:451)
at clojure.lang.Namespace.<init>(Namespace.java:34)
at clojure.lang.Namespace.findOrCreate(Namespace.java:176)
at clojure.lang.Var.internPrivate(Var.java:153)
at testgraal.core.<clinit>(Unknown Source)
at com.oracle.svm.core.hub.ClassInitializationInfo.invokeClassInitializer(ClassInitializationInfo.java:350)
at com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:270)
at java.lang.Class.ensureInitialized(DynamicHub.java:451)
Caused by: java.io.FileNotFoundException: Could not locate clojure/core__init.class or clojure/core.clj on classpath.
at clojure.lang.RT.load(RT.java:463)
at clojure.lang.RT.load(RT.java:426)
at clojure.lang.RT.doInit(RT.java:468)
at clojure.lang.RT.<clinit>(RT.java:336)
at com.oracle.svm.core.hub.ClassInitializationInfo.invokeClassInitializer(ClassInitializationInfo.java:350)
at com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:270)
... 8 more
Any idea why I got this..? lein clean && lein compile && lein uberjar
and as in this docs native-image -jar target/cljtree-graalvm-0.1.0-SNAPSHOT-standalone.jar -H:Name="cljtree" --no-server J-Xmx3G -J-Xms3G -H:+ReportUnsupportedElementsAtRuntime
I tried -J-Xmx3G -J-Xms3G --no-server
flag too.. but similar error. The jars work fine.. with java -jar
maybe the problem .. native-image --version >> GraalVM Version 19.1.0 CE and I have GraalVM EE
? ๐