[ANN] nio.file 0.1.0 - A clojure wrapper for java.nio.file.*

[tobereplaced]

Announcing an initial release of a wrapper for java.nio.file's classes and 
methods.

It's hard to use java.nio.file.* from clojure, and this library makes that 
easier.

Instead of rehashing the documentation, I'll just point you at the 
repository:
https://github.com/ToBeReplaced/nio.file

In particular, take a look at why I created this library at:
https://github.com/ToBeReplaced/nio.file/blob/master/WHY.md

Cheers,
ToBeReplaced

-- 
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: Strange behavior with alts! and :default in core async

[Eric Normand]

>
> So, if a list whose first element is a vector is provided after a get or a 
> put in alt!, then that's treated as the binding form/code to be executed if 
> that succeeds, but if a non-list is provided, then that is treated as a 
> value to return if that action was taken (and that value is evaluated 
> before any operation happens)?
>
>
I'm not sure about the evaluation order, but I bet you can come up with an 
experiment to test it :)

Eric

 

> On Friday, August 15, 2014 8:35:05 AM UTC-4, Daniel Solano Gómez wrote:
>>
>> On Thu Aug 14 19:04 2014, dgrnbrg wrote: 
>> > You're all right--that was a cut & paste error. I meant that I see this 
>> > behavior with alt!!, not alts! 
>>
>> With alt!!, it should probably be something like: 
>>
>> (let [result (alt!! [[inner-chan e]] ([v] (if v 
>> :put-a-value 
>> :channel-closed)) 
>> :default :failed-to-put 
>> :priority true)] 
>>   (println result)) 
>>
>> I hope this helps. 
>>
>> Sincerely, 
>>
>> Daniel 
>>
>> > 
>> > On Thursday, August 14, 2014 3:31:45 PM UTC-4, Ghadi Shayban wrote: 
>> > > 
>> > > What Daniel said.  The call is incorrect, its args are alt-shaped, 
>> but it 
>> > > calls alt*s*. 
>> > > 
>> > > alt is the macro that is shaped like cond. 
>> > > alts is the function that takes a vector 
>> > > 
>> > > Both take splatted options at the end. 
>> > > 
>> > > Can never use single bang* except within go.* 
>> > > 
>> > > go => ! 
>> > > thread => !! 
>> > > 
>> > > Unfortunately if the two are confused, the exception will happen... 
>> > > probably elsewhere. 
>> > > 
>> > > On Thursday, August 14, 2014 2:46:22 PM UTC-4, Eric Normand wrote: 
>> > >> 
>> > >> Hi there, 
>> > >> 
>> > >> The :default option is for a *value* that should be returned if none 
>> of 
>> > >> the channels are available. The expression is evaluated *before* the 
>> > >> async/alts! call happens (just like normal parameters). 
>> > >> 
>> > >> I think you are misunderstanding alts!. It should be used like this 
>> > >> 
>> > >> (let [[val ch] (async/alts! [[inner-chan e]] :default :default)] 
>> > >>   (if (= :default val) 
>> > >> (println "inner-chan was not ready") 
>> > >> (if val 
>> > >>   (println "did the put to inner-chan") 
>> > >>   (println "inner-chan is closed" 
>> > >> 
>> > >> I hope that helps. Let me know if you have any more questions. 
>> > >> 
>> > >> Eric 
>> > >> 
>> > >> On Thursday, August 14, 2014 11:03:01 AM UTC-5, dgrnbrg wrote: 
>> > >>> 
>> > >>> When I use alts!, it seems that both the put and :default action 
>> run 
>> > >>> every time. I've included the code sample below: 
>> > >>> 
>> > >>> (let [inner-chan (async/chan (async/buffer 1000)) 
>> > >>>   mult (async/mult inner-chan) 
>> > >>>   (async/thread 
>> > >>> (while true 
>> > >>>   (let [e (.take linked-blocking-queue)] 
>> > >>> (async/alts! 
>> > >>>   [[inner-chan e]] (println "did the put") 
>> > >>>   :default (println "failed to put") 
>> > >>>   :priority true) 
>> > >>> 
>> > >>> 
>> > >>> Elsewhere in the code, I tap the mult before I start putting 
>> elements 
>> > >>> onto the linked-blocking-queue. For every element I put onto the 
>> LBQ, I see 
>> > >>> both messages: "did the put" and "failed to put". What is going on 
>> here? 
>> > >>> 
>> > >> 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "Clojure" group. 
>> > To post to this group, send email to clo...@googlegroups.com 
>> > Note that posts from new members are moderated - please be patient with 
>> your first post. 
>> > To unsubscribe from this group, send email to 
>> > clojure+u...@googlegroups.com 
>> > For more options, visit this group at 
>> > http://groups.google.com/group/clojure?hl=en 
>> > --- 
>> > You received this message because you are subscribed to the Google 
>> Groups "Clojure" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to clojure+u...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

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

Re: Strange behavior with alts! and :default in core async

[dgrnbrg]

So, if a list whose first element is a vector is provided after a get or a 
put in alt!, then that's treated as the binding form/code to be executed if 
that succeeds, but if a non-list is provided, then that is treated as a 
value to return if that action was taken (and that value is evaluated 
before any operation happens)?

On Friday, August 15, 2014 8:35:05 AM UTC-4, Daniel Solano Gómez wrote:
>
> On Thu Aug 14 19:04 2014, dgrnbrg wrote: 
> > You're all right--that was a cut & paste error. I meant that I see this 
> > behavior with alt!!, not alts! 
>
> With alt!!, it should probably be something like: 
>
> (let [result (alt!! [[inner-chan e]] ([v] (if v 
> :put-a-value 
> :channel-closed)) 
> :default :failed-to-put 
> :priority true)] 
>   (println result)) 
>
> I hope this helps. 
>
> Sincerely, 
>
> Daniel 
>
> > 
> > On Thursday, August 14, 2014 3:31:45 PM UTC-4, Ghadi Shayban wrote: 
> > > 
> > > What Daniel said.  The call is incorrect, its args are alt-shaped, but 
> it 
> > > calls alt*s*. 
> > > 
> > > alt is the macro that is shaped like cond. 
> > > alts is the function that takes a vector 
> > > 
> > > Both take splatted options at the end. 
> > > 
> > > Can never use single bang* except within go.* 
> > > 
> > > go => ! 
> > > thread => !! 
> > > 
> > > Unfortunately if the two are confused, the exception will happen... 
> > > probably elsewhere. 
> > > 
> > > On Thursday, August 14, 2014 2:46:22 PM UTC-4, Eric Normand wrote: 
> > >> 
> > >> Hi there, 
> > >> 
> > >> The :default option is for a *value* that should be returned if none 
> of 
> > >> the channels are available. The expression is evaluated *before* the 
> > >> async/alts! call happens (just like normal parameters). 
> > >> 
> > >> I think you are misunderstanding alts!. It should be used like this 
> > >> 
> > >> (let [[val ch] (async/alts! [[inner-chan e]] :default :default)] 
> > >>   (if (= :default val) 
> > >> (println "inner-chan was not ready") 
> > >> (if val 
> > >>   (println "did the put to inner-chan") 
> > >>   (println "inner-chan is closed" 
> > >> 
> > >> I hope that helps. Let me know if you have any more questions. 
> > >> 
> > >> Eric 
> > >> 
> > >> On Thursday, August 14, 2014 11:03:01 AM UTC-5, dgrnbrg wrote: 
> > >>> 
> > >>> When I use alts!, it seems that both the put and :default action run 
> > >>> every time. I've included the code sample below: 
> > >>> 
> > >>> (let [inner-chan (async/chan (async/buffer 1000)) 
> > >>>   mult (async/mult inner-chan) 
> > >>>   (async/thread 
> > >>> (while true 
> > >>>   (let [e (.take linked-blocking-queue)] 
> > >>> (async/alts! 
> > >>>   [[inner-chan e]] (println "did the put") 
> > >>>   :default (println "failed to put") 
> > >>>   :priority true) 
> > >>> 
> > >>> 
> > >>> Elsewhere in the code, I tap the mult before I start putting 
> elements 
> > >>> onto the linked-blocking-queue. For every element I put onto the 
> LBQ, I see 
> > >>> both messages: "did the put" and "failed to put". What is going on 
> here? 
> > >>> 
> > >> 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
>  
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: [ANN] Envvar 1.1.0 — a library for handling environment variables

[James Reeves]

On 14 August 2014 17:36, Constantine Vetoshev  wrote:

>
> 2. Loading env files in the REPL, and modifying the environment at runtime
> in general. Environ only handles loading variables when it loads itself,
> and has no provision for modifying them except by restarting the Clojure
> process.
>
> You can still modify the env var with alter-var-root. You don't need to
restart the REPL to change the value of a var, even a non-dynamic one.

In general though, you're correct. With Environ, I wanted to distinguish
between the execution environment and the application configuration. The
environment is static for the duration of the process, but the
configuration is user-defined and can be changed at will.

The idea is that you have a configuration that is *based* on the
environment, but not the same as the environment. For example:

(def system-config
  {:server {:port (Integer. (env :port "3000"))}})

By making it separate, the configuration can make use of nested maps and
non-string data types, like using an integer for the port number. You can
also set default options, and add functions to parse or manipulate
environment variables into more useful forms.

If you like, you could also make this configuration dynamic, or place it
into an atom.

Another advantage to this approach is that you can always reset it back to
the environment options if you mess anything up. If the env var is static
for the duration of the REPL session, you can rebuild the configuration
from the environment.

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

Re: [ANN] Envvar 1.1.0 — a library for handling environment variables

[James Reeves]

On 14 August 2014 17:31, Constantine Vetoshev  wrote:

> On Thursday, August 14, 2014 6:46:56 AM UTC-7, James Reeves wrote:
>>
>> You can do this with Environ. Leiningen checks for a profiles.clj in your
>> project directory, as well as then one in $HOME/.lein. If you add
>> profiles.clj to your .gitignore file, you can use it for local overrides
>> during development and testing.
>>
>
> Please update the Environ README to include this suggestion. The current
> text explicitly suggests setting variables in ~/.lein/profiles.clj, and I
> did not notice the reference to project-specific profiles.clj files buried
> deeply in Leiningen documentation.
>

Good idea. I've rewritten the README with a better example usage:

https://github.com/weavejester/environ/blob/master/README.md

I'd be interested to know what people think about it (with apologies for
derailing this thread - please email me directly).

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

Re: complex numbers in clojure

[Maik Schünemann]

Hi,

On Fri, Aug 15, 2014 at 7:00 PM, Reid McKenzie 
wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The best way to build a complex arithmetic package is probably to work
> atop `clojure.algo.generic`. I've done a pair of libraries (
> https://github.com/arrdem/imprecise, https://github.com/arrdem/meajure)
> based around extending algo.generic with custom datatypes and they've both
> worked out well
>
I'll look at these.
Building complex arithmetic atop algo.generic wouldn't bring the desired
unification, because for example core.matrix doesn't use algo.generic ...

> Clojure in general seems pretty loath to package "traditional" numerics
> facilities... note that we don't even have a built in square root operator
> and the common practice is to use java.lang.Math through interop so I
> wouldn't go holding your breath over adding irrational numbers to the
> language core. Also clojure.contrib is abandoned and deprecated in favor of
> "real" community maintained standalone libraries. The most likely place for
> an irrational type is probably either a user library like both of the above
> or possibly algo.generic itself.
>
Yeah, I meant 'as a contrib library' when I wrote clojure.contrib. Sorry
for the confusion.
As for the other part, let me elaborate a bit:
As it is true that clojure doesn't have much numeric functions in core
(like the square root example), it doesn't eschew numeric /types/ like
BigInt and Rationals, and you obviously can't pass  to java.lang.Math via
interop already.

Take rationals as example. I really like them and use them often in my
clojure code because they give you exact arithmetic basically for free
because they are part of the core language and you can use them anywhere
(in pure clojure). They even have a convenient literal syntax (but that is
not that inportant).

We had a discussion a while ago on the clojure-numerics mailing list on how
we could open core.matrix for arbitrary scalar types, like complex numbers
or symbolic expressions. I'll link this here as it could be of interest:
https://groups.google.com/forum/#!topic/numerical-clojure/Ze7lNjXJeQc/discussion
I think a reason that held the discussion back was missing standard types
to experiment with.

I don't argue that clojure should provide complex types as part of
clojure.core and can understand the reasons not to (while I think it would
be the same reason as including rationals in clojure.core) but as a clojure
contrib library that other clojure math libraries build ontop of (including
core.matrix and algo.generic).
The tricky part would then be figuring out how to nicely interop with the
other clojure types without incuring too much overhead to be used in
serious scientific computing (I think algo.generic uses multimethods for
dispatch, which is definitly too slow in highly stressed inner loops of
heavy matrix manipulations for example).

greetings
Maik

Reid
>
>
> On 08/15/2014 10:24 AM, Maik Schünemann wrote:
> > Hi,
> > is there a recommended way to do complex arithmetic in clojure ?
> > I am interested to see clojure going forward for scientific computing
> purposes.
> > There is already considerable effort going on with core.matrix,
> incanter, expresso etc.
> > But something thad is oddly lacking is support for complex numbers. For
> some areas, this is
> > a show stopper and it is very basic stuff in other languages and
> systems:
> > - common-lisp, python etc all have a standard complex type as part of
> the language/standard library
> > - see language support here
> http://en.wikipedia.org/wiki/Complex_data_type
> >
> > In Java, there are multiple incompatible complex number classes and I
> don't want that incompatibilities
> > in clojure libraries that provide complex number manipulation.
> >
> > In my opinion we should strive as a community for a standard complex
> number datatype, that is agreed on by clojure libraries,
> > and plays nicely with clojures other numeric types.
> > Ideally, this would be provided as part of clojure.contrib or even
> clojure itself - like rationals are!
> >
> >
> >
> >
> > --
> > 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.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBAgAGBQJT7jysAAoJELjHpJOzPfTlUqoP/3UGoIusWh

Re: Compilation failure to reject arguments matching formal parameters

[Andy Fingerhut]

I don't know how hard or easy it might be to implement a check like this in
a lint tool like Eastwood, but I've created a Github issue for it with the
idea, linking to this discussion, in case someone thinks of a way.

https://github.com/jonase/eastwood/issues/83

Andy


On Fri, Aug 15, 2014 at 10:12 AM, Reid McKenzie 
wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Comments inline
> On 08/15/2014 06:47 AM, Dave Tenny wrote:
> > This is getting old.   Any suggestions or plans to fix it?  Do I need to
> use some other common
> declaration style for functions?
> >
> > ; CIDER 0.5.0 (Clojure 1.6.0, nREPL 0.2.3)
> > user> (defn foo [& {:keys [bar]}] bar)
> > #'user/foo
> > user> (foo :baz 1)
> > nil
> >
> > In my opinion the compilation of the call to foo should have
> complained about :baz not matching a known parameter.
>
> At the implementation level, there is no "formal parameter" here. You've
> defined a variadic function, who's varargs are to be treated as a map
> key/value sequence, and the key ":bar" of which you wish to extract and
> bind to a local. "bar" here is _not_ a formal parameter of foo, it's
> simply a local destructured from the map converted varargs.
>
> > Failure to do this leads to lots of extra debugging because someone had
> a typo in a keyword name,
> > e.g. ":Name" instead of ":name" or :product instead of :project, or
> whatever.
> >
> > This is probably the leading cause of unexpected program operation in
> clojure for me.
>
> For a number of implementation reasons, this is not something that
> clojure/core is ever likely to provide better support for. Prismatic's
> Schema, core.typed and aggressive use of preconditions are the best
> tools available for you to guard against these errors. For exactly this
> reason I have personally adopted the practice of asserting what equates
> to a full typecheck of all arguments in function preconditions.
> Clojure/core doesn't do this in the name of "performance", but for user
> code it's easy enough to remove typechecks if the overhead becomes
> significant.
>
> Reid
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBAgAGBQJT7j+QAAoJELjHpJOzPfTl2pAP/3IbqqxDayp5Vz7I2l3D1dE5
> Eq4mFz3bjLrsR+th69xd6VWY4szTeeg09ub1NKUPQ2Uhm8EIMj1lFeZIHi9VmxNN
> zKASZ+l29ntDolChSLBM7JqQBWNYaLcPQQl4BTXi6BFy97TUFUq5IxKhIpvhgjQ+
> HV9Csg7rGhvz3sQU55W/K3YwoIgf1Kjd18Ewa3KytbKgKbGiwYDAqfqPtaQn0V+K
> 709lPTDe/WNMCjW8AcKsCqQAOhRObxfLwdL9iBRrdJNSaj17Vy0p+0xXA8RXuiGk
> tdEF6MADOmquFxZko3tvkaJfizA/2wRwIzbvqByuGqfgVQgsDdUEbsC04tB5pMqi
> 8H/O7HZ5DnExeOmL6TcSuBW+wWwqptBvqI1QuplZX2BOfbu1/whozUXU9Jq0SQLp
> V+bB2nM9qO+c6lxF9o8Fep3UaGxU4eKwwviJ6i3e5+uEvZ0N6p6vY4+wJO8ezJnN
> s4UOiEEMjtfBo4CyBZGxcNW3XzLoM6/5kAt25nKRQHDSChqsH5vjFbvrP6oq7S1d
> 4HEcGKHdA2D8wrE5b3XkLwsRjpNmXXn1h5TdE5RB3DYqSmU56Dwrt08aew7gC7We
> OvFQpIX9F/gW6dFJzVxQka4MV1IkYT0JiNypKFyHXz3l3PkFMYR//W0ehsSlAkjT
> +E0U1+KjplF9RPZ98myw
> =sqVb
> -END PGP SIGNATURE-
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Compilation failure to reject arguments matching formal parameters

[Reid McKenzie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Comments inline
On 08/15/2014 06:47 AM, Dave Tenny wrote:
> This is getting old.   Any suggestions or plans to fix it?  Do I need to use 
> some other common
declaration style for functions?
>
> ; CIDER 0.5.0 (Clojure 1.6.0, nREPL 0.2.3)
> user> (defn foo [& {:keys [bar]}] bar)
> #'user/foo
> user> (foo :baz 1)
> nil
>
> In my opinion the compilation of the call to foo should have
complained about :baz not matching a known parameter.

At the implementation level, there is no "formal parameter" here. You've
defined a variadic function, who's varargs are to be treated as a map
key/value sequence, and the key ":bar" of which you wish to extract and
bind to a local. "bar" here is _not_ a formal parameter of foo, it's
simply a local destructured from the map converted varargs.

> Failure to do this leads to lots of extra debugging because someone had a 
> typo in a keyword name,
> e.g. ":Name" instead of ":name" or :product instead of :project, or
whatever.
>
> This is probably the leading cause of unexpected program operation in
clojure for me.

For a number of implementation reasons, this is not something that
clojure/core is ever likely to provide better support for. Prismatic's
Schema, core.typed and aggressive use of preconditions are the best
tools available for you to guard against these errors. For exactly this
reason I have personally adopted the practice of asserting what equates
to a full typecheck of all arguments in function preconditions.
Clojure/core doesn't do this in the name of "performance", but for user
code it's easy enough to remove typechecks if the overhead becomes
significant.

Reid
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJT7j+QAAoJELjHpJOzPfTl2pAP/3IbqqxDayp5Vz7I2l3D1dE5
Eq4mFz3bjLrsR+th69xd6VWY4szTeeg09ub1NKUPQ2Uhm8EIMj1lFeZIHi9VmxNN
zKASZ+l29ntDolChSLBM7JqQBWNYaLcPQQl4BTXi6BFy97TUFUq5IxKhIpvhgjQ+
HV9Csg7rGhvz3sQU55W/K3YwoIgf1Kjd18Ewa3KytbKgKbGiwYDAqfqPtaQn0V+K
709lPTDe/WNMCjW8AcKsCqQAOhRObxfLwdL9iBRrdJNSaj17Vy0p+0xXA8RXuiGk
tdEF6MADOmquFxZko3tvkaJfizA/2wRwIzbvqByuGqfgVQgsDdUEbsC04tB5pMqi
8H/O7HZ5DnExeOmL6TcSuBW+wWwqptBvqI1QuplZX2BOfbu1/whozUXU9Jq0SQLp
V+bB2nM9qO+c6lxF9o8Fep3UaGxU4eKwwviJ6i3e5+uEvZ0N6p6vY4+wJO8ezJnN
s4UOiEEMjtfBo4CyBZGxcNW3XzLoM6/5kAt25nKRQHDSChqsH5vjFbvrP6oq7S1d
4HEcGKHdA2D8wrE5b3XkLwsRjpNmXXn1h5TdE5RB3DYqSmU56Dwrt08aew7gC7We
OvFQpIX9F/gW6dFJzVxQka4MV1IkYT0JiNypKFyHXz3l3PkFMYR//W0ehsSlAkjT
+E0U1+KjplF9RPZ98myw
=sqVb
-END PGP SIGNATURE-

-- 
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: complex numbers in clojure

[Reid McKenzie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The best way to build a complex arithmetic package is probably to work
atop `clojure.algo.generic`. I've done a pair of libraries
(https://github.com/arrdem/imprecise, https://github.com/arrdem/meajure)
based around extending algo.generic with custom datatypes and they've
both worked out well.

Clojure in general seems pretty loath to package "traditional" numerics
facilities... note that we don't even have a built in square root
operator and the common practice is to use java.lang.Math through
interop so I wouldn't go holding your breath over adding irrational
numbers to the language core. Also clojure.contrib is abandoned and
deprecated in favor of "real" community maintained standalone libraries.
The most likely place for an irrational type is probably either a user
library like both of the above or possibly algo.generic itself.

Reid

On 08/15/2014 10:24 AM, Maik Schünemann wrote:
> Hi, 
> is there a recommended way to do complex arithmetic in clojure ?
> I am interested to see clojure going forward for scientific computing
purposes.
> There is already considerable effort going on with core.matrix,
incanter, expresso etc.
> But something thad is oddly lacking is support for complex numbers.
For some areas, this is
> a show stopper and it is very basic stuff in other languages and systems:
> - common-lisp, python etc all have a standard complex type as part of
the language/standard library
> - see language support here http://en.wikipedia.org/wiki/Complex_data_type
>
> In Java, there are multiple incompatible complex number classes and I
don't want that incompatibilities
> in clojure libraries that provide complex number manipulation.
>
> In my opinion we should strive as a community for a standard complex
number datatype, that is agreed on by clojure libraries,
> and plays nicely with clojures other numeric types.
> Ideally, this would be provided as part of clojure.contrib or even
clojure itself - like rationals are!
>
>
>
>
> --
> 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.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJT7jysAAoJELjHpJOzPfTlUqoP/3UGoIusWhK+/0yzYvqCHsPK
QzU7criJGsNCfP8h0H7kClwJh7gIZHJlnBDMVHh7eP6VDPlnunTv7nYbFCPMYUys
SiM0dhW94EqEKUtl0gcIUoFfhDBeAPhgoi02/Lm0w51CcarhEnstVFVnUOLJPbsB
sTJuEC1ZigBtJz8pwBzGQnBYIRDaSONSxAEoV8aDmXinKBh+mPZKDRkE2emHsxDi
kSkMmDYicmc/2chFnjdbhSvJQajqoKKZvxuHAVboKKkWqowgHbHaB3ybsoZs/GT9
NYZEBVfEJWrgvQvgQsZNnuc2esd4f86JJp/QAyCvIzofsoNQbGBtPzbXBLkq7JYF
Me3JBwI1F9N221ZfTyRIXjRzc2P6cZdRcMAetsRgw2tSl94HVuHp2VGzaeqGlsR/
b7tsv06o2jTlNbaH+o1lisAQcs7pTJ1SZO1FZmCBoY1/b7f3MVa//hAK5pHa/tMH
+bAVZaAtAe+K3JjCokHwN7MX1gfVUNyIxD9kj/jlnrq+Xmvg8U7EA16wH+NDEI0j
jDXUkcTYfdM/dR7NV5Jvzwgd9A7Gm+2If6xN4Kx1ZviJk+XP3tYWx3FoCLungjaz
FujqwSChdDQ3Qw9k9uJ8zUR+e+9EsOsB86CmX/BmQCifcEpp1KlTUzFaR1XR3Gbg
VS5qG9H32gMMXpXSU02M
=cssb
-END PGP SIGNATURE-

-- 
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] Nomad 0.7.0 and Frodo 0.4.1 - configuration made simple

[James Henderson]

Hi all,

I've just released Nomad 0.7.0, a configuration management library that 
makes it simple to configure instances of your applications on multiple 
machines; and Frodo 0.4.1 - a web server that is configured using Nomad and 
uses Stuart Sierra's 'Reloaded' pattern. 

Github repos are at https://github.com/james-henderson/nomad 
and https://github.com/james-henderson/frodo respectively.

Thanks to Dylan Paris and Luke Snape for their PRs!

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

complex numbers in clojure

[Maik Schünemann]

Hi, 
is there a recommended way to do complex arithmetic in clojure ? 
I am interested to see clojure going forward for scientific computing 
purposes. 
There is already considerable effort going on with core.matrix, incanter, 
expresso etc.
But something thad is oddly lacking is support for complex numbers. For 
some areas, this is
a show stopper and it is very basic stuff in other languages and systems: 
- common-lisp, python etc all have a standard complex type as part of the 
language/standard library
- see language support here http://en.wikipedia.org/wiki/Complex_data_type

In Java, there are multiple incompatible complex number classes and I don't 
want that incompatibilities 
in clojure libraries that provide complex number manipulation. 

In my opinion we should strive as a community for a standard complex number 
datatype, that is agreed on by clojure libraries, 
and plays nicely with clojures other numeric types.
Ideally, this would be provided as part of clojure.contrib or even clojure 
itself - like rationals are!




-- 
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: Compilation failure to reject arguments matching formal parameters

[Jonah Benton]

Hi Dave,

Somewhat related: I've been looking at Prismatic's Schema [1] along with
ordinary pre and post conditions to apply stricter runtime controls on
suites of functions that take and return maps:

user=> (require '[schema.core :as sc])
nil

user=> (def FooIn "FooIn must have a string at :bar, a number at :baz, and
no other keys" { :bar sc/Str :baz sc/Num })
#'user/FooIn

user=> (def FooOut  "FooOut must have :baz and :qux, but can have any other
keys/values" { :baz sc/Num :qux sc/Str sc/Any sc/Any })
#'user/FooOut

user=> (defn foo
  #_=>   "Input map must match FooIn, returns FooOut"
  #_=>   [ {:keys [bar baz] :as m}]
  #_=>   {:pre [(sc/validate FooIn m)]
  #_=>:post [(sc/validate FooOut %)]}
  #_=>   (assoc m :qux "zoop"))
#'user/foo

user=> (doc foo)
-
user/foo
([{:keys [bar baz], :as m}])
  Input map must match FooIn, returns FooOut
nil

user=> (doc FooIn)
-
user/FooIn
  FooIn must have a string at :bar, a number at :baz, and no other keys
nil

user=> (doc FooOut)
-
user/FooOut
  FooOut must have :baz and :qux, but can have any other keys/values
nil

user=> (foo { :bar "1" :baz 2 })
{:qux "zoop", :baz 2, :bar "1"}

user=> (foo { :bar 1 :baz 2 })
ExceptionInfo Value does not match schema: {:bar (not (instance?
java.lang.String 1))}  schema.core/validate (core.clj:165)

user=> (foo { :bar "1" :baz 2 :beez 3 })
ExceptionInfo Value does not match schema: {:beez disallowed-key}
schema.core/validate (core.clj:165)

It's not compile time, requires multiple declarations, and imposes some
runtime cost, but in a repl workflow can provide guidance and immediate
feedback.

Prismatic has gone significantly further in the keyword functions space
with Plumbing and Graph. [2]

HTH,

Jonah

1. https://github.com/Prismatic/schema
2. https://github.com/Prismatic/plumbing



On Fri, Aug 15, 2014 at 7:47 AM, Dave Tenny  wrote:

> This is getting old.   Any suggestions or plans to fix it?  Do I need to
> use some other common declaration style for functions?
>
> ; CIDER 0.5.0 (Clojure 1.6.0, nREPL 0.2.3)
> user> (defn foo [& {:keys [bar]}] bar)
> #'user/foo
> user> (foo :baz 1)
> nil
>
> In my opinion the compilation of the call to foo should have complained
> about :baz not matching a known parameter.
>
> Failure to do this leads to lots of extra debugging because someone had a
> typo in a keyword name,
> e.g. ":Name" instead of ":name" or :product instead of :project, or
> whatever.
>
> This is probably the leading cause of unexpected program operation in
> clojure for me.
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Strange behavior with alts! and :default in core async

[Daniel Solano Gómez]

On Thu Aug 14 19:04 2014, dgrnbrg wrote:
> You're all right--that was a cut & paste error. I meant that I see this 
> behavior with alt!!, not alts!

With alt!!, it should probably be something like:

(let [result (alt!! [[inner-chan e]] ([v] (if v
:put-a-value
:channel-closed))
:default :failed-to-put
:priority true)]
  (println result))

I hope this helps.

Sincerely,

Daniel

> 
> On Thursday, August 14, 2014 3:31:45 PM UTC-4, Ghadi Shayban wrote:
> >
> > What Daniel said.  The call is incorrect, its args are alt-shaped, but it 
> > calls alt*s*.
> >
> > alt is the macro that is shaped like cond.
> > alts is the function that takes a vector
> >
> > Both take splatted options at the end.
> >
> > Can never use single bang* except within go.*
> >
> > go => !
> > thread => !!
> >
> > Unfortunately if the two are confused, the exception will happen... 
> > probably elsewhere.
> >
> > On Thursday, August 14, 2014 2:46:22 PM UTC-4, Eric Normand wrote:
> >>
> >> Hi there,
> >>
> >> The :default option is for a *value* that should be returned if none of 
> >> the channels are available. The expression is evaluated *before* the 
> >> async/alts! call happens (just like normal parameters).
> >>
> >> I think you are misunderstanding alts!. It should be used like this
> >>
> >> (let [[val ch] (async/alts! [[inner-chan e]] :default :default)]
> >>   (if (= :default val)
> >> (println "inner-chan was not ready")
> >> (if val
> >>   (println "did the put to inner-chan")
> >>   (println "inner-chan is closed"
> >>
> >> I hope that helps. Let me know if you have any more questions.
> >>
> >> Eric
> >>
> >> On Thursday, August 14, 2014 11:03:01 AM UTC-5, dgrnbrg wrote:
> >>>
> >>> When I use alts!, it seems that both the put and :default action run 
> >>> every time. I've included the code sample below:
> >>>
> >>> (let [inner-chan (async/chan (async/buffer 1000))
> >>>   mult (async/mult inner-chan)
> >>>   (async/thread
> >>> (while true
> >>>   (let [e (.take linked-blocking-queue)]
> >>> (async/alts!
> >>>   [[inner-chan e]] (println "did the put")
> >>>   :default (println "failed to put")
> >>>   :priority true)
> >>>
> >>>
> >>> Elsewhere in the code, I tap the mult before I start putting elements 
> >>> onto the linked-blocking-queue. For every element I put onto the LBQ, I 
> >>> see 
> >>> both messages: "did the put" and "failed to put". What is going on here?
> >>>
> >>
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Compilation failure to reject arguments matching formal parameters

[Dave Tenny]

This is getting old.   Any suggestions or plans to fix it?  Do I need to 
use some other common declaration style for functions?

; CIDER 0.5.0 (Clojure 1.6.0, nREPL 0.2.3)
user> (defn foo [& {:keys [bar]}] bar)
#'user/foo
user> (foo :baz 1)
nil

In my opinion the compilation of the call to foo should have complained 
about :baz not matching a known parameter.

Failure to do this leads to lots of extra debugging because someone had a 
typo in a keyword name,
e.g. ":Name" instead of ":name" or :product instead of :project, or 
whatever.

This is probably the leading cause of unexpected program operation in 
clojure for me.


-- 
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] Sente - Clojure(Script) + core.async + WebSockets/Ajax

[Henrik Eneroth]

Yes, thanks for Sente, Peter!

Will Sente eventually use/support Transit? :-)


On Friday, August 15, 2014 11:30:56 AM UTC+2, Peter Taoussanis wrote:
>
> You're very welcome Andrew, thanks for saying so!
>
> Cheers! :-)
>
> -- 
> *Peter Taoussanis*
> taoensso.com 
>  

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

Re: [ANN] Sente - Clojure(Script) + core.async + WebSockets/Ajax

[Peter Taoussanis]

You're very welcome Andrew, thanks for saying so!

Cheers! :-)

-- 
*Peter Taoussanis*
taoensso.com 

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

Re: [ANN] Sente - Clojure(Script) + core.async + WebSockets/Ajax

[keeds]

Peter,
Just wanted to say thanks for Sente. Just dropped it into an existing 
application. Going to make improving the UI alongside Om a breeze.

Thanks,
Andrew

On Wednesday, 26 February 2014 13:57:24 UTC, Peter Taoussanis wrote:
>
> Hi folks,
>
> Quick post to announce a new lib release: 
> https://github.com/ptaoussanis/sente
>
> From the README:
> *Sente* is small client+server library that makes it easy to build *reliable, 
> high-performance realtime web applications with Clojure*.
>
> * *Bidirectional a/sync comms* over both *WebSockets* and *Ajax* 
> (auto-selecting).
> * *Robust*: auto keep-alives, buffering, mode fallback, reconnects.
> * edn rocks. So *send edn, get edn*: no json here.
> * *Tiny, simple API*: make-channel-socket! and you're good to go.
> * Automatic, sensible support for users connected with *multiple clients* 
> and/or 
> devices simultaneously.
> * *Flexible model*: use it anywhere you'd use WebSockets or Ajax.
> * *Fully documented, with examples* (more forthcoming).
> * Small: *less than 600 lines of code* for the entire client+server 
> implementation.
> * *Supported servers*: currently only http-kit, but easily extended.
>
> ---
> Have been using something like this in production since a little after 
> core.async came out, and wouldn't want to go back. Note that I tweaked a 
> few things for the public release so there may be some rough edges 
> initially. 
>
> An example project's included (new as of today) and there's a Leiningen 
> alias configured to handle all the fiddly bits like getting the Cljx and 
> Cljs to compile: just download, `lein start-dev` at a terminal, and you're 
> good to go.
>
> Any questions/problems/whatever, you can reach me here or on GitHub.
>
> That's it! Happy hacking, cheers! :-)
> - *Peter Taoussanis*
> https://twitter.com/ptaoussanis
> https://www.taoensso.com/clojure-libraries
>

-- 
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: FYI: for Clojure people stuck with some Java, use DCEVM

[Sean Corfield]

On Wed, Aug 13, 2014 at 7:59 PM, Colin Fleming
 wrote:
> This looks really great. Due to limitations in Clojure's interop I'm forced
> to use much more Java than I'd like in Cursive itself

Could you elaborate on this Colin?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

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