Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Dragan Djuric]

I understand the concept core.matrix tries to achieve, and would be extremely 
happy if I thought it would be possible, since I would be able to use it and 
spend time on some other stuff instead of writing C, JNI, OpenCL and such 
low-level code.
Thanks for the pointer to your neural networks experience and benchmark. I have 
taken a look at the thread you started about that issue, and it clearly shows 
what (in my opinion) is wrong is core.matrix: it is extremely easy to shoot 
yourself in the foot with it by (unintentionally) using the backing 
implementation in a wrong way. And, when you need to be specific an exploit the 
strength of the implementation, core.matrix gets in your way by making it more 
difficult in best cases and even impossible. Moreover, the optimizations that 
you manage to achieve with one implementation, often turn to be hogs with 
another, with "just one configuration change".
For example, if you look at the benchmark on the neanderthal's web site, you'd 
see that for 512x512 matrices, matrix multiplication is 5x faster with clatrix 
(jblas) than vectorz. Yet, in your implementation, you managed to turn that 5x 
speedup into a 1000x slowdown (in the 500x500 case) without even one change in 
code. Quite impressive on the core.matrix side ;)
I do not even claim that an unified api is not possible. I think that to some 
extent it is. I just doubt in core.matrix eligibility for THE api in numerical 
computing. For it makes easy things easy and hard things impossible.

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

ring - setting no-cache for everything?

[Colin Yates]

Hi all, is there a quick way to disable caching for everything or 
alternatively hash based on the contents of the resource. I am talking 
specifically about CSS and javascript issues served from the JAR's class 
path?

-- 
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: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?

[Serzh Nechyporchuk]

OOP always talks about object (mutable or immutable) in terms of
polymorphism, encapsulation and inheritance. Components library misses only
inheritance, which, obviously, the "killer feature" in OOP. So we could say
that Components library that take good ideas from OOP.

If you want call something on load of module, make call to this something
explicit, ie: wrap it into a function and run on your system component
start explicitly. This approach will give more flexibility and control on
your state.

2015-06-18 13:08 GMT+03:00 Xiangtao Zhou :

> oop means object oriented programming, which doesn't mean mutable. record
> is oop and immutable. when you use java, you can asume everthing is
> immutable.
>
> if i use dynamic to implement the object, i can test it with "binding";
> others i can test with "with-redefs". so it works, except side effects.
>
> On Thursday, June 18, 2015 at 5:21:46 PM UTC+8, Atamert Ölçgen wrote:
>>
>> How is stuartsierra/component OOP when it is building an immutable object
>> graph? (Contrast that to Guava etc.)
>>
>> On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou  wrote:
>>
>>> hi guys,
>>>
>>> Constructing simple clojure project is trival, just make functions. if
>>> the project grows large, with more datasources, message queue, and other
>>> storages, dependencies problem is on the table.
>>>
>>> One solution is stuartsierra/component,  using system to configure
>>> dependencies graph, make component and dependencies resolution separate.
>>>
>>> If we make namespace must run with code block that init the namespace,
>>> like the "start" method in component, is this a good way to solve the
>>> dependencies?
>>>
>>
>> You can do that. But it's not a really good idea to have top-level
>> side-effectful code within namespaces. How are you going to test that ns?
>> How will you do (stop)?
>>
>> Namespaces should only define things.
>>
>>
>>>
>>> because when the namespace is required the first time, the init block
>>> worked once.
>>>
>>> any suggestion is appreciated.
>>>
>>>
>>> - Joe
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> Kind Regards,
>> Atamert Ölçgen
>>
>> ◻◼◻
>> ◻◻◼
>> ◼◼◼
>>
>> www.muhuk.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.
>



-- 
Best regards,
Serhii Nechyporchuk

-- 
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: ring - setting no-cache for everything?

[James Reeves]

Ring doesn't set any caching headers unless you add in middleware to do so.

The most common middleware is wrap-not-modified, which returns a 304
response if the etag or last-modified dates indicate the resource hasn't
been modified. For resources in jar files, the last-modified date is set to
the modification date of the containing jar.

You could add some middleware to force the browser not to cache resources
via the cache-control header (see here
),
or if this is just for development, then Chrome at least has a checkbox in
the developer tools for disabling caching.

- James

On 19 June 2015 at 10:00, Colin Yates  wrote:

> Hi all, is there a quick way to disable caching for everything or
> alternatively hash based on the contents of the resource. I am talking
> specifically about CSS and javascript issues served from the JAR's class
> path?
>
> --
> 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: ring - setting no-cache for everything?

[Colin Yates]

Thanks James.

> On 19 Jun 2015, at 10:53, James Reeves  wrote:
> 
> Ring doesn't set any caching headers unless you add in middleware to do so.
> 
> The most common middleware is wrap-not-modified, which returns a 304 response 
> if the etag or last-modified dates indicate the resource hasn't been 
> modified. For resources in jar files, the last-modified date is set to the 
> modification date of the containing jar.
> 
> You could add some middleware to force the browser not to cache resources via 
> the cache-control header (see here 
> ),
>  or if this is just for development, then Chrome at least has a checkbox in 
> the developer tools for disabling caching.
> 
> - James
> 
> On 19 June 2015 at 10:00, Colin Yates  > wrote:
> Hi all, is there a quick way to disable caching for everything or 
> alternatively hash based on the contents of the resource. I am talking 
> specifically about CSS and javascript issues served from the JAR's class path?
> 
> -- 
> 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 
> .

-- 
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: ring - setting no-cache for everything?

[Colin Yates]

It is worth mentioning for others that if you are using 
ring.middleware.defaults/wrap-defaults then this middleware is already in play.

> On 19 Jun 2015, at 10:53, James Reeves  wrote:
> 
> Ring doesn't set any caching headers unless you add in middleware to do so.
> 
> The most common middleware is wrap-not-modified, which returns a 304 response 
> if the etag or last-modified dates indicate the resource hasn't been 
> modified. For resources in jar files, the last-modified date is set to the 
> modification date of the containing jar.
> 
> You could add some middleware to force the browser not to cache resources via 
> the cache-control header (see here 
> ),
>  or if this is just for development, then Chrome at least has a checkbox in 
> the developer tools for disabling caching.
> 
> - James
> 
> On 19 June 2015 at 10:00, Colin Yates  > wrote:
> Hi all, is there a quick way to disable caching for everything or 
> alternatively hash based on the contents of the resource. I am talking 
> specifically about CSS and javascript issues served from the JAR's class path?
> 
> -- 
> 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 
> .

-- 
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: ring - setting no-cache for everything?

[Fluid Dynamics]

On Friday, June 19, 2015 at 5:54:03 AM UTC-4, James Reeves wrote:
>
> Ring doesn't set any caching headers unless you add in middleware to do so.
>
> The most common middleware is wrap-not-modified, which returns a 304 
> response if the etag or last-modified dates indicate the resource hasn't 
> been modified. For resources in jar files, the last-modified date is set to 
> the modification date of the containing jar.
>
> You could add some middleware to force the browser not to cache resources 
> via the cache-control header (see here 
> ),
>  
> or if this is just for development, then Chrome at least has a checkbox in 
> the developer tools for disabling caching.
>

Cache-control is evil. Users concerned with seeing the most up-to-date 
information know to hit reload (and probably do anyway, just to be sure), 
and there's also the option of AJAX polling for that (or whatever precisely 
sites like Facebook do).

Meanwhile, cache-control has all of the following very annoying 
consequences for users (at lease one of which hits the web site too):

* Every page load and navigation step is painfully slow because of all of 
the various reloading assets and such, if the user is on any typical 
consumer "broadband" connection rather than real broadband.
* In particular, normally instant back-arrow and forward-arrow navigation 
are annoyingly slow.
* If the user's connection is noticeably flaky, then the page is likely to 
only partly load, and using back-arrow forward-arrow to try to force the 
missing elements to load also loses the elements that were already loaded, 
instead of incrementally loading more and more of the page until eventually 
it's all there.
* It costs both the user and the web site bandwidth. Important to you, and 
important to at least your mobile users, who probably have metered *and* 
tightly capped data plans.
* In Firefox, at least, cache-control breaks image right-click save-as, 
because right-click save-as just copies the cached image normally, but if 
it's not cached instead tries to download it again. If that's combined with 
typical hotlinking blocking, the result tends to be errors or corrupt 
jpegs. To see this effect go to a Photobucket album, which serves either 
the image itself or a webpage with the image in it depending on referer and 
which also uses cache-control. If you right-click save-as the image you'll 
get a corrupt jpeg file that, when opened in Notepad, is actually full of 
HTML. Of course, blocking hotlinking and playing "clever" redirection 
tricks with referer is evil too, but cache-control compounds that evil a 
thousandfold. (The only correct use of referer is for log analysis to 
discover how your users navigate around your site. Using it to discriminate 
against users based on where they were linked in from is evil and wrong.)

Upshot: Use Ajax push/pull if you really want users to always see 
up-to-date information, and otherwise let them use "refresh" as 
appropriate. And don't get cute serving different content for the same URI 
depending on referer; that's just wrong. :)

-- 
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: ring - setting no-cache for everything?

[Colin Yates]

None of this is applicable for closed intranet sites, and cache-control solves 
the very annoying situation where users are running an old version of CSS or 
Javascript.

I agree with these points for public facing ‘web sites’. For ‘enterprise SPAs’ 
there is usually a different context and set of requirements/restrictions to 
deal with.

> On 19 Jun 2015, at 13:56, Fluid Dynamics  wrote:
> 
> On Friday, June 19, 2015 at 5:54:03 AM UTC-4, James Reeves wrote:
> Ring doesn't set any caching headers unless you add in middleware to do so.
> 
> The most common middleware is wrap-not-modified, which returns a 304 response 
> if the etag or last-modified dates indicate the resource hasn't been 
> modified. For resources in jar files, the last-modified date is set to the 
> modification date of the containing jar.
> 
> You could add some middleware to force the browser not to cache resources via 
> the cache-control header (see here 
> ),
>  or if this is just for development, then Chrome at least has a checkbox in 
> the developer tools for disabling caching.
> 
> Cache-control is evil. Users concerned with seeing the most up-to-date 
> information know to hit reload (and probably do anyway, just to be sure), and 
> there's also the option of AJAX polling for that (or whatever precisely sites 
> like Facebook do).
> 
> Meanwhile, cache-control has all of the following very annoying consequences 
> for users (at lease one of which hits the web site too):
> 
> * Every page load and navigation step is painfully slow because of all of the 
> various reloading assets and such, if the user is on any typical consumer 
> "broadband" connection rather than real broadband.
> * In particular, normally instant back-arrow and forward-arrow navigation are 
> annoyingly slow.
> * If the user's connection is noticeably flaky, then the page is likely to 
> only partly load, and using back-arrow forward-arrow to try to force the 
> missing elements to load also loses the elements that were already loaded, 
> instead of incrementally loading more and more of the page until eventually 
> it's all there.
> * It costs both the user and the web site bandwidth. Important to you, and 
> important to at least your mobile users, who probably have metered *and* 
> tightly capped data plans.
> * In Firefox, at least, cache-control breaks image right-click save-as, 
> because right-click save-as just copies the cached image normally, but if 
> it's not cached instead tries to download it again. If that's combined with 
> typical hotlinking blocking, the result tends to be errors or corrupt jpegs. 
> To see this effect go to a Photobucket album, which serves either the image 
> itself or a webpage with the image in it depending on referer and which also 
> uses cache-control. If you right-click save-as the image you'll get a corrupt 
> jpeg file that, when opened in Notepad, is actually full of HTML. Of course, 
> blocking hotlinking and playing "clever" redirection tricks with referer is 
> evil too, but cache-control compounds that evil a thousandfold. (The only 
> correct use of referer is for log analysis to discover how your users 
> navigate around your site. Using it to discriminate against users based on 
> where they were linked in from is evil and wrong.)
> 
> Upshot: Use Ajax push/pull if you really want users to always see up-to-date 
> information, and otherwise let them use "refresh" as appropriate. And don't 
> get cute serving different content for the same URI depending on referer; 
> that's just wrong. :)
> 
> -- 
> 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 Goo

1.7.0b2, lein, cljc and tests

[Colin Yates]

First - cljc is (for me) a huge upgrade over cljx, which was a great 
solution. Not having to run lein clix auto every time I do a clean is far 
more useful than I realised.

The problem I am having is that cljc test files don't seem to be picked up. 
I have test/clj and test/cljc, my test-paths in project.clj are ["test/clj" 
"test/cljc"] but 'lein test', and 'lein test-refresh' don't see them. If I 
do a 'lein test some-namespace-in-cljc' then the tests are run.

Has anyone else experienced this and if so, any pointers on moving forward?

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: 1.7.0b2, lein, cljc and tests

[Gary Trakhman]

Leiningen needs to support cljc, right now only the compiler does, and
clojure-maven-plugin since a few days ago.

https://github.com/technomancy/leiningen/issues/1827

On Fri, Jun 19, 2015 at 9:41 AM Colin Yates  wrote:

> First - cljc is (for me) a huge upgrade over cljx, which was a great
> solution. Not having to run lein clix auto every time I do a clean is far
> more useful than I realised.
>
> The problem I am having is that cljc test files don't seem to be picked
> up. I have test/clj and test/cljc, my test-paths in project.clj are
> ["test/clj" "test/cljc"] but 'lein test', and 'lein test-refresh' don't see
> them. If I do a 'lein test some-namespace-in-cljc' then the tests are run.
>
> Has anyone else experienced this and if so, any pointers on moving forward?
>
> 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.
>

-- 
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: 1.7.0b2, lein, cljc and tests

[Colin Yates]

Hi Gary, lein does appear to support it as lein test some-test-in-cljc works, 
just not if I do ‘lein test’. Is this expected? I am running 2.5.1

> On 19 Jun 2015, at 14:46, Gary Trakhman  wrote:
> 
> Leiningen needs to support cljc, right now only the compiler does, and 
> clojure-maven-plugin since a few days ago.
> 
> https://github.com/technomancy/leiningen/issues/1827 
> 
> 
> On Fri, Jun 19, 2015 at 9:41 AM Colin Yates  > wrote:
> First - cljc is (for me) a huge upgrade over cljx, which was a great 
> solution. Not having to run lein clix auto every time I do a clean is far 
> more useful than I realised.
> 
> The problem I am having is that cljc test files don't seem to be picked up. I 
> have test/clj and test/cljc, my test-paths in project.clj are ["test/clj" 
> "test/cljc"] but 'lein test', and 'lein test-refresh' don't see them. If I do 
> a 'lein test some-namespace-in-cljc' then the tests are run.
> 
> Has anyone else experienced this and if so, any pointers on moving forward?
> 
> 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 
> .
> 
> -- 
> 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: 1.7.0b2, lein, cljc and tests

[Luc Préfontaine]

I encountered a couple of glitches around cljc support through figwheel.
Updating a .cljc file was triggering a recompilation in some circumstances.

I did not investigate further, it kind of disappeared from my horizon but I do 
not why exactly.
Can't relate this to a change in my project yet.

Luc P.


> Hi Gary, lein does appear to support it as lein test some-test-in-cljc works, 
> just not if I do ‘lein test’. Is this expected? I am running 2.5.1
> 
> > On 19 Jun 2015, at 14:46, Gary Trakhman  wrote:
> > 
> > Leiningen needs to support cljc, right now only the compiler does, and 
> > clojure-maven-plugin since a few days ago.
> > 
> > https://github.com/technomancy/leiningen/issues/1827 
> > 
> > 
> > On Fri, Jun 19, 2015 at 9:41 AM Colin Yates  > > wrote:
> > First - cljc is (for me) a huge upgrade over cljx, which was a great 
> > solution. Not having to run lein clix auto every time I do a clean is far 
> > more useful than I realised.
> > 
> > The problem I am having is that cljc test files don't seem to be picked up. 
> > I have test/clj and test/cljc, my test-paths in project.clj are ["test/clj" 
> > "test/cljc"] but 'lein test', and 'lein test-refresh' don't see them. If I 
> > do a 'lein test some-namespace-in-cljc' then the tests are run.
> > 
> > Has anyone else experienced this and if so, any pointers on moving forward?
> > 
> > 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 
> > .
> > 
> > -- 
> > 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.
> 
--
Luc Préfontaine sent by ibisMail!

-- 
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: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?

[Leon Grapenthin]

All objects can as well be implemented with message passing, a functional 
technique. However, if one would do it with stuartsierra/component, it 
would be so trivial that you could hardly call the lib object "orientated".


On Friday, June 19, 2015 at 11:14:04 AM UTC+2, Serzh Nechyporchuk wrote:
>
> OOP always talks about object (mutable or immutable) in terms of 
> polymorphism, encapsulation and inheritance. Components library misses only 
> inheritance, which, obviously, the "killer feature" in OOP. So we could say 
> that Components library that take good ideas from OOP. 
>
> If you want call something on load of module, make call to this something 
> explicit, ie: wrap it into a function and run on your system component 
> start explicitly. This approach will give more flexibility and control on 
> your state.
>
> 2015-06-18 13:08 GMT+03:00 Xiangtao Zhou >:
>
>> oop means object oriented programming, which doesn't mean mutable. record 
>> is oop and immutable. when you use java, you can asume everthing is 
>> immutable. 
>>
>> if i use dynamic to implement the object, i can test it with "binding"; 
>> others i can test with "with-redefs". so it works, except side effects.
>>
>> On Thursday, June 18, 2015 at 5:21:46 PM UTC+8, Atamert Ölçgen wrote:
>>>
>>> How is stuartsierra/component OOP when it is building an immutable 
>>> object graph? (Contrast that to Guava etc.)
>>>
>>> On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou  wrote:
>>>
 hi guys,

 Constructing simple clojure project is trival, just make functions. if 
 the project grows large, with more datasources, message queue, and other 
 storages, dependencies problem is on the table. 

 One solution is stuartsierra/component,  using system to configure 
 dependencies graph, make component and dependencies resolution separate.

 If we make namespace must run with code block that init the namespace, 
 like the "start" method in component, is this a good way to solve the 
 dependencies?

>>>
>>> You can do that. But it's not a really good idea to have top-level 
>>> side-effectful code within namespaces. How are you going to test that ns? 
>>> How will you do (stop)?
>>>
>>> Namespaces should only define things.
>>>  
>>>

 because when the namespace is required the first time, the init block 
 worked once.

 any suggestion is appreciated.


 - Joe

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

>>>
>>>
>>>
>>> -- 
>>> Kind Regards,
>>> Atamert Ölçgen
>>>
>>> ◻◼◻
>>> ◻◻◼
>>> ◼◼◼
>>>
>>> www.muhuk.com
>>>  
>>  -- 
>> 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.
>>
>
>
>
> -- 
> Best regards,
> Serhii Nechyporchuk
>  

-- 
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] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Mars0i]

Neanderthal seems very cool.  You've clearly put a *lot* of work into 
this.  I for one am thankful that you've made available what is a very nice 
tool, as far as I can see.

I don't think there's necessarily a conflict concerning core.matrix, 
though.  You may not want to write a core.matrix wrapper for Neanderthal.  
There's no reason that you must.  Someone else might want to do that; maybe 
I would be able to help with that project.  In that case, those who wanted 
to use Neanderthal via core.matrix could do so, knowing that they lose out 
on any potential advantages of writing directly to Neanderthal, and those 
who want to use Neanderthal in its original form can still do so.  I don't 
see a conflict.

In my case, I have existing code that uses core.matrix.  I wrote to 
core.matrix in part because I didn't want to have to worry about which 
implementation to write to.  I would love to try my code on Neanderthal, 
but I'm not willing to port it.  That's my problem, not yours, though.

For future projects, I could write to Neanderthal, but I also have to 
consider the possibility that there might be situations in which another 
implementation would be better for my code.  Neanderthal looks great, but 
is it always fastest for every application that uses non-tiny matrices?  
Maybe it would be for anything I would write.  I'd rather not have to 
figure that out.  I'm granting that there could be advantages to using 
Neanderthal in its native form rather than via core.matrix, but for me, 
personally, it would be simpler to use it via core.matrix if that was an 
option.  It's not your responsibility to enable that unless you wanted to 
do so, though.  What you've done is already more than enough, Dragan.


On Friday, June 19, 2015 at 3:57:32 AM UTC-5, Dragan Djuric wrote:
>
> I understand the concept core.matrix tries to achieve, and would be 
> extremely happy if I thought it would be possible, since I would be able to 
> use it and spend time on some other stuff instead of writing C, JNI, OpenCL 
> and such low-level code. 
> Thanks for the pointer to your neural networks experience and benchmark. I 
> have taken a look at the thread you started about that issue, and it 
> clearly shows what (in my opinion) is wrong is core.matrix: it is extremely 
> easy to shoot yourself in the foot with it by (unintentionally) using the 
> backing implementation in a wrong way. And, when you need to be specific an 
> exploit the strength of the implementation, core.matrix gets in your way by 
> making it more difficult in best cases and even impossible. Moreover, the 
> optimizations that you manage to achieve with one implementation, often 
> turn to be hogs with another, with "just one configuration change". 
> For example, if you look at the benchmark on the neanderthal's web site, 
> you'd see that for 512x512 matrices, matrix multiplication is 5x faster 
> with clatrix (jblas) than vectorz. Yet, in your implementation, you managed 
> to turn that 5x speedup into a 1000x slowdown (in the 500x500 case) without 
> even one change in code. Quite impressive on the core.matrix side ;) 
> I do not even claim that an unified api is not possible. I think that to 
> some extent it is. I just doubt in core.matrix eligibility for THE api in 
> numerical computing. For it makes easy things easy and hard things 
> impossible.

-- 
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: 1.7.0b2, lein, cljc and tests

[Alex Miller]

Probably this needs updating

https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137

On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote:
>
> First - cljc is (for me) a huge upgrade over cljx, which was a great 
> solution. Not having to run lein clix auto every time I do a clean is far 
> more useful than I realised.
>
> The problem I am having is that cljc test files don't seem to be picked 
> up. I have test/clj and test/cljc, my test-paths in project.clj are 
> ["test/clj" "test/cljc"] but 'lein test', and 'lein test-refresh' don't see 
> them. If I do a 'lein test some-namespace-in-cljc' then the tests are run.
>
> Has anyone else experienced this and if so, any pointers on moving forward?
>
> 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: ring - setting no-cache for everything?

[Thomas Heller]

>
>
> Cache-control is evil. Users concerned with seeing the most up-to-date 
> information know to hit reload (and probably do anyway, just to be sure), 
> and there's also the option of AJAX polling for that (or whatever precisely 
> sites like Facebook do).
>
>  
I don't even  a wrong Cache-Control will cause problems but 
Cache-Control is probably one of the most important headers to set for your 
webapp. It is also one of the harder ones to get right but the benefits are 
significant.

As for preventing users from seeing stale CSS/Javascript I'd recommend 
serving files with a unique name which changes with each new release. This 
way old HTML refers to old CSS and new HTML to new CSS, plus you can add 
"Cache-Control: public, max-age=31536000" to the static files which allows 
the browser to actually SKIP checking if a resource was modified (ie. huge 
speed gains, no if-modified-since->not modified round trip).

Disabling cache is usually the least desirable option and if you care about 
performance at all you should think twice before doing so (yes, even for 
intranet sites). 

/thomas

-- 
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: 1.7.0b2, lein, cljc and tests

[Alex Miller]

Filed

https://github.com/technomancy/leiningen/pull/1920/

On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote:
>
> Probably this needs updating
>
>
> https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137
>
> On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote:
>>
>> First - cljc is (for me) a huge upgrade over cljx, which was a great 
>> solution. Not having to run lein clix auto every time I do a clean is far 
>> more useful than I realised.
>>
>> The problem I am having is that cljc test files don't seem to be picked 
>> up. I have test/clj and test/cljc, my test-paths in project.clj are 
>> ["test/clj" "test/cljc"] but 'lein test', and 'lein test-refresh' don't see 
>> them. If I do a 'lein test some-namespace-in-cljc' then the tests are run.
>>
>> Has anyone else experienced this and if so, any pointers on moving 
>> forward?
>>
>> 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: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Dragan Djuric]

That is what I think from the start of the discussion, and I agree with you.

The only thing is that i am almost certain that the performance gain will
be very easy to reverse, just like in the case of Clatrix.

Because it is built on top of blas and atlas, which is the the de facto
standard and a state of the art implementation, I am also pretty certain
that it will be the fastest library on the CPU even for small matrices. The
only exception would be the very teeny ones like 3x2 or something (see the
benchmark), and even then Neanderthal is only 2x slower than vectorz
despite the FFI dance.

If I was you, it is not the speed that I would be concerned about regarding
Neanderthal. In my opinion, currently there are only two major drawbacks to
using Neanderthal:

1. It is a new and unproven library. The author may win the lottery, decide
to retire on the tropical island and abandon all projects. This is less of
a trouble if it becomes popular, since someone else could just take over
the development.

2. You have to install a native library (atlas). This issue is not even
that big, since i (or you, since the build is automatic) could ship atlas
statically compiled like jblas does, but then the top performance would
depend on the user having similar cpu as I (but even that for the last 10
or 20% of performance, and not in the order of magnitude).


On Friday, June 19, 2015, Mars0i  wrote:

> Neanderthal seems very cool.  You've clearly put a *lot* of work into
> this.  I for one am thankful that you've made available what is a very nice
> tool, as far as I can see.
>
> I don't think there's necessarily a conflict concerning core.matrix,
> though.  You may not want to write a core.matrix wrapper for Neanderthal.
> There's no reason that you must.  Someone else might want to do that; maybe
> I would be able to help with that project.  In that case, those who wanted
> to use Neanderthal via core.matrix could do so, knowing that they lose out
> on any potential advantages of writing directly to Neanderthal, and those
> who want to use Neanderthal in its original form can still do so.  I don't
> see a conflict.
>
> In my case, I have existing code that uses core.matrix.  I wrote to
> core.matrix in part because I didn't want to have to worry about which
> implementation to write to.  I would love to try my code on Neanderthal,
> but I'm not willing to port it.  That's my problem, not yours, though.
>
> For future projects, I could write to Neanderthal, but I also have to
> consider the possibility that there might be situations in which another
> implementation would be better for my code.  Neanderthal looks great, but
> is it always fastest for every application that uses non-tiny matrices?
> Maybe it would be for anything I would write.  I'd rather not have to
> figure that out.  I'm granting that there could be advantages to using
> Neanderthal in its native form rather than via core.matrix, but for me,
> personally, it would be simpler to use it via core.matrix if that was an
> option.  It's not your responsibility to enable that unless you wanted to
> do so, though.  What you've done is already more than enough, Dragan.
>
>
> On Friday, June 19, 2015 at 3:57:32 AM UTC-5, Dragan Djuric wrote:
>>
>> I understand the concept core.matrix tries to achieve, and would be
>> extremely happy if I thought it would be possible, since I would be able to
>> use it and spend time on some other stuff instead of writing C, JNI, OpenCL
>> and such low-level code.
>> Thanks for the pointer to your neural networks experience and benchmark.
>> I have taken a look at the thread you started about that issue, and it
>> clearly shows what (in my opinion) is wrong is core.matrix: it is extremely
>> easy to shoot yourself in the foot with it by (unintentionally) using the
>> backing implementation in a wrong way. And, when you need to be specific an
>> exploit the strength of the implementation, core.matrix gets in your way by
>> making it more difficult in best cases and even impossible. Moreover, the
>> optimizations that you manage to achieve with one implementation, often
>> turn to be hogs with another, with "just one configuration change".
>> For example, if you look at the benchmark on the neanderthal's web site,
>> you'd see that for 512x512 matrices, matrix multiplication is 5x faster
>> with clatrix (jblas) than vectorz. Yet, in your implementation, you managed
>> to turn that 5x speedup into a 1000x slowdown (in the 500x500 case) without
>> even one change in code. Quite impressive on the core.matrix side ;)
>> I do not even claim that an unified api is not possible. I think that to
>> some extent it is. I just doubt in core.matrix eligibility for THE api in
>> numerical computing. For it makes easy things easy and hard things
>> impossible.
>
>



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

Re: 1.7.0b2, lein, cljc and tests

[Colin Yates]

Thanks Alex - you beat me to it!
> On 19 Jun 2015, at 17:31, Alex Miller  wrote:
> 
> Filed
> 
> https://github.com/technomancy/leiningen/pull/1920/
> 
> On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote:
> Probably this needs updating
> 
> https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137
>  
> 
> 
> On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote:
> First - cljc is (for me) a huge upgrade over cljx, which was a great 
> solution. Not having to run lein clix auto every time I do a clean is far 
> more useful than I realised.
> 
> The problem I am having is that cljc test files don't seem to be picked up. I 
> have test/clj and test/cljc, my test-paths in project.clj are ["test/clj" 
> "test/cljc"] but 'lein test', and 'lein test-refresh' don't see them. If I do 
> a 'lein test some-namespace-in-cljc' then the tests are run.
> 
> Has anyone else experienced this and if so, any pointers on moving forward?
> 
> 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 
> .

-- 
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: 1.7.0b2, lein, cljc and tests

[Karsten Schmidt]

Hi Alex,

I looked at this a couple of weeks ago and it actually also has to do with
the bultitude fn called within that fn you patched. Bultitude has been
fixed and there was a new release end of May, but not sure if lein has been
updated meanwhile...

https://github.com/Raynes/bultitude/commit/d8c12b62eb8302cf9d2e9f8566541dbf95981a51
On 19 Jun 2015 17:31, "Alex Miller"  wrote:

> Filed
>
> https://github.com/technomancy/leiningen/pull/1920/
>
> On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote:
>>
>> Probably this needs updating
>>
>>
>> https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137
>>
>> On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote:
>>>
>>> First - cljc is (for me) a huge upgrade over cljx, which was a great
>>> solution. Not having to run lein clix auto every time I do a clean is far
>>> more useful than I realised.
>>>
>>> The problem I am having is that cljc test files don't seem to be picked
>>> up. I have test/clj and test/cljc, my test-paths in project.clj are
>>> ["test/clj" "test/cljc"] but 'lein test', and 'lein test-refresh' don't see
>>> them. If I do a 'lein test some-namespace-in-cljc' then the tests are run.
>>>
>>> Has anyone else experienced this and if so, any pointers on moving
>>> forward?
>>>
>>> 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.
>

-- 
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: 1.7.0b2, lein, cljc and tests

[Karsten Schmidt]

Colin, in the meantime you can still test by stating your ns as arg: lein
test my.ns.test.core
On 19 Jun 2015 18:21, "Karsten Schmidt"  wrote:

> Hi Alex,
>
> I looked at this a couple of weeks ago and it actually also has to do with
> the bultitude fn called within that fn you patched. Bultitude has been
> fixed and there was a new release end of May, but not sure if lein has been
> updated meanwhile...
>
>
> https://github.com/Raynes/bultitude/commit/d8c12b62eb8302cf9d2e9f8566541dbf95981a51
> On 19 Jun 2015 17:31, "Alex Miller"  wrote:
>
>> Filed
>>
>> https://github.com/technomancy/leiningen/pull/1920/
>>
>> On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote:
>>>
>>> Probably this needs updating
>>>
>>>
>>> https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137
>>>
>>> On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote:

 First - cljc is (for me) a huge upgrade over cljx, which was a great
 solution. Not having to run lein clix auto every time I do a clean is far
 more useful than I realised.

 The problem I am having is that cljc test files don't seem to be picked
 up. I have test/clj and test/cljc, my test-paths in project.clj are
 ["test/clj" "test/cljc"] but 'lein test', and 'lein test-refresh' don't see
 them. If I do a 'lein test some-namespace-in-cljc' then the tests are run.

 Has anyone else experienced this and if so, any pointers on moving
 forward?

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

-- 
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: 1.7.0b2, lein, cljc and tests

[Colin Yates]

Hi Karsten, yep, that is what I am doing now - thanks.

> On 19 Jun 2015, at 18:23, Karsten Schmidt  wrote:
> 
> Colin, in the meantime you can still test by stating your ns as arg: lein 
> test my.ns.test.core
> 
> On 19 Jun 2015 18:21, "Karsten Schmidt"  > wrote:
> Hi Alex,
> 
> I looked at this a couple of weeks ago and it actually also has to do with 
> the bultitude fn called within that fn you patched. Bultitude has been fixed 
> and there was a new release end of May, but not sure if lein has been updated 
> meanwhile...
> 
> https://github.com/Raynes/bultitude/commit/d8c12b62eb8302cf9d2e9f8566541dbf95981a51
>  
> 
> On 19 Jun 2015 17:31, "Alex Miller"  > wrote:
> Filed
> 
> https://github.com/technomancy/leiningen/pull/1920/ 
> 
> 
> On Friday, June 19, 2015 at 10:48:46 AM UTC-5, Alex Miller wrote:
> Probably this needs updating
> 
> https://github.com/technomancy/leiningen/blob/master/src/leiningen/test.clj#L137
>  
> 
> 
> On Friday, June 19, 2015 at 8:41:49 AM UTC-5, Colin Yates wrote:
> First - cljc is (for me) a huge upgrade over cljx, which was a great 
> solution. Not having to run lein clix auto every time I do a clean is far 
> more useful than I realised.
> 
> The problem I am having is that cljc test files don't seem to be picked up. I 
> have test/clj and test/cljc, my test-paths in project.clj are ["test/clj" 
> "test/cljc"] but 'lein test', and 'lein test-refresh' don't see them. If I do 
> a 'lein test some-namespace-in-cljc' then the tests are run.
> 
> Has anyone else experienced this and if so, any pointers on moving forward?
> 
> 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 
> .
> 
> -- 
> 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.

ANN: org.clojure/tools.namespace "0.2.11"

[Stuart Sierra]

tools.namespace: parse namespace declarations and reload
files in dependency order.

https://github.com/clojure/tools.namespace

Release 0.2.11 contains the following changes:

  * [TNS-34] Support for reader conditionals

tools.namespace still works only in Clojure(JVM), not
ClojureScript. But it is now able to parse both .clj files
and .cljc source files containing reader conditionals.

This release of tools.namespace remains backwards-compatible
with older versions of Clojure back to 1.3.0.


Leiningen dependency information:
[org.clojure/tools.namespace "0.2.11"]

This is a Clojure-contrib project,
http://dev.clojure.org/display/doc/Clojure+Contrib

[TNS-34]: http://dev.clojure.org/jira/browse/TNS-34

-- 
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] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Matt Revelle]

On Friday, June 19, 2015 at 4:57:32 AM UTC-4, Dragan Djuric wrote:
>
> I do not even claim that an unified api is not possible. I think that to 
> some extent it is. I just doubt in core.matrix eligibility for THE api in 
> numerical computing. For it makes easy things easy and hard things 
> impossible.


Are you saying you don't believe core.matrix should be _the_ abstract API 
for matrices/arrays in Clojure? If so, what are your concerns? Feel free to 
point to me a previous post if it's already been stated. It also sounds 
like you're alluding to the thread in the Numerical Clojure group about a 
broad "numerical computing lib" for complex numbers and various math 
functions, but I'm not following how that matters 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.

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

[Christopher Small]

I see now Dragan; you're concerned not about whether easily implementing
and swapping in/out implementations of core.matrix is possible, but whether
it can be done while maintaining the performance characteristics of
Neanderthal, yes? That did not come through in your earlier comments in
this thread.

Certainly, performance is one of those things that can leak in an
abstraction. But I'd like to echo Matt's enquiry: If you think a unified
API might be possible but that core.matrix isn't it, I think we'd all love
to hear what you think it's missing and/or what would would need to be
rearchitected in order for it to fit the bill.

As for any sort of "responsibility" to implement core.matrix, I don't think
anyone is arguing you have such a responsibility, and I hope our _pleading_
hasn't come across as such. We are simply impressed with your work, and
would like to take advantage of it, but also see a "drawback" you don't: at
present Neanderthal is less interoperable with many existing tools, and
"trying it out" on an existing project would require a rewrite (as would
migrating away from it if we weren't happy).

Certainly, a third party library implementing core.matrix with Neanderthal
is a possibility, but I'm a bit worried that a) it would add extra burden
keeping things in sync and feel a little second class; and more importantly
b) it might be easier to maintain more of the performance benefits if it's
directly integrating (I could imagine less indirection this way, but could
be totally wrong). So let me ask you this:

Assuming a) someone forks Neanderthal and makes a core.matrix
implementation with close performance parity to the direct Neanderthal API
and/or b) folks working on core.matrix are able to address some of your
issues with the core.matrix architecture, would you consider a merge?


With gratitude

Chris



On Fri, Jun 19, 2015 at 1:45 PM, Matt Revelle  wrote:

> On Friday, June 19, 2015 at 4:57:32 AM UTC-4, Dragan Djuric wrote:
>>
>> I do not even claim that an unified api is not possible. I think that to
>> some extent it is. I just doubt in core.matrix eligibility for THE api in
>> numerical computing. For it makes easy things easy and hard things
>> impossible.
>
>
> Are you saying you don't believe core.matrix should be _the_ abstract API
> for matrices/arrays in Clojure? If so, what are your concerns? Feel free to
> point to me a previous post if it's already been stated. It also sounds
> like you're alluding to the thread in the Numerical Clojure group about a
> broad "numerical computing lib" for complex numbers and various math
> functions, but I'm not following how that matters 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/dFPOOw8pSGI/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.

Re: [ANN] Clojure 1.7.0-RC2

[James Elliott]

After some quick testing, everything is looking good for me. I will pound 
on it more heavily this weekend, and report back if that changes, although 
I do not expect it to. Thanks!

On Wednesday, June 17, 2015 at 12:44:39 PM UTC-5, Alex Miller wrote:
>
> Clojure 1.7.0-RC2 is now available.
>
> Try it via
> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC2/
> - Leiningen: [org.clojure/clojure "1.7.0-RC2"]
>
> 1.7.0-RC2 has the following changes since 1.7.0-RC1:
>
> 1) CLJ-1735 - Throwable->map was missing docstring
>
> 2) CLJ-1237 - reduce gives a StackOverflow for seqs that switch back and 
> forth between chunked and unchunked many times
>
> This was an old problem that was amplified in 1.7, but has now been fixed.
>
> 3) CLJ-1738 - Seqs over Java iterators that return the same mutating 
> object on every next() call
>
> Seqs are fundamentally incompatible with Java iterators that return the 
> same mutating object on every call to next().  Some Clojure libraries 
> incorrectly rely on calling seq on such iterators. In 1.7, iterator-seqs 
> are chunked, which will cause many of these incorrect usages to return 
> incorrect results immediately. The `seq` and `iterator-seq` docstrings have 
> been updated to include an explicit warning. Libraries that incorrectly use 
> `seq` and `iterator-seq` will need to be fixed before running against 1.7.
>
> 4) CLJ-1745 - Exceptions thrown from macros wrapped in additional 
> CompilerException
>
> This was a regression from CLJ-1169 and most of that change has been 
> rolled back.
>
> For a full list of changes since 1.6.0, see: 
> https://github.com/clojure/clojure/blob/master/changes.md
>
> Please give it a try and let us know if things are working (or not). The 
> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>
> - Alex
>

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

breaking homoiconicity?

[Joe Corneli]

This is an interaction with Clojure via CIDER.

repl [1]> (type (into-array String ["Awesome"]))
[Ljava.lang.String;
repl [2]> [Ljava.lang.String;
RuntimeException EOF while reading, starting at line 1  
clojure.lang.Util.runtimeException (Util.java:221)
repl [3]> (quote [Ljava.lang.String;)

CIDER won't let me enter [3] claiming that the input is not complete.  
What's going on here, apart from things not working?  If 
[Ljava.lang.String; is a valid return value, and can show up in code that I 
construct programmatically, why is it not valid input?  Is this a flaw in 
CIDER / lein, or are they giving me the right answers 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.

Re: breaking homoiconicity?

[James Reeves]

Most Java types don't have reversible serialisation in Clojure. There's
actually only a small subset of data types that can be printed and then
read without losing information.

- James

On 20 June 2015 at 01:08, Joe Corneli  wrote:

> This is an interaction with Clojure via CIDER.
>
> repl [1]> (type (into-array String ["Awesome"]))
> [Ljava.lang.String;
> repl [2]> [Ljava.lang.String;
> RuntimeException EOF while reading, starting at line 1
> clojure.lang.Util.runtimeException (Util.java:221)
> repl [3]> (quote [Ljava.lang.String;)
>
> CIDER won't let me enter [3] claiming that the input is not complete.
> What's going on here, apart from things not working?  If
> [Ljava.lang.String; is a valid return value, and can show up in code that I
> construct programmatically, why is it not valid input?  Is this a flaw in
> CIDER / lein, or are they giving me the right answers 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.

Re: breaking homoiconicity?

[Sean Corfield]

On Jun 19, 2015, at 5:08 PM, Joe Corneli  wrote:
> This is an interaction with Clojure via CIDER.
> 
> repl [1]> (type (into-array String ["Awesome"]))
> [Ljava.lang.String;

This is a java.lang.Class object whose name is "[Ljava.lang.String;" because 
that’s how Java native arrays are encoded.

> CIDER won't let me enter [3] claiming that the input is not complete.  What's 
> going on here, apart from things not working?

You can get the Class object like this:

(Class/forName "[Ljava.lang.String;")
;;=> [Ljava.lang.String; — unhelpful but this is the name of the class, 
as above.

and you can see what it really is like this:

(.getTypeName (Class/forName "[Ljava.lang.String;"))
;;=> "java.lang.String[]" — that is more readable!

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

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