ANN Langohr 1.1.0 is released

[Michael Klishin]

Langohr [1] is a small, feature complete Clojure RabbitMQ client.


1.1 is a minor feature release that improves RabbitMQ HTTP API support,
contributed by Steffen Dienst. There are no breaking API changes in this
release.

Release notes:
http://blog.clojurewerkz.org/blog/2013/07/31/langohr-1-dot-1-0-is-released/

1. http://clojurerabbitmq.info
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
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: Digest for clojure@googlegroups.com - 25 Messages in 7 Topics

[Cedric Greevey]

A mailing list debate doesn't count as a "real world application" for such
skills as well? :)


On Wed, Jul 31, 2013 at 2:05 AM, James Ashley wrote:

> Steven Degutis  Jul 24 08:16AM -0500
>
>>
>>
>>First, the goal of Verily was not the same as Test2. It wasn't
>>intended to
>>unify any existing test libs. It was really just meant to succeed
>>clojure.test in spirit. That's all.
>>
>>Second, nobody "bullied" me into this decision. Some people asked how
>>Verily improved upon the alternatives, and, try as I might, I
>>couldn't come
>>up with any good answer. That's how I realized that the project was
>>pointless, a waste of time, and was wrought in arrogance.
>>
>>
> I know I'm a week late catching up, and I don't have any credibility on
> this list at all, but
> I'm still inclined to submit some profanity at this point.
>
> 
> Did you learn anything from writing this? Have you produced anything at
> all that might
> be worth contributing to other projects (even if it's just ideas?) Did you
> produce something
> that we lesser mortals might learn from in our efforts to contribute to
> the Holy
> Sanctum of High Testing?
>
> Or, for that matter, hints about best ways to use them?
>
> (I'm totally not commenting about any of the existing "major"
> frameworks...I'm commenting
> strictly about this email).
>
> I don't care if you just produced some ASCII art that some Bavarian hacker
> will someday
> find amusing while she's dribbling her baklava in her latte (or whatever
> it is people do in
> countries that actually need fancy character sets)...if you produced
> something, it was worthwhile.
>
> We live in a world that's full of consumers. And complainers that what you
> produced wasn't
> good enough. It sounds like this isn't what really what happened here, but
> the basic idea and
> attitude applies.
>
> A "how could I do this better?" RFC is one thing. I've learned tons from
> those sorts of
> discussions. The projects by themselves might have been pointless, but (if
> nothing else)
> the learning experience was not.
>
> Who knows who else might learn from our mistakes?
> 
>
> My apologies for the rant...I recently acquired a tween daughter, so I'm
> trying to hone my
> skills for these sorts of moments in real world applications.
> 
>
> Regards,
> James
>
> --
> --
> 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: Digest for clojure@googlegroups.com - 25 Messages in 7 Topics

[James Ashley]

Steven Degutis  Jul 24 08:16AM -0500

>
>
>First, the goal of Verily was not the same as Test2. It wasn't
>intended to
>unify any existing test libs. It was really just meant to succeed
>clojure.test in spirit. That's all.
>
>Second, nobody "bullied" me into this decision. Some people asked how
>Verily improved upon the alternatives, and, try as I might, I couldn't
>come
>up with any good answer. That's how I realized that the project was
>pointless, a waste of time, and was wrought in arrogance.
>
>
I know I'm a week late catching up, and I don't have any credibility on
this list at all, but
I'm still inclined to submit some profanity at this point.


Did you learn anything from writing this? Have you produced anything at all
that might
be worth contributing to other projects (even if it's just ideas?) Did you
produce something
that we lesser mortals might learn from in our efforts to contribute to the
Holy
Sanctum of High Testing?

Or, for that matter, hints about best ways to use them?

(I'm totally not commenting about any of the existing "major"
frameworks...I'm commenting
strictly about this email).

I don't care if you just produced some ASCII art that some Bavarian hacker
will someday
find amusing while she's dribbling her baklava in her latte (or whatever it
is people do in
countries that actually need fancy character sets)...if you produced
something, it was worthwhile.

We live in a world that's full of consumers. And complainers that what you
produced wasn't
good enough. It sounds like this isn't what really what happened here, but
the basic idea and
attitude applies.

A "how could I do this better?" RFC is one thing. I've learned tons from
those sorts of
discussions. The projects by themselves might have been pointless, but (if
nothing else)
the learning experience was not.

Who knows who else might learn from our mistakes?


My apologies for the rant...I recently acquired a tween daughter, so I'm
trying to hone my
skills for these sorts of moments in real world applications.


Regards,
James

-- 
-- 
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] cljzmq-0.1.1 - A Clojure binding for ØMQ

[Trevor Bernard]

Here is a simple way to send and receive Clojure data over ØMQ:

https://gist.github.com/trevorbernard/6118918

On Monday, July 29, 2013 10:00:13 AM UTC-3, Trevor Bernard wrote:
>
> Hello,
>
> I'd like to announce the immediate availability of cljzmq-0.1.1 on maven 
> central.
>
> https://github.com/zeromq/cljzmq
>
> For sample usage, I've started porting the zguide examples here:
>
> https://github.com/trevorbernard/cljzmq-examples
>
> Pull requests welcome!
>
> Warmest regards,
>
> Trev
>

-- 
-- 
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] immutable-bitset: smalller, faster integer sets

[Zach Tellman]

https://github.com/ztellman/immutable-bitset

There's not much to describe here, this provides an implementation of an 
integer-only set which can take up three orders of magnitude less memory 
under certain conditions.  I needed this to implement a Bloom filter, but I 
figured it had applications elsewhere.  If anyone has questions, I'd be 
happy to answer them.

Zach

-- 
-- 
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: changing a value in a vector of maps

[Joel Holdbrooks]

This probably won't help with your garbage collection worries, but it's a 
bit more flexible.

*(defn find-assoc-in [pred coll k v & kvs]*
*  (let [f #(if (pred %) (apply assoc % k v kvs) %)]*
*(into (empty coll) (map f coll*


On Tuesday, July 30, 2013 10:53:48 AM UTC-7, cej38 wrote:
>
> Suppose I have a vector of maps (this could also be a vector of records)
>
> (def aa [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 0} {:a 100 :b 0 :c 0}])
>
> and I want to go in an change the value of associated with :c when :a has 
> a value of 50, so that the final col of maps looks like
>
> [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 3} {:a 100 :b 0 :c 0}].
>
>
>
> I came up with a function that does this:
>
> (defn find-assoc-in
>   [k v  mv]
>   (let [f #(if (= ((first k) %) (first v))
>  (assoc % (second k) (second v))
>  %)]
>  (map f mv)))
>
>
> (find-assoc-in [:a :c] [50 3] aa)
>
>
> The problem with this function is that it potentially does a lot 
> of unnecessary copying of elements that aren't changed, and thus has a lot 
> of garbage collection.  I would like help coming up with something that 
> does much less garbage collection.
>
>
> Will someone please point out a better way of doing this?
>
>

-- 
-- 
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: changing a value in a vector of maps

[Cedric Greevey]

For a more quantitative comparison, the (reduce #(assoc-in ...)) approach
generates O(* (count index-seq) (log_32 (count input-vec))) garbage, while
the (vec (for ...)) approach, with its temporary seq the size of the
vector, and likely wholesale replacement of the vector itself (assuming you
don't keep the old version around after this), generates O(count input-vec)
garbage. They both only traverse the whole vector once, copying in one case
and building up the index-seq in the other, so they're much more even in
speed however large the vector is (both O(count input-vec)).

This is why the assoc-in approach is only really better if the vector is
considerably larger than the number of entries needing updating. Otherwise,
the (vec (for ...)) approach produces simpler, more maintainable code and
should be preferred if you never expect the vectors to grow very large, or
if you expect the proportion of items needing updating to often be a
substantial fraction of "all of them".


On Tue, Jul 30, 2013 at 6:34 PM, Cedric Greevey  wrote:

> Note: to repeatedly assoc-in over a seq of indices you'd want
>
> (reduce #(assoc-in %1 [%2 :c] 50) input-vec index-seq)
>
> Replace the key :c and value 50 as needed. If the 50 would actually be
> computed from the index, an expression using %2 would work. If the 50 would
> actually be computed from the existing value associated with the :c (or
> whatever) key, use update-in instead of assoc-in and pass in the function
> that transforms the existing value to the appropriate new value as the last
> argument to update-in.
>
>
>
> On Tue, Jul 30, 2013 at 6:27 PM, Cedric Greevey wrote:
>
>> That's basically the same as the first solution, in terms of how it works
>> under the hood.
>>
>> If the desire is for the output to share structure with the input, not
>> just the maps but the vector as well, then you need to do something a bit
>> more complicated. First you need to find the map you want, and return its
>> index in the vector (assuming it will be unique if present). Then you need
>> to use assoc-in with the index, like (assoc-in v [idx :c] 50) or whatever.
>>
>> If there may be more than one map that should be adjusted, you could
>> return a seq of indices and repeatedly assoc-in, but I doubt this would
>> give superior efficiency unless the vector was typically huge and the
>> number of maps needing changes typically much smaller. With million-element
>> vectors and two or three maps needing updating it would likely be
>> preferable to the (vec (for ...)) approach. With dozen-element vectors with
>> half a dozen maps needing updating I'd go with (vec (for ...)).
>>
>>
>>
>> On Tue, Jul 30, 2013 at 4:58 PM, Jim - FooBar(); wrote:
>>
>>>  Hi,
>>>
>>> how about 
>>>
>>> (vec
>>> (for [{:keys [a b c] :as m} aa]
>>>  (if (= a 50) (assoc m :c 3) m)))
>>>
>>> :)
>>> Jim
>>>
>>>
>>>
>>> On 30/07/13 18:53, cej38 wrote:
>>>
>>> Suppose I have a vector of maps (this could also be a vector of records)
>>>
>>>  (def aa [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 0} {:a 100 :b 0 :c 0}])
>>>
>>>  and I want to go in an change the value of associated with :c when :a
>>> has a value of 50, so that the final col of maps looks like
>>>
>>>  [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 3} {:a 100 :b 0 :c 0}].
>>>
>>>
>>>
>>>  I came up with a function that does this:
>>>
>>>  (defn find-assoc-in
>>>   [k v  mv]
>>>   (let [f #(if (= ((first k) %) (first v))
>>>  (assoc % (second k) (second v))
>>>  %)]
>>>  (map f mv)))
>>>
>>>
>>>  (find-assoc-in [:a :c] [50 3] aa)
>>>
>>>
>>>  The problem with this function is that it potentially does a lot
>>> of unnecessary copying of elements that aren't changed, and thus has a lot
>>> of garbage collection.  I would like help coming up with something that
>>> does much less garbage collection.
>>>
>>>
>>>  Will someone please point out a better way of doing this?
>>>
>>>  --
>>> --
>>> 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 em

Re: changing a value in a vector of maps

[Cedric Greevey]

Note: to repeatedly assoc-in over a seq of indices you'd want

(reduce #(assoc-in %1 [%2 :c] 50) input-vec index-seq)

Replace the key :c and value 50 as needed. If the 50 would actually be
computed from the index, an expression using %2 would work. If the 50 would
actually be computed from the existing value associated with the :c (or
whatever) key, use update-in instead of assoc-in and pass in the function
that transforms the existing value to the appropriate new value as the last
argument to update-in.



On Tue, Jul 30, 2013 at 6:27 PM, Cedric Greevey  wrote:

> That's basically the same as the first solution, in terms of how it works
> under the hood.
>
> If the desire is for the output to share structure with the input, not
> just the maps but the vector as well, then you need to do something a bit
> more complicated. First you need to find the map you want, and return its
> index in the vector (assuming it will be unique if present). Then you need
> to use assoc-in with the index, like (assoc-in v [idx :c] 50) or whatever.
>
> If there may be more than one map that should be adjusted, you could
> return a seq of indices and repeatedly assoc-in, but I doubt this would
> give superior efficiency unless the vector was typically huge and the
> number of maps needing changes typically much smaller. With million-element
> vectors and two or three maps needing updating it would likely be
> preferable to the (vec (for ...)) approach. With dozen-element vectors with
> half a dozen maps needing updating I'd go with (vec (for ...)).
>
>
>
> On Tue, Jul 30, 2013 at 4:58 PM, Jim - FooBar(); wrote:
>
>>  Hi,
>>
>> how about 
>>
>> (vec
>> (for [{:keys [a b c] :as m} aa]
>>  (if (= a 50) (assoc m :c 3) m)))
>>
>> :)
>> Jim
>>
>>
>>
>> On 30/07/13 18:53, cej38 wrote:
>>
>> Suppose I have a vector of maps (this could also be a vector of records)
>>
>>  (def aa [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 0} {:a 100 :b 0 :c 0}])
>>
>>  and I want to go in an change the value of associated with :c when :a
>> has a value of 50, so that the final col of maps looks like
>>
>>  [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 3} {:a 100 :b 0 :c 0}].
>>
>>
>>
>>  I came up with a function that does this:
>>
>>  (defn find-assoc-in
>>   [k v  mv]
>>   (let [f #(if (= ((first k) %) (first v))
>>  (assoc % (second k) (second v))
>>  %)]
>>  (map f mv)))
>>
>>
>>  (find-assoc-in [:a :c] [50 3] aa)
>>
>>
>>  The problem with this function is that it potentially does a lot
>> of unnecessary copying of elements that aren't changed, and thus has a lot
>> of garbage collection.  I would like help coming up with something that
>> does much less garbage collection.
>>
>>
>>  Will someone please point out a better way of doing this?
>>
>>  --
>> --
>> 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: changing a value in a vector of maps

[Cedric Greevey]

That's basically the same as the first solution, in terms of how it works
under the hood.

If the desire is for the output to share structure with the input, not just
the maps but the vector as well, then you need to do something a bit more
complicated. First you need to find the map you want, and return its index
in the vector (assuming it will be unique if present). Then you need to use
assoc-in with the index, like (assoc-in v [idx :c] 50) or whatever.

If there may be more than one map that should be adjusted, you could return
a seq of indices and repeatedly assoc-in, but I doubt this would give
superior efficiency unless the vector was typically huge and the number of
maps needing changes typically much smaller. With million-element vectors
and two or three maps needing updating it would likely be preferable to the
(vec (for ...)) approach. With dozen-element vectors with half a dozen maps
needing updating I'd go with (vec (for ...)).



On Tue, Jul 30, 2013 at 4:58 PM, Jim - FooBar(); wrote:

>  Hi,
>
> how about 
>
> (vec
> (for [{:keys [a b c] :as m} aa]
>  (if (= a 50) (assoc m :c 3) m)))
>
> :)
> Jim
>
>
>
> On 30/07/13 18:53, cej38 wrote:
>
> Suppose I have a vector of maps (this could also be a vector of records)
>
>  (def aa [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 0} {:a 100 :b 0 :c 0}])
>
>  and I want to go in an change the value of associated with :c when :a
> has a value of 50, so that the final col of maps looks like
>
>  [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 3} {:a 100 :b 0 :c 0}].
>
>
>
>  I came up with a function that does this:
>
>  (defn find-assoc-in
>   [k v  mv]
>   (let [f #(if (= ((first k) %) (first v))
>  (assoc % (second k) (second v))
>  %)]
>  (map f mv)))
>
>
>  (find-assoc-in [:a :c] [50 3] aa)
>
>
>  The problem with this function is that it potentially does a lot
> of unnecessary copying of elements that aren't changed, and thus has a lot
> of garbage collection.  I would like help coming up with something that
> does much less garbage collection.
>
>
>  Will someone please point out a better way of doing this?
>
>  --
> --
> 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.

October Barnstorming in Europe

[Stuart Halloway]

Michael Nygard [1] and Stu Halloway [2] will be in Europe for much of
October.  We are speaking at a bunch of conferences [3], [4], [5], and
[6] and hope to see some of you there.

Since we are already on the road, we thought it would be a good
opportunity to turn this into a barnstorming tour, working with teams
who are looking for help with Clojure, ClojureScript, and/or Datomic.
If you would like to have us work with your team, pricing is as
follows:

* Free for user group talks
* $1500 for a 90 minute talk
* $5000 for a day of training or consulting
* $0 for travel expenses (we are already there!)

Our prepared materials are summarized at [7] and [8], or feel free to
request
specific topics.

If you are interested in scheduling a meeting, please send an email to
i...@thinkrelevance.com, subject line: "October Barnstorming".
Includes in the body of the message the kind of event you are
interested in, as well as possible dates and locations.

Regards,
Michael and Stu

[1] http://thinkrelevance.com/team/members/stuart-halloway
[2] http://thinkrelevance.com/team/members/michael-nygard
[3] http://euroclojure.com/2013/
[4] http://reaktordevday.fi/2013/
[5] http://gotocon.com/berlin-2013/
[6] http://gotocon.com/amsterdam-2013/upcomingevents/
[7] https://github.com/stuarthalloway/presentations/wiki
[8] https://github.com/mtnygard/presentations/wiki

-- 
-- 
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: changing a value in a vector of maps

[Jim - FooBar();]

Hi,

how about 

(vec
(for [{:keys [a b c] :as m} aa]
 (if (= a 50) (assoc m :c 3) m)))

:)
Jim


On 30/07/13 18:53, cej38 wrote:

Suppose I have a vector of maps (this could also be a vector of records)

(def aa [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 0} {:a 100 :b 0 :c 0}])

and I want to go in an change the value of associated with :c when :a 
has a value of 50, so that the final col of maps looks like


[{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 3} {:a 100 :b 0 :c 0}].



I came up with a function that does this:

(defn find-assoc-in
  [k v  mv]
  (let [f #(if (= ((first k) %) (first v))
 (assoc % (second k) (second v))
 %)]
 (map f mv)))


(find-assoc-in [:a :c] [50 3] aa)


The problem with this function is that it potentially does a lot 
of unnecessary copying of elements that aren't changed, and thus has a 
lot of garbage collection.  I would like help coming up with something 
that does much less garbage collection.



Will someone please point out a better way of doing this?

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

changing a value in a vector of maps

[cej38]

Suppose I have a vector of maps (this could also be a vector of records)

(def aa [{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 0} {:a 100 :b 0 :c 0}])

and I want to go in an change the value of associated with :c when :a has a 
value of 50, so that the final col of maps looks like

[{:a 0 :b 0 :c 0} {:a 50 :b 0 :c 3} {:a 100 :b 0 :c 0}].



I came up with a function that does this:

(defn find-assoc-in
  [k v  mv]
  (let [f #(if (= ((first k) %) (first v))
 (assoc % (second k) (second v))
 %)]
 (map f mv)))


(find-assoc-in [:a :c] [50 3] aa)


The problem with this function is that it potentially does a lot 
of unnecessary copying of elements that aren't changed, and thus has a lot 
of garbage collection.  I would like help coming up with something that 
does much less garbage collection.


Will someone please point out a better way of doing this?

-- 
-- 
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: Invalid token exception on a / operator

[Maik Schünemann]

Thanks Nicola!

On Tue, Jul 30, 2013 at 2:32 PM, Nicola Mometto  wrote:
>
> It's going to be possible in clojure-1.6 see: 
> https://github.com/clojure/clojure/commit/88cad2510243289d2bbe28cf8bd14007d9df5fc3
>
> Maik Schünemann writes:
>
>> Is / a valid clojure function name (valid, but not recommended)?
>> I tought so because of clojure.core//
>> in the repl there is also no problem with clojure.core//:
>> clojure.core//
>> ;=>#
>> but if / is in another namespace, for example in core.matrix:
>> clojure.core.matrix.operators//
>> RuntimeException Invalid token: clojure.core.matrix.operators//
>>  clojure.lang.Util.runtimeException (Util.java:219)
>>
>> clearly this is an edge case, because / also separates namespaces but I
>> think
>> if clojure.core// is valid clojure.core.matrix.operators// should also be a
>> valid token?!
>>
>> regards
>> Maik Schünemann
>>
>> --
>
> --
> --
> 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: Invalid token exception on a / operator

[Nicola Mometto]

It's going to be possible in clojure-1.6 see: 
https://github.com/clojure/clojure/commit/88cad2510243289d2bbe28cf8bd14007d9df5fc3

Maik Schünemann writes:

> Is / a valid clojure function name (valid, but not recommended)?
> I tought so because of clojure.core//
> in the repl there is also no problem with clojure.core//:
> clojure.core//
> ;=>#
> but if / is in another namespace, for example in core.matrix:
> clojure.core.matrix.operators//
> RuntimeException Invalid token: clojure.core.matrix.operators//
>  clojure.lang.Util.runtimeException (Util.java:219)
>
> clearly this is an edge case, because / also separates namespaces but I
> think
> if clojure.core// is valid clojure.core.matrix.operators// should also be a
> valid token?!
>
> regards
> Maik Schünemann
>
> --

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

Invalid token exception on a / operator

[Maik Schünemann]

Is / a valid clojure function name (valid, but not recommended)?
I tought so because of clojure.core//
in the repl there is also no problem with clojure.core//:
clojure.core//
;=>#
but if / is in another namespace, for example in core.matrix:
clojure.core.matrix.operators//
RuntimeException Invalid token: clojure.core.matrix.operators// 
 clojure.lang.Util.runtimeException (Util.java:219)

clearly this is an edge case, because / also separates namespaces but I 
think
if clojure.core// is valid clojure.core.matrix.operators// should also be a 
valid token?!

regards
Maik Schünemann

-- 
-- 
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: YA regular expression tool

[Mikera]

On Monday, 29 July 2013 21:20:49 UTC+1, Joel Holdbrooks wrote:
>
> I spent some time this weekend writing a little tool for generating 
> regular expressions *from known inputs*. My goal is to produce regular 
> expressions that backtrack as few times as possible along with a complete 
> and total disregard for readability. :)
>
> The code for the tool is here . 
> Suggestions/ideas would be greatly appreciated.
>

Nice - I like the fact that it has a very simple API that focuses on doing 
just one thing well! 

-- 
-- 
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: core.async + swing

[eliassonaand]

Hi Tim, 
I did try invokeLater before unsuccessfully. I think the problem was that 
the Graphics I passed on the channel wasn't valid anymore. This time around 
I tried getting the graphics with Component.getGraphics instead, inside 
invokeLater. That worked!
By the way, I think core.async is fantastic, what a relief to get rid of 
all the callbacks.
Thanks so much for your help and for core.async!
--anders
  

Den måndagen den 29:e juli 2013 kl. 16:52:31 UTC+2 skrev tbc++:
>
> I recommend using invokeLater to send a fn to Swing to do the rendering.
>
>
> http://docs.oracle.com/javase/6/docs/api/javax/swing/SwingUtilities.html#invokeLater(java.lang.Runnable)
>  
>
> If you need Swing to notify the go channel when the rendering is complete, 
> you can do something like this:
>
> (go
>   (let [c (chan)]
> (SwingUtilities/invokeLater (fn [] (do ...stuff ) (close! c)))
> (
> Wrap in a macro if you find yourself doing it a lot:
>
> (go (in-swing-and-wait
>...stuff...))
>
> Timothy 
>
>
> On Mon, Jul 29, 2013 at 8:44 AM, >wrote:
>
>> Hi, I'm playing around with core.async a bit.
>> Is it possible to put java.awt.Graphics object into a channel and do the 
>> drawing in a go loop consuming this channel.
>> The problem I'm having is that when I consume the channel, core.async has 
>> switched to another thread. I'm not in the Swing thread anymore.
>> Is there a way to stay in the Swing thread while doing this?
>>  
>> This is how I setup the producer:
>>
>> (defn create-canvas [paint-channel]
>>   (proxy [JButton] []
>>  (getPreferredSize [] (Dimension. 300 300))
>>  (paintComponent [g]
>>(go
>>  (proxy-super paintComponent g)
>>  (>! paint-channel g) ;I've tried put! too
>>
>> Thanks!
>> --anders
>>
>>
>>  -- 
>> -- 
>> 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.
>>  
>>  
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

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