Re: New Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Christopher Small]

Ditto; same boat as Mars0i.

I think the work Dragan has done is wonderful, and that he bears no 
responsibility to implement the core.matrix api himself. I'm also 
personally not interested in touching it without core.matrix support, 
because similarly for me, the performance/flexibility tradeoff isn't worth 
it. I wish I had time to work on this myself, since it would be an awesome 
contribution to the community, but I just don't have the time right now 
with everything else on my plate (including a 1 year old (figurative plate, 
obviously)). So I would highly encourage anyone interested in numerical 
computing and clojure looking for a project to sharpen their teeth on to 
put some time here. I think it would be a real asset to the community.

The one thing I *would* like to as from you, Dragan, is that you help us 
(well, Mike perhaps more than anyone) understand what you really don't like 
about the core.matrix architecture. In previous threads where we've 
discussed this, I felt like nothing concrete ever came up. You seem to not 
like that the fact that the API doesn't mirror BLAS, and I get your 
thinking here (even if I don't necessarily agree). Is that really the 
extent of it, or did I miss something?

It was mentioned that core.matrix has a BLAS-style API ns, but you still 
seem uninterested in this, since those functions delegate to a non-BLAS 
API. If I'm right, your concern is that this would lead to leaky 
abstractions, and affect performance, yes? I haven't looked at this API or 
it's implementation, but I have an idea that might satisfy everyone. What 
if it were possible to specify a core.matrix implementation directly 
through the BLAS API, with the rest of the "standard" core.matrix API based 
off these functions (by default; custom implementations could still be 
provided I'm sure...)? (Does this seem doable Mike?) Could this get us the 
best of both worlds and make core.matrix look more attractive to you Dragan 
(even if you don't feel personally interested in working on the 
Neanderthal/core.matrix implementation yourself)? Those who want and know 
the BLAS API can use it, without any overhead or leakiness, and everything 
would remain interoperable with other libraries. If this still wouldn't do 
it, what would? You clearly have very deep knowledge in this subject, and I 
think I speak for the Clojure numerical computing community (and 
core.matrix community in particular) in expressing that we'd greatly 
appreciate any insights you can give which would help make the ecosystem as 
a whole better.

With gratitude

Chris




On Tuesday, March 15, 2016 at 6:42:45 AM UTC-7, Bobby Bobble wrote:
>
> I'm in the same boat as Mars0i in that I've written a load of code with 
> core.matrix, which I'm happy with and which I will never have time to 
> rewrite for Neanderthal. If I had a new project that was 
> performance-critical I might bother to learn Neanderthal but for my 
> existing project, speed is secondary to maintainability now. If my boss 
> asked me to speed it up by 60x I'd love to be able to just switch to 
> implementation :Neanderthal with core.matrix! One keyword and boom.
>
> On Tuesday, March 15, 2016 at 3:54:03 AM UTC, Mars0i wrote:
>>
>> Dragan, I still support you doing whatever you want with your time, and 
>> I'm grateful that you've produced was I gather is a great library.  
>> Wonderful.  I don't feel that you have to implement the core.matrix 
>> api--but I really, really wish someone would produce a core.matrix 
>> interface to Neanderthal.  (I don't know how difficult that will be; I just 
>> know that I'm not the right person to do it.)  
>>
>> Some of the following has been said before, but some the points below 
>> seem to have been lost in the current discussion.
>>
>> I want to try Neanderthal, but I may never do so until someone produces a 
>> core.matrix mapping.  That needn't be a problem for you, Dragan, but my 
>> time is too precious to reimplement my existing code for a new api.  Even 
>> with new code, I'm always going to prefer core.matrix in the foreseeable 
>> future unless I have very special needs, because being able to swap out 
>> implementations is just too convenient for me.  core.matrix allows me to 
>> easily figure out which library is most efficient in my application.  I 
>> also want there to be a standard api for matrix operations, and at this 
>> point, core.matrix is the standard imo.  
>>
>> I came to Clojure from Common Lisp, where there are 5-10 matrix libraries 
>> with different APIs and different efficiency profiles, several seemingly 
>> best for different purposes (the Curse of Lisp mentioned by Mikera, applied 
>> to our case).  I am just very grateful that, instead of CL's mess of 
>> libraries and APIs, in the Clojure world Mikera and others decided to 
>> construct a standard API for matrix implementations.  What he's promoting 
>> is not marketing, nor religion--it's just convenience and coherence.  It's 
>> part of what 

decrypting binary text with azjure

[Clayton Haapala]

Fairly noob Clojure user, here.

I have a task to read two blocks of data from a file.

The blocks were created as follows:

Block 1: Plain UTF-8 text is blowfish-encrypted and then base64 encoded

Block 2: UTF-8 text is gzip-compressed, then blowfish-encrypted, and then 
base64 encoded

Goal is to reverse those processes and get the text back.

Using azjure/decrypt with the following map on Block 1 yields the UTF-8 
text just fine:
(decrypt txt
   {:type :blowfish
:mode :ecb
:pad :zero
:did :base64
:doe :str
:key ky})

The trouble is with Block 2. With a goal of feeding the decrypted results 
into a ztellman's byte-transform/decompress function, I used a similar map:
(decrypt txt
   {:type :blowfish
:mode :ecb
:pad :zero
:did :base64
:key ky})
but the result was truncated at 128 bytes, rather than the ~3500 expected. 
That looks like a bug, but may just be me not understanding proper usage.

I then took out the :did :base64 and used a byte-stream transform for the 
base64 decoding. That leaves me trying to get some output encoding out of 
decrypt that is acceptable to a byte-transform.
If it encodes to a string, byte-transform says it is not in :gzip format. 
Left to default encoding, byte-transform complains about unable to convert 
from Persistent Vector. I'm a bit at a loss, and tried various things to 
make it a byte-array. Kind of suspicious that the decrypt didn't work, 
though. The difference between Block 1 and Block 2 is the resulting text of 
decryption is UTF-8 in one case, and more binary in the other. Is that 
germain?

Clues or clue-bats welcome.

-- 
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: Neanderthal 0.5.0 - much easier installation and out of the box Mac OS X support

[Dragan Djuric]

Forgot to add the link: 
http://neanderthal.uncomplicate.org/articles/getting_started.html

On Tuesday, March 15, 2016 at 6:26:29 PM UTC+1, Dragan Djuric wrote:
>
> Most notable new features:
>
>- Streamlined dependencies: no longer need 2 dependencies in project 
>files. The dependency on uncomplicate/neanderthal is enough
>- Comes with Mac OS X build out of the box. No need even for external 
>ATLAS.
>- release and with-release moved from ClojureCL to uncomplicate/commons
>- Support for Fluokitten's fmap!, fmap, fold, foldmap, op...
>
>

-- 
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] ClojureCL - OpenCL 2.0 Clojure library (GPGPU and high performance parallel computing)

[Dragan Djuric]

A few minor changes so Neanderthal can work better. New version of 
ClojureCL 0.5.0 has been released to Clojars Clojars. 
http://clojurecl.uncomplicate.org

On Tuesday, March 15, 2016 at 1:32:34 AM UTC+1, Dragan Djuric wrote:
>
> New version of ClojureCL 0.4.0 has been released to Clojars Clojars. 
> http://clojurecl.uncomplicate.org
>
> On Wednesday, October 21, 2015 at 7:18:27 PM UTC+2, Dragan Djuric wrote:
>>
>> New version of ClojureCL 0.3.0 is out in Clojars. 
>> http://clojurecl.uncomplicate.org
>>
>> On Wednesday, June 17, 2015 at 4:59:02 PM UTC+2, Dragan Djuric wrote:
>>>
>>> Certainly, but that is not a priority, since I do not use (nor need) 
>>> OpenGL myself. I would be very interested to include contributions as soon 
>>> as I get them, and the foundations are already there (in JOCL), so it is 
>>> not that hard at might look at first glance - I just do not have time to be 
>>> sure that I do it properly now.
>>>
>>> On Wednesday, June 17, 2015 at 4:54:45 PM UTC+2, Bobby Bobble wrote:

 superb!

 are there any plans to include opengl context sharing for visualisation 
 ?

>>>

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

Neanderthal 0.5.0 - much easier installation and out of the box Mac OS X support

[Dragan Djuric]

Most notable new features:

   - Streamlined dependencies: no longer need 2 dependencies in project 
   files. The dependency on uncomplicate/neanderthal is enough
   - Comes with Mac OS X build out of the box. No need even for external 
   ATLAS.
   - release and with-release moved from ClojureCL to uncomplicate/commons
   - Support for Fluokitten's fmap!, fmap, fold, foldmap, op...

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

Jepsen testing Onyx

[Michael Drogalis]

Hi everyone,

We're happy to share that we've been busy Jepsen testing Onyx
over the last few months. We've written a blog post to share
the results with how we did it, what we found, and how we fixed
problematic areas:

Blog 
post: 
http://www.onyxplatform.org/jekyll/update/2016/03/15/Onyx-Straps-In-For-A-Jepsening.html

Thanks!

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

Re: New Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Bobby Bobble]

I'm in the same boat as Mars0i in that I've written a load of code with 
core.matrix, which I'm happy with and which I will never have time to 
rewrite for Neanderthal. If I had a new project that was 
performance-critical I might bother to learn Neanderthal but for my 
existing project, speed is secondary to maintainability now. If my boss 
asked me to speed it up by 60x I'd love to be able to just switch to 
implementation :Neanderthal with core.matrix! One keyword and boom.

On Tuesday, March 15, 2016 at 3:54:03 AM UTC, Mars0i wrote:
>
> Dragan, I still support you doing whatever you want with your time, and 
> I'm grateful that you've produced was I gather is a great library.  
> Wonderful.  I don't feel that you have to implement the core.matrix 
> api--but I really, really wish someone would produce a core.matrix 
> interface to Neanderthal.  (I don't know how difficult that will be; I just 
> know that I'm not the right person to do it.)  
>
> Some of the following has been said before, but some the points below seem 
> to have been lost in the current discussion.
>
> I want to try Neanderthal, but I may never do so until someone produces a 
> core.matrix mapping.  That needn't be a problem for you, Dragan, but my 
> time is too precious to reimplement my existing code for a new api.  Even 
> with new code, I'm always going to prefer core.matrix in the foreseeable 
> future unless I have very special needs, because being able to swap out 
> implementations is just too convenient for me.  core.matrix allows me to 
> easily figure out which library is most efficient in my application.  I 
> also want there to be a standard api for matrix operations, and at this 
> point, core.matrix is the standard imo.  
>
> I came to Clojure from Common Lisp, where there are 5-10 matrix libraries 
> with different APIs and different efficiency profiles, several seemingly 
> best for different purposes (the Curse of Lisp mentioned by Mikera, applied 
> to our case).  I am just very grateful that, instead of CL's mess of 
> libraries and APIs, in the Clojure world Mikera and others decided to 
> construct a standard API for matrix implementations.  What he's promoting 
> is not marketing, nor religion--it's just convenience and coherence.  It's 
> part of what Clojure is all about.
>
> Again, Dragan, I certainly don't think that you have to support 
> core.matrix, and I am still grateful for Neanderthal even no one ever gives 
> it a core.matrix front end.  From my point of view, everyone in the Clojure 
> community can be grateful for Neanderthal--even those of us who might never 
> end up using it.  It's a good resource for those who know in advance that 
> it will be best for their application, or for those with time to benchmark 
> their application with variant code.  I personally don't want to negotiate 
> different matrix APIs, however.  That's what's important to me.  
>
> I don't have any opinion about the relative benefits of the core.matrix 
> and Neanderthal APIs as such.  I just want to write to standard API.  If 
> the Neanderthal API became the standard, with multiple back ends, and was 
> overall better than core.matrix in that respect, I'd use it.  At this 
> point, going that route seems unlikely to be a good option, because 
> core.matrix already exists, with a lot of work having gone into it by a 
> reasonably large community.  For me the API seems just fine, and it's still 
> being enhanced.  (If it can be made better through conversation with you or 
> others familiar with Neanderthal, that's even better.)
>
> So ... I understand why Mikera keeps mentioning core.matrix whenever 
> Neanderthal is promoted here.  I support him doing that, because I want the 
> matrix libraries for Clojure to stay away from the curse of Common Lisp.  I 
> also understand why core.matrix isn't important for you, personally.  But 
> core.matrix is important for others besides Mikera.  It's not just a pet 
> project; it's a Good Thing, because well thought out common APIs for 
> libraries with similar functionality is a Good Thing.  I think you probably 
> agree, at least *in the abstract,* even if in this particular context you 
> don't think that core.matrix is the best API for all matrix applications.  
> (Maybe it's not.  Still ... a common API, that's gotta be a good thing.  
> And if someone ever does produce a core.matrix interface to Neanderthal, 
> the regular Neanderthal interface will still be available, presumably.  
> Great!  Best of both worlds.)
>
> I don't think this discussion has to get as heated as it does.  Perhaps 
> I'll get some of the heat, now, but it's not necessary, imo.
>

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

Re: changes in logging in 1.8?

[Nicola Mometto]

Unlikely, as the default behaviour hasn't changed.

Nicola

> On 15 Mar 2016, at 12:27, Stuart Sierra  wrote:
> 
> Not sure, but possible related to http://dev.clojure.org/jira/browse/CLJ-1208 
> "Namespace is not loaded on defrecord class init"
> –S
> 
> On Friday, March 11, 2016 at 12:20:44 AM UTC-5, Andy L wrote:
> Hi,
> 
> I noticed that after upgrade to Clojure  1.8.0 (from 1.7.0) a weird 
> occurrence of logging, even during uberjar generation which looks like this, 
> using lein 2.5.3:
> 
> $ lein uberjar
> Compiling core
> 2016-03-10 22:11:23.030:INFO::main: Logging initialized @964ms
> 
> I believe that actual log is pegged from here 
> https://github.com/eclipse/jetty.project/blob/master/jetty-util/src/main/java/org/eclipse/jetty/util/log/Log.java#L186
>  , which gniazdo depend on.
> 
> I spend some time trying to better understand the underlying cause but failed 
> to do so. My questions are:
>  1) why client code would be executed during uberjar generation (provided my 
> assumption is valid)?
>  2) what changed in 1.8 to cause that?
> 
> Thanks in advance,
> Andy
> 
> 
> = sources 
> $ cat project.clj src/core.clj
> (defproject tmp "0.1.0-SNAPSHOT"
>   :dependencies [[org.clojure/clojure "1.8.0"] [stylefruits/gniazdo "0.4.1"]]
>   :profiles {:uberjar {:aot :all}})
> (ns core
>   (:require [gniazdo.core :as ws]))
> 
> --
> 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.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: changes in logging in 1.8?

[Stuart Sierra]

Not sure, but possible related to 
http://dev.clojure.org/jira/browse/CLJ-1208 "Namespace is not loaded on 
defrecord class init"
–S

On Friday, March 11, 2016 at 12:20:44 AM UTC-5, Andy L wrote:
>
> Hi,
>
> I noticed that after upgrade to Clojure  1.8.0 (from 1.7.0) a weird 
> occurrence of logging, even during uberjar generation which looks like 
> this, using lein 2.5.3:
>
> $ lein uberjar 
> Compiling core
> 2016-03-10 22:11:23.030:INFO::main: Logging initialized @964ms
>
> I believe that actual log is pegged from here 
> https://github.com/eclipse/jetty.project/blob/master/jetty-util/src/main/java/org/eclipse/jetty/util/log/Log.java#L186
>  
> , which gniazdo depend on. 
>
> I spend some time trying to better understand the underlying cause but 
> failed to do so. My questions are:
>  1) why client code would be executed during uberjar generation (provided 
> my assumption is valid)?
>  2) what changed in 1.8 to cause that?
>
> Thanks in advance,
> Andy
>
>
> = sources 
> $ cat project.clj src/core.clj 
> (defproject tmp "0.1.0-SNAPSHOT"
>   :dependencies [[org.clojure/clojure "1.8.0"] [stylefruits/gniazdo 
> "0.4.1"]]
>   :profiles {:uberjar {:aot :all}})
> (ns core
>   (:require [gniazdo.core :as ws]))
>

-- 
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: Including debugging information for Clojure code

[Jason Gilman]

Thanks for the information. I'll check those out. For others trying to
solve the same problem I also found what looks like the relevant code
within Counter Clockwise
https://github.com/laurentpetit/ccw/blob/fb3a5467087cbe76d6b4fafe36ba7b97f5564228/ccw.core/src/java/ccw/debug/ClojureLineBreakpointAdapter.java#L61

On Mon, Mar 14, 2016 at 10:48 PM, Colin Fleming  wrote:

> Hi Jason,
>
> Things you might be interested in checking out:
>
> George Jahad's CDT: https://github.com/georgejahad/cdt. It's kind of old,
> but the JDI hasn't changed much recently.
>
> There's also Ritz: https://github.com/pallet/ritz. Again, I think it's a
> little bit-rotted these days but there's probably lots of good stuff there.
>
> You might also be interested in my talk at Clojure/West last year:
> https://www.youtube.com/watch?v=ql77RwhcCK0. I don't talk much about the
> implementation, but I do talk a lot about what makes Clojure difficult to
> debug over JDI.
>
> Cheers,
> Colin
>
> On 15 March 2016 at 13:01, Jason Gilman  wrote:
>
>> That's awesome that you got it working. If you could share any
>> information you found that would be really helpful for others in the future.
>>
>>
>> On Monday, March 14, 2016 at 7:43:26 PM UTC-4, James Norton wrote:
>>>
>>>
>>> Thanks for the reply. I was able to get it working when I looked at
>>> other classes. The first class I tried on the list resulted in the
>>> exception, but other classes (including those from my test project) worked.
>>> And thanks for the note about CIDER. I had looked at those sources briefly,
>>> but now I won't spend time on them.
>>>
>>> -James
>>>
>>> On Monday, March 14, 2016 at 2:26:11 AM UTC-4, Colin Fleming wrote:

 I don't have much time right now, but AFAIK Cursive is the only
 debugger using JDI - CIDER has a source manipulation debugger. I don't
 generally have to do anything special to debug, although I use an IntelliJ
 layer on top of JDI. I can try to check if it's doing anything with that
 flag. You can also check if your classes have debug info using Javap or a
 decompiler.

 I have to run now, but if you have further questions or you can't get
 it working let me know and I can dig further.

 On 14 March 2016 at 15:13, Jason Gilman  wrote:

> I'd recommend asking on slack. There's a cider channel where they hang
> out and may be able to answer your question. You can join here
> https://clojurians.slack.com/
>
> I'd really like to know this information for Proto REPL as well.
>
> --
> 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.
>>
>
> --
> 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/KkhgttZ1wDw/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