[ANN] Clojure 1.8.0-alpha2

[Alex Miller]

Clojure 1.8.0-alpha1 and 1.8.0-alpha2 are now available.

Try it via

- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha2

- Leiningen: [org.clojure/clojure "1.8.0-alpha2"]

1.8.0-alpha1 includes support for tuples (optimized small vectors) inspired by Zach Tellman's work.

1.8.0-alpha2 has an additional set of bug fixes and enhancements:

CLJ-703 Improve writeClassFile performance

CLJ-1659 compile leaks files

CLJ-1761 clojure.core/run! does not always return nil

CLJ-1645 'javap -v' on protocol class reveals no source file

CLJ-1644 into-array fails for sequences starting with nil

CLJ-1588 StackOverflow in clojure.test macroexpand with `are` and anonymous `fn`

CLJ-1565 pprint issues infinite output for a protocol

CLJ-1562 some->,some->>,cond->,cond->> and as-> doesn't work with (recur)

CLJ-1533 Oddity in type tag usage for primInvoke

CLJ-1528 clojure.test/inc-report-counter is not thread safe

CLJ-1399 missing field munging when recreating deftypes serialized into byte code

CLJ-1313 Correct a few unit tests

CLJ-1250 Reducer (and folder) instances hold onto the head of seqs

CLJ-1208 Namespace is not loaded on defrecord class init

Our current plans for 1.8 are to feature freeze on October 1st (typically that is beta 1) and then work through a release in time for the Clojure/Conj in late November. We expect 1.8 to include the Socket Server REPL work (http://dev.clojure.org/display/design/Socket+Server+REPL) and possibly other things to be determined.

- Alex

[Sean Corfield]

Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this week. We may go to production with it fairly quickly.

Sean

--
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.

--

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Robin Heggelund Hansen]

Are tuples used for small maps as well?

[Peter Taoussanis]

Hey Alex,

Looks terrific, thank you! Particularly excited about CLJ-703 and tuples.

Quick question: are tuples intended to implement :kv-reduce?

Currently (with 1.8.0-alpha2):

(reduce-kv (fn [acc idx in] acc) nil [1 2 3 4 5 6 7]) ; => nil

(reduce-kv (fn [acc idx in] acc) nil [1 2])

;; =>  No implementation of method: :kv-reduce of protocol:

;; #'clojure.core.protocols/IKVReduce found for class: clojure.lang.Tuple$T2

Cheers :-)

[Alex Miller]

Seems like a bug to me.

[Daniel Compton]

Is this a good candidate area for adding generative tests? It seems like they may have been able to catch this regression.

--

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.

--

--

Daniel

[Sean Corfield]

On Jul 18, 2015, at 10:33 PM, Sean Corfield <se...@corfield.org> wrote:
> Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this week. We may go to production with it fairly quickly.

Switched out 1.7.0 for 1.8.0-alpha2 and got the exception below. Posting here in case anyone knows immediately what the cause is, while I go debugging...

Exception in thread "main" java.lang.NoClassDefFoundError: IllegalName: compile__stub.clj_http.headers.clj-http.headers/HeaderMap, compiling:(clj_http/headers.clj:105:1)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6798)
at clojure.lang.Compiler.analyze(Compiler.java:6592)
at clojure.lang.Compiler.analyze(Compiler.java:6553)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6247)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6791)
at clojure.lang.Compiler.analyze(Compiler.java:6592)
at clojure.lang.Compiler.analyze(Compiler.java:6553)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5929)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5359)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3959)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6789)
at clojure.lang.Compiler.analyze(Compiler.java:6592)
at clojure.lang.Compiler.eval(Compiler.java:6847)
at clojure.lang.Compiler.eval(Compiler.java:6839)
at clojure.lang.Compiler.load(Compiler.java:7295)
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__5448.invoke(core.clj:5866)
at clojure.core$load.doInvoke(core.clj:5865)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5671)
at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
at clojure.core$load_lib.doInvoke(core.clj:5710)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$load_libs.doInvoke(core.clj:5749)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$require.doInvoke(core.clj:5832)
at clojure.lang.RestFn.invoke(RestFn.java:482)
at clj_http.core$eval855$loading__5340__auto____856.invoke(core.clj:1)
at clj_http.core$eval855.invoke(core.clj:1)

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

[Michael Blume]

Sean, I think that was identified as a bug in Potemkin. The pull was merged but I'm not sure if there's been a release since. Zack?

https://github.com/ztellman/potemkin/pull/40

http://dev.clojure.org/jira/browse/CLJ-1208?focusedCommentId=39632&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39632

[Michael Blume]

Looks like it has, pinning to Potemkin 0.4.1 should probably sort you out

[Michael Blume]

(It looks like you're depending on Potemkin through clj-http, so upgrading to clj-http 2.0.0 will also solve the problem)

[Sean Corfield]

Bumping clj-http to 2.0.0 got me past that problem (and it uses Potemkin 0.4.1) but then I hit the problem below, which I’ve run into several times trying to use updated versions of clj-http over the last year.

Message	java.lang.RuntimeException: No such var: clj-tuple/vector, compiling:(potemkin/utils.clj:110:10)
Cause	clojure.lang.Compiler$CompilerException
Stacktrace	The Error Occurred in core.clj: line 5866  called from core.clj: line 5865  called from core.clj: line 5671  called from core.clj: line 5711  called from core.clj: line 5710  called from core.clj: line 632  called from core.clj: line 5753  called from core.clj: line 634  called from core.clj: line 5843  called from collections.clj: line 1  called from collections.clj: line 1  called from core.clj: line 5866  called from core.clj: line 5865  called from core.clj: line 5671  called from core.clj: line 5711  called from core.clj: line 5710  called from core.clj: line 632  called from core.clj: line 5753  called from core.clj: line 632  called from core.clj: line 5832  called from potemkin.clj: line 1  called from potemkin.clj: line 1  called from core.clj: line 5866  called from core.clj: line 5865  called from core.clj: line 5671  called from core.clj: line 5711  called from core.clj: line 5710  called from core.clj: line 632  called from core.clj: line 5749  called from core.clj: line 632  called from core.clj: line 5832  called from headers.clj: line 1  called from headers.clj: line 1  called from core.clj: line 5866  called from core.clj: line 5865  called from core.clj: line 5671  called from core.clj: line 5711  called from core.clj: line 5710  called from core.clj: line 632  called from core.clj: line 5749  called from core.clj: line 632  called from core.clj: line 5832  called from core.clj: line 1  called from core.clj: line 1  called from core.clj: line 5866  called from core.clj: line 5865  called from core.clj: line 5671  called from core.clj: line 5711  called from core.clj: line 5710  called from core.clj: line 632  called from core.clj: line 5749  called from core.clj: line 632  called from core.clj: line 5832  called from client.clj: line 1

[Zach Tellman]

You're also going to have to target [clj-tuple "0.2.2"], since something else seems to be shadowing that depedency.  Sorry for all the fuss.

[Peter Taoussanis]

> Seems like a bug to me.

Thanks Alex, was about to open an issue but seems you beat me to it :-)

For anyone interested: http://dev.clojure.org/jira/browse/CLJ-1781

[Sean Corfield]

On Jul 19, 2015, at 9:58 PM, Zach Tellman <ztel...@gmail.com> wrote:
> You're also going to have to target [clj-tuple "0.2.2"], since something else seems to be shadowing that depedency. Sorry for all the fuss.

Yeah, potemkin 0.4.1 pulls in clj-tuple 0.2.2 (and nothing else in our system depended on either) so we’re good there.

I eventually tracked down the shadowing of clj-tuple to an older version of our app that had left a legacy JAR still in place in www/WEB-INF/lib (the problem only occurred when we loaded the Clojure project into the web app, not in any of our standalone Clojure projects!). That dated back to when we still had to add JARs to the lib folder due to the way our old Clojure loader used to work — now we load everything dynamically based on `lein classpath`.

So, sorry for the noise :(

Sean

[Sean Corfield]

Having updated clj-http from 1.0.1 to 2.0.0 to pick up a later version of Potemkin — to avoid the problem listed below — and fixed a subsequent environment issue on our end, all our dev tests pass with 1.8.0-alpha2. It probably won’t make this week’s production build, but I’m hoping to get it into production "soon".

Sean

[Adam Krieg]

Wow, I've upgraded a couple of projects and builds are roughly 50% faster over 1.7.0.  Is that to be expected?

[Andy Fingerhut]

Very likely that was the change for this ticket: http://dev.clojure.org/jira/browse/CLJ-703

Andy

--

[Rui Paulo]

On Monday 20 July 2015 19:19:08 Adam Krieg wrote:
> Wow, I've upgraded a couple of projects and builds are roughly 50% faster
> over 1.7.0. Is that to be expected?

These two changes might give you some insight:

> > CLJ-703 Improve writeClassFile performance
> > CLJ-1659 compile leaks files

--
Rui Paulo

[Rangel Spasov]

Hey guys,

Getting this error with 1.8.0-alpha2, I think related to aleph (using 0.4.0, latest version at the moment).

#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 6798]}

  {: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 7815]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  [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__5448 invoke core.clj 5866]

  [clojure.core$load doInvoke core.clj 5865]

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

  [clojure.core$load_one invoke core.clj 5671]

  [clojure.core$load_lib$fn__5397 invoke core.clj 5711]

  [clojure.core$load_lib doInvoke core.clj 5710]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$load_libs doInvoke core.clj 5749]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$require doInvoke core.clj 5832]

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

  [aleph.http.server$eval9251$loading__5340__auto____9252 invoke server.clj 1]

  [aleph.http.server$eval9251 invoke server.clj 1]

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

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

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

  [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__5448 invoke core.clj 5866]

  [clojure.core$load doInvoke core.clj 5865]

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

  [clojure.core$load_one invoke core.clj 5671]

  [clojure.core$load_lib$fn__5397 invoke core.clj 5711]

  [clojure.core$load_lib doInvoke core.clj 5710]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$load_libs doInvoke core.clj 5753]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$require doInvoke core.clj 5832]

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

  [aleph.http$eval1594$loading__5340__auto____1595 invoke http.clj 1]

  [aleph.http$eval1594 invoke http.clj 1]

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

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

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

  [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__5448 invoke core.clj 5866]

  [clojure.core$load doInvoke core.clj 5865]

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

  [clojure.core$load_one invoke core.clj 5671]

  [clojure.core$load_lib$fn__5397 invoke core.clj 5711]

  [clojure.core$load_lib doInvoke core.clj 5710]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$load_libs doInvoke core.clj 5749]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$require doInvoke core.clj 5832]

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

  [cloud_monkey.aleph_netty$eval1588$loading__5340__auto____1589 invoke aleph_netty.clj 1]

  [cloud_monkey.aleph_netty$eval1588 invoke aleph_netty.clj 1]

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

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

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

  [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__5448 invoke core.clj 5866]

  [clojure.core$load doInvoke core.clj 5865]

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

  [clojure.core$load_one invoke core.clj 5671]

  [clojure.core$load_lib$fn__5397 invoke core.clj 5711]

  [clojure.core$load_lib doInvoke core.clj 5710]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$load_libs doInvoke core.clj 5749]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$require doInvoke core.clj 5832]

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

  [cloud_monkey.core$eval14$loading__5340__auto____15 invoke core.clj 1]

  [cloud_monkey.core$eval14 invoke core.clj 1]

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

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

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

  [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__5448 invoke core.clj 5866]

  [clojure.core$load doInvoke core.clj 5865]

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

  [clojure.core$load_one invoke core.clj 5671]

  [clojure.core$load_lib$fn__5397 invoke core.clj 5711]

  [clojure.core$load_lib doInvoke core.clj 5710]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$load_libs doInvoke core.clj 5749]

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

  [clojure.core$apply invoke core.clj 632]

  [clojure.core$require doInvoke core.clj 5832]

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

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

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

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

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

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

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

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

  [clojure.main$init_opt invoke main.clj 280]

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

  [clojure.main$null_opt invoke main.clj 343]

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

  [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]]}

@raspasov

[Zach Tellman]

A similar issue was reported earlier in the thread, target [potemkin "0.4.1"] and see if that fixes it.

[Rangel Spasov]

Ok, I think someone already mentioned this - sorry. Got it to compile by bumping to [potemkin "0.4.1"] - thanks Zach + all : ) 

On Tuesday, July 21, 2015 at 12:24:43 PM UTC-7, Rangel Spasov wrote:

[Lawrence Krubner]

Off topic, but I wonder if there was ever any discussion of megarefs being added to Clojure?

https://github.com/cgrand/megaref

[Daniel Compton]

I think this is pretty unlikely. While megarefs look very cool, I'm not sure what the benefit to having these directly in Clojure would be over having them in a library. 

Anecdotally, everyone I have talked to about Clojure's reference types have said that they have never needed to use ref's or agents in real world code (I'm sure some people have to good effect though).

That being said, you can always open a JIRA or design doc about this if you feel strongly about it to start a discussion.

--

Daniel.

--

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.

--

--

Daniel

[Justin Smith]

I use agents instead of atoms when the function altering the value has side effects, or is especially expensive (and thus should not retry).

I haven't had to use refs yet, but my use case would be if the mutable data has enough parallel modification that splitting one atomic map into separate ref maps would be a performance boost.