Yes
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@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
Will someone remember to update http://clojure.org/transients once 1.7.0 is
released?
On Monday, November 3, 2014 at 1:57:58 AM UTC-8, Daniel Marjenburgh wrote:
Hi,
I just want to address this issue (CLJ-1498
http://dev.clojure.org/jira/browse/CLJ-1498). It was accepted in
1.7-alpha2 and
Hi Atamert, yes, that is also wrong usage that is not caught. I do want to
focus on the current change though.
So the thought behind this change is that the birth-thread check was
unnecessary or too strict from the beginning and people should just use
transients correctly, caveat implementor.
I'll be more careful before posted code that doesn't compile :)
Anyway, here's my output using clojure 1.7-alpha3
https://lh4.googleusercontent.com/-MqiKnTcxneE/VFigwvQtzBI/A08/vGvY2waCJdc/s1600/Screen%2BShot%2B2014-11-04%2Bat%2B10.43.17.png
It could be that depending on OS/env the
Hi there,
On Tuesday, November 4, 2014 8:05:03 AM UTC+1, Daniel Marjenburgh wrote:
I know transients aren't bash-in-place, as they may return new references,
but that is not the problem I'm having here.
If you bash in place, you would get unexpected results, but still the same
result every
Hi Jean,
In this case, we are dealing with 1 key-value pair, so there is only one
transient reference all the time. It is not my experience that each update
returns a new transient value (here, each update is identical to the
original, as per the identical? predicate).
I know you shouldn't
Hi Daniel,
On Tuesday, November 4, 2014 11:54:30 AM UTC+1, Daniel Marjenburgh wrote:
Hi Jean,
In this case, we are dealing with 1 key-value pair, so there is only one
transient reference all the time. It is not my experience that each update
returns a new transient value (here, each
I think all of these examples violate the usage expectations of transients
(regardless of release) and you should expect to get confusing results from
them.
I do not think it's worth modifying core.async go blocks to do anything special
in this regard (eince go is a macro I don't think you can
Hi Alex,
I understand any concurrent use of transients violates the usage
expectations. Of course, if you treat any piece of mutable state
sequentially like transients, you would not run into trouble either.
My concern is purely about the safety that is taken away when transients
'are' used
Hi Daniel,
On Wed, Nov 5, 2014 at 3:06 PM, Daniel Marjenburgh dmarjenbu...@gmail.com
wrote:
My concern is purely about the safety that is taken away when transients
'are' used wrongly. All the examples would've throw exceptions before
1.7-alpha2, and they don't do so anymore.
But they
Hi,
I just want to address this issue (CLJ-1498
http://dev.clojure.org/jira/browse/CLJ-1498). It was accepted in
1.7-alpha2 and I haven't seen a lot of discussion around it, even though
it's quite a big change.
With this change the following code is possible:
(let [m (transient {:a 0})
On Mon, Nov 3, 2014 at 5:57 PM, Daniel Marjenburgh dmarjenbu...@gmail.com
wrote:
Hi,
I just want to address this issue (CLJ-1498
http://dev.clojure.org/jira/browse/CLJ-1498). It was accepted in
1.7-alpha2 and I haven't seen a lot of discussion around it, even though
it's quite a big change.
On Monday, November 3, 2014 9:00:10 PM UTC-6, Atamert Ölçgen wrote:
On Mon, Nov 3, 2014 at 5:57 PM, Daniel Marjenburgh dmarje...@gmail.com
javascript: wrote:
Hi,
I just want to address this issue (CLJ-1498
http://dev.clojure.org/jira/browse/CLJ-1498). It was accepted in
1.7-alpha2
Thanks Alex!
Now that I took a second look at Daniel's code, it seems assoc! is used
like swap!, as if it would modify m in place. So I would expect, if it runs
without errors, result to be {:a 0}.
Given that transients are values (not reference types like ref or atom) I
can't think of a case
On Monday, November 3, 2014 10:44:19 PM UTC-6, Atamert Ölçgen wrote:
Thanks Alex!
Now that I took a second look at Daniel's code, it seems assoc! is used
like swap!, as if it would modify m in place. So I would expect, if it runs
without errors, result to be {:a 0}.
Right, that is an
Hi Alex.
I know transients aren't bash-in-place, as they may return new references,
but that is not the problem I'm having here.
If you bash in place, you would get unexpected results, but still the same
result every time. The problem here is that the 'value' of the transient is
changing
I was a bit too quick there and posted some errors int he code:
(let [v (transient {:a 0})
f1 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))
f2 (future (reduce #(assoc! % (+ (:a %) %2)) v (range 10)))]
@f1 @f2 ; wait for futures
(persistent! @f1))
--
You received
FWIW I can confirm the following code produces {:a 90} consistently:
(let [v (transient {:a 0})
f1 (delay (reduce #(assoc! % :a (+ (:a %) %2)) v (range 10)))
f2 (delay (reduce #(assoc! % :a (+ (:a %) %2)) v (range 10)))]
@f1 @f2 ; wait for futures
(persistent! @f1))
Note that
On Nov 3, 2014, at 11:13 PM, Daniel Marjenburgh dmarjenbu...@gmail.com wrote:
I was a bit too quick there and posted some errors int he code:
That’s still not quite right. I think you mean:
(let [v (transient {:a 0})
f1 (future (reduce #(assoc! % :a (+ (:a %) %2)) v (range 10)))
f2
19 matches
Mail list logo
