Fork me on GitHub
#clojure-dev
<
2019-11-07
>
borkdude20:11:44

when trying to compile clojure master, I get this error:

compile-clojure:
     [java] Exception in thread "main" java.lang.ExceptionInInitializerError
     [java] 	at clojure.lang.Compile.<clinit>(Compile.java:29)
     [java] Caused by: Syntax error compiling at (clojure/core.clj:7053:1).
     [java] 	at clojure.lang.Compiler.load(Compiler.java:7648)
     [java] 	at clojure.lang.RT.loadResourceScript(RT.java:381)
     [java] 	at clojure.lang.RT.loadResourceScript(RT.java:372)
     [java] 	at clojure.lang.RT.load(RT.java:459)
     [java] 	at clojure.lang.RT.load(RT.java:424)
     [java] 	at clojure.lang.RT.<clinit>(RT.java:338)
     [java] 	... 1 more
     [java] Caused by: java.lang.NumberFormatException: null
     [java] 	at java.base/java.lang.Integer.parseInt(Integer.java:614)
     [java] 	at java.base/java.lang.Integer.valueOf(Integer.java:983)
     [java] 	at clojure.core$eval4288.invokeStatic(core.clj:7065)
     [java] 	at clojure.core$eval4288.invoke(core.clj:7055)
     [java] 	at clojure.lang.Compiler.eval(Compiler.java:7177)
     [java] 	at clojure.lang.Compiler.load(Compiler.java:7636)
     [java] 	... 6 more

borkdude20:11:50

anyone else seeing this?

borkdude20:11:28

I'm running mvn package -Dmaven.test.skip=true

alexmiller20:11:00

did you clean?

borkdude20:11:45

now I did, but same issue

alexmiller20:11:03

it builds every day here https://build.clojure.org/job/clojure/ - haven't seen any issues

alexmiller20:11:24

java -version ?

ghadi20:11:00

what version + jvm @borkdude

alexmiller20:11:04

build matrix uses 8-11, but I've tested with 12 and 13

borkdude20:11:32

now it worked. mvn clean didn't work, but rm -rf target did 😕

borkdude20:11:16

$ java -version
openjdk version "1.8.0_212"
$ mvn -version
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-27T17:06:16+02:00)

borkdude21:11:08

it seems loading clojure.string in spec.alpha can be avoided (it isn't used for anything there)

andy.fingerhut21:11:40

Regarding your deleted comment of why clojure.string/... works without require'ing clojure.string, IIRC there is a subset (not all) of the namespaces that come with the Clojure JAR that are require'd during init.

alexmiller21:11:57

you should never rely on that

alexmiller21:11:00

as they may change

alexmiller21:11:05

not making any fixes to spec.alpha

borkdude21:11:25

I'm not saying you should rely on it, but it explains why it works?

alexmiller21:11:39

require just means to load

ghadi21:11:45

it happens that clojure.string is required within clojure.core, iirc

alexmiller21:11:51

some namespaces loaded during bootstrap load other stuff

ghadi21:11:56

but again, that may change

alexmiller21:11:04

will likely change

ghadi21:11:10

the only thing you never have to require is clojure.core

borkdude21:11:34

> it happens that clojure.string is required within clojure.core I don't see that anywhere in core.clj?

andy.fingerhut21:11:39

you guys are tag-teaming us 🙂

ghadi22:11:15

that would be a great thing to warn on @borkdude

alexmiller22:11:43

currently, bootstrap loads clojure.core.server, which loads clojure.string

andy.fingerhut22:11:48

Some namespaces are created during init other than clojure.core, might be more precise than saying they are require'd.

alexmiller22:11:12

we have a pending ticket that will avoid loading clojure.core.server (and thus clojure.string) in the case that you don't have socket servers to load

ghadi22:11:13

clojure.core -> -> clojure.string is another place

ghadi22:11:36

where the require happens

alexmiller22:11:47

if we change the order or set of these requires and your code breaks, I'm going to claim your code was already broken :)

👍 1
andy.fingerhut22:11:31

(tongue in cheek) Clojure 1.11 seems due for reminding people that clojure.core/hash values can change across releases

alexmiller22:11:21

we should just add the hash of the release version into all hashes :)

andy.fingerhut22:11:28

for continuity (or something like that) the hash of mutable Java collections can include the hash of the previous release version 🙂

borkdude22:11:12

@alexmiller that's not why I brought this up. I brought it up because loading namespaces unnecessarily can slow down startup time.

alexmiller22:11:27

yes, and the point above is - we might improve that in the core :)

borkdude22:11:28

(although clojure.string would not likely be a huge win)

alexmiller22:11:47

although compared to loading core, the rest are pretty tiny

alexmiller22:11:03

if you find anything for spec-alpha2, let me know and I'll fix. I think that one was fixed long ago.

borkdude22:11:29

the reason I looked at this was I tried out a patch for CLJ-1472. some notes here: https://gist.github.com/borkdude/dd0857cf1958b25496fddbdbf359ca59

alexmiller22:11:44

if the patch doesn't apply, it needs to be rebased over current master. patches drift....

ghadi22:11:48

@borkdude when you tried CLJ-1472-reentrant-finally2.patch, which program wasn't loadable by Graal native-image?

ghadi22:11:05

and did you compile spec.alpha, too?

borkdude22:11:33

@ghadi I updated the notes with the exception I saw during the GraalVM compilation

borkdude22:11:45

I first compiled clojure, then spec and then clojure using that compiled spec

ghadi22:11:30

I don't think spec.alpha was compiled with the patched clojure if that error cropped up

alexmiller22:11:09

you would need to change the spec pom.xml to include the patched clojure

ghadi22:11:57

(the spec.alpha artifact in Maven is AOT compiled, and it contains a locking expr)

borkdude22:11:52

you're right, I made a mistake there

borkdude23:11:57

got rid of that mistake, still same error.

borkdude23:11:24

I wanted to get leiningen out of the loop, so I tried this: https://gist.github.com/borkdude/dd0857cf1958b25496fddbdbf359ca59#trying-to-compile-only-using-toolsdeps not sure why it can't find the main entrypoint. I'll try some more later, getting late here