[ANN] Clojure 1.8.0-RC1 is now available

[Alex Miller]

Clojure 1.8.0-RC1 is now available. This build is a "release candidate"! We would appreciate any and all testing you can do on your own libraries or internal projects to find problems. If no problems are found, we expect to make this the 1.8.0 final release! 

Try it via

• Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
  
• Leiningen: [org.clojure/clojure "1.8.0-RC1"]

Below is the only change since 1.8.0-beta2. See the full 1.8 change log here: https://github.com/clojure/clojure/blob/master/changes.md.

• CLJ-1845 Make clojure.core/load dynamic so it can be redef'ed even with direct linking

[Alan Thompson]

Runs fine in my tests.

One small question: would it be feasible to keep everything lowercase in the future (i.e. org.clojure:clojure:jar:1.8.0-rc1)?

Keep up the great work,

Alan

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Miller]

Any reason why?

[Ghadi Shayban]

Two points of feedback:

1) One of the reason tuples were disabled was that they polluted dispatch paths.  Shouldn't we make sure that they are completely inactive?

   Map entries (everywhere: c.l.Persistent*, records, gvec, bean) still use them.

2) I get the rationale behind direct linking, but I'm lacking evidence that the benefits are achieved.

[Alan Thompson]

Just keeps it simpler when typing, and most other things seem to be all lowercase.  Not a big deal.

Alan

[Ghadi Shayban]

Never mind the first point.  I've been pointed to the fact that Tuple/create returns a PV [1]

[1] https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Tuple.java#L22

[Michael Drogalis]

Upgrading Clojure to 1.8.0-RC1 passed Onyx's full test suite. Thumbs up on our end.

[Mike Rodriguez]

I second Ghadi's question (2). Is there any further information to read that discusses the benefits found from direct linking? I understand the motivation. I was just hoping to here some performance boost success stories.

[Alex Miller]

I would love for people to try building their apps with and without direct linking to see if there is a difference! Has anyone done so?

[Mike Rodriguez]

I did a trial run of some of my production applications (big data space) and I did see an overall improvement in execution time that seemed consistent. It was not too significant of a difference though, but it was still good to see. I am not positive my use case would have necessarily been in position to drastically improve from the direct linking at this point though anyways.
I also haven't tried to direct link my own application code (I think that's an option you can switch on, I forget ).

I was just curious to hear if there were some significant differences people have observed. It's always good to see concrete examples.

[Robin Heggelund Hansen]

I got an exception when compiling with this RC (exception below). Seems it have trouble compiling aleph, so I've added an issue there. I assume you will be contacted if the bug is found to be an error in Clojure itself, and not Aleph.

#error {

 :cause IllegalName: compile__stub.aleph.http.core.aleph.http.core/HeaderMap

 :via

 [{:type clojure.lang.Compiler$CompilerException

   :message java.lang.NoClassDefFoundError: IllegalName: compile__stub.aleph.http.core.aleph.http.core/HeaderMap, compiling:(aleph/http/core.clj:81:1)

   :at [clojure.lang.Compiler analyzeSeq Compiler.java 6861]}

  {:type java.lang.NoClassDefFoundError

   :message IllegalName: compile__stub.aleph.http.core.aleph.http.core/HeaderMap

   :at [java.lang.ClassLoader preDefineClass ClassLoader.java 654]}]

 :trace

 [[java.lang.ClassLoader preDefineClass ClassLoader.java 654]

  [java.lang.ClassLoader defineClass ClassLoader.java 758]

  [java.lang.ClassLoader defineClass ClassLoader.java 642]

  [clojure.lang.DynamicClassLoader defineClass DynamicClassLoader.java 46]

  [clojure.lang.Compiler$NewInstanceExpr compileStub Compiler.java 7880]

  [clojure.lang.Compiler$NewInstanceExpr build Compiler.java 7745]

  [clojure.lang.Compiler$NewInstanceExpr$DeftypeParser parse Compiler.java 7655]

  [clojure.lang.Compiler analyzeSeq Compiler.java 6854]

  [clojure.lang.Compiler analyze Compiler.java 6655]

  [clojure.lang.Compiler analyze Compiler.java 6611]

  [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5987]

  [clojure.lang.Compiler$LetExpr$Parser parse Compiler.java 6305]

  [clojure.lang.Compiler analyzeSeq Compiler.java 6854]

  [clojure.lang.Compiler analyze Compiler.java 6655]

  [clojure.lang.Compiler analyze Compiler.java 6611]

  [clojure.lang.Compiler$BodyExpr$Parser parse Compiler.java 5987]

  [clojure.lang.Compiler$FnMethod parse Compiler.java 5368]

  [clojure.lang.Compiler$FnExpr parse Compiler.java 3971]

  [clojure.lang.Compiler analyzeSeq Compiler.java 6852]

  [clojure.lang.Compiler analyze Compiler.java 6655]

  [clojure.lang.Compiler eval Compiler.java 6910]

  [clojure.lang.Compiler eval Compiler.java 6902]

  [clojure.lang.Compiler load Compiler.java 7360]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5673 invoke core.clj 5895]

  [clojure.core$load invokeStatic core.clj 5894]

  [clojure.core$load_one invokeStatic core.clj 5694]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]

  [clojure.core$load_lib invokeStatic core.clj 5738]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$load_libs invokeStatic core.clj 5776]

  [clojure.core$load_libs doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 137]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$require invokeStatic core.clj 5798]

  [clojure.core$require doInvoke core.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 551]

  [aleph.http.server$eval18258$loading__5565__auto____18259 invoke server.clj 1]

  [aleph.http.server$eval18258 invokeStatic server.clj 1]

  [aleph.http.server$eval18258 invoke server.clj -1]

  [clojure.lang.Compiler eval Compiler.java 6913]

  [clojure.lang.Compiler eval Compiler.java 6902]

  [clojure.lang.Compiler load Compiler.java 7360]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5673 invoke core.clj 5895]

  [clojure.core$load invokeStatic core.clj 5894]

  [clojure.core$load_one invokeStatic core.clj 5694]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]

  [clojure.core$load_lib invokeStatic core.clj 5738]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$load_libs invokeStatic core.clj 5780]

  [clojure.core$load_libs doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 137]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$require invokeStatic core.clj 5798]

  [clojure.core$require doInvoke core.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 457]

  [aleph.http$eval16931$loading__5565__auto____16932 invoke http.clj 1]

  [aleph.http$eval16931 invokeStatic http.clj 1]

  [aleph.http$eval16931 invoke http.clj -1]

  [clojure.lang.Compiler eval Compiler.java 6913]

  [clojure.lang.Compiler eval Compiler.java 6902]

  [clojure.lang.Compiler load Compiler.java 7360]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5673 invoke core.clj 5895]

  [clojure.core$load invokeStatic core.clj 5894]

  [clojure.core$load_one invokeStatic core.clj 5694]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]

  [clojure.core$load_lib invokeStatic core.clj 5738]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$load_libs invokeStatic core.clj 5776]

  [clojure.core$load_libs doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 137]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$require invokeStatic core.clj 5798]

  [clojure.core$require doInvoke core.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 512]

  [episode_next.tv_shows$eval16548$loading__5565__auto____16549 invoke tv_shows.clj 1]

  [episode_next.tv_shows$eval16548 invokeStatic tv_shows.clj 1]

  [episode_next.tv_shows$eval16548 invoke tv_shows.clj -1]

  [clojure.lang.Compiler eval Compiler.java 6913]

  [clojure.lang.Compiler eval Compiler.java 6902]

  [clojure.lang.Compiler load Compiler.java 7360]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5673 invoke core.clj 5895]

  [clojure.core$load invokeStatic core.clj 5894]

  [clojure.core$load_one invokeStatic core.clj 5694]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]

  [clojure.core$load_lib invokeStatic core.clj 5738]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$load_libs invokeStatic core.clj 5776]

  [clojure.core$load_libs doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 137]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$require invokeStatic core.clj 5798]

  [clojure.core$require doInvoke core.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 805]

  [episode_next.tasks$eval3350$loading__5565__auto____3351 invoke tasks.clj 1]

  [episode_next.tasks$eval3350 invokeStatic tasks.clj 1]

  [episode_next.tasks$eval3350 invoke tasks.clj -1]

  [clojure.lang.Compiler eval Compiler.java 6913]

  [clojure.lang.Compiler eval Compiler.java 6902]

  [clojure.lang.Compiler load Compiler.java 7360]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5673 invoke core.clj 5895]

  [clojure.core$load invokeStatic core.clj 5894]

  [clojure.core$load_one invokeStatic core.clj 5694]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]

  [clojure.core$load_lib invokeStatic core.clj 5738]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$load_libs invokeStatic core.clj 5776]

  [clojure.core$load_libs doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 137]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$require invokeStatic core.clj 5798]

  [clojure.core$require doInvoke core.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 930]

  [episode_next.db$eval995$loading__5565__auto____996 invoke db.clj 1]

  [episode_next.db$eval995 invokeStatic db.clj 1]

  [episode_next.db$eval995 invoke db.clj -1]

  [clojure.lang.Compiler eval Compiler.java 6913]

  [clojure.lang.Compiler eval Compiler.java 6902]

  [clojure.lang.Compiler load Compiler.java 7360]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5673 invoke core.clj 5895]

  [clojure.core$load invokeStatic core.clj 5894]

  [clojure.core$load_one invokeStatic core.clj 5694]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]

  [clojure.core$load_lib invokeStatic core.clj 5738]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$load_libs invokeStatic core.clj 5776]

  [clojure.core$load_libs doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 137]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$require invokeStatic core.clj 5798]

  [clojure.core$require doInvoke core.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 457]

  [repl$eval14$loading__5565__auto____15 invoke repl.clj 1]

  [repl$eval14 invokeStatic repl.clj 1]

  [repl$eval14 invoke repl.clj -1]

  [clojure.lang.Compiler eval Compiler.java 6913]

  [clojure.lang.Compiler eval Compiler.java 6902]

  [clojure.lang.Compiler load Compiler.java 7360]

  [clojure.lang.RT loadResourceScript RT.java 372]

  [clojure.lang.RT loadResourceScript RT.java 363]

  [clojure.lang.RT load RT.java 453]

  [clojure.lang.RT load RT.java 419]

  [clojure.core$load$fn__5673 invoke core.clj 5895]

  [clojure.core$load invokeStatic core.clj 5894]

  [clojure.core$load_one invokeStatic core.clj 5694]

  [clojure.core$load_one invoke core.clj -1]

  [clojure.core$load_lib$fn__5622 invoke core.clj 5739]

  [clojure.core$load_lib invokeStatic core.clj 5738]

  [clojure.core$load_lib doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 142]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$load_libs invokeStatic core.clj 5776]

  [clojure.core$load_libs doInvoke core.clj -1]

  [clojure.lang.RestFn applyTo RestFn.java 137]

  [clojure.core$apply invokeStatic core.clj 647]

  [clojure.core$require invokeStatic core.clj 5798]

  [clojure.core$require doInvoke core.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 408]

  [user$eval5 invokeStatic form-init5115162863409237928.clj 1]

  [user$eval5 invoke form-init5115162863409237928.clj -1]

  [clojure.lang.Compiler eval Compiler.java 6913]

  [clojure.lang.Compiler eval Compiler.java 6902]

  [clojure.lang.Compiler eval Compiler.java 6902]

  [clojure.lang.Compiler load Compiler.java 7360]

  [clojure.lang.Compiler loadFile Compiler.java 7298]

  [clojure.main$load_script invokeStatic main.clj 275]

  [clojure.main$init_opt invokeStatic main.clj 277]

  [clojure.main$init_opt invoke main.clj -1]

  [clojure.main$initialize invokeStatic main.clj 308]

  [clojure.main$null_opt invokeStatic main.clj 342]

  [clojure.main$null_opt invoke main.clj -1]

  [clojure.main$main invokeStatic main.clj 421]

  [clojure.main$main doInvoke main.clj -1]

  [clojure.lang.RestFn invoke RestFn.java 421]

  [clojure.lang.Var invoke Var.java 383]

  [clojure.lang.AFn applyToHelper AFn.java 156]

  [clojure.lang.Var applyTo Var.java 700]

  [clojure.main main main.java 37]]}

[Shantanu Kumar]

One of my libraries (https://github.com/kumarshantanu/asphalt) is failing to compile with 1.8 (works fine with 1.6, 1.7); the stack trace is below:

$ lein do clean, with-profile dev,c18 test

Exception in thread "main" java.lang.VerifyError: (class: asphalt/core$invoke_with_transaction, method: invokeStatic signature: (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) Expecting to find integer on stack, compiling:(core.clj:201:1)

at clojure.lang.Compiler$DefExpr.eval(Compiler.java:463)

at clojure.lang.Compiler.eval(Compiler.java:6918)

at clojure.lang.Compiler.load(Compiler.java:7360)

at clojure.lang.RT.loadResourceScript(RT.java:372)

at clojure.lang.RT.loadResourceScript(RT.java:363)

at clojure.lang.RT.load(RT.java:453)

at clojure.lang.RT.load(RT.java:419)

at clojure.core$load$fn__5673.invoke(core.clj:5895)

at clojure.core$load.invokeStatic(core.clj:5894)

at clojure.core$load_one.invokeStatic(core.clj:5694)

at clojure.core$load_one.invoke(core.clj)

at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)

at clojure.core$load_lib.invokeStatic(core.clj:5738)

at clojure.core$load_lib.doInvoke(core.clj)

at clojure.lang.RestFn.applyTo(RestFn.java:142)

at clojure.core$apply.invokeStatic(core.clj:647)

at clojure.core$load_libs.invokeStatic(core.clj:5776)

at clojure.core$load_libs.doInvoke(core.clj)

at clojure.lang.RestFn.applyTo(RestFn.java:137)

at clojure.core$apply.invokeStatic(core.clj:647)

at clojure.core$require.invokeStatic(core.clj:5798)

at clojure.core$require.doInvoke(core.clj)

at clojure.lang.RestFn.invoke(RestFn.java:457)

at asphalt.test_util$eval198$loading__5565__auto____199.invoke(test_util.clj:1)

at asphalt.test_util$eval198.invokeStatic(test_util.clj:1)

at asphalt.test_util$eval198.invoke(test_util.clj)

at clojure.lang.Compiler.eval(Compiler.java:6913)

at clojure.lang.Compiler.eval(Compiler.java:6902)

at clojure.lang.Compiler.load(Compiler.java:7360)

at clojure.lang.RT.loadResourceScript(RT.java:372)

at clojure.lang.RT.loadResourceScript(RT.java:363)

at clojure.lang.RT.load(RT.java:453)

at clojure.lang.RT.load(RT.java:419)

at clojure.core$load$fn__5673.invoke(core.clj:5895)

at clojure.core$load.invokeStatic(core.clj:5894)

at clojure.core$load_one.invokeStatic(core.clj:5694)

at clojure.core$load_one.invoke(core.clj)

at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)

at clojure.core$load_lib.invokeStatic(core.clj:5738)

at clojure.core$load_lib.doInvoke(core.clj)

at clojure.lang.RestFn.applyTo(RestFn.java:142)

at clojure.core$apply.invokeStatic(core.clj:647)

at clojure.core$load_libs.invokeStatic(core.clj:5776)

at clojure.core$load_libs.doInvoke(core.clj)

at clojure.lang.RestFn.applyTo(RestFn.java:137)

at clojure.core$apply.invokeStatic(core.clj:647)

at clojure.core$require.invokeStatic(core.clj:5798)

at clojure.core$require.doInvoke(core.clj)

at clojure.lang.RestFn.invoke(RestFn.java:457)

at asphalt.core_test$eval192$loading__5565__auto____193.invoke(core_test.clj:1)

at asphalt.core_test$eval192.invokeStatic(core_test.clj:1)

at asphalt.core_test$eval192.invoke(core_test.clj)

at clojure.lang.Compiler.eval(Compiler.java:6913)

at clojure.lang.Compiler.eval(Compiler.java:6902)

at clojure.lang.Compiler.load(Compiler.java:7360)

at clojure.lang.RT.loadResourceScript(RT.java:372)

at clojure.lang.RT.loadResourceScript(RT.java:363)

at clojure.lang.RT.load(RT.java:453)

at clojure.lang.RT.load(RT.java:419)

at clojure.core$load$fn__5673.invoke(core.clj:5895)

at clojure.core$load.invokeStatic(core.clj:5894)

at clojure.core$load_one.invokeStatic(core.clj:5694)

at clojure.core$load_one.invoke(core.clj)

at clojure.core$load_lib$fn__5622.invoke(core.clj:5739)

at clojure.core$load_lib.invokeStatic(core.clj:5738)

at clojure.core$load_lib.doInvoke(core.clj)

at clojure.lang.RestFn.applyTo(RestFn.java:142)

at clojure.core$apply.invokeStatic(core.clj:647)

at clojure.core$load_libs.invokeStatic(core.clj:5776)

at clojure.core$load_libs.doInvoke(core.clj)

at clojure.lang.RestFn.applyTo(RestFn.java:137)

at clojure.core$apply.invokeStatic(core.clj:647)

at clojure.core$require.invokeStatic(core.clj:5798)

at clojure.core$require.doInvoke(core.clj)

at clojure.lang.RestFn.applyTo(RestFn.java:137)

at clojure.core$apply.invokeStatic(core.clj:647)

at clojure.core$apply.invoke(core.clj)

at user$eval91.invokeStatic(form-init7505432955041312280.clj:1)

at user$eval91.invoke(form-init7505432955041312280.clj)

at clojure.lang.Compiler.eval(Compiler.java:6913)

at clojure.lang.Compiler.eval(Compiler.java:6903)

at clojure.lang.Compiler.load(Compiler.java:7360)

at clojure.lang.Compiler.loadFile(Compiler.java:7298)

at clojure.main$load_script.invokeStatic(main.clj:275)

at clojure.main$init_opt.invokeStatic(main.clj:277)

at clojure.main$init_opt.invoke(main.clj)

at clojure.main$initialize.invokeStatic(main.clj:308)

at clojure.main$null_opt.invokeStatic(main.clj:342)

at clojure.main$null_opt.invoke(main.clj)

at clojure.main$main.invokeStatic(main.clj:421)

at clojure.main$main.doInvoke(main.clj)

at clojure.lang.RestFn.invoke(RestFn.java:421)

at clojure.lang.Var.invoke(Var.java:383)

at clojure.lang.AFn.applyToHelper(AFn.java:156)

at clojure.lang.Var.applyTo(Var.java:700)

at clojure.main.main(main.java:37)

Caused by: java.lang.VerifyError: (class: asphalt/core$invoke_with_transaction, method: invokeStatic signature: (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;) Expecting to find integer on stack

at java.lang.Class.getDeclaredConstructors0(Native Method)

at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)

at java.lang.Class.getConstructor0(Class.java:3075)

at java.lang.Class.newInstance(Class.java:412)

at clojure.lang.Compiler$ObjExpr.eval(Compiler.java:4902)

at clojure.lang.Compiler$DefExpr.eval(Compiler.java:450)

... 95 more

I welcome any suggestion/pointers on preparing an isolated test case.

Shantanu

[Alex Miller]

There is a Potemkin error that was exposed during 1.8 that looks like this (the compile_stub) - is that library in your dependencies? If so, supplying the latest version explicitly should fix the problem.

[Alex Miller]

Can you file a ticket for that VerifyError Shantanu?

[Nicola Mometto]

Here's a minimal repro case:

user=> (defn foo ^long [] 1)

#'user/foo

user=> (Integer/bitCount ^int (foo))

VerifyError (class: user$eval13, method: invokeStatic signature: ()Ljava/lang/Object;) Expecting to find integer on stack  java.lang.Class.getDeclaredConstructors0 (Class.java:-2)

[Shantanu Kumar]

Thanks, Nicola!

Filed the ticket: http://dev.clojure.org/jira/browse/CLJ-1846

Shantanu

[Phillip Lord]

I've been trying out RC1. I've tried enabling the direct linking in
leiningen, by sticking:

:jvm-opts ["-Dclojure.compiler.direct-linking=true"]

I can't see any particular performance change (when running tests
anyway).

Is there a way to know whether it is actually working?

Phil


Alex Miller <al...@puredanger.com> writes:

> Clojure 1.8.0-RC1 is now available. *This build is a "release candidate"!*

> We would appreciate any and all testing you can do on your own libraries or
> internal projects to find problems. If no problems are found, we expect to
> make this the 1.8.0 final release!
>
> Try it via
>

> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
> - Leiningen: [org.clojure/clojure "1.8.0-RC1"]

>
> Below is the only change since 1.8.0-beta2. See the full 1.8 change log
> here: https://github.com/clojure/clojure/blob/master/changes.md.
>

> - CLJ-1845 <http://dev.clojure.org/jira/browse/CLJ-1845> Make

[Nicola Mometto]

To be honest I'm not sure this should even be a valid use of type hints.

You're telling the compiler that the result of (foo) is an int, when it is infact a long.

The correct way to do this should be:

 (Integer/bitCount (int (foo))

Again, lack of specification on what the correct type hinting semantics should be make it hard to evaluate if this should be considered a bug or just an user error that previously just got ignored.

[Alex Miller]

Aside on the type hinting specs: - I would be happy to have a doc contribution at https://github.com/clojure/clojure-site that defines specs that I could move through review with Rich.

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/9ZmaZI6NO1I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Fluid Dynamics]

On Wednesday, November 11, 2015 at 9:23:16 AM UTC-5, Nicola Mometto wrote:

To be honest I'm not sure this should even be a valid use of type hints.

You're telling the compiler that the result of (foo) is an int, when it is infact a long.

The correct way to do this should be:

 (Integer/bitCount (int (foo))

Again, lack of specification on what the correct type hinting semantics should be make it hard to evaluate if this should be considered a bug or just an user error that previously just got ignored.

It's a bug. Even if ^int (thing-that-returns-long) is a user error, the result should be a sane error message from the Clojure compiler, not bad bytecode that later fails with a VerifyError.

[Nicola Mometto]

Clojure has a history of adopting the GIGO approach

On 11 Nov 2015, at 12:08, Shantanu Kumar <kumar.s...@gmail.com> wrote:

[Alex Miller]

In this case, I am definitely in agreement with FD that producing invalid bytecode does not seem like an acceptable outcome. The other two options are a compiler error or having the compiler ignore or resolve the mismatch such that it produces valid bytecode. Rich is looking at it.

[Andy Fingerhut]

Results of some testing done on 1.8.0-RC1:

Ran 'mvn clean test' on a few OS/JDK combos that are not tested as often.  Reason: there have been (or still are) build or test failures with some of them.  All JDKs listed below were 64-bit.

Windows 7 Enterprise SP1 + Oracle JDK 1.7.0_80-b15: ok 3/3 trials
Ubuntu 14.04.3 LTS + OpenJDK 1.7.0_85: ok 3/3 trials
Ubuntu 14.04.3 LTS + IBM JDK 1.7.0: ok 10/10 trials, as long as failing tests mentioned in http://dev.clojure.org/jira/browse/CLJ-1678 are commented out
Ubuntu 14.04.3 LTS + IBM JDK 1.8.0 (based on jdk8u51-b15): same as for IBM JDK 1.7.0
Mac OS X 10.11.1 + Oracle JDK 1.8.0_11: ok 631/631 trials

There were some JVM crashes during 'mvn test' that I have seen with an earlier version of IBM JDK 1.8.0 (based on jdk8u45-b13), but with the version mentioned above those seem to be gone.  The older one failed 5 out of 10 trials.  The newer one gave passing test results with no JVM crash 10 out of 10 trials.

I plan to, but haven't yet, compared Eastwood results with 1.8.0-RC1 vs. 1.7.0.  That will take some work before I can give those results, primarily updating Eastwood to work with 1.8.0-RC1.  Eastwood makes some assumptions about the structure of ASTs (abstract syntax trees) that 1.8.0-RC!'s :rettag addition changed.  I don't think it is much work, but not sure when I will be able to get to it.  Until then, I have the following message near the beginning of Eastwood's README:

It has been tried with some of the Clojure 1.8.0-alpha versions, but there are known problems there (e.g. incorrect warning about misplaced docstrings, perhaps incorrect warnings about wrong tags, etc.)

Andy

[Alex Miller]

On Wednesday, November 11, 2015 at 2:03:07 PM UTC-6, Andy Fingerhut wrote:

Results of some testing done on 1.8.0-RC1:

Ran 'mvn clean test' on a few OS/JDK combos that are not tested as often.  Reason: there have been (or still are) build or test failures with some of them.  All JDKs listed below were 64-bit.

Thanks Andy!!

[Alex Miller]

Rich pushed a commit to master that will now detect this invalid primitive type hint and throw a compiler error.

Shantanu - your asphalt library will fail due to this new compile error. You should change your two ^int type hints to casts instead (int ...) to fix the error. FYI, this type mismatch was ignored (effectively a no-op) until the change from CLJ-1533 in 1.8.0-alpha2 which is why we did not see it previously.

[Robin Heggelund Hansen]

You were right. Aleph depended on potemkin, upgrading that dependency fixed the problem.

[rebo...@gmail.com]

Hello,

the following stops executing on 1.8.0-rc1 or current master-head (9448d627e091bc010e68e05a5669c134cd715a98, 1.8-RC1 plus Rich fix for CLJ-1846):

[/Users/reborg]$ repl

Clojure 1.8.0-master-SNAPSHOT

user=> (defn ^double timespi [^double x] (* x 3.14))

#'user/timespi

user=> (timespi 2)

AbstractMethodError Method user$timespi.invokePrim(D)Ljava/lang/Object; is abstract  user/timespi (NO_SOURCE_FILE:-1)

It works if you enable direct linking (or if you use 1.7.0).

Renzo

[Alex Miller]

That's not a valid type hint. Var meta is evaluated, in this case to the double function object. You really want:

(defn timespi ^double [^double x] (* x 3.14))

[Nicola Mometto]

This is :rettag in action.

Any reason why this error should be acceptable while the CLJ-1846 one isn't?

[Nicola Mometto]

Given the number of bytecode/type hinting issues we've seen caused by direct linking and the lack of real benchmarks demonstrating its benefits, I'm also wondering what's the rationale between including it in the current release.

On 10 Nov 2015, at 18:15, Ghadi Shayban <gsha...@gmail.com> wrote:

Two points of feedback:

1) One of the reason tuples were disabled was that they polluted dispatch paths.  Shouldn't we make sure that they are completely inactive?

   Map entries (everywhere: c.l.Persistent*, records, gvec, bean) still use them.

2) I get the rationale behind direct linking, but I'm lacking evidence that the benefits are achieved.

On Tuesday, November 10, 2015 at 12:30:47 PM UTC-5, Alex Miller wrote:

Clojure 1.8.0-RC1 is now available. This build is a "release candidate"! We would appreciate any and all testing you can do on your own libraries or internal projects to find problems. If no problems are found, we expect to make this the 1.8.0 final release! 

Try it via

• Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-RC1
  
• Leiningen: [org.clojure/clojure "1.8.0-RC1"]

Below is the only change since 1.8.0-beta2. See the full 1.8 change log here: https://github.com/clojure/clojure/blob/master/changes.md.

• CLJ-1845 Make clojure.core/load dynamic so it can be redef'ed even with direct linking

[Renzo Borgatti]

Thanks Alex, I’ve missed the wrong type hint in that line. Now 1.8 is even telling me!

Cheers
Renzo

> On 12 Nov 2015, at 12:55, Alex Miller <al...@puredanger.com> wrote:
>

[Alex Miller]

Neither is acceptable, so I either misunderstand or disagree with your question. :) 

The code below is an invalid type hint at that location. Are you maybe saying this should throw an error on definition?

CLJ-1846 is instead a valid type hint that is in conflict with the call. Which now throws an error.

[Nicola Mometto]

Depends on how you look at it.

From my point of view, both examples are using an otherwise valid type hint, at an invalid location, and in both cases the emitted code is nonsensical.

So I'd say that if the decision for the CLJ-1846 issue was to handle that with a compile time error, this one should too.

[Nicola Mometto]

Also just like the CLJ-1846 issue, this bit of code was valid pre 1.8

[Michael Blume]

Sorry, I'm confused now -- is the appropriate place to give a return type hint for a function the arg list and not the function name? I've always seen the function name hinted.

[Nicola Mometto]

It.. depends :(

If your type hint is a *primitive* then you want to put it in the arglist. If you put it in the Var, the best case scenario is that you'll get either reflection warnings or boxed maths, and the worst case scenario is a Compiler/bytecode error.

If your type hint is an array type hint (^objects, ^ints ..) you want to put it in the arglist or in the Var as a quoted symbol (^{:tag 'objects}).

If your type hint is a non primitive class, you want to put it in the Var or in the arglist as a fully qualified symbol (not necessary anymore since 1.8)

If your type hint is a string representing a class, you can safely put it in either place.

[Leon Grapenthin]

Does this mean putting it in the arglist always works and there is rarely a practical reason to do anything else?

[Nicola Mometto]

*mostly* works, and since 1.8 only.

The issue pre 1.8 is that since metadata on arglist is not evaluated, the type hint wasn't a fully qualified classname, forcing the user namespaces to import that Class.

Scenarios like this would break:

(ns foo (:import my.Klass))

(defn foo ^Klass [] (Klass.))

(ns bar (:require foo))

(.method (foo/foo))

[Sean Corfield]

Nicola Mometto wrote on Thursday, November 12, 2015 at 11:52 AM:

*mostly* works, and since 1.8 only.

The issue pre 1.8 is that since metadata on arglist is not evaluated, the type hint wasn't a fully qualified classname, forcing the user namespaces to import that Class.

Scenarios like this would break:

(ns foo (:import my.Klass))

(defn foo ^Klass [] (Klass.))

(ns bar (:require foo))

(.method (foo/foo))

Ah, thank you for the explanation! I’d run into that and couldn’t really understand why it was failing!

Sean

[tcrayford]

Hi,

I ran Yeller's very extensive benchmark suite against Clojure 1.8 RC1.

I saw no performance regressions, over 72 individual benchmarks.

There were no notable performance improvements either (all benchmarks were

comparatively equal to a benchmark run against 1.7 with a 95% confidence interval).

I've also ran Yeller's (extensive) test.check based suite (94 individual

test.check properties) for 24h on a CI machine against Clojure 1.8 RC1 and saw

no test failures at all. There were ~1 billion assertions made during that

test run.

So, from all my testing, Clojure 1.8 RC1 seems to be fine. Thumbs up on my end.

Thanks for all the hard work that goes into making Clojure so stable.

Tom Crayford

Founder, yellerapp.com

[Ambrose Bonnaire-Sergeant]

Can we get a 3rd jar that is AOT compiled but without direct linking? I'd like the benefits of AOT load

time but also to build dev-time tooling to improve core error messages.

Thanks,

Ambrose

[Andy Fingerhut]

With updates I have made in the latest release of Eastwood 0.2.2 (announced in a separate message), I am seeing pretty much identical linting results running Eastwood on about 80 Clojure contrib and 3rd party libraries when using Clojure 1.8.0-RC1 as I see with Clojure 1.7.0.  The run time is nearly the same -- about 2% longer with 1.8.0-RC1, but I only ran each set of tests once, and that could be within the range of variability across runs.

Andy

[Daniel Compton]

Tom, would you be able to run your performance regression suite against 1.8 with direct linking enabled and share the performance changes?

--

Daniel