Re: In clojure.spec, how to declare all valid keys in a map

2016-09-21 Thread David Goldfarb 
Nice, thanks. I had not thought to use map-of for this. And, s/merge 
certainly helps too.

The only remaining issue for me is that this requires supplying the list of 
keys twice.
AI think this case is general enough that it is worth extending the s/keys 
macro to support: (s/keys :req [::a ::b] :allow-other-keys false)

Or, if is is objectionable to have a keyword default to true when not 
supplied, perhaps: (s/keys :req [::a ::b] :strict-keys true)

On Tuesday, September 20, 2016 at 9:47:43 PM UTC+3, Alex Miller wrote:
>
> For stuff like this s/merge is probably preferable to s/and (when 
> combining map specs) - the difference being that merge does not flow 
> conformed results, will combine all failures, and that gen can work better 
> in some cases.
>
> (s/def ::a int?)
> (s/def ::b string?)  ;; changed for this example
> (s/explain ::my-map {::a 1 ::b 2 ::BAD 3})
> In: [:user/b] val: 2 fails spec: :user/b at: [:user/b] predicate: string?
>
> ;; vs:
>
> (s/def ::my-map2 (s/merge (s/keys :req [::a ::b])  (s/map-of #{::a ::b} 
> any?)))
> (s/explain ::my-map2 {::a 1 ::b 2 ::BAD 3})
> In: [:user/b] val: 2 fails spec: :user/b at: [:user/b] predicate: string?
> In: [:user/BAD 0] val: :user/BAD fails spec: :user/my-map2 at: [0] 
> predicate: #{:user/a :user/b}
>
> ^^ Note you get *both* failures here - both bad attribute value AND the 
> invalid key vs the prior one where you only get the first failure.
>
>
> On Tuesday, September 20, 2016 at 11:38:47 AM UTC-5, Beau Fabry wrote:
>>
>> boot.user=> (s/def ::my-map (s/and (s/keys :req [::a ::b])  (s/map-of 
>> #{::a ::b} any?)))
>> boot.user=> (s/explain ::my-map {::a 1 ::b 2 ::BAD 3})
>> In: [:boot.user/BAD 0] val: :boot.user/BAD fails spec: :boot.user/my-map 
>> at: [0] predicate: #{:boot.user/a :boot.user/b}
>>
>> Seems better
>>
>> On Tuesday, September 20, 2016 at 5:38:10 AM UTC-7, David Goldfarb wrote:
>>>
>>> In clojure.spec, how can I declare a map that accepts only certain keys? 
>>>  
>>>
>>> *{::a 1 ::b 2 ::BAD 3}* does conform to *(s/keys :req :req [::a ::b])*, 
>>> but I want a spec that will be bothered by ::BAD or any other undeclared 
>>> key.
>>>
>>> My use case: I am introducing spec to some legacy code, and I want to be 
>>> warned if I have failed to specify some elements that may appear in my map.
>>>
>>>
>>> Question 2:
>>>
>>>  So, assuming that this is not possible currently, I brute-forced it 
>>> with:
>>>
>>> *(defn- key-checker [valid-keys]*
>>> *  (fn [map-to-check]*
>>> *(empty? (clojure.set/difference (into #{} (keys map-to-check)) 
>>> valid-keys*
>>>
>>> *(s/def ::my-map (s/and (s/keys :req [::a ::b])  (key-checker #{::a 
>>> ::b})))*
>>>
>>>
>>> Ignoring the ugly, and easily fixable, smell of the duplicated set of 
>>> keys, this has a bigger problem:
>>>
>>> If the predicate fails, the error that assert gives me is *"{... big 
>>> ugly map ...} fails predicate: (key-checker #{::a ::b})"* with no easy 
>>> way for the viewer to see which key failed. Can I somehow hook into the 
>>> explain mechanism to give a more useful message?
>>>
>>

-- 
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 docstring style

2016-09-21 Thread narendra 
Is there a convention to be followed for referring the parameters of a 
function in the docstring, e.g. for emacs lisp we upcase the parameter name?

On Sunday, May 15, 2016 at 11:12:11 PM UTC+5:30, cskksc wrote:
>
> Hello,
> We are working on a new feature in CIDER which would parse a docstring and 
> create hyperlinks that follow the functions/vars/interop-forms mentioned 
> there.
> It is very similar to the "See Also" links shown by ClojureDocs 
> . Right now, we are using backticks to identify 
> the reference forms and create links.
>
> So a function like;
>
> (defn test-mde
>   "Does something with `user-ns/user-fn`.
>Also see: `clojure.core/map`, `clojure.core/reduce`, `defn`"
>   []
>   (+ 1 1))
>
> would create hyperlinks for map, reduce, defn and user-ns/user-fn forms.
>
> What style do you tend to use in such docstrings ?
> It would help us figure out whether to continue with the backticks or do 
> something else, like adding a configuration variable for this.
>
> Thanks,
> Chaitanya
>

-- 
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 docstring style

2016-09-21 Thread Eli Naeher 
On Wed, Sep 21, 2016, at 06:36 AM, naren...@helpshift.com wrote:
> Is there a convention to be followed for referring the parameters of
> a function in the docstring, e.g. for emacs lisp we upcase the
> parameter name?

Uppercase is (or was) also pretty standard style in Common Lisp. In
Clojure there does not seem to be a standard. Bozhidar Batsov's
Clojure Style guide is silent on this. Core Clojure docstrings do not
seem to identify parameters in docstrings with any special style. Some
people use Markdown-style backticks, but I'm not sure how widespread
that usage is.

-Eli

-- 
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: core.async top use cases

2016-09-21 Thread Beau Fabry 
You're probably right, I was confusing actors with agents.

On Tuesday, September 20, 2016 at 7:05:19 PM UTC-7, Matan Safriel wrote:
>
> Actually, I am not sure clojure implements the actor model, which I can 
> only construe as the Erlang actor model here. I am almost certain the core 
> language explicitly does not: http://clojure.org/about/state
>
> It can be shoehorned somehow (see okku) but I would probably not venture 
> saying clojure supports the actor model.
>
> Sent from my mobile
>
>  Original Message 
> From:Beau Fabry 
> Sent:Wed, 21 Sep 2016 03:47:29 +0300
> To:Clojure 
> Subject:Re: core.async top use cases
>
> I'm no expert on this, but the Actor model and the CSP model seem to be 
> two different ways to model a concurrent system. Clojure supports them 
> both. Personally I find the CSP model a simpler and easier to understand 
> one than Actors, and so pretty much default to it. You might find 
> non-clojure related sources comparing the tradeoffs between the two though?
>
>
> On Monday, September 19, 2016 at 11:50:53 PM UTC-7, Matan Safriel wrote:
>>
>> Thanks but I'm not entirely sure about this. I could use agents for side 
>> effects too, or at least I thought so. Care to further clarify?
>>
>>
>>  Original Message 
>> From:William la Forge 
>> Sent:Tue, 20 Sep 2016 02:37:20 +0300
>> To:Clojure 
>> Subject:Re: core.async top use cases
>>
>> The really nice thing to me is that async handles side-effects while 
>> agents do not.
>>
>> -- 
>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> clojure+u...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 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 a topic in the 
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/peJXvE0nBZs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+u...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Clojure docstring style

2016-09-21 Thread John Gabriele 
On Wednesday, September 21, 2016 at 9:54:23 AM UTC-4, Eli Naeher wrote:
>
> On Wed, Sep 21, 2016, at 06:36 AM, nare...@helpshift.com  
> wrote:
>
> Is there a convention to be followed for referring the parameters of a 
> function in the docstring, e.g. for emacs lisp we upcase the parameter name?
>
>
> Uppercase is (or was) also pretty standard style in Common Lisp. In 
> Clojure there does not seem to be a standard. Bozhidar Batsov's Clojure 
> Style guide is silent on this. Core Clojure docstrings do not seem to 
> identify parameters in docstrings with any special style. Some people use 
> Markdown-style backticks, but I'm not sure how widespread that usage is.
>
> -Eli
>


I believe the Style Guide only codifies established styles, and I don't 
think there is one for this.

I'd use a Pandoc-markdown definition list in your docstring. For example, 
for `(defn foo [num to from] ...)`:

~~~
`num`
  : the number of frobnicators

`to`
  : location it's going to

`from`
  : location it's coming from
~~~

I don't know if the markdown processor for codex supports this markup, but 
I think it's good and it's used by a few other markdowns besides Pandoc.

-- 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/d/optout.

Re: Clojure docstring style

2016-09-21 Thread John Gabriele 
On Wednesday, September 21, 2016 at 1:10:37 PM UTC-4, John Gabriele wrote:
>
> On Wednesday, September 21, 2016 at 9:54:23 AM UTC-4, Eli Naeher wrote:
>>
>> On Wed, Sep 21, 2016, at 06:36 AM, nare...@helpshift.com wrote:
>>
>> Is there a convention to be followed for referring the parameters of a 
>> function in the docstring, e.g. for emacs lisp we upcase the parameter name?
>>
>>
>> Uppercase is (or was) also pretty standard style in Common Lisp. In 
>> Clojure there does not seem to be a standard. Bozhidar Batsov's Clojure 
>> Style guide is silent on this. Core Clojure docstrings do not seem to 
>> identify parameters in docstrings with any special style. Some people use 
>> Markdown-style backticks, but I'm not sure how widespread that usage is.
>>
>> -Eli
>>
>
>
> I believe the Style Guide only codifies established styles, and I don't 
> think there is one for this.
>
> I'd use a Pandoc-markdown definition list in your docstring. For example, 
> for `(defn foo [num to from] ...)`:
>
> ~~~
> `num`
>   : the number of frobnicators
>
> `to`
>   : location it's going to
>
> `from`
>   : location it's coming from
> ~~~
>
> I don't know if the markdown processor for codex supports this markup, but 
> I think it's good and it's used by a few other markdowns besides Pandoc.
>
> -- John
>
>

Forgot to add that that's the markdown syntax for definition lists (the 
backticks are just to format the definition terms in monospace). And it 
degrades pretty nicely for any md processors that don't support that syntax.

-- 
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: [ANN] beta.clojars.org: new Clojars infrastructure that needs testing

2016-09-21 Thread John Gabriele 
On Tuesday, September 20, 2016 at 7:17:55 PM UTC-4, Daniel Compton wrote:
>
> Hi folks
>
> We’re moving the Clojars infrastructure from Linode to the very kind folks 
> at Rackspace. {snip}
>


Thanks, sounds like a lot of work. Any particular reasons for the switch?

-- 
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: [ANN] beta.clojars.org: new Clojars infrastructure that needs testing

2016-09-21 Thread Toby Crawley 
On Wed, Sep 21, 2016 at 2:05 PM, John Gabriele  wrote:
> On Tuesday, September 20, 2016 at 7:17:55 PM UTC-4, Daniel Compton wrote:
>>
>> Hi folks
>>
>> We’re moving the Clojars infrastructure from Linode to the very kind folks
>> at Rackspace. {snip}
>
>
> Thanks, sounds like a lot of work. Any particular reasons for the switch?
>

Three main reasons:

* we currently pay for Linode, and Rackspace is donating the server to us
* the majority of Clojars outages over the last year have been due to
DDoS attacks on Linode
* the existing server is a collection of configurations that were
edited in place over the years, so would be very difficult to recreate
in the event of a catastrophic failure. The new server is based off an
ansible setup[1] that makes it much easier to recreate (and rollback).

- Toby

[1]: https://github.com/clojars/clojars-server-config

-- 
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: [ANN] beta.clojars.org: new Clojars infrastructure that needs testing

2016-09-21 Thread Daniel Compton 
>
> Thanks, sounds like a lot of work. Any particular reasons for the switch?
>
> Yep it was :)

One more reason for moving is that we’re not comfortable with Linode’s
security.
-- 
—
Daniel

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

[ANN] Leiningen 2.7.1

2016-09-21 Thread Jean Niklas L'orange 
Hi fellow Clojurians,

I am happy to announce Leiningen 2.7.1! This release contains bugfixes
to managed dependencies, and an alternative installation option: Users
who use SDKMAN!  can now install Leiningen by issuing 
`sdk install leiningen`.

The list of changes since 2.7.0:

* Add support for SDKMAN! as installation alternative. (Jean Niklas
  L'orange)
* Improved text in some error messages. (Jean Niklas L'orange)
* Don't require `nil` for version in managed deps. (Chris Price)
* Fix a bug with snapshot dependencies for managed deps. (Chris Price)

For those who manually installed, `lein upgrade` will automatically
upgrade to the latest version. `lein downgrade 2.7.0` will bring it
back down to 2.7.0 if you run into any issues.

-- Jean Niklas

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

Clojure 1.9.0-alpha12 breaks REPL for counterclockwise

2016-09-21 Thread PK 
I am using 

  Counterclockwise (Clojure plugin for Eclipse) 0.35.0.STABLE001 
ccw.feature.feature.group Counterclockwise

in 
Eclipse
Version: Neon Release (4.6.0)
Build id: 20160613-1800

If I use Clojure 1.8.0 in my project, the REPL starts and connects just 
fine. If I switch to 1.9.0-alpha12, it keeps waiting for the REPL to be 
ready.

I am not sure if Counterclockwise needs to update anything or if there is 
an issue with the alpha release itself.

-- 
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 docstring style

2016-09-21 Thread Narendra Joshi 
Backticks are turned into links in cider-doc so I do this only for other
definitions. To refer to arguments in a batch, I use:

varname- description
varname2  - description2

I am not using anything for inline references to function parameters. But
it would have been great if there was a convention for this.

Best,
Narendra

On Wed, Sep 21, 2016 at 11:33 PM, John Gabriele  wrote:

> On Wednesday, September 21, 2016 at 1:10:37 PM UTC-4, John Gabriele wrote:
>>
>> On Wednesday, September 21, 2016 at 9:54:23 AM UTC-4, Eli Naeher wrote:
>>>
>>> On Wed, Sep 21, 2016, at 06:36 AM, nare...@helpshift.com wrote:
>>>
>>> Is there a convention to be followed for referring the parameters of a
>>> function in the docstring, e.g. for emacs lisp we upcase the parameter name?
>>>
>>>
>>> Uppercase is (or was) also pretty standard style in Common Lisp. In
>>> Clojure there does not seem to be a standard. Bozhidar Batsov's Clojure
>>> Style guide is silent on this. Core Clojure docstrings do not seem to
>>> identify parameters in docstrings with any special style. Some people use
>>> Markdown-style backticks, but I'm not sure how widespread that usage is.
>>>
>>> -Eli
>>>
>>
>>
>> I believe the Style Guide only codifies established styles, and I don't
>> think there is one for this.
>>
>> I'd use a Pandoc-markdown definition list in your docstring. For example,
>> for `(defn foo [num to from] ...)`:
>>
>> ~~~
>> `num`
>>   : the number of frobnicators
>>
>> `to`
>>   : location it's going to
>>
>> `from`
>>   : location it's coming from
>> ~~~
>>
>> I don't know if the markdown processor for codex supports this markup,
>> but I think it's good and it's used by a few other markdowns besides Pandoc.
>>
>> -- John
>>
>>
>
> Forgot to add that that's the markdown syntax for definition lists (the
> backticks are just to format the definition terms in monospace). And it
> degrades pretty nicely for any md processors that don't support that syntax.
>
> --
> 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/b9NOo0hOT9g/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 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.

ClojureScript Quick-Start node_repl java.lang.IllegalArgumentException: Value out of range for char: -1

2016-09-21 Thread Jiacai Liu 
http://stackoverflow.com/questions/39629743/clojurescript-quick-start-node-repl-java-lang-illegalargumentexception-value-ou

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