Re: About transients no longer being safe in 1.7-alpha2

[Sean Corfield]

On Nov 3, 2014, at 11:13 PM, Daniel Marjenburgh  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 (future (reduce #(assoc! % :a (+ (:a %) %2)) v (range 10)))]
  @f1 @f2 ; wait for futures
  (persistent! @f1))

Which seems to consistently produce {:a 90} on both Clojure 1.7.0 Alpha 2 and 
Clojure 1.7.0 Alpha 3.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

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



-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: About transients no longer being safe in 1.7-alpha2

[Atamert Ölçgen]

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 there are no future calls here. Clojure 1.5.1

Part of me wants the result to be {:a 45}


On Tue, Nov 4, 2014 at 3:13 PM, Daniel Marjenburgh 
wrote:

> 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 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
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: About transients no longer being safe in 1.7-alpha2

[Daniel Marjenburgh]

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 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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: About transients no longer being safe in 1.7-alpha2

[Daniel Marjenburgh]

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 underneath you because of another thread.

Let me change the example a bit:

(let [v (transient {:a 0})
  f1 (future (reduce #(assoc! % (+ (:a %) %2
  f2 (future (reduce #(assoc! % (+ (:a %) %2]
  @f1 @f2 ; wait for futures
  (persistent! f1))

This will also give varying results on each run. If you were to add a 
(println (:a %)) in the reducing fn of f1 you would see the results are not 
the same each time.

Op dinsdag 4 november 2014 06:13:00 UTC+1 schreef Alex Miller:
>
>
>
> 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 incorrect usage - it will actually modify with changes 
> though, but not in expected ways (this is independent of the change we're 
> discussing - you can get the same behavior in a single thread modifying a 
> transient without reusing the return).
>
> Given that transients are values (not reference types like ref or atom) I 
>> can't think of a case where they can be modified concurrently.
>>
>
> You can, but not without going pretty far out of normal Clojure code. 
>  
>
>>
>>
>> On Tue, Nov 4, 2014 at 11:19 AM, Alex Miller  
>> wrote:
>>
>>>
>>>
>>> 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 >>> > wrote:

> Hi,
>
> I just want to address this issue (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:
>

 With persistents the result would be the same, every time. If this is 
 now valid Clojure, I didn't run it myself, we are sacrificing consistency. 
 I don't understand what we're getting in return.

 Even the simple example in the ticket (with one future) doesn't make a 
 lot of sense to me.

 Am I missing something obvious?

>>>
>>> Transients always expect thread isolation. In the past this was locked 
>>> to a single thread (the one that made the transient). That restriction now 
>>> extends to being used by multiple threads, but isolation should still be 
>>> maintained for proper use. 
>>>
>>> What we are gaining is the ability to use transient collections in go 
>>> blocks with core.async, where the thread being used is just one pool out of 
>>> a thread. For example (just typing this not running it, so excuse any 
>>> typos):
>>>
>>> (defn drain [ch coll] 
>>>   (let [t (transient []]
>>> (go-loop
>>>   (if-some [v (>> (do (conj! t v) (recur))
>>> (persistent! t)
>>>
>>> This doesn't necessarily work in core.async because each time the >> parks, it may be woken up with a different thread from the pool. The 
>>> transient change allows this kind of code to succeed.
>>>
>>>

> (let [m (transient {:a 0})
>   futs (for [n (range 100)]
>  (future (assoc! m :a (inc (:a m)]
>   (mapv deref futs) ; wait until futures are done
>   (persistent! m))
>
>
> The results will vary per run, where it used to throw 
> an IllegalAccessError: "Transient used by non-owner thread".
>
> I understand the problems of not being able to have 1 go routine 
> access a transient, even though it would be safe, but this solution feels 
> like it's throwing out the baby with the bathwater. Basically, it's doing 
> away with what the following block on clojure.org 
>  says:
>
> *Transients enforce thread isolation**.* Because each result of a 
>> transient operation shares (mutable) structure with the previous, it 
>> would 
>> be very dangerous if more than one thread were to manipulate a transient 
>> at 
>> once. In order to prevent this, transients will detect any (read or 
>> write) 
>> use from a thread other than the one that created them and throw an 
>> exception.
>
>  
>
>>
>> This may not sound like a concurrency story, but single-thread 
>> isolation is actually a very useful concurrency semantic. The whole 
>> point 
>> of using transients is that doing so is safe, because their use is an 
>> isolated implementation detail of otherwise functional code. Having that 
>> be 
>> enforced means that some things that would normally be very hard to make 
>> 

Re: About transients no longer being safe in 1.7-alpha2

[Alex Miller]

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 incorrect usage - it will actually modify with changes 
though, but not in expected ways (this is independent of the change we're 
discussing - you can get the same behavior in a single thread modifying a 
transient without reusing the return).

Given that transients are values (not reference types like ref or atom) I 
> can't think of a case where they can be modified concurrently.
>

You can, but not without going pretty far out of normal Clojure code. 
 

>
>
> On Tue, Nov 4, 2014 at 11:19 AM, Alex Miller  > wrote:
>
>>
>>
>> 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  
>>> wrote:
>>>
 Hi,

 I just want to address this issue (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:

>>>
>>> With persistents the result would be the same, every time. If this is 
>>> now valid Clojure, I didn't run it myself, we are sacrificing consistency. 
>>> I don't understand what we're getting in return.
>>>
>>> Even the simple example in the ticket (with one future) doesn't make a 
>>> lot of sense to me.
>>>
>>> Am I missing something obvious?
>>>
>>
>> Transients always expect thread isolation. In the past this was locked to 
>> a single thread (the one that made the transient). That restriction now 
>> extends to being used by multiple threads, but isolation should still be 
>> maintained for proper use. 
>>
>> What we are gaining is the ability to use transient collections in go 
>> blocks with core.async, where the thread being used is just one pool out of 
>> a thread. For example (just typing this not running it, so excuse any 
>> typos):
>>
>> (defn drain [ch coll] 
>>   (let [t (transient []]
>> (go-loop
>>   (if-some [v (> (do (conj! t v) (recur))
>> (persistent! t)
>>
>> This doesn't necessarily work in core.async because each time the > parks, it may be woken up with a different thread from the pool. The 
>> transient change allows this kind of code to succeed.
>>
>>
>>>
 (let [m (transient {:a 0})
   futs (for [n (range 100)]
  (future (assoc! m :a (inc (:a m)]
   (mapv deref futs) ; wait until futures are done
   (persistent! m))


 The results will vary per run, where it used to throw 
 an IllegalAccessError: "Transient used by non-owner thread".

 I understand the problems of not being able to have 1 go routine access 
 a transient, even though it would be safe, but this solution feels like 
 it's throwing out the baby with the bathwater. Basically, it's doing away 
 with what the following block on clojure.org 
  says:

 *Transients enforce thread isolation**.* Because each result of a 
> transient operation shares (mutable) structure with the previous, it 
> would 
> be very dangerous if more than one thread were to manipulate a transient 
> at 
> once. In order to prevent this, transients will detect any (read or 
> write) 
> use from a thread other than the one that created them and throw an 
> exception.

  

>
> This may not sound like a concurrency story, but single-thread 
> isolation is actually a very useful concurrency semantic. The whole point 
> of using transients is that doing so is safe, because their use is an 
> isolated implementation detail of otherwise functional code. Having that 
> be 
> enforced means that some things that would normally be very hard to make 
> safe with ordinary mutable data structures become easy.


 I don't have a good solution for dealing with transients and logical 
 threads, but I would much prefer keeping the semantics of transients as 
 they are and maybe pass an option to transient to disable owner checking.

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

Re: About transients no longer being safe in 1.7-alpha2

[Atamert Ölçgen]

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 where they can be modified concurrently.


On Tue, Nov 4, 2014 at 11:19 AM, Alex Miller  wrote:

>
>
> 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 
>> wrote:
>>
>>> Hi,
>>>
>>> I just want to address this issue (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:
>>>
>>
>> With persistents the result would be the same, every time. If this is now
>> valid Clojure, I didn't run it myself, we are sacrificing consistency. I
>> don't understand what we're getting in return.
>>
>> Even the simple example in the ticket (with one future) doesn't make a
>> lot of sense to me.
>>
>> Am I missing something obvious?
>>
>
> Transients always expect thread isolation. In the past this was locked to
> a single thread (the one that made the transient). That restriction now
> extends to being used by multiple threads, but isolation should still be
> maintained for proper use.
>
> What we are gaining is the ability to use transient collections in go
> blocks with core.async, where the thread being used is just one pool out of
> a thread. For example (just typing this not running it, so excuse any
> typos):
>
> (defn drain [ch coll]
>   (let [t (transient []]
> (go-loop
>   (if-some [v ( (do (conj! t v) (recur))
> (persistent! t)
>
> This doesn't necessarily work in core.async because each time the  parks, it may be woken up with a different thread from the pool. The
> transient change allows this kind of code to succeed.
>
>
>>
>>> (let [m (transient {:a 0})
>>>   futs (for [n (range 100)]
>>>  (future (assoc! m :a (inc (:a m)]
>>>   (mapv deref futs) ; wait until futures are done
>>>   (persistent! m))
>>>
>>>
>>> The results will vary per run, where it used to throw
>>> an IllegalAccessError: "Transient used by non-owner thread".
>>>
>>> I understand the problems of not being able to have 1 go routine access
>>> a transient, even though it would be safe, but this solution feels like
>>> it's throwing out the baby with the bathwater. Basically, it's doing away
>>> with what the following block on clojure.org
>>>  says:
>>>
>>> *Transients enforce thread isolation**.* Because each result of a
 transient operation shares (mutable) structure with the previous, it would
 be very dangerous if more than one thread were to manipulate a transient at
 once. In order to prevent this, transients will detect any (read or write)
 use from a thread other than the one that created them and throw an
 exception.
>>>
>>>
>>>

 This may not sound like a concurrency story, but single-thread
 isolation is actually a very useful concurrency semantic. The whole point
 of using transients is that doing so is safe, because their use is an
 isolated implementation detail of otherwise functional code. Having that be
 enforced means that some things that would normally be very hard to make
 safe with ordinary mutable data structures become easy.
>>>
>>>
>>> I don't have a good solution for dealing with transients and logical
>>> threads, but I would much prefer keeping the semantics of transients as
>>> they are and maybe pass an option to transient to disable owner checking.
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> Kind Regards,
>> Atamert Ölçgen
>>
>> -+-
>> --+
>> +++
>>
>> www.muhuk.com
>>
>  --
> 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
> clojure+unsubscr...@googlegroups.com
> For more options, visit

Re: About transients no longer being safe in 1.7-alpha2

[Alex Miller]

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  > wrote:
>
>> Hi,
>>
>> I just want to address this issue (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:
>>
>
> With persistents the result would be the same, every time. If this is now 
> valid Clojure, I didn't run it myself, we are sacrificing consistency. I 
> don't understand what we're getting in return.
>
> Even the simple example in the ticket (with one future) doesn't make a lot 
> of sense to me.
>
> Am I missing something obvious?
>

Transients always expect thread isolation. In the past this was locked to a 
single thread (the one that made the transient). That restriction now 
extends to being used by multiple threads, but isolation should still be 
maintained for proper use. 

What we are gaining is the ability to use transient collections in go 
blocks with core.async, where the thread being used is just one pool out of 
a thread. For example (just typing this not running it, so excuse any 
typos):

(defn drain [ch coll] 
  (let [t (transient []]
(go-loop
  (if-some [v (
>> (let [m (transient {:a 0})
>>   futs (for [n (range 100)]
>>  (future (assoc! m :a (inc (:a m)]
>>   (mapv deref futs) ; wait until futures are done
>>   (persistent! m))
>>
>>
>> The results will vary per run, where it used to throw 
>> an IllegalAccessError: "Transient used by non-owner thread".
>>
>> I understand the problems of not being able to have 1 go routine access a 
>> transient, even though it would be safe, but this solution feels like it's 
>> throwing out the baby with the bathwater. Basically, it's doing away with 
>> what the following block on clojure.org 
>>  says:
>>
>> *Transients enforce thread isolation**.* Because each result of a 
>>> transient operation shares (mutable) structure with the previous, it would 
>>> be very dangerous if more than one thread were to manipulate a transient at 
>>> once. In order to prevent this, transients will detect any (read or write) 
>>> use from a thread other than the one that created them and throw an 
>>> exception.
>>
>>  
>>
>>>
>>> This may not sound like a concurrency story, but single-thread isolation 
>>> is actually a very useful concurrency semantic. The whole point of using 
>>> transients is that doing so is safe, because their use is an isolated 
>>> implementation detail of otherwise functional code. Having that be enforced 
>>> means that some things that would normally be very hard to make safe with 
>>> ordinary mutable data structures become easy.
>>
>>
>> I don't have a good solution for dealing with transients and logical 
>> threads, but I would much prefer keeping the semantics of transients as 
>> they are and maybe pass an option to transient to disable owner checking.
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> -+-
> --+
> +++
>
> www.muhuk.com
>  

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: About transients no longer being safe in 1.7-alpha2

[Atamert Ölçgen]

On Mon, Nov 3, 2014 at 5:57 PM, Daniel Marjenburgh 
wrote:

> Hi,
>
> I just want to address this issue (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:
>

With persistents the result would be the same, every time. If this is now
valid Clojure, I didn't run it myself, we are sacrificing consistency. I
don't understand what we're getting in return.

Even the simple example in the ticket (with one future) doesn't make a lot
of sense to me.

Am I missing something obvious?



>
> (let [m (transient {:a 0})
>   futs (for [n (range 100)]
>  (future (assoc! m :a (inc (:a m)]
>   (mapv deref futs) ; wait until futures are done
>   (persistent! m))
>
>
> The results will vary per run, where it used to throw
> an IllegalAccessError: "Transient used by non-owner thread".
>
> I understand the problems of not being able to have 1 go routine access a
> transient, even though it would be safe, but this solution feels like it's
> throwing out the baby with the bathwater. Basically, it's doing away with
> what the following block on clojure.org 
>  says:
>
> *Transients enforce thread isolation**.* Because each result of a
>> transient operation shares (mutable) structure with the previous, it would
>> be very dangerous if more than one thread were to manipulate a transient at
>> once. In order to prevent this, transients will detect any (read or write)
>> use from a thread other than the one that created them and throw an
>> exception.
>
>
>
>>
>> This may not sound like a concurrency story, but single-thread isolation
>> is actually a very useful concurrency semantic. The whole point of using
>> transients is that doing so is safe, because their use is an isolated
>> implementation detail of otherwise functional code. Having that be enforced
>> means that some things that would normally be very hard to make safe with
>> ordinary mutable data structures become easy.
>
>
> I don't have a good solution for dealing with transients and logical
> threads, but I would much prefer keeping the semantics of transients as
> they are and maybe pass an option to transient to disable owner checking.
>
> --
> 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
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kind Regards,
Atamert Ölçgen

-+-
--+
+++

www.muhuk.com

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

OJ - A friendly way to talk to your database using Clojure.

[Taylor Lapeyre]

GitHub project link:
https://github.com/taylorlapeyre/oj

The idea is to lay a solid foundation for talking to databases in Clojure 
using regular Clojure data structures to represent queries. My goal is to 
let this library become established enough that is becomes the foundation 
for larger frameworks that abstract away the ideas found in SQL.

Looking for feedback and for others to help me on this project! I hope you 
find this useful, it has been very useful for me so far.

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deterministic Randomness in Functional Clojure

[Rob Lally]

It might also be worth noting that the JDK ships with 
java.security.SecureRandom a subclass of java.util.Random.

http://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html



R.




On 1 Nov 2014, at 10:31, Mars0i  wrote:

> 
> 
> On Friday, October 31, 2014 11:19:19 PM UTC-5, Isaac Karth wrote:
> Looks like if I want to use libraries like clojure.data.generators or 
> bigml.sampling I'd need to amend the random generators to replace calls to 
> the Mersenne Twister function or (def ^:dynamic *rnd* (java.util.Random. 
> 42)). As long 
> 
> Further clarification: I believe that java.util.Random doesn't use a Mersenne 
> Twister, so clojure.data.generators doesn't by default, either.  However, 
> Sean Luke's MersenneTwister.java subclasses java.util.Random, so you should 
> be able to use it as the RNG behind clojure.data.generators, if that seemed 
> like a good idea in other respects.  (Luke's other implementation, 
> MersenneTwisterFast.java, does not subclass java.util.Random.  I'm not 
> certain whether it can be used it with data.generators.  At one time I knew, 
> but I would have to review past investigations to know now.)
> 
> And, while I'm at it, it's worth mentioning that the Incanter statistical 
> library for Clojure also has some random number generating functions.  Some 
> of these are based on java.util.Random.  Don't know if they'd be worth 
> looking at for your purposes.  (I don't know anything about PRF's so no 
> comments from me about that path.)
> 
> -- 
> 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
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Garden defcssfn not rendering

[Rory Douglas]

I'm having an issue generating a CSS function (for the scale() transform 
function) using Garden's *defcssfn *macro.  The macro appears to generate 
the Garden CSSFunction record fine, but the (css) call returns an empty 
string.

(defcssfn scale
  ([a] [a a])
  ([x y] [x y]))

(scale 2)
;; #garden.types.CSSFunction{:function "scale", :args [2 2]}

(css (scale 2))
;; ""   <-- source of woe

Any idea what I might be missing? I'm using garden 1.2.5 and lein-garden 
0.2.5.


-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure usage in production - survey on Hacker News (Nov 2014)

[Ashton Kemerling]

We aren't secretive about our usage of it, but it's used for testing only. It 
doesn't get shipped to any server, hence why production is a stretch.

On Mon, Nov 3, 2014 at 5:57 PM, Alex Miller  wrote:

> I was mostly trying to include interesting companies using it for 
> something. Sorry if I overstepped! :)
> On Monday, November 3, 2014 6:27:41 PM UTC-6, viksit wrote:
>>
>>
>> Ashton - perhaps you should elucidate on matters on that thread :) And why 
>> do you say "stretching" definitions?
>>
>>
>> On Monday, November 3, 2014 4:03:36 PM UTC-8, Ashton Kemerling wrote:
>>>
>>> I'm really entertained that pivotal labs made that list, as I wrote that 
>>> code (and that blog post) and "production" is stretching definitions pretty 
>>> far sadly. 
>>>
>>>
>>>
>>> On Mon, Nov 3, 2014 at 4:55 PM, viksit  wrote:
>>>
 Hello all,

 I was curious about the state of Clojure in production, and put up this 
 thread on Hacker News asking for insight, since all the other threads are 
 quite dated. 

 https://news.ycombinator.com/item?id=8549823

 Given the large amount of feedback that's already on it, I thought I'd 
 cross post here and get the list's feedback on this as well. 

 I think it would be great to have this resource updated with the latest 
 state of Clojure in production around the world, especially so in helping 
 answer queries in people's minds as they try to figure out who else uses 
 it 
 before they do.

 Cheers,
 Viksit




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

>>>
>>>
> -- 
> 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
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure usage in production - survey on Hacker News (Nov 2014)

[Alex Miller]

I was mostly trying to include interesting companies using it for 
something. Sorry if I overstepped! :)

On Monday, November 3, 2014 6:27:41 PM UTC-6, viksit wrote:
>
>
> Ashton - perhaps you should elucidate on matters on that thread :) And why 
> do you say "stretching" definitions?
>
>
> On Monday, November 3, 2014 4:03:36 PM UTC-8, Ashton Kemerling wrote:
>>
>> I'm really entertained that pivotal labs made that list, as I wrote that 
>> code (and that blog post) and "production" is stretching definitions pretty 
>> far sadly. 
>>
>>
>>
>> On Mon, Nov 3, 2014 at 4:55 PM, viksit  wrote:
>>
>>> Hello all,
>>>
>>> I was curious about the state of Clojure in production, and put up this 
>>> thread on Hacker News asking for insight, since all the other threads are 
>>> quite dated. 
>>>
>>> https://news.ycombinator.com/item?id=8549823
>>>
>>> Given the large amount of feedback that's already on it, I thought I'd 
>>> cross post here and get the list's feedback on this as well. 
>>>
>>> I think it would be great to have this resource updated with the latest 
>>> state of Clojure in production around the world, especially so in helping 
>>> answer queries in people's minds as they try to figure out who else uses it 
>>> before they do.
>>>
>>> Cheers,
>>> Viksit
>>>
>>>
>>>
>>>
>>>  -- 
>>> 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.
>>>
>>
>>

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure usage in production - survey on Hacker News (Nov 2014)

[viksit]

Ashton - perhaps you should elucidate on matters on that thread :) And why 
do you say "stretching" definitions?


On Monday, November 3, 2014 4:03:36 PM UTC-8, Ashton Kemerling wrote:
>
> I'm really entertained that pivotal labs made that list, as I wrote that 
> code (and that blog post) and "production" is stretching definitions pretty 
> far sadly. 
>
>
>
> On Mon, Nov 3, 2014 at 4:55 PM, viksit > 
> wrote:
>
>> Hello all,
>>
>> I was curious about the state of Clojure in production, and put up this 
>> thread on Hacker News asking for insight, since all the other threads are 
>> quite dated. 
>>
>> https://news.ycombinator.com/item?id=8549823
>>
>> Given the large amount of feedback that's already on it, I thought I'd 
>> cross post here and get the list's feedback on this as well. 
>>
>> I think it would be great to have this resource updated with the latest 
>> state of Clojure in production around the world, especially so in helping 
>> answer queries in people's minds as they try to figure out who else uses it 
>> before they do.
>>
>> Cheers,
>> Viksit
>>
>>
>>
>>
>>  -- 
>> 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.
>>
>
>

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure usage in production - survey on Hacker News (Nov 2014)

[Ashton Kemerling]

I'm really entertained that pivotal labs made that list, as I wrote that code 
(and that blog post) and "production" is stretching definitions pretty far 
sadly.

On Mon, Nov 3, 2014 at 4:55 PM, viksit  wrote:

> Hello all,
> I was curious about the state of Clojure in production, and put up this 
> thread on Hacker News asking for insight, since all the other threads are 
> quite dated. 
> https://news.ycombinator.com/item?id=8549823
> Given the large amount of feedback that's already on it, I thought I'd 
> cross post here and get the list's feedback on this as well. 
> I think it would be great to have this resource updated with the latest 
> state of Clojure in production around the world, especially so in helping 
> answer queries in people's minds as they try to figure out who else uses it 
> before they do.
> Cheers,
> Viksit
> -- 
> 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
> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Clojure usage in production - survey on Hacker News (Nov 2014)

[viksit]

Hello all,

I was curious about the state of Clojure in production, and put up this 
thread on Hacker News asking for insight, since all the other threads are 
quite dated. 

https://news.ycombinator.com/item?id=8549823

Given the large amount of feedback that's already on it, I thought I'd 
cross post here and get the list's feedback on this as well. 

I think it would be great to have this resource updated with the latest 
state of Clojure in production around the world, especially so in helping 
answer queries in people's minds as they try to figure out who else uses it 
before they do.

Cheers,
Viksit




-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introducing Boot v2 with a streamlined CLJS workflow

[Laurent PETIT]

And more seriously, I remember reading that you put an emphasis on removing
the need to use a clean task.
If I'm right, then I'd be interested in knowing how one is encouraged /
helped to pursue this good property in its own tasks ?

Le lundi 3 novembre 2014, Laurent PETIT  a écrit :

> Tongue in cheek question: if Leiningen were the maven of clojure, would
> you say boot2 is gradle ? :-)
>
> Le lundi 3 novembre 2014, Micha Niskin  > a écrit :
>
>> Hi!
>>
>> Boot (http://github.com/boot-clj/boot) is a build tool for Clojure.
>> We've pulled together lessons learned from a year or so using boot v1 in
>> production and are now getting ready to release v2. To show what boot can
>> do we present a very streamlined and awesome boot-based ClojureScript
>> development workflow (
>> http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/).
>>
>> Try it out, maybe you'll like it! We're hoping to get some feedback
>> before committing to a stable release, so please if you have any comments
>> or questions we'd be happy to hear them. Have fun!
>>
>> --
>> 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
>> clojure+unsubscr...@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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Laurent Petit
>
>

-- 
Laurent Petit

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Introducing Boot v2 with a streamlined CLJS workflow

[Laurent PETIT]

Tongue in cheek question: if Leiningen were the maven of clojure, would you
say boot2 is gradle ? :-)

Le lundi 3 novembre 2014, Micha Niskin  a écrit :

> Hi!
>
> Boot (http://github.com/boot-clj/boot) is a build tool for Clojure. We've
> pulled together lessons learned from a year or so using boot v1 in
> production and are now getting ready to release v2. To show what boot can
> do we present a very streamlined and awesome boot-based ClojureScript
> development workflow (
> http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/).
>
> Try it out, maybe you'll like it! We're hoping to get some feedback before
> committing to a stable release, so please if you have any comments or
> questions we'd be happy to hear them. Have fun!
>
> --
> 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
> clojure+unsubscr...@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+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Laurent Petit

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Java Listener on Textfield

[Stefan Kamphausen]

Hi,

not directly an answer to your question, but you may be interested in 
Seesaw and it binding facilities.

Unless you are looking for pure Java solutions in which case your posting 
in the wrong group.

Kind regards,
stefan

On Monday, November 3, 2014 1:52:46 PM UTC+1, Azzoug Youcef wrote:
>
>
> Hellow everybody,
>
> Somebody please tell me how to trigger the right Event listener to a text 
> field in java
>
> In the example below all components modify their corresponding panel's 
> background color including the text field
>
> the latter do this streatement by writing the color among five colors,my 
> issue is what is the right listener or adapter to use for it
>
> Thanks in advance
>

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Introducing Boot v2 with a streamlined CLJS workflow

[Micha Niskin]

Hi!

Boot (http://github.com/boot-clj/boot) is a build tool for Clojure. We've 
pulled together lessons learned from a year or so using boot v1 in 
production and are now getting ready to release v2. To show what boot can 
do we present a very streamlined and awesome boot-based ClojureScript 
development workflow (
http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/). 

Try it out, maybe you'll like it! We're hoping to get some feedback before 
committing to a stable release, so please if you have any comments or 
questions we'd be happy to hear them. Have fun!

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

About transients no longer being safe in 1.7-alpha2

[Daniel Marjenburgh]

Hi,

I just want to address this issue (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})
  futs (for [n (range 100)]
 (future (assoc! m :a (inc (:a m)]
  (mapv deref futs) ; wait until futures are done
  (persistent! m))


The results will vary per run, where it used to throw 
an IllegalAccessError: "Transient used by non-owner thread".

I understand the problems of not being able to have 1 go routine access a 
transient, even though it would be safe, but this solution feels like it's 
throwing out the baby with the bathwater. Basically, it's doing away with 
what the following block on clojure.org 
 says:

*Transients enforce thread isolation**.* Because each result of a transient 
> operation shares (mutable) structure with the previous, it would be very 
> dangerous if more than one thread were to manipulate a transient at once. 
> In order to prevent this, transients will detect any (read or write) use 
> from a thread other than the one that created them and throw an exception.

 

>
> This may not sound like a concurrency story, but single-thread isolation 
> is actually a very useful concurrency semantic. The whole point of using 
> transients is that doing so is safe, because their use is an isolated 
> implementation detail of otherwise functional code. Having that be enforced 
> means that some things that would normally be very hard to make safe with 
> ordinary mutable data structures become easy.


I don't have a good solution for dealing with transients and logical 
threads, but I would much prefer keeping the semantics of transients as 
they are and maybe pass an option to transient to disable owner checking.

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Java Listener on Textfield

[Azzoug Youcef]

Hellow everybody,

Somebody please tell me how to trigger the right Event listener to a text 
field in java

In the example below all components modify their corresponding panel's 
background color including the text field

the latter do this streatement by writing the color among five colors,my 
issue is what is the right listener or adapter to use for it

Thanks in advance

-- 
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
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.FlowLayout;
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.FocusAdapter;
import java.awt.event.FocusEvent;
import java.awt.event.FocusListener;
import java.awt.event.ItemEvent;
import java.awt.event.ItemListener;
import java.awt.event.MouseEvent;
import java.awt.event.MouseListener;

import javax.swing.BorderFactory;
import javax.swing.ButtonGroup;
import javax.swing.JComboBox;
import javax.swing.JComponent;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JRadioButton;
import javax.swing.JSlider;
import javax.swing.JSpinner;
import javax.swing.JTextField;
import javax.swing.SpinnerListModel;
import javax.swing.SpinnerModel;
import javax.swing.border.TitledBorder;
import javax.swing.event.CaretEvent;
import javax.swing.event.CaretListener;
import javax.swing.event.ChangeEvent;
import javax.swing.event.ChangeListener;
import javax.swing.event.DocumentEvent;
import javax.swing.event.DocumentListener;


public class Exercice5 extends JFrame {
	JPanel pan = new JPanel(new GridLayout(3,1));
	JPanel phaut = new JPanel(new FlowLayout(FlowLayout.CENTER,25,15));
	JPanel pcentre = new JPanel();
	JPanel pbas = new JPanel(); 
	JSlider slid = new JSlider(JSlider.HORIZONTAL, 0, 4, 0);
	JRadioButton rgreen = new JRadioButton("green");
	JRadioButton rblue = new JRadioButton("blue");
	JRadioButton rred = new JRadioButton("red");
	JRadioButton rmagenta = new JRadioButton("magenta");
	JRadioButton rorange = new JRadioButton("orange");
	String   couleurs[] = {"green","blue","red","magenta","orange"};
	JComboBox cb1 = new JComboBox(couleurs);
	SpinnerModel spm = new SpinnerListModel(couleurs);
	JSpinner spin = new JSpinner(spm);
	JTextField field1 = new JTextField("blanc",15);
	 
public Exercice5 () {
	
	this.setTitle("Exercice 5");
	this.setBounds(300, 100, 750, 225);
	this.setContentPane(pan); 	 
	spin.getEditor().setPreferredSize(new Dimension(60, 20));
	pan.add(phaut,BorderLayout.NORTH);
	pan.add(pcentre,BorderLayout.CENTER);
	pan.add(pbas,BorderLayout.SOUTH); 
	phaut.add(spin);
	slid.setMinorTickSpacing(1);
	slid.setPaintTicks(true);
	ButtonGroup group = new ButtonGroup();
	group.add(rgreen);
	group.add(rblue);
	group.add(rred);
	group.add(rmagenta);
	group.add(rorange);
	pcentre.setLayout(new FlowLayout(FlowLayout.CENTER,20,10));
pcentre.add(cb1);
pcentre.add(slid);
pcentre.add(rgreen);
pcentre.add(rblue);
pcentre.add(rred);
pcentre.add(rmagenta);
pcentre.add(rorange); 
pbas.setLayout(new FlowLayout(FlowLayout.CENTER,20,10));
TitledBorder postitle = BorderFactory.createTitledBorder("panel de saisie");
pbas.setBorder(postitle);
pbas.add(new JLabel("Color name (English)?"));
pbas.add(field1);
class Testcouleurs{
	JPanel pl;
	String s;
	Testcouleurs(JPanel pl,String s) {
		this.pl=pl;
		this.s=s;
		if(s=="green") pl.setBackground(Color.GREEN);
		if(s=="blue") pl.setBackground(Color.BLUE);
		if(s=="red") pl.setBackground(Color.RED);
		if(s=="magenta") pl.setBackground(Color.MAGENTA);
		if(s=="orange") pl.setBackground(Color.ORANGE);
	}	
}
class EventChange implements ChangeListener { 
	JPanel panel; 
	JComponent c;
	 EventChange(JPanel pan,JComponent cp){
		 this.panel = pan;
		 this.c = cp;
	 }
		public void stateChanged(ChangeEvent a) { 
			String sp = spin.getValue().toString();
			new Testcouleurs(panel,sp);		
		} 			 
	}
class EventItem implements ItemListener {
	JPanel panel;  
	 EventItem(JPanel pan){
		 this.panel = pan; 
	 }
		public void itemStateChanged(ItemEvent e) {
			 String sp = cb1.getSelectedItem().toString();
			 new Testcouleurs(panel,sp);	
		}  
} 
class EventDocume