first vals first vals

[Zhemin Lin]

Hi.
I'm quite annoyed by the ugly smell of (first (vals (first ... )).  Is 
there any better way to do it?

user=> (-> {:key1 {:cf {:cq "0,1,2,3"}}} vals first vals first vals first 
(clojure.string/split #","))
["0" "1" "2" "3"]


Thanks a lot!

-- 
-- 
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/groups/opt_out.

Re: first vals first vals

[John Szakmeister]

On Thu, Nov 21, 2013 at 4:08 AM, Zhemin Lin  wrote:
> Hi.
> I'm quite annoyed by the ugly smell of (first (vals (first ... )).  Is there
> any better way to do it?
>
> user=> (-> {:key1 {:cf {:cq "0,1,2,3"}}} vals first vals first vals first
> (clojure.string/split #","))
> ["0" "1" "2" "3"]

I think you want get-in:

(-> {:key1 {:cf {:cq "0,1,2,3"}}}
(get-in [:key1 :cf :cq])
(clojure.string/split #","))

-John

-- 
-- 
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/groups/opt_out.

Re: first vals first vals

[Jernau]

You could use get-in:

(-> {:key1 {:cf {:cq "0,1,2,3"}}}
(get-in [:key1 :cf :cq]))

Cheers, 
James

On Thursday, November 21, 2013 10:08:06 AM UTC+1, Zhemin Lin wrote:
>
> Hi.
> I'm quite annoyed by the ugly smell of (first (vals (first ... )).  Is 
> there any better way to do it?
>
> user=> (-> {:key1 {:cf {:cq "0,1,2,3"}}} vals first vals first vals first 
> (clojure.string/split #","))
> ["0" "1" "2" "3"]
>
>
> Thanks a lot!
>

-- 
-- 
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/groups/opt_out.

Re: first vals first vals

[Zhemin Lin]

Thanks, John & Jernau.
What if :cf, :cq are not fixed, and I don't really care about the keys, but 
only the value of the value of the value ...?


Thanks,
Zhemin.

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Jim - FooBar();]

On 20/11/13 19:36, juan.facorro wrote:
The value for all refs whose value you don't actually modify inside a 
transaction should be obtained through ensure 
if you want 
to make sure :P their value won't be changed by a different 
transaction, that way you get a consistent value when the current 
transaction is finally committed.


ok this is an interesting and relevant for me commentlet's take a 
step back. Assume the same bank from my previous example and consider 
the following function:


(defn total!
 "Sum all accounts safely with a consistent view even if other 
transactions are still running."

 [bank]
   (dosync
 (reduce +'
   (map (comp :curr-balance second) *@bank*

What would be the implications of changing the bold bit to *(ensure bank) *?

On a slightly different note, is the mega-ref (the entire map in a ref) 
approach generally suggested ? I initially had a map-ref with agents 
inside (the accounts) but I find it a lot simpler to just have the 
map-ref...what ref-granularity are people suggesting for the bank example?



Jim

--
--
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Meikel Brandmeyer (kotarak)]

Hi Jim,

the main differences are:

deref inside transaction:
returns the value of bank at the end of this transaction (unless you used 
commute somewhere).

deref outside transaction:
returns the value of bank at that time, other transaction may have 
committed meanwhile.

Hope that helps.

Meikel

-- 
-- 
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/groups/opt_out.

Re: first vals first vals

[John Szakmeister]

On Thu, Nov 21, 2013 at 4:32 AM, Zhemin Lin  wrote:
> Thanks, John & Jernau.
> What if :cf, :cq are not fixed, and I don't really care about the keys, but
> only the value of the value of the value ...?

You might want to consider tree-seq to get at the innermost string:

(last (tree-seq map? vals
{:key1 {:cf {:cq "0,1,2,3"}}}))

-John

-- 
-- 
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Ulises]

First of all: Congratulations, looks like a great book!

Second, do you know why Amazon doesn't offer the kindle version while
Packt says it's available in digital format and displays an Amazon
logo (I'm assuming the Amazon logo means it's kindle)?

Cheers and looking forward to reading your book!

On 21 November 2013 02:10, Alex Baranosky  wrote:
> Congratulation on the book Shantanu!
>
>
> On Wed, Nov 20, 2013 at 5:16 PM, Shantanu Kumar 
> wrote:
>>
>> Now also available on
>> Amazon US: http://www.amazon.com/dp/1782165606/?tag=packtpubli-20
>> Amazon UK: http://www.amazon.co.uk/dp/1782165606/?tag=packtpubli-21
>>
>> Shantanu
>>
>> On Thursday, 21 November 2013 05:21:45 UTC+5:30, Shantanu Kumar wrote:
>>>
>>> Hi,
>>>
>>> I am pleased to announce availability of the book `Clojure High
>>> Performance Programming` that I have been writing for the better part of
>>> this year:
>>>
>>> http://www.packtpub.com/clojure-high-performance-programming/book
>>>
>>> This book is ideally meant for intermediate Clojure programmers. It is
>>> divided into seven chapters covering Clojure abstractions, Java interop, JVM
>>> internals, Concurrency and other performance-related topics.
>>>
>>> Shantanu
>>
>> --
>> --
>> 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/groups/opt_out.
>
>
> --
> --
> 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/groups/opt_out.

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Meikel Brandmeyer (kotarak)]

Hi,

Am Donnerstag, 21. November 2013 11:19:54 UTC+1 schrieb Jim foo.bar:
>
>  On 20/11/13 19:36, juan.facorro wrote:
>  
> The value for all refs whose value you don't actually modify inside a 
> transaction should be obtained through 
> ensure
>  if you want to make sure :P their value won't be changed by a different 
> transaction, that way you get a consistent value when the current 
> transaction is finally committed. 
>
>
> ok this is an interesting and relevant for me commentlet's take a step 
> back. Assume the same bank from my previous example and consider the 
> following function:
>
> (defn total! 
>  "Sum all accounts safely with a consistent view even if other 
> transactions are still running."
>  [bank]
>(dosync
>  (reduce +'
>(map (comp :curr-balance second) *@bank*
>
> What would be the implications of changing the bold bit to *(ensure bank) 
> *?
>
>
For this you don't even need a transaction. As long as you bank doesn't 
contain other refs, this is perfectly fine. With the deref you get a 
snapshot.

ensure is only needed when you want to change a ref based on the value of 
another ref, but you only read the other ref. See this example:

(defn maybe-launch-rockets!
  [defcon command-queue]
  (dosync
(when (= :war (ensure defcon))
  (alter command-queue conj :launch-rockets

Here you change command-queue purely based on the value of defcon without 
modifying defcon. Then you have to use ensure to get a consistent view of 
both refs. Without using ensure, you might get the following situation:

1. Your transaction starts.
2. You read defcon.
3. A peace treaty is signed and another transaction resets defcon to :peace.
4. You schedule the rocket launch based on a now bogus defcon value.
5. Your transaction commits, because you did not modify defcon and thusly 
don't get a conflict.
6. 3rd world war ensues.

ensure declares your interest in defcon. You get a conflict and the above 
cannot happen. (In fact: you block the peace treaty negotiations until the 
rockets are launched, but that is an implementation detail.)

Hope that helps.

Meikel

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Stefan Kamphausen]

Hi,

I may be missing something here, since this thread leaves me a bit confused.

1. Why are you using a Ref for the bank in the first place?  It is a single 
identity and thus should be an atom, because you do not need to coordinate 
changes of at least two identities.

If I am not mistaken, the generic bank transfer example is to have a Ref 
for each of the accounts and to make sure, that there is never a state of 
the world in which the money is missing or is available twice.

2. "Even our side-effecting fns return something (per alter) which is 
good." -> That seems debatable to me.

3. Why do you nest transactions on the same Ref in transfer1 and transfer?

Don't get me wrong, what you're doing may be fine.  In that case, I just 
don't get it.  Which, in turn, may be a relevant feedback to you, since 
this is to be educational :-)


Kind regards,
Stefan


-- 
-- 
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/groups/opt_out.

Re: [Job spam] Write Clojure in your pajamas, for decent money in a pleasant company, remote pairing all the time

[Thiago Massa]

Again, does it offers H1B's?

I've got a good github(mostly ruby), but like you said... I'm from south
america. I don't mind to freelance for a while with you guys until next
H1B's quota, or to pay it with my work.

I think the thread kinda has lost it's purpose as people started arguing
about Ruby or that most of the american clojure guys are well employed.


On Wed, Nov 20, 2013 at 11:07 PM, Jeff Heon  wrote:

>
>
> On Tuesday, November 19, 2013 7:44:33 PM UTC-5, Alexey Verkhovsky wrote:
>>
>> Back to the original subject of the thread, it looks like either there is
>> more Clojure work than people with platform expertise, or Clojure is a
>> mostly South American phenomenon. One way or the other, South America is
>> the only place I've got any responses from so far. {puzzled}
>>
>
> "We are only hiring master programmers and very strong journeymen."
>
> My guess is master programmers in the US already have plenty of
> opportunities to thrive at exciting places and are probably already
> established in excellent companies, whereas as in other countries it might
> be harder to find such excellent work conditions and the opportunity to
> work remotely for your company makes it extra attractive.
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Shantanu Kumar]

On Thursday, 21 November 2013 07:40:09 UTC+5:30, Alex Baranosky wrote:
>
> Congratulation on the book Shantanu!
>

Thanks, Alex!

Shantanu
 

>
>
> On Wed, Nov 20, 2013 at 5:16 PM, Shantanu Kumar 
> 
> > wrote:
>
>> Now also available on
>> Amazon US: http://www.amazon.com/dp/1782165606/?tag=packtpubli-20
>> Amazon UK: http://www.amazon.co.uk/dp/1782165606/?tag=packtpubli-21
>>
>> Shantanu
>>
>> On Thursday, 21 November 2013 05:21:45 UTC+5:30, Shantanu Kumar wrote:
>>>
>>> Hi,
>>>
>>> I am pleased to announce availability of the book `Clojure High 
>>> Performance Programming` that I have been writing for the better part of 
>>> this year:
>>>
>>> http://www.packtpub.com/clojure-high-performance-programming/book
>>>
>>> This book is ideally meant for intermediate Clojure programmers. It is 
>>> divided into seven chapters covering Clojure abstractions, Java interop, 
>>> JVM internals, Concurrency and other performance-related topics.
>>>
>>> Shantanu
>>>
>>  -- 
>> -- 
>> 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/groups/opt_out.
>>
>
>

-- 
-- 
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Shantanu Kumar]

On Thursday, 21 November 2013 15:57:21 UTC+5:30, Ulises wrote:
>
> First of all: Congratulations, looks like a great book! 
>
> Second, do you know why Amazon doesn't offer the kindle version while 
> Packt says it's available in digital format and displays an Amazon 
> logo (I'm assuming the Amazon logo means it's kindle)? 
>
> Cheers and looking forward to reading your book! 
>

Thank you! The book is published very recently and I noticed it took a 
while for the printed editions to appear on Amazon. I am getting in touch 
with Packt to find out why the kindle editions not on Amazon and whether 
this is temporary.

Shantanu
 

>
> On 21 November 2013 02:10, Alex Baranosky 
> > 
> wrote: 
> > Congratulation on the book Shantanu! 
> > 
> > 
> > On Wed, Nov 20, 2013 at 5:16 PM, Shantanu Kumar 
> > > 
>
> > wrote: 
> >> 
> >> Now also available on 
> >> Amazon US: http://www.amazon.com/dp/1782165606/?tag=packtpubli-20 
> >> Amazon UK: http://www.amazon.co.uk/dp/1782165606/?tag=packtpubli-21 
> >> 
> >> Shantanu 
> >> 
> >> On Thursday, 21 November 2013 05:21:45 UTC+5:30, Shantanu Kumar wrote: 
> >>> 
> >>> Hi, 
> >>> 
> >>> I am pleased to announce availability of the book `Clojure High 
> >>> Performance Programming` that I have been writing for the better part 
> of 
> >>> this year: 
> >>> 
> >>> http://www.packtpub.com/clojure-high-performance-programming/book 
> >>> 
> >>> This book is ideally meant for intermediate Clojure programmers. It is 
> >>> divided into seven chapters covering Clojure abstractions, Java 
> interop, JVM 
> >>> internals, Concurrency and other performance-related topics. 
> >>> 
> >>> Shantanu 
> >> 
> >> -- 
> >> -- 
> >> 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/groups/opt_out. 
> > 
> > 
> > -- 
> > -- 
> > 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/groups/opt_out. 
>

-- 
-- 
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Ulises]

> Thank you! The book is published very recently and I noticed it took a while
> for the printed editions to appear on Amazon. I am getting in touch with
> Packt to find out why the kindle editions not on Amazon and whether this is
> temporary.

Great! Thanks for the diligence.

If you're getting in touch with them you can also let them know that
the page for your book is broken (it doesn't load images for
instance.)

Cheers!

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Jim - FooBar();]

Hi Stefan,

thanks for your interest. let me explain further...

1. I did start with a design that involved a map (the bank) full of 
agents (accounts). Then I switched to a map full of atoms thinking that 
I don't really need asynchronous operations. I settled to the single ref 
approach because it seemed like an overkill to have all these refs 
inside. Your comment however does make sense...Since there is a single 
identity, perhaps STM is an overkill...


2. can you ellaborate why you think this is debatable? All the 
ref-managing fns return the in-transaction value of the ref (i.e. 
'alter'). My problem was with 'doseq' which returns nil so I followed 
the general approach of returning the in-transaction value of the ref 
after it commits.


3. As I understand it these 2 transactions will be composed/merged into 
a single transaction. Again, originally I had a bare 'alter' (no dosync) 
on the private fn transfer1 simply because it is hidden and not supposed 
to be used...think of it as a helper fn for 'transfer'. but then I read 
somewhere that transaction can be nested without a problem so I thought 
it is safer to include 'dosync' in tranfer1 as well...


I'm not getting you wrong, don't worry...this is the reason I started 
this thread - need some answers /feedback :)


Jim


On 21/11/13 10:42, Stefan Kamphausen wrote:

Hi,

I may be missing something here, since this thread leaves me a bit 
confused.


1. Why are you using a Ref for the bank in the first place?  It is a 
single identity and thus should be an atom, because you do not need to 
coordinate changes of at least two identities.


If I am not mistaken, the generic bank transfer example is to have a 
Ref for each of the accounts and to make sure, that there is never a 
state of the world in which the money is missing or is available twice.


2. "Even our side-effecting fns return something (per alter) which is 
good." -> That seems debatable to me.


3. Why do you nest transactions on the same Ref in transfer1 and transfer?

Don't get me wrong, what you're doing may be fine.  In that case, I 
just don't get it.  Which, in turn, may be a relevant feedback to you, 
since this is to be educational :-)



Kind regards,
Stefan


--
--
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/groups/opt_out.


--
--
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Shantanu Kumar]

On Thursday, 21 November 2013 16:28:14 UTC+5:30, Ulises wrote:
>
> > Thank you! The book is published very recently and I noticed it took a 
> while 
> > for the printed editions to appear on Amazon. I am getting in touch with 
> > Packt to find out why the kindle editions not on Amazon and whether this 
> is 
> > temporary. 
>
> Great! Thanks for the diligence. 
>
> If you're getting in touch with them you can also let them know that 
> the page for your book is broken (it doesn't load images for 
> instance.) 
>

Could you please let me know which URL and page no. did you find the images 
missing on? I noticed the images are visible (for example on page number 
21) when I visited http://www.amazon.com/dp/1782165606/?tag=packtpubli-20 and 
clicked on the book image to open the preview.

Shantanu
 

>
> Cheers! 
>

-- 
-- 
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Baishampayan Ghose]

The ToC looks amazing. Great work, Shantanu! ~BG

On Thu, Nov 21, 2013 at 5:21 AM, Shantanu Kumar
 wrote:
> Hi,
>
> I am pleased to announce availability of the book `Clojure High Performance
> Programming` that I have been writing for the better part of this year:
>
> http://www.packtpub.com/clojure-high-performance-programming/book
>
> This book is ideally meant for intermediate Clojure programmers. It is
> divided into seven chapters covering Clojure abstractions, Java interop, JVM
> internals, Concurrency and other performance-related topics.
>
> Shantanu
>
> --
> --
> 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/groups/opt_out.



-- 
Baishampayan Ghose
b.ghose at gmail.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/groups/opt_out.

Re: [ANN] Component: dependency injection and state management

[Jan Herich]

This is simple brilliant... The approach proposed and the component 
"framework" implementing it finally solves the issue with the "necessary 
evil" (start/stop interactions with statefull components in any bigger 
Clojure app) by cleverly taking only the best ideas (like using inferred 
dependency graph to automatically start/stop components in the correct 
order) from Java DI frameworks like Spring, which i have a lot of 
experience with. Thank you very much for this work.

Dňa štvrtok, 21. novembra 2013 3:01:19 UTC+1 Stuart Sierra napísal(-a):
>
> This is a small library/framework I've been working on for a few months.
>
> https://github.com/stuartsierra/component
>
> I use this to manage runtime state in combination with my "reloaded" 
> workflow using tools.namespace.[1]
>
> I've started using this on some personal and professional projects and it 
> seems to be working fairly well.
>
>
> [1]: http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded
>
>

-- 
-- 
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Ulises]

> Could you please let me know which URL and page no. did you find the images
> missing on? I noticed the images are visible (for example on page number 21)
> when I visited http://www.amazon.com/dp/1782165606/?tag=packtpubli-20 and
> clicked on the book image to open the preview.

Apologies for the lack of clarity. It's the Packt page for your book
that doesn't load images (at least for me.)

U

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Jim - FooBar();]

also I forgot to add that having the bank in some reference type allows 
opening/closing new accounts, an operation that at least to me sounds 
like it needs coordination...
So which way is preferred? map-ref that stores values, map that stores 
refs or map-ref that stores refs?


Jim


On 21/11/13 10:58, Jim - FooBar(); wrote:

Hi Stefan,

thanks for your interest. let me explain further...

1. I did start with a design that involved a map (the bank) full of 
agents (accounts). Then I switched to a map full of atoms thinking 
that I don't really need asynchronous operations. I settled to the 
single ref approach because it seemed like an overkill to have all 
these refs inside. Your comment however does make sense...Since there 
is a single identity, perhaps STM is an overkill...


2. can you ellaborate why you think this is debatable? All the 
ref-managing fns return the in-transaction value of the ref (i.e. 
'alter'). My problem was with 'doseq' which returns nil so I followed 
the general approach of returning the in-transaction value of the ref 
after it commits.


3. As I understand it these 2 transactions will be composed/merged 
into a single transaction. Again, originally I had a bare 'alter' (no 
dosync) on the private fn transfer1 simply because it is hidden and 
not supposed to be used...think of it as a helper fn for 'transfer'. 
but then I read somewhere that transaction can be nested without a 
problem so I thought it is safer to include 'dosync' in tranfer1 as 
well...


I'm not getting you wrong, don't worry...this is the reason I started 
this thread - need some answers /feedback :)


Jim


On 21/11/13 10:42, Stefan Kamphausen wrote:

Hi,

I may be missing something here, since this thread leaves me a bit 
confused.


1. Why are you using a Ref for the bank in the first place?  It is a 
single identity and thus should be an atom, because you do not need 
to coordinate changes of at least two identities.


If I am not mistaken, the generic bank transfer example is to have a 
Ref for each of the accounts and to make sure, that there is never a 
state of the world in which the money is missing or is available twice.


2. "Even our side-effecting fns return something (per alter) which is 
good." -> That seems debatable to me.


3. Why do you nest transactions on the same Ref in transfer1 and 
transfer?


Don't get me wrong, what you're doing may be fine.  In that case, I 
just don't get it.  Which, in turn, may be a relevant feedback to 
you, since this is to be educational :-)



Kind regards,
Stefan


--
--
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/groups/opt_out.




--
--
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/groups/opt_out.

Re: first vals first vals

[Zhemin Lin]

Wow, that's really cool!
Thanks a lot, John!

-- 
-- 
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/groups/opt_out.

Re: [ANN] tools.reader 0.8.0 released

[Ambrose Bonnaire-Sergeant]

Cool, nice work Nicola and Alex!

Ambrose


On Thu, Nov 21, 2013 at 2:16 PM, Nicola Mometto  wrote:

>
> https://github.com/clojure/tools.reader
>
> Changelog:
> https://github.com/clojure/tools.reader/blob/master/CHANGELOG.md
>
> Leiningen dependency information: [org.clojure/tools.reader "0.8.0"]
>
> While the releases I made on the last months contained mainly small
> bugfixes and enhancements needed specifically for better integration in
> clojurescript, this one contains a more interesting enhancement.
>
> Thanks to the awesome work by Alex Redington, tools.reader now provides
> richer informations regarding the forms it is reading in the form of
> attached metadata; specifically it now adds end-line/end-column metadata
> information as opposed to only line/column info and can optionally
> keep source information.
>
> To see it in action:
> clojure.tools.reader> (meta (read (source-logging-push-back-reader "[^:foo
> bar]")))
> {:end-column 12, :end-line 1, :column 1, :line 1, :source "[^:foo bar]"}
> clojure.tools.reader> (meta (first (read (source-logging-push-back-reader
> "[^:foo bar]"
> {:foo true, :end-column 11, :end-line 1, :column 8, :line 1, :source
> "^:foo bar"}
>
> Nicola
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] Component: dependency injection and state management

[abp]

Hi, great work indeed.

One question though: Why do you prefer declaring dependencies between 
components of a system explicitly instead of using prismatics Graph?

On Thursday, November 21, 2013 3:01:19 AM UTC+1, Stuart Sierra wrote:
>
> This is a small library/framework I've been working on for a few months.
>
> https://github.com/stuartsierra/component
>
> I use this to manage runtime state in combination with my "reloaded" 
> workflow using tools.namespace.[1]
>
> I've started using this on some personal and professional projects and it 
> seems to be working fairly well.
>
>
> [1]: http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded
>
>

-- 
-- 
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/groups/opt_out.

ANN: double-check, a Clojure/ClojureScript-portable fork of simple-check

[Chas Emerick]

Reid Draper's simple-check[1] is a generative/property-based testing 
library for Clojure that implements (and improves upon IMO) the 
shrinking of failing test cases seen in e.g. quickcheck in the Haskell 
and Erlang lands.


simple-check has totally changed how I do certain kinds of testing. From 
the beginning, I've wanted to use it when testing ClojureScript 
libraries and apps as well, since most of my ClojureScript code is 
portable to Clojure, or made that way with cljx[2].


The result is double-check, a fork of simple-check that provides the 
same API and generator semantics for Clojure and ClojureScript:


https://github.com/cemerick/double-check

double-check will fast-follow the development of simple-check, aiming to 
provide nothing more than a portable API; there should never be anything 
novel or interesting in double-check, except for the recasting of the 
simple-check codebase into a portable form.


Naturally, double-check adds support/integration for 
clojurescript.test[3] where simple-check supports/integrates clojure.test.


I've discovered (and reported and/or fixed) a number of issues in 
ClojureScript itself solely by making simple-check's own tests portable, 
and running them on ClojureScript.  I suspect you'll have the same 
experience with your own Clojure/ClojureScript projects once you apply 
double-check to them.


Cheers,

- Chas

[1] https://github.com/reiddraper/simple-check
[2] https://github.com/lynaghk/cljx
[3] https://github.com/cemerick/clojurescript.test

--
--
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/groups/opt_out.

Re: Using xlisp assoc-lists in clojure

[Justin Smith]

The issue, as far as I am concerned, is not that clojure cannot do alists 
as any traditional lisp would (it can, quite easily, as has already been 
shown).

The real question is why you would use a linked list for associative data, 
when you have an associative type with better lookup time and a convenient 
read syntax?

user> (defn alput [m k v] (update-in m [k] conj v))
#'user/alput
user> (alput {} :a 0)
{:a (0)}
user> (alput {} :a 1)
{:a (1)}
user> (defn alget [m k] (first (get m k)))
#'user/alget
user> (alget '{:a (1 0)} :a)
1
user> (defn aldissoc [m k] (update-in m [k] rest))
#'user/aldissoc
user> (aldissoc '{:a (1 0)} :a)
{:a (0)}
user> (aldissoc *1 :a)
{:a ()}

On Wednesday, November 20, 2013 9:19:58 AM UTC-8, Gary Trakhman wrote:
>
> 'Relatively bad at lists' ?
>
> I think the thing that clojure's intentionally bad at is arbitrary nested 
> mutation, so you're forced to be recursive about things and return values 
> (this is how update-in and assoc-in are implemented), but this has nothing 
> to do with data type.
>
> Clojure provides simple (maybe not easy or familiar) components for 
> manipulating data, which includes lists.
>
> We should understand the core principles and tradeoffs the language makes 
> before making judgments like this.
>
>
> On Wed, Nov 20, 2013 at 12:03 PM, >wrote:
>
>> Hello,
>>
>> Thanks for the answers and code hints.
>>
>> What a bit surprise me, is the fact that clojure is announced as 'a lisp' 
>> and is relativ poor on working with lists.
>> A long time ago I learned that 'lisp' was the agronym for 
>> 'ListProcessing'. ;-)
>> As I note, I am a longtime user of newLISP which is compared in 
>> list-processing functions a power horse.
>> But I do not want to blame the language at all, otherwise I would not be 
>> interested.
>> I still have to find the best way to get the wanted job done with minimal 
>> efforts.
>>
>> Regards
>>
>> Hans-Peter
>>
>>
>>
>>>  -- 
>> -- 
>> 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/groups/opt_out.
>>
>
>

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Jim - FooBar();]

On 21/11/13 13:19, John D. Hume wrote:


If you want to demonstrate STM with the deposit-withdraw-transfer 
example, you definitely need a ref for each account.


I'd suggest an atom for the account-num->balance-ref map ("the bank") 
and an atom for the account-num-generator, but you say coordination is 
necessary for opening and closing accounts. What coordination do you 
have in mind?





exactly my point! thank you...

I finally settled to an atom (the entire bank) that holds a map from 
string ids to a ref containing the actual customer-account map.
Sorry, by coordination, I meant atoms or refs. It needs to be 
synchronous because  we may open an account and deposit immediately. am 
I not thinking correctly?


also, people complained about me doing this because I'm altering a 
single identity:


(defn deposit!
[account amount]
 (dosync
   (alter account credit amount)))

whereas this is fine:

(defn- transfer1
 [amount from to]
(dosync
   (alter to  credit amount)
   (alter from debit amount)))

but I can't have it both ways! if accounts are refs then a simple 
deposit or withdraw must happen in a transaction...



Jim

--
--
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/groups/opt_out.

Re: ANN: double-check, a Clojure/ClojureScript-portable fork of simple-check

[Stephen Cagle]

Did you try out test.generative? If so, how does simple check contrast to 
test.generative?

On Thursday, November 21, 2013 11:31:19 AM UTC-8, Chas Emerick wrote:
>
> simple-check is planning on remaining Clojure-only, at least for the 
> foreseeable future.  This "non-fork fork" is the best alternative Reid 
> and I could come up with to enable people to use it on both Clojure and 
> ClojureScript.  Hopefully double-check will be unnecessary at some 
> point. :-) 
>
> - Chas 
>
> On Thu 21 Nov 2013 02:01:02 PM EST, Max Penet wrote: 
> > Looks good! 
> > 
> > I am wondering though, why not merging your work on the parent project 
> > instead of creating a new one (with a new name etc), you seemed to be 
> > on your way of doing just this? 
> > 
> > On Thursday, November 21, 2013 5:38:16 PM UTC+1, Chas Emerick wrote: 
> > 
> > Reid Draper's simple-check[1] is a generative/property-based testing 
> > library for Clojure that implements (and improves upon IMO) the 
> > shrinking of failing test cases seen in e.g. quickcheck in the 
> > Haskell 
> > and Erlang lands. 
> > 
> > simple-check has totally changed how I do certain kinds of 
> > testing. From 
> > the beginning, I've wanted to use it when testing ClojureScript 
> > libraries and apps as well, since most of my ClojureScript code is 
> > portable to Clojure, or made that way with cljx[2]. 
> > 
> > The result is double-check, a fork of simple-check that provides the 
> > same API and generator semantics for Clojure and ClojureScript: 
> > 
> > 
> > https://github.com/cemerick/double-check
> >  
> > <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcemerick%2Fdouble-check&sa=D&sntz=1&usg=AFQjCNGMdmXeOnf3w2MMaq09pIO9XEqONw>
>  
>
> > 
> > 
> > double-check will fast-follow the development of simple-check, 
> > aiming to 
> > provide nothing more than a portable API; there should never be 
> > anything 
> > novel or interesting in double-check, except for the recasting of 
> the 
> > simple-check codebase into a portable form. 
> > 
> > Naturally, double-check adds support/integration for 
> > clojurescript.test[3] where simple-check supports/integrates 
> > clojure.test. 
> > 
> > I've discovered (and reported and/or fixed) a number of issues in 
> > ClojureScript itself solely by making simple-check's own tests 
> > portable, 
> > and running them on ClojureScript.  I suspect you'll have the same 
> > experience with your own Clojure/ClojureScript projects once you 
> > apply 
> > double-check to them. 
> > 
> > Cheers, 
> > 
> > - Chas 
> > 
> > [1] 
> > https://github.com/reiddraper/simple-check
> >  
> > <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Freiddraper%2Fsimple-check&sa=D&sntz=1&usg=AFQjCNENCgO1ktV_VfKH71w4oza6yEE0xw>
>  
>
> > 
> > [2] 
> > https://github.com/lynaghk/cljx
> >  
> > <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Flynaghk%2Fcljx&sa=D&sntz=1&usg=AFQjCNErrEPQTKkQAd-ma4oaCPVdW8BUJQ>
>  
>
> > 
> > [3] 
> > https://github.com/cemerick/clojurescript.test
> >  
> > <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcemerick%2Fclojurescript.test&sa=D&sntz=1&usg=AFQjCNGiV-NGOk4wuDpgDkZolznHF5c1Dg>
>  
>
> > 
> > 
> > -- 
> > -- 
> > 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 grou

Re: preferred way to dereference a ref: outside or inside dosync?

[John D. Hume]

generate-key is not thread-safe. Multiple callers might get the same id.

It would probably be worthwhile to have your debit fn disallow a negative
balance in some way. Maybe also don't allow closing an account unless it
has zero balance. (Though the latter might require coordination between the
"bank" and the account ref, hence bank can't be an atom any more.) Do at
least consider the case where one thread already has a reference to an
account another thread is closing.
 My latest iteration has brought me to this:

https://github.com/jimpil/bankio/blob/master/src/bankio/core.clj

If anyone can think of a more evident and safe approach for demonstration
purposes, by all means, shout out. After consulting the Clojure Programming
book, I decided to use commute for simply depositing in to an account.
There are still 2 fns that use dosync but only modify a single identity,
namely deposit! & withdraw!. I don't see how else this can be done since
they are refs. I would appreciate feedback for this (hopefully) last
version...


many thanks in advance :)

Jim


On 21/11/13 13:19, John D. Hume wrote:

If you want to demonstrate STM with the deposit-withdraw-transfer example,
you definitely need a ref for each account.

I'd suggest an atom for the account-num->balance-ref map ("the bank") and
an atom for the account-num-generator, but you say coordination is
necessary for opening and closing accounts. What coordination do you have
in mind?
On Nov 21, 2013 5:27 AM, "Jim - FooBar();"  wrote:

> also I forgot to add that having the bank in some reference type allows
> opening/closing new accounts, an operation that at least to me sounds like
> it needs coordination...
> So which way is preferred? map-ref that stores values, map that stores
> refs or map-ref that stores refs?
>
> Jim
>
>
> On 21/11/13 10:58, Jim - FooBar(); wrote:
>
>> Hi Stefan,
>>
>> thanks for your interest. let me explain further...
>>
>> 1. I did start with a design that involved a map (the bank) full of
>> agents (accounts). Then I switched to a map full of atoms thinking that I
>> don't really need asynchronous operations. I settled to the single ref
>> approach because it seemed like an overkill to have all these refs inside.
>> Your comment however does make sense...Since there is a single identity,
>> perhaps STM is an overkill...
>>
>> 2. can you ellaborate why you think this is debatable? All the
>> ref-managing fns return the in-transaction value of the ref (i.e. 'alter').
>> My problem was with 'doseq' which returns nil so I followed the general
>> approach of returning the in-transaction value of the ref after it commits.
>>
>> 3. As I understand it these 2 transactions will be composed/merged into a
>> single transaction. Again, originally I had a bare 'alter' (no dosync) on
>> the private fn transfer1 simply because it is hidden and not supposed to be
>> used...think of it as a helper fn for 'transfer'. but then I read somewhere
>> that transaction can be nested without a problem so I thought it is safer
>> to include 'dosync' in tranfer1 as well...
>>
>> I'm not getting you wrong, don't worry...this is the reason I started
>> this thread - need some answers /feedback :)
>>
>> Jim
>>
>>
>> On 21/11/13 10:42, Stefan Kamphausen wrote:
>>
>>> Hi,
>>>
>>> I may be missing something here, since this thread leaves me a bit
>>> confused.
>>>
>>> 1. Why are you using a Ref for the bank in the first place?  It is a
>>> single identity and thus should be an atom, because you do not need to
>>> coordinate changes of at least two identities.
>>>
>>> If I am not mistaken, the generic bank transfer example is to have a Ref
>>> for each of the accounts and to make sure, that there is never a state of
>>> the world in which the money is missing or is available twice.
>>>
>>> 2. "Even our side-effecting fns return something (per alter) which is
>>> good." -> That seems debatable to me.
>>>
>>> 3. Why do you nest transactions on the same Ref in transfer1 and
>>> transfer?
>>>
>>> Don't get me wrong, what you're doing may be fine.  In that case, I just
>>> don't get it.  Which, in turn, may be a relevant feedback to you, since
>>> this is to be educational :-)
>>>
>>>
>>> Kind regards,
>>> Stefan
>>>
>>>
>>> --
>>> --
>>> 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/groups/opt_out.
>

Re: [ANN] Major update of modern-cljs

[Gary Johnson]

+1 to Bastien's comment.

Your tutorials are by far the best introduction to web programming in 
Clojure and Clojurescript on the web. Thank you so much for keeping these 
up to date so that we can all benefit from them.

  ~Gary

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Jim - FooBar();]

apart from the generate-keys fn which is intentionally simplistic and 
predictable so I can test somehow, I will admit that these are very good 
points indeed.



Do at least consider the case where one thread already has a reference 
to an account another thread is closing. 


to me, this smells like proper use of 'ensure' which would be another 
reason to make the bank itself a ref? interesting point though...I also 
came across Cristophes' megaref which, if I understood correctly fits 
the bill perfectly but I'd rather stick to the built-in fns. It would 
not be nice to go a demonstration for a particular feature and say "ok, 
we'll use this library instead".


thanks again, I will have another go at it in the morning :)
Jim


[1] https://github.com/cgrand/megaref

On 21/11/13 22:35, John D. Hume wrote:


generate-key is not thread-safe. Multiple callers might get the same id.

It would probably be worthwhile to have your debit fn disallow a 
negative balance in some way. Maybe also don't allow closing an 
account unless it has zero balance. (Though the latter might require 
coordination between the "bank" and the account ref, hence bank can't 
be an atom any more.) Do at least consider the case where one thread 
already has a reference to an account another thread is closing.


My latest iteration has brought me to this:

https://github.com/jimpil/bankio/blob/master/src/bankio/core.clj

If anyone can think of a more evident and safe approach for 
demonstration purposes, by all means, shout out. After consulting the 
Clojure Programming book, I decided to use commute for simply 
depositing in to an account. There are still 2 fns that use dosync but 
only modify a single identity, namely deposit! & withdraw!. I don't 
see how else this can be done since they are refs. I would appreciate 
feedback for this (hopefully) last version...



many thanks in advance :)

Jim


On 21/11/13 13:19, John D. Hume wrote:


If you want to demonstrate STM with the deposit-withdraw-transfer 
example, you definitely need a ref for each account.


I'd suggest an atom for the account-num->balance-ref map ("the bank") 
and an atom for the account-num-generator, but you say coordination 
is necessary for opening and closing accounts. What coordination do 
you have in mind?


On Nov 21, 2013 5:27 AM, "Jim - FooBar();" > wrote:


also I forgot to add that having the bank in some reference type
allows opening/closing new accounts, an operation that at least
to me sounds like it needs coordination...
So which way is preferred? map-ref that stores values, map that
stores refs or map-ref that stores refs?

Jim


On 21/11/13 10:58, Jim - FooBar(); wrote:

Hi Stefan,

thanks for your interest. let me explain further...

1. I did start with a design that involved a map (the bank)
full of agents (accounts). Then I switched to a map full of
atoms thinking that I don't really need asynchronous
operations. I settled to the single ref approach because it
seemed like an overkill to have all these refs inside. Your
comment however does make sense...Since there is a single
identity, perhaps STM is an overkill...

2. can you ellaborate why you think this is debatable? All
the ref-managing fns return the in-transaction value of the
ref (i.e. 'alter'). My problem was with 'doseq' which returns
nil so I followed the general approach of returning the
in-transaction value of the ref after it commits.

3. As I understand it these 2 transactions will be
composed/merged into a single transaction. Again, originally
I had a bare 'alter' (no dosync) on the private fn transfer1
simply because it is hidden and not supposed to be
used...think of it as a helper fn for 'transfer'. but then I
read somewhere that transaction can be nested without a
problem so I thought it is safer to include 'dosync' in
tranfer1 as well...

I'm not getting you wrong, don't worry...this is the reason I
started this thread - need some answers /feedback :)

Jim


On 21/11/13 10:42, Stefan Kamphausen wrote:

Hi,

I may be missing something here, since this thread leaves
me a bit confused.

1. Why are you using a Ref for the bank in the first
place?  It is a single identity and thus should be an
atom, because you do not need to coordinate changes of at
least two identities.

If I am not mistaken, the generic bank transfer example
is to have a Ref for each of the accounts and to make
sure, that there is never a state of the world in which
the money is missing or is available twice.

2. "Even our side-effecting fns return something (per
alter) which is good." -> That seems

Re: ANN: double-check, a Clojure/ClojureScript-portable fork of simple-check

[Max Penet]

Looks good! 

I am wondering though, why not merging your work on the parent project 
instead of creating a new one (with a new name etc), you seemed to be on 
your way of doing just this?  

On Thursday, November 21, 2013 5:38:16 PM UTC+1, Chas Emerick wrote:
>
> Reid Draper's simple-check[1] is a generative/property-based testing 
> library for Clojure that implements (and improves upon IMO) the 
> shrinking of failing test cases seen in e.g. quickcheck in the Haskell 
> and Erlang lands. 
>
> simple-check has totally changed how I do certain kinds of testing. From 
> the beginning, I've wanted to use it when testing ClojureScript 
> libraries and apps as well, since most of my ClojureScript code is 
> portable to Clojure, or made that way with cljx[2]. 
>
> The result is double-check, a fork of simple-check that provides the 
> same API and generator semantics for Clojure and ClojureScript: 
>
> https://github.com/cemerick/double-check
>  
>
> double-check will fast-follow the development of simple-check, aiming to 
> provide nothing more than a portable API; there should never be anything 
> novel or interesting in double-check, except for the recasting of the 
> simple-check codebase into a portable form. 
>
> Naturally, double-check adds support/integration for 
> clojurescript.test[3] where simple-check supports/integrates clojure.test. 
>
> I've discovered (and reported and/or fixed) a number of issues in 
> ClojureScript itself solely by making simple-check's own tests portable, 
> and running them on ClojureScript.  I suspect you'll have the same 
> experience with your own Clojure/ClojureScript projects once you apply 
> double-check to them. 
>
> Cheers, 
>
> - Chas 
>
> [1] 
> https://github.com/reiddraper/simple-check
>  
> [2] 
> https://github.com/lynaghk/cljx
>  
> [3] 
> https://github.com/cemerick/clojurescript.test
>  
>

-- 
-- 
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/groups/opt_out.

ANN: ClojureScript 0.0-2060

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

New release version: 0.0-2060

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2060"]

Source map accuracy is considerably improved in this release. Source
maps now work great under incremental compilation regardless of the
level of optimization. PersistentVector performance is considerably
improved for conj and instantiation.

Enhancements:
* CLJS-683: :source-map-path compiler option to simplify web server
  integration
* enable-console-print! for console.log based printing
* *print-length* now supported

Bug fixes:
* CLJS-691: IComparable for keywords and symbols
* CLJS-674: relativization of source map paths
* CLJS-687: error when deftype/record used as a function
* CLJS-639: warnings when record initialized incorrectly
* CLJS-672: source maps + optimizations + :libs breaks building
* CLJS-676: source map stale under incremental compilation + closure
  optimization
* CLJS-684: throw on circular dependency
* CLJS-583: duplicate keys in sets
* CLJS-680: function name shadows JS globals
* CLJS-699: namespaced keyword regression
* CLJS-647: js-obj keys could not be expressions

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[John D. Hume]

If you want to demonstrate STM with the deposit-withdraw-transfer example,
you definitely need a ref for each account.

I'd suggest an atom for the account-num->balance-ref map ("the bank") and
an atom for the account-num-generator, but you say coordination is
necessary for opening and closing accounts. What coordination do you have
in mind?
On Nov 21, 2013 5:27 AM, "Jim - FooBar();"  wrote:

> also I forgot to add that having the bank in some reference type allows
> opening/closing new accounts, an operation that at least to me sounds like
> it needs coordination...
> So which way is preferred? map-ref that stores values, map that stores
> refs or map-ref that stores refs?
>
> Jim
>
>
> On 21/11/13 10:58, Jim - FooBar(); wrote:
>
>> Hi Stefan,
>>
>> thanks for your interest. let me explain further...
>>
>> 1. I did start with a design that involved a map (the bank) full of
>> agents (accounts). Then I switched to a map full of atoms thinking that I
>> don't really need asynchronous operations. I settled to the single ref
>> approach because it seemed like an overkill to have all these refs inside.
>> Your comment however does make sense...Since there is a single identity,
>> perhaps STM is an overkill...
>>
>> 2. can you ellaborate why you think this is debatable? All the
>> ref-managing fns return the in-transaction value of the ref (i.e. 'alter').
>> My problem was with 'doseq' which returns nil so I followed the general
>> approach of returning the in-transaction value of the ref after it commits.
>>
>> 3. As I understand it these 2 transactions will be composed/merged into a
>> single transaction. Again, originally I had a bare 'alter' (no dosync) on
>> the private fn transfer1 simply because it is hidden and not supposed to be
>> used...think of it as a helper fn for 'transfer'. but then I read somewhere
>> that transaction can be nested without a problem so I thought it is safer
>> to include 'dosync' in tranfer1 as well...
>>
>> I'm not getting you wrong, don't worry...this is the reason I started
>> this thread - need some answers /feedback :)
>>
>> Jim
>>
>>
>> On 21/11/13 10:42, Stefan Kamphausen wrote:
>>
>>> Hi,
>>>
>>> I may be missing something here, since this thread leaves me a bit
>>> confused.
>>>
>>> 1. Why are you using a Ref for the bank in the first place?  It is a
>>> single identity and thus should be an atom, because you do not need to
>>> coordinate changes of at least two identities.
>>>
>>> If I am not mistaken, the generic bank transfer example is to have a Ref
>>> for each of the accounts and to make sure, that there is never a state of
>>> the world in which the money is missing or is available twice.
>>>
>>> 2. "Even our side-effecting fns return something (per alter) which is
>>> good." -> That seems debatable to me.
>>>
>>> 3. Why do you nest transactions on the same Ref in transfer1 and
>>> transfer?
>>>
>>> Don't get me wrong, what you're doing may be fine.  In that case, I just
>>> don't get it.  Which, in turn, may be a relevant feedback to you, since
>>> this is to be educational :-)
>>>
>>>
>>> Kind regards,
>>> Stefan
>>>
>>>
>>> --
>>> --
>>> 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/groups/opt_out.
>>>
>>
>>
> --
> --
> 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/groups/opt_out.
>

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

Re: [ANN] Component: dependency injection and state management

[Ben Mabey]

On Thu Nov 21 07:14:16 2013, Stuart Sierra wrote:

On Thursday, November 21, 2013 7:22:10 AM UTC-5, abp wrote:
> Why do you prefer declaring dependencies between
> components of a system explicitly instead of using
> prismatics Graph?

'Graph' by itself does not preserve the dependency
relationships after constructing the map. But the two
approaches are not incompatible: you can use 'Graph' to
construct the system map, then use 'Component' to manage it.

-S


If you are interesting in taking that approach you can use my 
system-graph which does just that:


https://github.com/RedBrainLabs/system-graph

I spoke with Stuart at the conj about this library and I realized that 
system-graph it is currently relying on an implementation detail in 
order to work.  I haven't had any issues with it but I can see places 
where it will not work.  I plan on fixing this issue so the proper 
'Component' metadata is attached to the system-graph.  When I do that 
I'll release v0.2.0.


-Ben

--
--
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Shantanu Kumar]

On Thursday, 21 November 2013 16:48:56 UTC+5:30, Ulises wrote:
>
> > Could you please let me know which URL and page no. did you find the 
> images 
> > missing on? I noticed the images are visible (for example on page number 
> 21) 
> > when I visited http://www.amazon.com/dp/1782165606/?tag=packtpubli-20and 
> > clicked on the book image to open the preview. 
>
> Apologies for the lack of clarity. It's the Packt page for your book 
> that doesn't load images (at least for me.) 
>

I can see the images on the Packt website. I think you would have tried 
clearing the browser cache or using a different browser. Can you try and 
see if others in your network neighborhood can access the images?

Shantanu
 

>
> U 
>

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Jim - FooBar();]

My latest iteration has brought me to this:

https://github.com/jimpil/bankio/blob/master/src/bankio/core.clj

If anyone can think of a more evident and safe approach for 
demonstration purposes, by all means, shout out. After consulting the 
Clojure Programming book, I decided to use commute for simply depositing 
in to an account. There are still 2 fns that use dosync but only modify 
a single identity, namely deposit! & withdraw!. I don't see how else 
this can be done since they are refs. I would appreciate feedback for 
this (hopefully) last version...



many thanks in advance :)

Jim


On 21/11/13 13:19, John D. Hume wrote:


If you want to demonstrate STM with the deposit-withdraw-transfer 
example, you definitely need a ref for each account.


I'd suggest an atom for the account-num->balance-ref map ("the bank") 
and an atom for the account-num-generator, but you say coordination is 
necessary for opening and closing accounts. What coordination do you 
have in mind?


On Nov 21, 2013 5:27 AM, "Jim - FooBar();" > wrote:


also I forgot to add that having the bank in some reference type
allows opening/closing new accounts, an operation that at least to
me sounds like it needs coordination...
So which way is preferred? map-ref that stores values, map that
stores refs or map-ref that stores refs?

Jim


On 21/11/13 10:58, Jim - FooBar(); wrote:

Hi Stefan,

thanks for your interest. let me explain further...

1. I did start with a design that involved a map (the bank)
full of agents (accounts). Then I switched to a map full of
atoms thinking that I don't really need asynchronous
operations. I settled to the single ref approach because it
seemed like an overkill to have all these refs inside. Your
comment however does make sense...Since there is a single
identity, perhaps STM is an overkill...

2. can you ellaborate why you think this is debatable? All the
ref-managing fns return the in-transaction value of the ref
(i.e. 'alter'). My problem was with 'doseq' which returns nil
so I followed the general approach of returning the
in-transaction value of the ref after it commits.

3. As I understand it these 2 transactions will be
composed/merged into a single transaction. Again, originally I
had a bare 'alter' (no dosync) on the private fn transfer1
simply because it is hidden and not supposed to be
used...think of it as a helper fn for 'transfer'. but then I
read somewhere that transaction can be nested without a
problem so I thought it is safer to include 'dosync' in
tranfer1 as well...

I'm not getting you wrong, don't worry...this is the reason I
started this thread - need some answers /feedback :)

Jim


On 21/11/13 10:42, Stefan Kamphausen wrote:

Hi,

I may be missing something here, since this thread leaves
me a bit confused.

1. Why are you using a Ref for the bank in the first
place?  It is a single identity and thus should be an
atom, because you do not need to coordinate changes of at
least two identities.

If I am not mistaken, the generic bank transfer example is
to have a Ref for each of the accounts and to make sure,
that there is never a state of the world in which the
money is missing or is available twice.

2. "Even our side-effecting fns return something (per
alter) which is good." -> That seems debatable to me.

3. Why do you nest transactions on the same Ref in
transfer1 and transfer?

Don't get me wrong, what you're doing may be fine.  In
that case, I just don't get it.  Which, in turn, may be a
relevant feedback to you, since this is to be educational :-)


Kind regards,
Stefan


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

Re: ANN: Clojure High Performance Programming

[Praki Prakash]

Hi Shantanu,

Congrats on the book. Looks like it's going to be a great read and no doubt
a much needed book on the subject of performant code.

Regards,
Praki Prakash


On Thu, Nov 21, 2013 at 11:09 AM, Shantanu Kumar
wrote:

>
>
> On Thursday, 21 November 2013 21:39:36 UTC+5:30, Gary Johnson wrote:
>>
>> This looks incredible! Just bought a copy. Congratulations, Shantanu!
>>
>
> Thanks, Gary!
>
> Those who might look for a Kindle edition can find it here:
>
> http://www.amazon.com/Clojure-Performance-Programming-Shantanu-Kumar-ebook/dp/B00GTE1RVW/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1385043536&sr=1-2&keywords=packt+publishing
>
> Shantanu
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: first vals first vals

[John D. Hume]

On Nov 21, 2013 3:32 AM, "Zhemin Lin"  wrote:
> What if :cf, :cq are not fixed, and I don't really care about the keys,
but only the value of the value of the value ...?

Maps seem an awkward choice of data-structure for a scenario where you
don't know or care about the keys.

-- 
-- 
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/groups/opt_out.

Re: ANN: ClojureScript 0.0-2060

[Thomas Heller]

Amazing work! Thanks to everyone involved.

Are there any hopes of optimizing things in the source-map department? It 
adds about 30sec (on optimize only, compile times are fine) to my build 
which makes it unsuitable for development.

A while back I opened http://dev.clojure.org/jira/browse/CLJS-474, it adds 
no compile-time and it helps a lot in finding out WHERE stuff happened. 
Can't compare it to full source maps but the stack traces no longer leave 
you completely helpless. The patch no longer works since some stuff in that 
area has changed, but should be fairly simple to get it working again. I'd 
be happy too if there is any interest.

See my initial description 
https://groups.google.com/d/msg/clojurescript/ZX6M4KXx8I8/0-NSjci9EEUJ 
about what it does.

To recap, it turns the standard cljs stack traces from


Uncaught Error: No protocol method IElement.-to-dom defined for type null:
missing_protocol
(anonymous function)
_to_dom
append__2
append
append__1
append
popup_open__delegate
popup_open
list_objects
dom_event_handler
goog.events.Listener.handleEvent
goog.events.fireListener
goog.events.handleBrowserEvent_
(anonymous function)


into


Uncaught Error: No protocol method IElement.-to-dom defined for type null:
fn_cljs_DOT_core_SLASH_missing_protocol_78
(anonymous function)
fn_thheller_DOT_web_DOT_dom_SLASH__to_dom_89
fn_thheller_DOT_web_DOT_dom_SLASH_append_122__2
fn_thheller_DOT_web_DOT_dom_SLASH_append_122
fn_thheller_DOT_web_DOT_dom_SLASH_append_122__1
fn_thheller_DOT_web_DOT_dom_SLASH_append_122
fn_thheller_DOT_debug_SLASH_popup_open_108__delegate
fn_thheller_DOT_debug_SLASH_popup_open_108
fn_thheller_DOT_debug_SLASH_list_objects_121
fn_thheller_DOT_object_SLASH_dom_event_handler_169
goog.events.Listener.handleEvent
goog.events.fireListener
goog.events.handleBrowserEvent_
(anonymous function)

All cljs functions are named with a fn_/_ pattern, 
since at least Chrome is not smart enough to figure out the function names 
on its own. So fn_thheller_DOT_web_DOT_dom_SLASH_append_122 is 
thheller.web.dom/append in line 122, its only a minor debug helper but it 
saved me tons of time.


Regards,
/thomas


On Thursday, November 21, 2013 4:12:55 PM UTC+1, David Nolen wrote:
>
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> README and source code: 
> https://github.com/clojure/clojurescript
>
> New release version: 0.0-2060
>
> Leiningen dependency information:
>
> [org.clojure/clojurescript "0.0-2060"]
>
> Source map accuracy is considerably improved in this release. Source
> maps now work great under incremental compilation regardless of the
> level of optimization. PersistentVector performance is considerably
> improved for conj and instantiation.
>
> Enhancements:
> * CLJS-683: :source-map-path compiler option to simplify web server
>   integration
> * enable-console-print! for console.log based printing
> * *print-length* now supported
>
> Bug fixes:
> * CLJS-691: IComparable for keywords and symbols
> * CLJS-674: relativization of source map paths
> * CLJS-687: error when deftype/record used as a function
> * CLJS-639: warnings when record initialized incorrectly
> * CLJS-672: source maps + optimizations + :libs breaks building
> * CLJS-676: source map stale under incremental compilation + closure
>   optimization
> * CLJS-684: throw on circular dependency
> * CLJS-583: duplicate keys in sets
> * CLJS-680: function name shadows JS globals
> * CLJS-699: namespaced keyword regression
> * CLJS-647: js-obj keys could not be expressions
>  

-- 
-- 
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/groups/opt_out.

R: [ClojureScript] ANN: ClojureScript 0.0-2060

[mimmo.cose...@gmail.com]

great work david!Inviato da Samsung Mobile 

 David Nolen  ha scritto: 

ClojureScript, the Clojure compiler that emits _javascript_ source code.README and source code: https://github.com/clojure/clojurescript
New release version: 0.0-2060Leiningen dependency information:    [org.clojure/clojurescript "0.0-2060"]Source map accuracy is considerably improved in this release. Source
maps now work great under incremental compilation regardless of thelevel of optimization. PersistentVector performance is considerablyimproved for conj and instantiation.
Enhancements:* CLJS-683: :source-map-path compiler option to simplify web server  integration* enable-console-print! for console.log based printing* *print-length* now supported
Bug fixes:* CLJS-691: IComparable for keywords and symbols* CLJS-674: relativization of source map paths* CLJS-687: error when deftype/record used as a function
* CLJS-639: warnings when record initialized incorrectly* CLJS-672: source maps + optimizations + :libs breaks building* CLJS-676: source map stale under incremental compilation + closure  optimization
* CLJS-684: throw on circular dependency* CLJS-583: duplicate keys in sets* CLJS-680: function name shadows JS globals* CLJS-699: namespaced keyword regression* CLJS-647: js-obj keys could not be expressions




-- 
Note that posts from new members are moderated - please be patient with your first post.
--- 
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescr...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript. 



-- 
-- 
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/groups/opt_out.

Re: My recap of Clojure/conj 2013

[Daniel Higginbotham]

Thanks, Logan! It was fun meeting you! Congrats again on winning the conj! 
:D

Daniel

On Wednesday, November 20, 2013 11:02:38 AM UTC-5, Logan Linn wrote:
>
> I've posted a writeup of my experience from this year's Clojure/conj and 
> wanted to share with those who couldn't make it: 
> http://loganlinn.com/blog/2013/11/18/clojureconj-2013/
>
> Big thanks to all who helped organize & operate the event!
>

-- 
-- 
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Shantanu Kumar]

On Thursday, 21 November 2013 21:39:36 UTC+5:30, Gary Johnson wrote:
>
> This looks incredible! Just bought a copy. Congratulations, Shantanu!
>

Thanks, Gary!

Those who might look for a Kindle edition can find it here:
http://www.amazon.com/Clojure-Performance-Programming-Shantanu-Kumar-ebook/dp/B00GTE1RVW/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1385043536&sr=1-2&keywords=packt+publishing

Shantanu

-- 
-- 
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/groups/opt_out.

Re: Compiling ClojureScript in the repl using a macro defined in Clojure

[juan.facorro]

I tried the following:

1. Created a project with David Nolen's lein template (taken from 
here
):
 

*$ lein new mies hello-world* 


2. Created a *macro.clj* file in the *src/hello-world*  folder with the 
contents you posted:

*$ touch src/hello_world/macro.clj*


3. Edited the *src/hello_world/core.clj *file so that it requires the macro 
and uses it:

*(ns hello-world.core*
*  (:require-macros [hello-world.macro :as macro])) *

*(macro/my-when true*
*  (. js/console (log "Hello world!")))*


4. Started cljsbuild auto and wait for it to finish compilation:
 

*$ lein cljsbuild auto hello-world*


5. Opened the *index.html* file in a browser and verified the console 
message was there.

It worked this way in my case. This is the *project.clj* for this project, 
maybe the *:cljsbuild* configuration in yours has the *:source-paths*messed up?

*(defproject hello-world "0.1.0-SNAPSHOT"*
*  :description "FIXME: write this!"*
*  :url "http://example.com/FIXME"*

*  :dependencies [[org.clojure/clojure "1.5.1"]*
* [org.clojure/clojurescript "0.0-2030"]]*

*  :plugins [[lein-cljsbuild "1.0.0-alpha2"]]*

*  :source-paths ["src"]*

*  :cljsbuild { *
*:builds [{:id "hello-world"*
*  :source-paths ["src"]*
*  :compiler {*
*:output-to "hello_world.js"*
*:output-dir "out"*
*:optimizations :none*
*:source-map true}}]})*

HTH,

Juan

On Thursday, November 21, 2013 11:51:22 AM UTC+8, Ed Yu wrote:
>
> Hello,
>   I'm stuck on this particular problem that I'm having problem figuring 
> out what to do:
>
> Say I have a leiningen project that has a simple ClojureScript 
> src/cljs/hello_world/hello.cljs file that has the following:
>
> (ns hello-world.hello
>   (:require-macros [hello-world.macro :as macro]))
>
> (defn ^:export main []
>   (macro/my-when true
> (.write js/document "Hello, world!")))
>
> and I have the macro file macro.clj
>
> (ns hello-world.macro)
>
> (defmacro my-when [condition & body]
>   `(if ~condition (do ~@body)))
>
> I can't figure out where do I put macro.clj for cljsc or 
> cljs.closure/build to find the macro. I tried placing the macro.clj in the 
> same directory as hello.cljs or place it under src/clj/hello_world or place 
> it directory under src/hello_world. It doesn't matter where I put it, it 
> will not compile as I get the following error:
>
> FileNotFoundException Could not locate hello_world/macro__init.class or 
> hello_world/macro.clj on classpath:   clojure.lang.RT.load (RT.java:443)
>
> Thank you
>
>
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] Component: dependency injection and state management

[Stuart Sierra]

On Thursday, November 21, 2013 7:22:10 AM UTC-5, abp wrote:
> Why do you prefer declaring dependencies between
> components of a system explicitly instead of using
> prismatics Graph?

'Graph' by itself does not preserve the dependency
relationships after constructing the map. But the two
approaches are not incompatible: you can use 'Graph' to
construct the system map, then use 'Component' to manage it.

-S

-- 
-- 
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/groups/opt_out.

Access the datastructure used to create a function?

[henry w]

Say you have a function created like this:

(fn [x] (+ x y))

and then you have a reference to an instance of this function, is there 
some way to use the function reference to access the list '(fn [x] (+ x y)),
including the symbol 'y' (such that you could dereference 'y' and get its 
value)? The source function is not the right thing and so far googling 
hasn't got me the answer.

Thanks

-- 
-- 
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/groups/opt_out.

Re: ANN: Clojure High Performance Programming

[Gary Johnson]

This looks incredible! Just bought a copy. Congratulations, Shantanu!

-- 
-- 
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/groups/opt_out.

Re: ANN: double-check, a Clojure/ClojureScript-portable fork of simple-check

[Chas Emerick]

simple-check is planning on remaining Clojure-only, at least for the 
foreseeable future.  This "non-fork fork" is the best alternative Reid 
and I could come up with to enable people to use it on both Clojure and 
ClojureScript.  Hopefully double-check will be unnecessary at some 
point. :-)


- Chas

On Thu 21 Nov 2013 02:01:02 PM EST, Max Penet wrote:

Looks good!

I am wondering though, why not merging your work on the parent project
instead of creating a new one (with a new name etc), you seemed to be
on your way of doing just this?

On Thursday, November 21, 2013 5:38:16 PM UTC+1, Chas Emerick wrote:

Reid Draper's simple-check[1] is a generative/property-based testing
library for Clojure that implements (and improves upon IMO) the
shrinking of failing test cases seen in e.g. quickcheck in the
Haskell
and Erlang lands.

simple-check has totally changed how I do certain kinds of
testing. From
the beginning, I've wanted to use it when testing ClojureScript
libraries and apps as well, since most of my ClojureScript code is
portable to Clojure, or made that way with cljx[2].

The result is double-check, a fork of simple-check that provides the
same API and generator semantics for Clojure and ClojureScript:

https://github.com/cemerick/double-check




double-check will fast-follow the development of simple-check,
aiming to
provide nothing more than a portable API; there should never be
anything
novel or interesting in double-check, except for the recasting of the
simple-check codebase into a portable form.

Naturally, double-check adds support/integration for
clojurescript.test[3] where simple-check supports/integrates
clojure.test.

I've discovered (and reported and/or fixed) a number of issues in
ClojureScript itself solely by making simple-check's own tests
portable,
and running them on ClojureScript.  I suspect you'll have the same
experience with your own Clojure/ClojureScript projects once you
apply
double-check to them.

Cheers,

- Chas

[1] https://github.com/reiddraper/simple-check



[2] https://github.com/lynaghk/cljx



[3] https://github.com/cemerick/clojurescript.test




--
--
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/groups/opt_out.


--
--
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/groups/opt_out.

Re: first vals first vals

[Lin Zhemin]

Clojure-hbase returns {rowkey {:cf {:cq value }}} and its a trade-off not
to write it in hbase API.
2013/11/21 21:24 "John D. Hume" :

> On Nov 21, 2013 3:32 AM, "Zhemin Lin"  wrote:
> > What if :cf, :cq are not fixed, and I don't really care about the keys,
> but only the value of the value of the value ...?
>
> Maps seem an awkward choice of data-structure for a scenario where you
> don't know or care about the keys.
>
> --
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/zJSk6wZ78fc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: preferred way to dereference a ref: outside or inside dosync?

[Stefan Kamphausen]

Hi,

On Thursday, November 21, 2013 11:58:31 AM UTC+1, Jim foo.bar wrote:
>
> [...] 

1. [...] Since there is a single 
> identity, perhaps STM is an overkill... 
>

If I read your example correctly, it is not a typical use-case for STM.
 

>
> 2. can you ellaborate why you think this is debatable? All the 
> ref-managing fns return the in-transaction value of the ref (i.e. 
> 'alter'). My problem was with 'doseq' which returns nil so I followed 
> the general approach of returning the in-transaction value of the ref 
> after it commits. 
>

Clojure is not really consistent here.  Many functions that are used for 
their side-effects return nil, e.g. doseq, dorun, println.  On the other 
hand, you are right, that in the realm of reference types, some return 
value seems to be the norm (e.g. alter, ref-set, swap!, alter-meta!).  I do 
not know the design principles behind this.

However, in your calling code you'll end up with the Ref, that you passed 
to transfer! to be manipulated, and the new value which you returned.  What 
are you going to do with those two? Why did you need the Ref, couldn't you 
just pass a plain old map and use the return value for further processing?


> 3. As I understand it these 2 transactions will be composed/merged into 
> a single transaction. 


That is my understanding, too.
 

> Again, originally I had a bare 'alter' (no dosync) 
> on the private fn transfer1 simply because it is hidden and not supposed 
> to be used...think of it as a helper fn for 'transfer'. but then I read 
> somewhere that transaction can be nested


AFAIK, that usually refers to transactions on different refs on different 
levels of the stack which will be merged into one transaction.
 

> without a problem so I thought 
> it is safer to include 'dosync' in tranfer1 as well... 
>

It is probably safe, but is it necessary?


Cheers,
Stefan

-- 
-- 
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/groups/opt_out.

Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)

[Alexander Hudek]

>
>
> Is anyone using the java.jdbc.sql namespace? (besides World Singles :) 
>
>
We are using it but not the DDL. We also use honeysql in places where 
jdbc.sql cannot express the query.

-- 
-- 
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/groups/opt_out.

Re: ANN: ClojureScript 0.0-2060

[Feng Hou]

On Thursday, November 21, 2013 10:12:55 AM UTC-5, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> 
> New release version: 0.0-2060
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "0.0-2060"]
> 
> 
> Source map accuracy is considerably improved in this release. Source
> 
> maps now work great under incremental compilation regardless of the
> level of optimization. PersistentVector performance is considerably
> improved for conj and instantiation.
> 
> 
> 
> Enhancements:
> * CLJS-683: :source-map-path compiler option to simplify web server
>   integration
> * enable-console-print! for console.log based printing
> * *print-length* now supported
> 
> 
> 
> Bug fixes:
> * CLJS-691: IComparable for keywords and symbols
> * CLJS-674: relativization of source map paths

I'm stuck with java 6 on an old MacAir. This patch does the same thing without 
using java 7 methods. All asserts in these files pass on Mac and Linux.

diff --git a/src/clj/cljs/closure.clj b/src/clj/cljs/closure.clj
index b13adf0..e67409c 100644
--- a/src/clj/cljs/closure.clj
+++ b/src/clj/cljs/closure.clj
@@ -987,8 +987,8 @@
 
 (defn same-or-subdirectory-of? [dir path]
   "Checks that path names a file or directory that is the dir or a 
subdirectory there of."
-  (let [dir-path  (.toAbsolutePath (.toPath (io/file dir)))
-path-path (.toAbsolutePath (.toPath (io/file path)))]
+  (let [dir-path  (.getCanonicalPath (io/file dir))
+path-path (.getCanonicalPath (io/file path))]
 (.startsWith path-path dir-path)))
 
 (defn check-output-to [{:keys [output-to] :as opts}]
diff --git a/src/clj/cljs/source_map.clj b/src/clj/cljs/source_map.clj
index 9363601..edc5739 100644
--- a/src/clj/cljs/source_map.clj
+++ b/src/clj/cljs/source_map.clj
@@ -165,14 +165,12 @@
   :default
   (let [unrelativized-jpath (-> bare-munged-path
 io/file
-.toPath
-.toAbsolutePath)
+.toURI)
 source-map-parent-jpath (-> source-map
 io/file
-.toPath
-.toAbsolutePath
-.getParent)]
-(str (.relativize source-map-parent-jpath unrelativized-jpath))
+.getParentFile
+.toURI)]
+(.getPath (.relativize source-map-parent-jpath 
unrelativized-jpath))
 
 (defn encode
   "Take an internal source map representation represented as nested

> * CLJS-687: error when deftype/record used as a function
> 
> * CLJS-639: warnings when record initialized incorrectly
> * CLJS-672: source maps + optimizations + :libs breaks building
> * CLJS-676: source map stale under incremental compilation + closure
>   optimization
> 
> * CLJS-684: throw on circular dependency
> * CLJS-583: duplicate keys in sets
> * CLJS-680: function name shadows JS globals
> * CLJS-699: namespaced keyword regression
> * CLJS-647: js-obj keys could not be expressions

-- 
-- 
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/groups/opt_out.

Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2060

[Tim Visher]

Thanks for the patch, Feng.

Patches don't tend to get discussed on the mailing list for Clojure.
Do you have your CA signed yet? http://clojure.org/contributing

Ironically, I had basically produced this patch, line for line, a
couple of hours ago. Hopefully we can get a release out soon. This was
totally my fault. :\

For now, you should be able to `lein install` your patched version and
depend on that until the official release goes out. Sorry!

On Thu, Nov 21, 2013 at 10:43 PM, Feng Hou  wrote:
> On Thursday, November 21, 2013 10:12:55 AM UTC-5, David Nolen wrote:
>> ClojureScript, the Clojure compiler that emits JavaScript source code.
>>
>>
>> README and source code: https://github.com/clojure/clojurescript
>>
>>
>>
>> New release version: 0.0-2060
>>
>>
>> Leiningen dependency information:
>>
>>
>> [org.clojure/clojurescript "0.0-2060"]
>>
>>
>> Source map accuracy is considerably improved in this release. Source
>>
>> maps now work great under incremental compilation regardless of the
>> level of optimization. PersistentVector performance is considerably
>> improved for conj and instantiation.
>>
>>
>>
>> Enhancements:
>> * CLJS-683: :source-map-path compiler option to simplify web server
>>   integration
>> * enable-console-print! for console.log based printing
>> * *print-length* now supported
>>
>>
>>
>> Bug fixes:
>> * CLJS-691: IComparable for keywords and symbols
>> * CLJS-674: relativization of source map paths
>
> I'm stuck with java 6 on an old MacAir. This patch does the same thing 
> without using java 7 methods. All asserts in these files pass on Mac and 
> Linux.
>
> diff --git a/src/clj/cljs/closure.clj b/src/clj/cljs/closure.clj
> index b13adf0..e67409c 100644
> --- a/src/clj/cljs/closure.clj
> +++ b/src/clj/cljs/closure.clj
> @@ -987,8 +987,8 @@
>
>  (defn same-or-subdirectory-of? [dir path]
>"Checks that path names a file or directory that is the dir or a 
> subdirectory there of."
> -  (let [dir-path  (.toAbsolutePath (.toPath (io/file dir)))
> -path-path (.toAbsolutePath (.toPath (io/file path)))]
> +  (let [dir-path  (.getCanonicalPath (io/file dir))
> +path-path (.getCanonicalPath (io/file path))]
>  (.startsWith path-path dir-path)))
>
>  (defn check-output-to [{:keys [output-to] :as opts}]
> diff --git a/src/clj/cljs/source_map.clj b/src/clj/cljs/source_map.clj
> index 9363601..edc5739 100644
> --- a/src/clj/cljs/source_map.clj
> +++ b/src/clj/cljs/source_map.clj
> @@ -165,14 +165,12 @@
>:default
>(let [unrelativized-jpath (-> bare-munged-path
>  io/file
> -.toPath
> -.toAbsolutePath)
> +.toURI)
>  source-map-parent-jpath (-> source-map
>  io/file
> -.toPath
> -.toAbsolutePath
> -.getParent)]
> -(str (.relativize source-map-parent-jpath 
> unrelativized-jpath))
> +.getParentFile
> +.toURI)]
> +(.getPath (.relativize source-map-parent-jpath 
> unrelativized-jpath))
>
>  (defn encode
>"Take an internal source map representation represented as nested
>
>> * CLJS-687: error when deftype/record used as a function
>>
>> * CLJS-639: warnings when record initialized incorrectly
>> * CLJS-672: source maps + optimizations + :libs breaks building
>> * CLJS-676: source map stale under incremental compilation + closure
>>   optimization
>>
>> * CLJS-684: throw on circular dependency
>> * CLJS-583: duplicate keys in sets
>> * CLJS-680: function name shadows JS globals
>> * CLJS-699: namespaced keyword regression
>> * CLJS-647: js-obj keys could not be expressions
>
> --
> Note that posts from new members are moderated - please be patient with your 
> first post.
> ---
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

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

Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2060

[Feng Hou]

On Thursday, November 21, 2013 10:48:42 PM UTC-5, Tim Visher wrote:
> Thanks for the patch, Feng.
> 
> 
> 
> Patches don't tend to get discussed on the mailing list for Clojure.
> 
> Do you have your CA signed yet? http://clojure.org/contributing
> 
> 
> 
> Ironically, I had basically produced this patch, line for line, a
> 
> couple of hours ago. Hopefully we can get a release out soon. This was
> 
> totally my fault. :\
> 
> 
> 
> For now, you should be able to `lein install` your patched version and
> 
> depend on that until the official release goes out. Sorry!
> 


Tim - Not a problem at all. It's a travel fix. Appreciate if you could submit 
your patch.

Regards,
Feng

> 
> 
> On Thu, Nov 21, 2013 at 10:43 PM, Feng Hou  wrote:
> 
> > On Thursday, November 21, 2013 10:12:55 AM UTC-5, David Nolen wrote:
> 
> >> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> >>
> 
> >>
> 
> >> README and source code: https://github.com/clojure/clojurescript
> 
> >>
> 
> >>
> 
> >>
> 
> >> New release version: 0.0-2060
> 
> >>
> 
> >>
> 
> >> Leiningen dependency information:
> 
> >>
> 
> >>
> 
> >> [org.clojure/clojurescript "0.0-2060"]
> 
> >>
> 
> >>
> 
> >> Source map accuracy is considerably improved in this release. Source
> 
> >>
> 
> >> maps now work great under incremental compilation regardless of the
> 
> >> level of optimization. PersistentVector performance is considerably
> 
> >> improved for conj and instantiation.
> 
> >>
> 
> >>
> 
> >>
> 
> >> Enhancements:
> 
> >> * CLJS-683: :source-map-path compiler option to simplify web server
> 
> >>   integration
> 
> >> * enable-console-print! for console.log based printing
> 
> >> * *print-length* now supported
> 
> >>
> 
> >>
> 
> >>
> 
> >> Bug fixes:
> 
> >> * CLJS-691: IComparable for keywords and symbols
> 
> >> * CLJS-674: relativization of source map paths
> 
> >
> 
> > I'm stuck with java 6 on an old MacAir. This patch does the same thing 
> > without using java 7 methods. All asserts in these files pass on Mac and 
> > Linux.
> 
> >
> 
> > diff --git a/src/clj/cljs/closure.clj b/src/clj/cljs/closure.clj
> 
> > index b13adf0..e67409c 100644
> 
> > --- a/src/clj/cljs/closure.clj
> 
> > +++ b/src/clj/cljs/closure.clj
> 
> > @@ -987,8 +987,8 @@
> 
> >
> 
> >  (defn same-or-subdirectory-of? [dir path]
> 
> >"Checks that path names a file or directory that is the dir or a 
> > subdirectory there of."
> 
> > -  (let [dir-path  (.toAbsolutePath (.toPath (io/file dir)))
> 
> > -path-path (.toAbsolutePath (.toPath (io/file path)))]
> 
> > +  (let [dir-path  (.getCanonicalPath (io/file dir))
> 
> > +path-path (.getCanonicalPath (io/file path))]
> 
> >  (.startsWith path-path dir-path)))
> 
> >
> 
> >  (defn check-output-to [{:keys [output-to] :as opts}]
> 
> > diff --git a/src/clj/cljs/source_map.clj b/src/clj/cljs/source_map.clj
> 
> > index 9363601..edc5739 100644
> 
> > --- a/src/clj/cljs/source_map.clj
> 
> > +++ b/src/clj/cljs/source_map.clj
> 
> > @@ -165,14 +165,12 @@
> 
> >:default
> 
> >(let [unrelativized-jpath (-> bare-munged-path
> 
> >  io/file
> 
> > -.toPath
> 
> > -.toAbsolutePath)
> 
> > +.toURI)
> 
> >  source-map-parent-jpath (-> source-map
> 
> >  io/file
> 
> > -.toPath
> 
> > -.toAbsolutePath
> 
> > -.getParent)]
> 
> > -(str (.relativize source-map-parent-jpath 
> > unrelativized-jpath))
> 
> > +.getParentFile
> 
> > +.toURI)]
> 
> > +(.getPath (.relativize source-map-parent-jpath 
> > unrelativized-jpath))
> 
> >
> 
> >  (defn encode
> 
> >"Take an internal source map representation represented as nested
> 
> >
> 
> >> * CLJS-687: error when deftype/record used as a function
> 
> >>
> 
> >> * CLJS-639: warnings when record initialized incorrectly
> 
> >> * CLJS-672: source maps + optimizations + :libs breaks building
> 
> >> * CLJS-676: source map stale under incremental compilation + closure
> 
> >>   optimization
> 
> >>
> 
> >> * CLJS-684: throw on circular dependency
> 
> >> * CLJS-583: duplicate keys in sets
> 
> >> * CLJS-680: function name shadows JS globals
> 
> >> * CLJS-699: namespaced keyword regression
> 
> >> * CLJS-647: js-obj keys could not be expressions
> 
> >
> 
> > --
> 
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> 
> > ---
> 
> > You received this message because you are subscribed to the Google Groups 
> > "ClojureScript" group.
> 
> > To unsubscribe from this group and stop receiving emails from it

Re: ANN: ClojureScript 0.0-2060

[Feng Hou]

On Thursday, November 21, 2013 10:12:55 AM UTC-5, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> 
> New release version: 0.0-2060
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "0.0-2060"]
> 
> 
> Source map accuracy is considerably improved in this release. Source
> 
> maps now work great under incremental compilation regardless of the
> level of optimization. PersistentVector performance is considerably
> improved for conj and instantiation.
> 
> 
> 
> Enhancements:
> * CLJS-683: :source-map-path compiler option to simplify web server
>   integration
> * enable-console-print! for console.log based printing
> * *print-length* now supported
> 
> 
> 
> Bug fixes:
> * CLJS-691: IComparable for keywords and symbols
> * CLJS-674: relativization of source map paths
> * CLJS-687: error when deftype/record used as a function
> 
> * CLJS-639: warnings when record initialized incorrectly
> * CLJS-672: source maps + optimizations + :libs breaks building
> * CLJS-676: source map stale under incremental compilation + closure
>   optimization
> 
> * CLJS-684: throw on circular dependency
> * CLJS-583: duplicate keys in sets
> * CLJS-680: function name shadows JS globals
> * CLJS-699: namespaced keyword regression
> * CLJS-647: js-obj keys could not be expressions

Hi David,

Got these errors in optimizations :none with source-map

Uncaught TypeError: undefined is not a function core.cljs:3852
Uncaught TypeError: Cannot read property 'EMPTY' of undefined net.cljs:24
Uncaught TypeError: Cannot call method 'call' of undefined repl.cljs:21
Uncaught TypeError: undefined is not a function template.cljs:7
Uncaught TypeError: Cannot read property 'EMPTY' of undefined 

The first one above points to this line at PersistentQueue. 

(set! cljs.core.PersistentQueue.EMPTY (PersistentQueue. nil 0 nil [] 0))

In simple mode without source-map, points to this line

cljs.core.PersistentQueue.EMPTY = new cljs.core.PersistentQueue(null, 0, null, 
cljs.core.with_meta(cljs.core.PersistentVector.EMPTY, new 
cljs.core.PersistentArrayMap(null, 2, [new cljs.core.Keyword(null, "end-line", 
"end-line", 2693041432), 3852, new cljs.core.Keyword(null, "end-column", 
"end-column", 3799845882), 69], null)), 0);

No error in advanced mode though (optimized out?)

Thanks,
Feng

-- 
-- 
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/groups/opt_out.

Re: java.jdbc DSLs (java.jdbc.sql / java.jdbc.ddl)

[seancorfield]

I spent this afternoon removing use of java.jdbc.sql from World Singles’ code 
base to see how much work it would be. The worst part for us was how much we 
relied on the naming strategy convenience macros (especially entities, since it 
flows :entities through all the DSL constructs).


How much impact would it have on you, Alexander, if the java.jdbc.sql namespace 
went away? 






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






From: Alexander Hudek
Sent: Thursday, November 21, 2013 7:37 PM
To: clojure@googlegroups.com







Is anyone using the java.jdbc.sql namespace? (besides World Singles :) 






We are using it but not the DDL. We also use honeysql in places where jdbc.sql 
cannot express the query.

-- 
-- 
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/groups/opt_out.

-- 
-- 
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/groups/opt_out.

[ANN] Reaction

[Kelker Ryan]

Reaction  - https://github.com/runexec/reactionA small reactive programming library for ClojureUsageuser> (use '[reaction.core])niluser> (def-reactive! my-int 123)#'user/my-intuser> @my-int123user> (rapply! my-int inc)niluser> @my-int124user> (original-value my-int)123user> @my-int124user> (rapply! my-int #(+ 5 %))niluser> @my-int129user> (defn reactive-minus-2 [] (- @my-int 2))#'user/reactive-minus-2user> (reactive-minus-2)127user> (rapply! my-int #(- % 20))niluser> @my-int109user> (reactive-minus-2)107user> (rset! my-int 1)niluser> (remove-actions! my-int)niluser> @my-int1user> (rapply! my-int inc)niluser> @my-int2user> (remove-actions! my-int)niluser> @my-int1user> 



-- 
-- 
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/groups/opt_out.