[ANN] Clojure 1.8.0-alpha2

1552 views
Skip to first unread message

Alex Miller

unread,
Jul 18, 2015, 9:12:12 AM7/18/15
to clo...@googlegroups.com
Clojure 1.8.0-alpha1 and 1.8.0-alpha2 are now available.

Try it via
- 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

unread,
Jul 19, 2015, 1:33:19 AM7/19/15
to clo...@googlegroups.com
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

unread,
Jul 19, 2015, 3:13:31 AM7/19/15
to clo...@googlegroups.com
Are tuples used for small maps as well?

Peter Taoussanis

unread,
Jul 19, 2015, 4:10:37 AM7/19/15
to clo...@googlegroups.com
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

unread,
Jul 19, 2015, 9:40:51 AM7/19/15
to clo...@googlegroups.com
Seems like a bug to me.

Daniel Compton

unread,
Jul 19, 2015, 7:41:12 PM7/19/15
to clo...@googlegroups.com
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

unread,
Jul 19, 2015, 7:47:18 PM7/19/15
to clo...@googlegroups.com
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

unread,
Jul 19, 2015, 7:50:51 PM7/19/15
to clo...@googlegroups.com
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?



Michael Blume

unread,
Jul 19, 2015, 7:53:24 PM7/19/15
to clo...@googlegroups.com
Looks like it has, pinning to Potemkin 0.4.1 should probably sort you out

Michael Blume

unread,
Jul 19, 2015, 8:00:55 PM7/19/15
to clo...@googlegroups.com
(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

unread,
Jul 19, 2015, 8:02:13 PM7/19/15
to clo...@googlegroups.com
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.

Messagejava.lang.RuntimeException: No such var: clj-tuple/vector, compiling:(potemkin/utils.clj:110:10)
Causeclojure.lang.Compiler$CompilerException
StacktraceThe 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

unread,
Jul 20, 2015, 12:58:38 AM7/20/15
to clo...@googlegroups.com
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

unread,
Jul 20, 2015, 3:03:54 AM7/20/15
to clo...@googlegroups.com
> Seems like a bug to me.

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

Sean Corfield

unread,
Jul 20, 2015, 3:03:45 PM7/20/15
to clo...@googlegroups.com
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

unread,
Jul 20, 2015, 3:30:54 PM7/20/15
to clo...@googlegroups.com
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

unread,
Jul 20, 2015, 10:19:08 PM7/20/15
to clo...@googlegroups.com
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

unread,
Jul 20, 2015, 11:27:12 PM7/20/15
to clo...@googlegroups.com
Very likely that was the change for this ticket: http://dev.clojure.org/jira/browse/CLJ-703

Andy

--

Rui Paulo

unread,
Jul 20, 2015, 11:29:18 PM7/20/15
to clo...@googlegroups.com, Adam Krieg
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

unread,
Jul 21, 2015, 3:24:43 PM7/21/15
to clo...@googlegroups.com
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

unread,
Jul 21, 2015, 3:26:42 PM7/21/15
to clo...@googlegroups.com
A similar issue was reported earlier in the thread, target [potemkin "0.4.1"] and see if that fixes it.

Rangel Spasov

unread,
Jul 21, 2015, 3:30:46 PM7/21/15
to clo...@googlegroups.com
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

unread,
Jul 27, 2015, 5:05:37 PM7/27/15
to Clojure, rasp...@gmail.com
Off topic, but I wonder if there was ever any discussion of megarefs being added to Clojure?

Daniel Compton

unread,
Jul 28, 2015, 2:00:56 AM7/28/15
to Clojure, rasp...@gmail.com
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

unread,
Jul 28, 2015, 11:59:08 AM7/28/15
to Clojure, rasp...@gmail.com, daniel.com...@gmail.com
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.
Reply all
Reply to author
Forward
0 new messages