Re: Keep application running when main thread only starts go blocks

[Miguel Ping]

Dunno about clojure, but in javaland you would submit jobs through an 
executor and then wait for all tasks on the executor to finish, blocking 
the main thread.

A bit of googling, and you can alter the core.async 
executor: http://stackoverflow.com/a/18779688/22992
And then you can await for its 
shutdown: http://stackoverflow.com/a/1250655/22992

On Saturday, August 6, 2016 at 5:38:24 AM UTC+1, Richard Möhn wrote:
>
> I'm using core.async. In my application the main thread creates a few 
> channels, starts a few go blocks and that's it. When I run it as a 
> stand-alone (i.e. not in the REPL), it starts those go blocks and then 
> exits. After being surprised initially, I understand why this happens: the 
> main thread has nothing more to do, so it terminates and with it the 
> application.
>
> However, I want the application to run until it receives SIGTERM, for 
> example. My current solution is to have a channel wait-for-exit and the 
> main thread does a
> ( after starting its go routines and the signal handler does a
> (put! wait-for-exit :ok)
> This blocks the main thread until the signal handler is called and the 
> application shut down.
>
> It also wastes the resources allocated to the main thread. (Which is only 
> a little bit of RAM, as far as I know, so not too bad.) What is the usual 
> way to solve this problem? Let the main thread do the work of one of the go 
> routines?
>
> Best,
>
> Richard
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Keep application running when main thread only starts go blocks

[Alex Miller]

I think this is solution is fine. A single channel is not going to use any 
noticeable resources. You've basically created a latch - there are several 
latch-like things built into Java you can use as well. 

In the main thread you could do:
(let [signal (java.util.concurrent.CountDownLatch. 1)]
  ... launch your work
  (.await signal))

And in the signal handler you then:
(.countdown signal)

You could also use a Lock and Condition (the oo version of wait/notify), or 
a Semaphore, or a CyclicBarrier.

On Friday, August 5, 2016 at 11:38:24 PM UTC-5, Richard Möhn wrote:
>
> I'm using core.async. In my application the main thread creates a few 
> channels, starts a few go blocks and that's it. When I run it as a 
> stand-alone (i.e. not in the REPL), it starts those go blocks and then 
> exits. After being surprised initially, I understand why this happens: the 
> main thread has nothing more to do, so it terminates and with it the 
> application.
>
> However, I want the application to run until it receives SIGTERM, for 
> example. My current solution is to have a channel wait-for-exit and the 
> main thread does a
> ( after starting its go routines and the signal handler does a
> (put! wait-for-exit :ok)
> This blocks the main thread until the signal handler is called and the 
> application shut down.
>
> It also wastes the resources allocated to the main thread. (Which is only 
> a little bit of RAM, as far as I know, so not too bad.) What is the usual 
> way to solve this problem? Let the main thread do the work of one of the go 
> routines?
>
> Best,
>
> Richard
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.spec for specifying sequences of states over time

[Timothy Baldridge]

A few thoughts on your design and a possible solution to your problem.
Firstly if we are concerned about the correct ordering of values over time,
then it sounds like we are dealing with something that contains hidden
mutable state. That hidden state is a can be problematic. In general, when
working with core.async I try to encourage everyone to avoid situations
where the data received on a channel demands a specific ordering, not only
does it introduce component coupling (both sides must agree to the
protocol), but it also involves mutable state.

One possible way to spec this, however, is to express your state machine
(because that's what you have here), as a finite state machine. That is to
say, don't spec the order of events, spec the state transitions:

a -> b
b -> c
c -> d
c -> b

Each of those could be a spec, and then you could pass in both the old and
new state to each step of the state machine. In this way your state machine
remains pure, and you can spec pairs of states. I.e. an event to move to
state "d" would fail to validate if the previous state was "a".

On Fri, Aug 5, 2016 at 12:08 PM, Alex Miller  wrote:

> There are a variety of possible extensions to what is currently offered by
> spec wrt regex derivatives but that's up to Rich.
>
>
> On Friday, August 5, 2016 at 12:37:15 PM UTC-5, Russell Mull wrote:
>>
>> Suppose you have a reactive process, something that receives a message,
>> processes it, updates its, state, and repeats. For example:
>>
>> (go-loop [s :initial]
>>  (case (>:a (recur :processing)
>>:b (recur :stopping)
>>nil [:success]))
>>
>> In this contrived example, there are some implied valid state transitions:
>> :initial -> :processsing
>> :processing ->: :processing
>> :processing -> :stopping
>> :stopping -> (done)
>>
>> This is pretty easy to write as a regular expression, using clojure.spec:
>> (s/def ::state-seq
>>   (s/cat :s1 #{:initial}
>>  :s2 (s/+ #{:processing})
>>  :s3 #{:stopping}))
>>
>> But with the clojure.spec api, we'd have to store the whole sequence of
>> states and validate it once at the end. To be useful for specifying a
>> sequence of values that are spread out over time, I'd really like to be
>> able to partially evaluate the schema with a single value when it is at
>> hand. The API doesn't expose this, but the implementation appears to
>> support it. It would require the ability to track the intermediate states
>> of the regex derivative, and the ability to do an explicit complete
>> (nullable) check. It could look something like this:
>> (go-loop [st :initial, sch (s/get-spec ::state-seq)]
>>   (let [[valid sch'] (s/partial-valid? sch st)]
>> (when-not (valid)
>>   [:error "everything is terrible"]
>>   (throw "everything is terrible"))
>> (case (>   :a (recur :processing sch')
>>   :b (recur :stopping sch')
>>   nil (if (s/complete? sch')
>> [:success]
>> [:error "input channel closed, but we weren't in a done
>> state"]
>>
>>
>> This could also be useful for specifying something about the order of
>> values expected on a channel:
>> (s/def ::channel-message-seq
>>   (s/cat :s1 #{:a}
>>  :s2 (s/+ #{:b})))
>>
>> (go-loop [sch (s/get-spec ::channel-message-seq)]
>>   (let [[sch' msg] (s/partial-conform sch (> (case msg
>>   :a (recur sch')
>>   :b (recur sch')
>>   ::s/invalid [:error "got unexpected message"])))
>>
>> There are of course many convenient ways this could be packaged.
>>
>> Is it feasible or desirable to add this to clojure.spec?
>>
>> - Russell Mull
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“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" gr

wondering why spec.test/instrument doesn't check :ret

[Tom Connors]

spec.test/instrument doesn't check the return value of spec'd functions and 
according to the spec guide this is because we should be checking function 
implementations at testing time, not development time. It seems to me that 
adding :ret and :fn checks to instrumented functions would be worthwhile 
even though tests are a better place to do those checks - since 
instrumentation is meant to be turned off in production the performance hit 
doesn't matter, and since we're already verifying that the arguments 
conform to spec, why not check the return value as well? A benefit would be 
that if we haven't yet written (or won't write) generators and tests, we 
still get a confidence increase about our instrumented functions' return 
values. 
I'm sure this was considered, so I'm just wondering if "do that in your 
tests" is the entire reason for this design choice.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is this behavior of clojure.core/pr a bug?

[Stuart Halloway]

Has anybody written a pr-edn that enforces the rules of
https://github.com/edn-format/edn, refusing to print anything nonconformant?

This would solve the original problem on this thread without requiring any
changes to Clojure.

On Fri, Aug 5, 2016 at 9:42 PM, Blake Miller  wrote:

> I agree with Herwig in principal ... even though EDN is not meant to cover
> the whole set of possible pure Clojure data, if it can be made to cover
> more (all other things being equal) that would be a Good Thing.
>
> I think it would be possible to fix these edge cases with reader macro
> dispatches without breaking compatibility. The major snag though is
> that performance would suffer ... every single keyword or symbol being
> `pr`d would have to be tested, even those in the vast majority that don't
> need to be emitted in any special way. So my conclusion is it's not worth
> trying ...
>
> It sucks that the docstring for pr https://github.com/clojure/
> clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L3552-L3555 fails to
> mention that the function may succeed and produce a string that the reader
> will barf on, but I think we're pretty much stuck with it.
>
> For posterity: I switched to using Transit for the Clojure(Script) app
> that had me run across this issue.
>
> On Thu, Aug 4, 2016 at 2:23 PM, Herwig Hochleitner  > wrote:
>
>> 2016-08-04 13:56 GMT+02:00 Timothy Baldridge :
>>
>>> The problem is that many do not understand that Clojure data is a
>>> superset of EDN. The two were never meant to be completely compatible.
>>> There are many things, especially when dealing with keywords and symbols,
>>> where its possible to have data that doesn't properly round-trip.
>>>
>>
>> Then fressian and transit are supersets of edn as well. Are those, at
>> least, meant to be the same set as clojure data?
>> Also, reader tags are a fantastic opportunity to make arbitrary data
>> round-trippable.
>>
>> An added problem when dealing with EDN is that there is only really one
>>> or two languages that properly parse it: Clojure and Clojurescript. So it's
>>> also a poor choice to use in cases where you desire any sort of interop.
>>>
>>
>> There many edn libraries for various languages: https://github.com/
>> edn-format/edn/wiki/Implementations
>> It is true, that there is a lack of compatibility, especially in the
>> handling of symbols and keywords and the community is hurting for it (I
>> remember a couple of tedious discussions on the matter)
>>
>> see http://dev.clojure.org/jira/browse/CLJ-1527 https://gith
>> ub.com/edn-format/edn/issues/67 ...
>>
>> Add on top of all that that EDN parsing is really slow compared to other
>>> approaches, and you have a lot of compelling reasons to, as Herwig put it,
>>> "abandon edn, except for hand-written data".
>>>
>>
>> My view is, that those reasons should be eliminated, starting with
>> interoperability concerns. I still think edn is a fantastic idea and to me
>> it still holds the promise of being a replacement for json and xml, but
>> only if we can get our act together and develop it towards that goal.
>>
>> Please note, that my "except for hand-written data" was meant to be
>> hyperbole. Every data is eventually machine-written.
>>
>> Abandoning edn would send a fatal signal not just to people in the
>> community. Especially if we let it slowly die instead of declaring it a
>> failed experiment in data exchange.
>>
>> Imagine if pr wouldn't handle embedded " quotes in strings and the
>> inofficial recommendation would be to just avoid that use case or use a
>> different encoding.
>>
>> And yes, the original problem that caused the creation of Transit was
>>> "how do we get data from language A to language B while still staying fast,
>>> not implementing a ton of code, and keeping rich data (dates should be
>>> dates, not strings)."
>>>
>>
>> I like the idea of having various encodings for different uses, but we
>> should strife towards compatibility.
>>
>> --
>> 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/to
>> pic/clojure/Rc_b4_Da-KU/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/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new memb

Re: Is this behavior of clojure.core/pr a bug?

[Andy Fingerhut]

The user-provided examples and comments at ClojureDocs.org are not official
Clojure documentation, but in many cases contain useful additional info.

I have just added examples to clojure.core/pr similar to those that
motivated this thread, and Timothy Baldridge's suggestion to use transit in
cases where such Clojure data may be present.

http://clojuredocs.org/clojure.core/pr

http://clojuredocs.org/clojure.edn/read

Andy


On Fri, Aug 5, 2016 at 6:42 PM, Blake Miller  wrote:

> I agree with Herwig in principal ... even though EDN is not meant to cover
> the whole set of possible pure Clojure data, if it can be made to cover
> more (all other things being equal) that would be a Good Thing.
>
> I think it would be possible to fix these edge cases with reader macro
> dispatches without breaking compatibility. The major snag though is
> that performance would suffer ... every single keyword or symbol being
> `pr`d would have to be tested, even those in the vast majority that don't
> need to be emitted in any special way. So my conclusion is it's not worth
> trying ...
>
> It sucks that the docstring for pr https://github.com/clojure/
> clojure/blob/clojure-1.7.0/src/clj/clojure/core.clj#L3552-L3555 fails to
> mention that the function may succeed and produce a string that the reader
> will barf on, but I think we're pretty much stuck with it.
>
> For posterity: I switched to using Transit for the Clojure(Script) app
> that had me run across this issue.
>
> On Thu, Aug 4, 2016 at 2:23 PM, Herwig Hochleitner  > wrote:
>
>> 2016-08-04 13:56 GMT+02:00 Timothy Baldridge :
>>
>>> The problem is that many do not understand that Clojure data is a
>>> superset of EDN. The two were never meant to be completely compatible.
>>> There are many things, especially when dealing with keywords and symbols,
>>> where its possible to have data that doesn't properly round-trip.
>>>
>>
>> Then fressian and transit are supersets of edn as well. Are those, at
>> least, meant to be the same set as clojure data?
>> Also, reader tags are a fantastic opportunity to make arbitrary data
>> round-trippable.
>>
>> An added problem when dealing with EDN is that there is only really one
>>> or two languages that properly parse it: Clojure and Clojurescript. So it's
>>> also a poor choice to use in cases where you desire any sort of interop.
>>>
>>
>> There many edn libraries for various languages: https://github.com/
>> edn-format/edn/wiki/Implementations
>> It is true, that there is a lack of compatibility, especially in the
>> handling of symbols and keywords and the community is hurting for it (I
>> remember a couple of tedious discussions on the matter)
>>
>> see http://dev.clojure.org/jira/browse/CLJ-1527 https://gith
>> ub.com/edn-format/edn/issues/67 ...
>>
>> Add on top of all that that EDN parsing is really slow compared to other
>>> approaches, and you have a lot of compelling reasons to, as Herwig put it,
>>> "abandon edn, except for hand-written data".
>>>
>>
>> My view is, that those reasons should be eliminated, starting with
>> interoperability concerns. I still think edn is a fantastic idea and to me
>> it still holds the promise of being a replacement for json and xml, but
>> only if we can get our act together and develop it towards that goal.
>>
>> Please note, that my "except for hand-written data" was meant to be
>> hyperbole. Every data is eventually machine-written.
>>
>> Abandoning edn would send a fatal signal not just to people in the
>> community. Especially if we let it slowly die instead of declaring it a
>> failed experiment in data exchange.
>>
>> Imagine if pr wouldn't handle embedded " quotes in strings and the
>> inofficial recommendation would be to just avoid that use case or use a
>> different encoding.
>>
>> And yes, the original problem that caused the creation of Transit was
>>> "how do we get data from language A to language B while still staying fast,
>>> not implementing a ton of code, and keeping rich data (dates should be
>>> dates, not strings)."
>>>
>>
>> I like the idea of having various encodings for different uses, but we
>> should strife towards compatibility.
>>
>> --
>> 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/to
>> pic/clojure/Rc_b4_Da-KU/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/d/optout.
>

Re: wondering why spec.test/instrument doesn't check :ret

[Josh Tilles]

I’m not sure it answers your question *directly*, but a quote from Rich in 
another 
thread  seems 
relevant:

On Monday, July 11, 2016 at 10:01:05 AM UTC-4, Rich Hickey wrote:

> On Sunday, July 10, 2016 at 6:04:39 AM UTC-4, puzzler wrote:

1. No way to test function output specs.  For documentation purposes, I 
>> want to have an output spec on my function.  However, as far as I know, 
>> after instrumentation-triggered checking of output specs was removed a 
>> couple of alphas ago, the only way remaining to check against output specs 
>> is to use randomly generated tests.  So if I can't make good generators, I 
>> have no way to confirm that my output spec works the way I think it does.  
>> My documentation could be totally out of touch with reality, and that 
>> displeases me.
>
> Running return-value instrument-style checking on whatever few 
> hand-written tests you might have isn’t going to give you better coverage 
> than a simple (even hardwired) generator that captures similar ranges. And 
> you can directly exercise your :ret spec - it’s just another spec. You can 
> also spec/assert on your return - the tests will disappear in production, 
> although this is similarly as weak as instrument-triggered return checking, 
> so I’m not going to help you do it, but you can do it yourself :) 


Incidentally, I think your question is common enough that it might be worth 
writing something up for http://clojure.org/guides/faq.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: wondering why spec.test/instrument doesn't check :ret

[Sean Corfield]

> I'm sure this was considered

 

Indeed, and when clojure.spec was first introduced, instrument did check :ret 
and :fn specs. That feature was deliberately removed and the reason for it is 
(paraphrased):

 

* clojure.spec/instrument helps check that your functions are _called_ correctly

* clojure.spec.test/check helps check that your functions are _implemented_ 
correctly

 

Those are two different concerns and they should not be complected into one 
function. The argument checks performed by instrument are straightforward: are 
the arguments valid? The function invariant is checked by performing generative 
testing.

 

See this thread for some of the discussion around this (and Rich has also 
discussed in on Slack quite a bit):

 

https://groups.google.com/d/topic/clojure/RLQBFJ0vGG4/discussion

 

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

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

On 8/6/16, 10:02 AM, "Tom Connors"  wrote:

 

spec.test/instrument doesn't check the return value of spec'd functions and 
according to the spec guide this is because we should be checking function 
implementations at testing time, not development time. It seems to me that 
adding :ret and :fn checks to instrumented functions would be worthwhile even 
though tests are a better place to do those checks - since instrumentation is 
meant to be turned off in production the performance hit doesn't matter, and 
since we're already verifying that the arguments conform to spec, why not check 
the return value as well? A benefit would be that if we haven't yet written (or 
won't write) generators and tests, we still get a confidence increase about our 
instrumented functions' return values. 

I'm sure this was considered, so I'm just wondering if "do that in your tests" 
is the entire reason for this design choice.

 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

can clojure java.jdbc function 'result-set-seq' add option to support custom 'result-set-read-column' ?

[Xiangtao Zhou]

Hello the contributor of jdbc,

Using java.jdbc with postgres composite type,  the common way is extend the 
IResultSetReadColumn 
protocol. When there are multiple databases in use, every database should 
specify it's own column reader. 
Add option to 'result-set-seq' support custom function to replace 
IResultSetReadColumn 
may be a solution for this situation.

any other idea to solve this?

Joe.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: can clojure java.jdbc function 'result-set-seq' add option to supportcustom 'result-set-read-column' ?

[sean]

Hi Joe,

I’m starting to see more requests for per-database customization in a 
multi-database environment so this is definitely something I’d consider. Could 
you create a JIRA issue for tracking purposes, along with any suggestions you 
have about how this might work – and remain performant? 
http://dev.clojure.org/jira/browse/JDBC

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

From: Xiangtao Zhou

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.