Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

hi,

RC1 works well with our largest project.  See a 5-8% slow-down but no other 
problems.

Regards,
Stefan

-- 
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] zcube 0.0.2

[Fabien Todescato]

Hi, clojure community. It is my pleasure to announce zcube[1], a Clojure 
library all about counting trees for analytical purposes.

The intent is to compute aggregate sums over multiple hierarchical dimensions, 
based on the (old) algorithmic ideas exposed in [2] by Pr. Minato et Al, and 
implemented in an immutable setting suitable for concurrent and functional 
programming.

The 0.0.2 version provides a parallel bulk API to compute aggregates over lazy 
sequences, taking advantage of multicores.

[1]https://github.com/ftod/zcube
[2]http://www-alg.ist.hokudai.ac.jp/~thomas/TCSTR/tcstr_05_3/tcstr_05_3.pdf

-- 
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: [GSoC] Proposal: persistent probabilistic data structures

[Matteo Ceccarello]

I just had a short conversation with Ambrose through comments on my 
proposal. He suggests to offer this library to Clojure contrib. 
So I have to sign a Clojure CA, however I don't know what "project name" to 
put in the form, since the project has yet to start.

Any suggestion? What should I do?

Thanks
Matteo

Il giorno venerdì 14 marzo 2014 14:53:44 UTC+1, Matteo Ceccarello ha 
scritto:
>
> Nicola,
> thank you :) It's really nice to see that I'm not alone!
>
> Everybody, I just updated the proposal, following the guidelines suggested 
> by the wiki.
>
> Cheers,
> Matteo
>
> Il giorno giovedì 13 marzo 2014 23:06:11 UTC+1, Nicola Mometto ha scritto:
>>
>>
>> Matteo, 
>> best of luck with your proposal, all of those seem like good potential 
>> additions to the clojure data-structure landscape. 
>>
>> BTW I'm too a fellow UniPD clojure user so you can inc the counter :) 
>>
>> Nicola 
>>
>> Matteo Ceccarello writes: 
>>
>> > Hello everybody, 
>> > 
>> > I just submitted my proposal for this year's GSoC. I already introduced 
>> the 
>> > topic on this mailing list. 
>> > Here you can find the complete proposal: 
>> > 
>> > 
>> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/matteo_ceccarello/5778586438991872
>>  
>> > 
>> > So, if you have suggestions on how to improve it, or if you have any 
>> > request, please tell me :) 
>> > 
>> > I'm really looking forward to work with Clojure for this year's GSoC: I 
>> > want to learn it really well, since 
>> > my long term goal is to make more and more people at my University use 
>> it. 
>> > Working on an open source project 
>> > under the guidance of an expert mentor seems to me the best way to 
>> achieve 
>> > this. 
>> > 
>> > Bests 
>> > Matteo 
>>
>

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

Kibit output

[Tim Terry]

Hi, is it possible to output kibit code analysis results into a file? My 
aim is to publish this file with a CI tool such as teamcity/ jenkins.

Thanks,

Tim

-- 
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: Kibit output

[Aaron France]

`lein kibit > file`

On Wed, Mar 19, 2014 at 03:26:17AM -0700, Tim Terry wrote:
>Hi, is it possible to output kibit code analysis results into a file? My
>aim is to publish this file with a CI tool such as teamcity/ jenkins.
>Thanks,
>Tim
> 
>--
>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.


pgpBPqIQhzpQS.pgp
Description: PGP signature

Re: algorithm help: extracting groups of consecutive ints from a sorted list

[Alex Nixon]

Or use glue from flatland.useful.seq 
 and:

user=> (glue conj [] (fn [s n] (= (inc (last s)) n)) [1 3 4 5 7 9 10 13])
([1] [3 4 5] [7] [9 10] [13])


On 19 March 2014 04:10, Shantanu Kumar  wrote:

>
>
> On Wednesday, 19 March 2014 09:39:56 UTC+5:30, Shantanu Kumar wrote:
>>
>> Something like this?
>>
>> (defn x [1 3 4 5 7 9 10 13])
>>
>
> Sory for the typo. Should be (def x [1 3 4 5 7 9 10 13])
>
>
>>
>> (reduce (fn [a i] (let [y (last a) z (last y)] (if (and z (= (inc z) i))
>> (conj (pop a) (conj y i)) (conj a [i] [] x)
>>
>> Shantanu
>>
>> On Wednesday, 19 March 2014 08:26:43 UTC+5:30, John Gabriele wrote:
>>>
>>> If you've got a sorted list of numbers, for example:
>>>
>>> [1 3 4 5 7 9 10 13]
>>>
>>> where some are consecutive, how can you pull out the consecutive runs?
>>> That is, either produce
>>>
>>> [1 [3 4 5] 7 [9 10] 13]; or maybe something like
>>> [[1 7 13] [3 4 5] [9 10]]  ; (the first vec is the elements left
>>> over)
>>>
>>> from the original coll?
>>>
>>> I can do it in Python in an imperative style, but it's a bit messy. My
>>> hunch is that there's probably a shorter way in Clojure, but I'm not seeing
>>> it.
>>>
>>> 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: [GSoC] Proposal: persistent probabilistic data structures

[Nicola Mometto]

Matteo,
When sending the CA adding a "project name" is optional, you can leave
it empty.

Usually the name for a contrib project will be chosen in the thread in
clojure-dev when proposing the library as a contrib project, see
http://dev.clojure.org/display/community/Guidelines+for+Clojure+Contrib+committers
for more details

Nicola

Matteo Ceccarello writes:

> I just had a short conversation with Ambrose through comments on my
> proposal. He suggests to offer this library to Clojure contrib.
> So I have to sign a Clojure CA, however I don't know what "project name" to
> put in the form, since the project has yet to start.
>
> Any suggestion? What should I do?
>
> Thanks
> Matteo
>
> Il giorno venerdì 14 marzo 2014 14:53:44 UTC+1, Matteo Ceccarello ha
> scritto:
>>
>> Nicola,
>> thank you :) It's really nice to see that I'm not alone!
>>
>> Everybody, I just updated the proposal, following the guidelines suggested
>> by the wiki.
>>
>> Cheers,
>> Matteo
>>
>> Il giorno giovedì 13 marzo 2014 23:06:11 UTC+1, Nicola Mometto ha scritto:
>>>
>>>
>>> Matteo,
>>> best of luck with your proposal, all of those seem like good potential
>>> additions to the clojure data-structure landscape.
>>>
>>> BTW I'm too a fellow UniPD clojure user so you can inc the counter :)
>>>
>>> Nicola
>>>
>>> Matteo Ceccarello writes:
>>>
>>> > Hello everybody,
>>> >
>>> > I just submitted my proposal for this year's GSoC. I already introduced
>>> the
>>> > topic on this mailing list.
>>> > Here you can find the complete proposal:
>>> >
>>> >
>>> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/matteo_ceccarello/5778586438991872
>>> >
>>> > So, if you have suggestions on how to improve it, or if you have any
>>> > request, please tell me :)
>>> >
>>> > I'm really looking forward to work with Clojure for this year's GSoC: I
>>> > want to learn it really well, since
>>> > my long term goal is to make more and more people at my University use
>>> it.
>>> > Working on an open source project
>>> > under the guidance of an expert mentor seems to me the best way to
>>> achieve
>>> > this.
>>> >
>>> > Bests
>>> > Matteo
>>>
>>

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Alex Miller]

 what's that about performance now?  

Is that something definitive and reproducible? And if so, is there any way to 
track down a cause?

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Nicola Mometto]

I'm guessing it's because of the minor overhead on hashing added with
the move to Murmur3?

Alex Miller writes:

>  what's that about performance now?
>
> Is that something definitive and reproducible? And if so, is there any way to 
> track down a cause?

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Walter van der Laan]

I moved to 1.6 two weeks ago for development and have had no problem. I had 
to change some tests because they depended on the order of elements if you 
seq a hashmap.

On Tuesday, March 18, 2014 3:21:22 PM UTC+1, Alex Miller wrote:
>
> Hello all, 
>
> We would love to release Clojure 1.6.0 final soon.
>
> We need your help in checking out the current release candidate - this is 
> your opportunity to let us know about problems *before* we release, rather 
> than after. 
>
> Try it via 
> - Download: http://central.maven.org/maven2/org/clojure/clojure/1.6.0-RC1
> - Leiningen: [org.clojure/clojure "1.6.0-RC1"]
>
> See the full change log here:
> https://github.com/clojure/clojure/blob/master/changes.md
>
> If you have questions, feel free to drop them here. For issues, please log 
> them in JIRA . 
>
> 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.

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Alex Miller]

That is the only set of changes that I know of that negatively affect 
performance in 1.6.0. However, the absolute differences are quite small and 
codes are cached. It's hard for me to conjure a scenario where the 
resulting effect is an overall 5-8% slowdown. If this is one, I'd like to 
understand it better. 


On Wednesday, March 19, 2014 8:28:18 AM UTC-5, Nicola Mometto wrote:
>
>
> I'm guessing it's because of the minor overhead on hashing added with 
> the move to Murmur3? 
>
> Alex Miller writes: 
>
> >  what's that about performance now? 
> > 
> > Is that something definitive and reproducible? And if so, is there any 
> way to track down a cause? 
>

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Michał Marczyk]

Hashes are cached for Clojure collections, keywords and symbols, but
not for strings.

I wonder if people who report these perf regressions use long string
keys in their maps... For this to explain the regression they'd have
to be looking up the same String objects a lot, of course (else
hashCode caching wouldn't have been helpful before the move to
Murmur3).


On 19 March 2014 15:21, Alex Miller  wrote:
> That is the only set of changes that I know of that negatively affect
> performance in 1.6.0. However, the absolute differences are quite small and
> codes are cached. It's hard for me to conjure a scenario where the resulting
> effect is an overall 5-8% slowdown. If this is one, I'd like to understand
> it better.
>
>
> On Wednesday, March 19, 2014 8:28:18 AM UTC-5, Nicola Mometto wrote:
>>
>>
>> I'm guessing it's because of the minor overhead on hashing added with
>> the move to Murmur3?
>>
>> Alex Miller writes:
>>
>> >  what's that about performance now?
>> >
>> > Is that something definitive and reproducible? And if so, is there any
>> > way to track down a cause?
>
> --
> 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: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

Hi Alex,


the runtime of the program changed from 19 to 20 seconds for one set of 
data and from approx 6minutes to 6:30 for another set.  To me that is 
acceptable. 

We are reading a few MB of files into memory, create lots of intermediate 
vectors, maps and sets and output up to a few hundred MB of data later.  
All this with pure Clojure, almost no Interop, no protocols, no records or 
types, just one multimethod which is only used during the first second.

Comparison was done by changing the project.clj to point to the desired 
Clojure version, followed by lein clean && lein uberjar and the running the 
uberjar with a fresh JVM.  All this on a QuadCore with 16GB RAM and OpenJDK 
1.7 on Linux.  We use tools.logging, tools.cli, core.async and log4j and 
AOT compile :all in the uberjar.

If you still consider this a possible breaker (I humbly don't) please let 
me know, what I should test for you.

Kind regards,
stefan


On Wednesday, March 19, 2014 3:21:54 PM UTC+1, Alex Miller wrote:
>
> That is the only set of changes that I know of that negatively affect 
> performance in 1.6.0. However, the absolute differences are quite small and 
> codes are cached. It's hard for me to conjure a scenario where the 
> resulting effect is an overall 5-8% slowdown. If this is one, I'd like to 
> understand it better. 
>
>
> On Wednesday, March 19, 2014 8:28:18 AM UTC-5, Nicola Mometto wrote:
>>
>>
>> I'm guessing it's because of the minor overhead on hashing added with 
>> the move to Murmur3? 
>>
>> Alex Miller writes: 
>>
>> >  what's that about performance now? 
>> > 
>> > Is that something definitive and reproducible? And if so, is there any 
>> way to track down a cause? 
>>
>

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

Hi,

On Wednesday, March 19, 2014 3:55:22 PM UTC+1, Michał Marczyk wrote:
>
> Hashes are cached for Clojure collections, keywords and symbols, but 
> not for strings. 
>
> I wonder if people who report these perf regressions use long string 
> keys in their maps... 


As far as I can see, we have /lots/ of strings in sets and lots of strings 
as keys, but they are not particularly /long/ (usually less than 10-15 
Characters).  We have one hot spot in the code, where we create lots 
(hundreds of thousands up to millions) of sets, each containing one to five 
strings.  I will run a few tests and see whether that makes a difference.

Best,
stefan

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Alex Miller]

Thanks, this is all really useful. I would appreciate any more detailed 
info. 

On Wednesday, March 19, 2014 10:15:35 AM UTC-5, Stefan Kamphausen wrote:
>
> Hi,
>
> On Wednesday, March 19, 2014 3:55:22 PM UTC+1, Michał Marczyk wrote:
>>
>> Hashes are cached for Clojure collections, keywords and symbols, but 
>> not for strings. 
>>
>> I wonder if people who report these perf regressions use long string 
>> keys in their maps... 
>
>
> As far as I can see, we have /lots/ of strings in sets and lots of strings 
> as keys, but they are not particularly /long/ (usually less than 10-15 
> Characters).  We have one hot spot in the code, where we create lots 
> (hundreds of thousands up to millions) of sets, each containing one to five 
> strings.  I will run a few tests and see whether that makes a difference.
>
> Best,
> stefan
>
>

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Steve Miner]

I just tried to build master locally with the new JDK 1.8 on a Mac.  I'm 
getting a build test failure.  Sorry, I don't have time to look into it at the 
moment.  JDK 1.7 worked fine for me.

 [java] clojure.test-clojure.reflect
 [java] 
 [java] java.lang.IllegalArgumentException
 [java] at clojure.asm.ClassReader.(ClassReader.java:170)
 [java] at clojure.asm.ClassReader.(ClassReader.java:153)
 [java] at clojure.asm.ClassReader.(ClassReader.java:424)
 [java] at clojure.reflect.AsmReflector.do_reflect(java.clj:200)
 [java] at clojure.reflect$fn__9042$G__9038__9045.invoke(reflect.clj:44)
 [java] at clojure.reflect$fn__9042$G__9037__9049.invoke(reflect.clj:44)
 [java] at clojure.lang.AFn.applyToHelper(AFn.java:156)
 [java] at clojure.lang.AFn.applyTo(AFn.java:144)
 [java] at clojure.core$apply.invoke(core.clj:626)
 [java] at clojure.core$partial$fn__4228.doInvoke(core.clj:2468)
 [java] at clojure.lang.RestFn.invoke(RestFn.java:408)
 [java] at clojure.reflect$type_reflect.doInvoke(reflect.clj:100)
 [java] at clojure.lang.RestFn.invoke(RestFn.java:439)
 [java] at clojure.test_clojure.reflect$fn__19909.invoke(reflect.clj:23)
 [java] at clojure.test$test_var$fn__7187.invoke(test.clj:704)
 [java] at clojure.test$test_var.invoke(test.clj:704)
 [java] at clojure.test$test_vars$fn__7209$fn__7214.invoke(test.clj:722)
 [java] at clojure.test$default_fixture.invoke(test.clj:674)
 [java] at clojure.test$test_vars$fn__7209.invoke(test.clj:722)
 [java] at clojure.test$default_fixture.invoke(test.clj:674)
 [java] at clojure.test$test_vars.invoke(test.clj:718)
 [java] at clojure.test$test_all_vars.invoke(test.clj:728)
 [java] at clojure.test$test_ns.invoke(test.clj:747)
 [java] at clojure.core$map$fn__4245.invoke(core.clj:2559)
 [java] at clojure.lang.LazySeq.sval(LazySeq.java:40)
 [java] at clojure.lang.LazySeq.seq(LazySeq.java:49)
 [java] at clojure.lang.Cons.next(Cons.java:39)
 [java] at clojure.lang.RT.next(RT.java:599)
 [java] at clojure.core$next.invoke(core.clj:64)
 [java] at clojure.core$reduce1.invoke(core.clj:903)
 [java] at clojure.core$reduce1.invoke(core.clj:894)
 [java] at clojure.core$merge_with.doInvoke(core.clj:2777)
 [java] at clojure.lang.RestFn.applyTo(RestFn.java:139)
 [java] at clojure.core$apply.invoke(core.clj:626)
 [java] at clojure.test$run_tests.doInvoke(test.clj:762)
 [java] at clojure.lang.RestFn.applyTo(RestFn.java:137)
 [java] at clojure.core$apply.invoke(core.clj:624)
 [java] at 
clojure.test.generative.runner$run_all_tests$fn__529.invoke(runner.clj:255)
 [java] at 
clojure.test.generative.runner$run_all_tests$run_with_counts__521$fn__525.invoke(runner.clj:251)
 [java] at 
clojure.test.generative.runner$run_all_tests$run_with_counts__521.invoke(runner.clj:251)
 [java] at 
clojure.test.generative.runner$run_all_tests.invoke(runner.clj:253)
 [java] at 
clojure.test.generative.runner$test_dirs.doInvoke(runner.clj:304)
 [java] at clojure.lang.RestFn.applyTo(RestFn.java:137)
 [java] at clojure.core$apply.invoke(core.clj:624)
 [java] at clojure.test.generative.runner$_main.doInvoke(runner.clj:312)
 [java] at clojure.lang.RestFn.invoke(RestFn.java:408)
 [java] at user$eval566.invoke(run_tests.clj:4)
 [java] at clojure.lang.Compiler.eval(Compiler.java:6703)
 [java] at clojure.lang.Compiler.load(Compiler.java:7130)
 [java] at clojure.lang.Compiler.loadFile(Compiler.java:7086)
 [java] at clojure.main$load_script.invoke(main.clj:274)
 [java] at clojure.main$script_opt.invoke(main.clj:336)
 [java] at clojure.main$main.doInvoke(main.clj:420)
 [java] at clojure.lang.RestFn.invoke(RestFn.java:408)
 [java] at clojure.lang.Var.invoke(Var.java:379)
 [java] at clojure.lang.AFn.applyToHelper(AFn.java:154)
 [java] at clojure.lang.Var.applyTo(Var.java:700)
 [java] at clojure.main.main(main.java:37)
 [java] {:file "ClassReader.java",
 [java]  :tstamp 1395244274721,
 [java]  :type :error,
 [java]  :clojure.test/vars (compare-reflect-and-asm),
 [java]  :level :error,
 [java]  :pid 97553,
 [java]  :line 170,
 [java]  :thread 1,
 [java]  :exception
 [java]  #,
 [java]  :thread/name "main",
 [java]  :message "Uncaught exception, not in assertion."}
 [java] 


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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Stefan Kamphausen]

On Wednesday, March 19, 2014 4:34:45 PM UTC+1, Alex Miller wrote:
>
> Thanks, this is all really useful. I would appreciate any more detailed 
> info. 
>>
>>
>>
* No atoms, agents, refs
* Almost purely functional plus logging and I/O
* Multi-threaded using latest core.async with thread, no go
* JVisualVM reports top methods in CPU sampling c.l.LazySeq.sval, 
c.c$promise$reify_6310.deref, c.l.LazySeq.seq no notable difference for me 
to see.

A few experiments on two data-sets (dat1 and dat2) using either a call to 
set or to doall:

   Clojure Op Time (dat1) Time (dat1) Average dat1 Time (dat2)  1.5.1 set 
19,1 19 19,05 323  1.5.1 doall 19 19,4 19,2 330  1.6.0-RC1 set 19,5 19,8 
19,65 350  1.6.0-RC1 doall 20,2 19,8 20 351




 

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Nicola Mometto]

ASM 4.1 does not work with JDK 1.8 see
http://dev.clojure.org/jira/browse/CLJ-1323


Steve Miner writes:

> I just tried to build master locally with the new JDK 1.8 on a Mac.  I'm 
> getting a build test failure.  Sorry, I don't have time to look into it at 
> the moment.  JDK 1.7 worked fine for me.
>
>  [java] clojure.test-clojure.reflect
>  [java]
>  [java] java.lang.IllegalArgumentException
>  [java]   at clojure.asm.ClassReader.(ClassReader.java:170)
>  [java]   at clojure.asm.ClassReader.(ClassReader.java:153)
>  [java]   at clojure.asm.ClassReader.(ClassReader.java:424)
>  [java]   at clojure.reflect.AsmReflector.do_reflect(java.clj:200)
>  [java]   at clojure.reflect$fn__9042$G__9038__9045.invoke(reflect.clj:44)
>  [java]   at clojure.reflect$fn__9042$G__9037__9049.invoke(reflect.clj:44)
>  [java]   at clojure.lang.AFn.applyToHelper(AFn.java:156)
>  [java]   at clojure.lang.AFn.applyTo(AFn.java:144)
>  [java]   at clojure.core$apply.invoke(core.clj:626)
>  [java]   at clojure.core$partial$fn__4228.doInvoke(core.clj:2468)
>  [java]   at clojure.lang.RestFn.invoke(RestFn.java:408)
>  [java]   at clojure.reflect$type_reflect.doInvoke(reflect.clj:100)
>  [java]   at clojure.lang.RestFn.invoke(RestFn.java:439)
>  [java]   at clojure.test_clojure.reflect$fn__19909.invoke(reflect.clj:23)
>  [java]   at clojure.test$test_var$fn__7187.invoke(test.clj:704)
>  [java]   at clojure.test$test_var.invoke(test.clj:704)
>  [java]   at clojure.test$test_vars$fn__7209$fn__7214.invoke(test.clj:722)
>  [java]   at clojure.test$default_fixture.invoke(test.clj:674)
>  [java]   at clojure.test$test_vars$fn__7209.invoke(test.clj:722)
>  [java]   at clojure.test$default_fixture.invoke(test.clj:674)
>  [java]   at clojure.test$test_vars.invoke(test.clj:718)
>  [java]   at clojure.test$test_all_vars.invoke(test.clj:728)
>  [java]   at clojure.test$test_ns.invoke(test.clj:747)
>  [java]   at clojure.core$map$fn__4245.invoke(core.clj:2559)
>  [java]   at clojure.lang.LazySeq.sval(LazySeq.java:40)
>  [java]   at clojure.lang.LazySeq.seq(LazySeq.java:49)
>  [java]   at clojure.lang.Cons.next(Cons.java:39)
>  [java]   at clojure.lang.RT.next(RT.java:599)
>  [java]   at clojure.core$next.invoke(core.clj:64)
>  [java]   at clojure.core$reduce1.invoke(core.clj:903)
>  [java]   at clojure.core$reduce1.invoke(core.clj:894)
>  [java]   at clojure.core$merge_with.doInvoke(core.clj:2777)
>  [java]   at clojure.lang.RestFn.applyTo(RestFn.java:139)
>  [java]   at clojure.core$apply.invoke(core.clj:626)
>  [java]   at clojure.test$run_tests.doInvoke(test.clj:762)
>  [java]   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>  [java]   at clojure.core$apply.invoke(core.clj:624)
>  [java]   at 
> clojure.test.generative.runner$run_all_tests$fn__529.invoke(runner.clj:255)
>  [java]   at 
> clojure.test.generative.runner$run_all_tests$run_with_counts__521$fn__525.invoke(runner.clj:251)
>  [java]   at 
> clojure.test.generative.runner$run_all_tests$run_with_counts__521.invoke(runner.clj:251)
>  [java]   at 
> clojure.test.generative.runner$run_all_tests.invoke(runner.clj:253)
>  [java]   at 
> clojure.test.generative.runner$test_dirs.doInvoke(runner.clj:304)
>  [java]   at clojure.lang.RestFn.applyTo(RestFn.java:137)
>  [java]   at clojure.core$apply.invoke(core.clj:624)
>  [java]   at clojure.test.generative.runner$_main.doInvoke(runner.clj:312)
>  [java]   at clojure.lang.RestFn.invoke(RestFn.java:408)
>  [java]   at user$eval566.invoke(run_tests.clj:4)
>  [java]   at clojure.lang.Compiler.eval(Compiler.java:6703)
>  [java]   at clojure.lang.Compiler.load(Compiler.java:7130)
>  [java]   at clojure.lang.Compiler.loadFile(Compiler.java:7086)
>  [java]   at clojure.main$load_script.invoke(main.clj:274)
>  [java]   at clojure.main$script_opt.invoke(main.clj:336)
>  [java]   at clojure.main$main.doInvoke(main.clj:420)
>  [java]   at clojure.lang.RestFn.invoke(RestFn.java:408)
>  [java]   at clojure.lang.Var.invoke(Var.java:379)
>  [java]   at clojure.lang.AFn.applyToHelper(AFn.java:154)
>  [java]   at clojure.lang.Var.applyTo(Var.java:700)
>  [java]   at clojure.main.main(main.java:37)
>  [java] {:file "ClassReader.java",
>  [java]  :tstamp 1395244274721,
>  [java]  :type :error,
>  [java]  :clojure.test/vars (compare-reflect-and-asm),
>  [java]  :level :error,
>  [java]  :pid 97553,
>  [java]  :line 170,
>  [java]  :thread 1,
>  [java]  :exception
>  [java]  #,
>  [java]  :thread/name "main",
>  [java]  :message "Uncaught exception, not in assertion."}
>  [java]

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

[ANN] stch.routing 0.1.1

[david]

I'm really excited to announce stch.routing.  This library is similar to 
Compojure in purpose, but is much different in use.  It is based off ideas 
from bulletphp.com.  The overall objective is concise routing of Ring 
requests.  Feedback is very much appreciated.

Full documentation, examples, and example site can be found at 
https://github.com/stch-library/routing.

Add the following to your project dependencies to use:

[stch-library/routing "0.1.1"]

BTW, I'm currently looking for work as a Clojure developer.  If you like 
what you see, please hit me up.

David

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

reduced

[Andy Smith]

Hi,

Ive been looking at http://www.4clojure.com/problem/137 and I have a 
solution :

(fn [x b] (reduce #(let [r (quot x %2) d (mod r b)] (if (zero? r) (reduced 
%1) (conj %1 d))) '() (iterate (partial * b) 1)))

but the 4clojure website is failing with :


java.lang.RuntimeException: Unable to resolve symbol: reduced in this 
context, compiling:(NO_SOURCE_PATH:0)

Any ideas?

Thanks

Andy

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

[Andy Smith]

ah ok...

i worked around this using a restriction on the input collection, but i 
think it is less concise :

(fn [x b] (if (zero? x) [0] (reduce #(let [r (quot x %2) d (mod r b)] (conj 
%1 d)) '() (take-while #(<= % x) (iterate (partial * b) 1)

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

[Moritz Ulrich]

`reduced' was added in 1.5. It looks like 4clojure is using an older
version.


On Wed, Mar 19, 2014 at 5:44 PM, Andy Smith wrote:

> Hi,
>
> Ive been looking at http://www.4clojure.com/problem/137 and I have a
> solution :
>
> (fn [x b] (reduce #(let [r (quot x %2) d (mod r b)] (if (zero? r) (reduced
> %1) (conj %1 d))) '() (iterate (partial * b) 1)))
>
> but the 4clojure website is failing with :
>
>
> java.lang.RuntimeException: Unable to resolve symbol: reduced in this
> context, compiling:(NO_SOURCE_PATH:0)
>
> Any ideas?
>
> Thanks
>
> Andy
>
>  --
> 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: reduced

[Jim]

I think `reduced` was added in 1.4...
4clojure is on 1.2 right?

Jim

On 19/03/14 16:44, Andy Smith wrote:

Hi,

Ive been looking at http://www.4clojure.com/problem/137 and I have a 
solution :


(fn [x b] (reduce #(let [r (quot x %2) d (mod r b)] (if (zero? r) 
(reduced %1) (conj %1 d))) '() (iterate (partial * b) 1)))


but the 4clojure website is failing with :



java.lang.RuntimeException: Unable to resolve symbol: reduced in this 
context, compiling:(NO_SOURCE_PATH:0)


Any ideas?

Thanks

Andy

--
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: STM and persistent data structures performance on mutli-core archs

[Raoul Duke]

> I like FSMs, but they do not compose well.

some have argued for generative grammars that generate the fsm,
because it is generally easier to compose grammars, and then generate
the final fsm. iiuc.

-- 
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: More functional Quil

[J . Pablo Fernández]

Hello Nikita,

I think Quil should definitely provide a way to write functional style 
processing code. At the moment, my knowledge of both Clojure and Processing 
is not enough to evaluate these solutions. I'm certainly going to write my 
code following some of this and if someone proposes a solution to be part 
of Quil 2, I would happily adopt it and report back on my experiences.

BTW, I noticed you had some discussions on IRC, you can find me there as 
Pupeno.

On Monday, March 10, 2014 12:29:00 AM UTC, Nikita Beloglazov wrote:
>
> Hi Pablo
>
> You can find similar old thread on Quil github repo: 
> https://github.com/quil/quil/pull/19 It may serve as good background what 
> other people considered to make Quil more "functional-style".
>
> I like your suggestion though I would split your :draw function to 2 fns: 
> an :update function, which only purpose is to update state and :drawwhich 
> draws state and doesn't change the world at all. If this approach is 
> implemented - other handler functions like :mouse-move, :key-pressed are 
> also need to become update-like functions - they should take state as 
> argument and return new state.
>
> The only problem is that it is not backward compatible at all. But 
> probably we still can do it... We can add option :fun-mode? true (stands 
> for functional-mode) which enables all these changes - :draw takes state 
> as argument, new :update function is added for modifying state, all 
> handlers behave like :update. This option is enabled per-sketch. It 
> requires additional work on Quil internals, but I think it is doable. This 
> option can be implemented in coming quil 2.0 and it would be great feature 
> to have. 
>
> One more thing we could do to make it more functional-like - pass 
> "changed" values to handlers directly. Currently when :key-pressedhandler is 
> called - no argument is passed to the function and you need to 
> use (key-code) or (raw-key) functions to identify which key was pressed. 
> I think this parameters should be explicitly passed to the function.
>
> What do you think?
>
> Nikita
>
> On Sunday, March 9, 2014 1:21:58 PM UTC, J. Pablo Fernández wrote:
>>
>>
>>
>> On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote:
>>>
>>> Hello, 
>>>
>>> To be honest I don't see any fundamental difference between your first 
>>> attempt and the improvement: both share the fact that the mutation of the 
>>> state happens within the draw function. So in both cases, you have a 
>>> temporal coupling between updating the state of the app and rendering a new 
>>> view of the app's state.
>>>
>>
>> Yes, what's happening in both cases is very similar, but the function 
>> draw in the "functional" style, in my opinion, is easier to read and maybe 
>> it's also easier to test.
>>  
>>
>>> I would suggest that you don't swap! at all within draw, just deref and 
>>> render the result of the dereffing.
>>>
>>> And, in another thread, at potentially a totally different pace than the 
>>> redrawing's pace, update the application's state accordingly to business 
>>> rules / constraints.
>>>
>>> Schematically, something like this: 
>>>
>>> (def app-state (atom (init-state)))
>>>
>>> (defn draw [...]
>>>   (let [app-snapshot (deref app-state)]
>>>   ... call quil primitives to render the application state snapshot 
>>> ...))
>>>
>>> (future
>>>   ... logic which updates the app-state atom depending on business rules 
>>> / constraints, in a separate thread ...)
>>>
>>
>> I never worked with future, this is exciting, but I have some questions. 
>> Do you mean that future is completely separate from draw? I'm just getting 
>> started, but draw is not only a function to draw, but as a side effect is 
>> the clock of the app, as it's called according to the set frames per second 
>> and you normally *take a step* en each draw. Would draw create these 
>> futures for the next draw?
>>
>

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Softaddicts]

Moved to this release 3 days ago. Nothing to report, works as expected :)

Thank to everyone for this new release :)

Luc P.


> Hello all,
> 
> We would love to release Clojure 1.6.0 final soon.
> 
> We need your help in checking out the current release candidate - this is
> your opportunity to let us know about problems *before* we release, rather
> than after.
> 
> Try it via
> - Download: http://central.maven.org/maven2/org/clojure/clojure/1.6.0-RC1
> - Leiningen: [org.clojure/clojure "1.6.0-RC1"]
> 
> See the full change log here:
> https://github.com/clojure/clojure/blob/master/changes.md
> 
> If you have questions, feel free to drop them here. For issues, please log
> them in JIRA .
> 
> 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.
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
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] Gorilla REPL 0.2.0 - all new extensible renderer

[Jony Hudson]

Hi all,

 I'm happy to announce a new release of Gorilla REPL. The number one 
comment I got from people on the original release was that it looked good, 
but they'd like to see it extended to some library or other. Jeff Rose hit 
the nail on the head with:

"Being able to render values of different types is important, and I think 
it deserves a lot of attention in both the design and documentation."

So with that in mind, on to the changes:

- All new renderer. This is the main change. The new renderer is simple and 
predictable, _very_ flexible, supports first-class pluggable custom 
rendering, and really respects the structure of Clojure values. In 
particular it renders aggregates of values as you might hope, so you can 
draw lists of tables, tables of plots, associatives of tables of tables of 
plots etc. I've made a couple of videos walking through its features, and 
how easy it is to extend. I'm really pleased with how it's come out :-)

https://vimeo.com/89529751
https://vimeo.com/89532785

As per the request, there's also documentation on it. Enough to choke a 
horse!

http://gorilla-repl.org/renderer.html

- You can open multiple tabs on the same REPL. This works really nicely - 
they each get they own session, but share the REPL.

- Runs a real nREPL server now, so should work together with things like 
vim-fireplace that make their own connection to the REPL server. (I haven't 
tested this though!)

- As you might have guessed from the above, there's now a website. 
http://gorilla-repl.org 

- Numerous small bug-fixes and feature requests.

There are some minor breaking changes, hence the version bump:

- Old worksheets will need to be re-run to regenerate their output.

- Code that dabbled with the internals of gorilla-plot might need to be 
adjusted.

It's on clojars now, with coordinates [gorilla-repl "0.2.0"] .

The new renderer lays the foundation for adding rendering for other 
libraries. I'd love to see support for core.matrix and Incanter, so I think 
this will be the immediate focus of development. If you maintain a library 
and would like to see it supported, then please do get in touch.

As always, all comments and criticism gratefully received.

[Proof-reading this email, I realise I sound rather pleased with myself. My 
apologies for that, but in truth I think I _am_ rather pleased with how 
this version has came together!]

Yours,


Jony

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Alex Miller]

Rich just pushed a change to the String hashing to address this. We're 
going to grab the string hashcode (which is cached after first call) and 
murmur the result of that. This gives us constant time hashcode after first 
call with better distribution for combinations in nested collections.  Will 
be in presumed RC2.

On Wednesday, March 19, 2014 11:26:51 AM UTC-5, Stefan Kamphausen wrote:
>
>
>
> On Wednesday, March 19, 2014 4:34:45 PM UTC+1, Alex Miller wrote:
>>
>> Thanks, this is all really useful. I would appreciate any more detailed 
>> info. 
>>>
>>>
>>>
> * No atoms, agents, refs
> * Almost purely functional plus logging and I/O
> * Multi-threaded using latest core.async with thread, no go
> * JVisualVM reports top methods in CPU sampling c.l.LazySeq.sval, 
> c.c$promise$reify_6310.deref, c.l.LazySeq.seq no notable difference for me 
> to see.
>
> A few experiments on two data-sets (dat1 and dat2) using either a call to 
> set or to doall:
>
>Clojure Op Time (dat1) Time (dat1) Average dat1 Time (dat2)  1.5.1 set 
> 19,1 19 19,05 323  1.5.1 doall 19 19,4 19,2 330  1.6.0-RC1 set 19,5 19,8 
> 19,65 350  1.6.0-RC1 doall 20,2 19,8 20 351
>
>
>
>
>  

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

Re: Clojure 1.6.0-RC1 - LAST CHANCE, PLEASE TEST

[Alex Miller]

And thanks everyone for giving RC1 a look. You are (collectively) the 
fortune in my fortune cookie.

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

[GSoC] Proposal, question and possible call for menthor

[Dmitry Groshev]

Hello, Clojurians!

GSoC application deadline is dangerously close and it's time to fill an 
application, at last. But here is a problem: I don't know what will be the 
best for community. I have a few ideas and I will present them here to get 
some feedback. Sorry for a bit late posting!

First: this is the idea listed on Ideas Page [1], "Data Visualization 
Components with Om / React.js". I would like to participate; in particular, 
I'm very interested in building a decent graph rendering library. It seems 
like there are a lot of JS libraries to draw graphs out there, but all of 
them lack features that I needed one time or another:
-composable layouts/transformations, like in Gephi (you can run one 
"transformation" after another there);
-"static" rendering without fancy animation of force-based layout;
-efficient handling of data changes (here is where React can be useful);
-ability to add user-defined forces. It's very useful when you have special 
nodes that should be pulled to particular points.
Of course, this should be based on top of React's model, which adds an 
interesting exploratory aspect to the project.
Mentor: I've tried to contact Kovas about this project, but wasn't 
successful. I hope that was a mail quirk.

Second: when I write Erlang, I enjoy PropEr (an Erlang property testing 
library) a lot. Some time ago a similar system was created for Clojure 
(test.check [2]). It's a decent property-based checker, but a couple of 
things are still lacking:
-support for stateful system checking. This is called "statem" in PropEr 
and described in [3]. It's based on modelling stateful system as FSM and 
comparing behaviour of model and system under test. One of interesting 
usages of "statem" in PropEr is to test external servers: for example, 
properly-designed REST API can be modelled pretty easily by a FSM.
-support for automatic generator inference from type specifications (in 
Clojure Prismatic's Schema can be used) [4]. Obviously, it makes using 
property-testing a lot easier.
-support for generator statistics — what instances was generated, what was 
the distribution of test sizes and so on.
In this project, if it will be selected, I will implement this three 
features for test.check. I had very positive experience with PropEr and I 
hope that this project can help more people start using property-based 
testing.
Mentor: Reid Draper. I contacted him and he agreed to mentor the project.

Third: arguably, one of the best plotting libraries around is R's ggplot 
[5]. It was recently ported to Python, as well [6]. It's different from all 
other libraries of the kind in that it implements a "grammar of graphics": 
small pieces of reusable functionality that together constitute plots. Here 
is an example:

ggplot(mry, aes(x=year, y=number, group=rating)) + geom_line(aes(colour = 
rating)) + scale_colour_gradient(low="red") # produces [7]

This fits Clojure's ideology nicely. It can also be even better in Clojure 
after a small modification of original ggplot design, which is replacing 
"overloaded plus" style with plain vectors. This is a big project, but I 
believe I can port this library to Clojure and ClojureScript in GSoC 
timeframe. The majority of code will be the same, and because this will not 
be a core.X project, I will be able to use cljx to share code. One of 
spin-offs from this project will be a simple "dataframe-like" (think R or 
Python's pandas [8]) data structure usable in both languages.
Mentor: there is no at this point. I will appreciate a lot if someone will 
volunteer.

This concludes the list of ideas. Please share your thoughts and let me 
know, if you are able to mentor me on third project! I will fill an 
application in 36 hours from now.

[1]: http://dev.clojure.org/display/community/Project+Ideas
[2]: https://github.com/clojure/test.check
[3]: http://proper.softlab.ntua.gr/papers/eirini-thesis.pdf
[4]: http://proper.softlab.ntua.gr/papers/proper_types.pdf
[5]: http://ggplot2.org/
[6]: https://pypi.python.org/pypi/ggplot
[7]: http://docs.ggplot2.org/current/geom_line-8.png
[8]: http://pandas.pydata.org/

-- 
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: STM and persistent data structures performance on mutli-core archs

[John Mastro]

> Due to the path-copy semantics, the contention gets driven to the root of the 
> tree. 

Out of curiosity, would reference counting (rather than or in addition to 
"normal" GC) help with this? Or is reference counting problematic in a highly 
concurrent environment? It seems like reference cycles will be less of an issue 
with immutable data. 

- John

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

Re: STM and persistent data structures performance on mutli-core archs

[Martin Thompson]

>
>
>1. Due to the path-copy semantics, the contention gets driven to the 
>root of the tree. 
>
>
> Out of curiosity, would reference counting (rather than or in addition to 
> "normal" GC) help with this? Or is reference counting problematic in a 
> highly concurrent environment? It seems like reference cycles will be less 
> of an issue with immutable data. 
>

Reference counting tends to be less efficient than a tracing collector in a 
concurrent environment. Reference counts must employ atomic updates that 
can be relatively expensive, e.g. similar to how 
AtomicLong.incrementAndGet() works. I've blogged on how atomic increments 
work.

http://mechanical-sympathy.blogspot.co.uk/2011/09/adventures-with-atomiclong.html

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

honeysql subquery

[Brian Craft]

Is there a way to do a subquery in honeysql, e.g.

{:select [:*] :from {:select [5]}}

(which doesn't work)?

-- 
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: honeysql subquery

[Brian Craft]

ah, got it. Need [] around the subselect.

On Wednesday, March 19, 2014 3:17:07 PM UTC-7, Brian Craft wrote:
>
> Is there a way to do a subquery in honeysql, e.g.
>
> {:select [:*] :from {:select [5]}}
>
> (which doesn't work)?
>

-- 
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] Gorilla REPL 0.2.0 - all new extensible renderer

[Paul Mooser]

This looks great, Jony - I look forward to playing with it soon! 

-- 
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] lein-4clj

[Alex Engelberg]

4clojure  is a great site for practicing various 
datatypes and concepts in Clojure. However, the code editor on the website 
is somewhat limited, mostly because it doesn't have a REPL to test out 
individual parts of your code. I'm not affiliated with 4clojure in any way, 
but I've created a leiningen plugin for working on 4clojure problems in the 
comfort of your own IDE.

https://github.com/aengelberg/lein-4clj
See the readme for more information and examples.

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

Re: [ANN] lein-4clj

[Alan Malloy]

Can you explain the difference between this 
and https://github.com/bfontaine/lein-fore-prob? I haven't really looked 
since back when https://github.com/broquaint/lein-foreclojure-plugin was 
new (in lein 1!), but it seems like there is a lein2 plugin already.

On Wednesday, March 19, 2014 4:37:46 PM UTC-7, Alex Engelberg wrote:
>
> 4clojure  is a great site for practicing 
> various datatypes and concepts in Clojure. However, the code editor on the 
> website is somewhat limited, mostly because it doesn't have a REPL to test 
> out individual parts of your code. I'm not affiliated with 4clojure in any 
> way, but I've created a leiningen plugin for working on 4clojure problems 
> in the comfort of your own IDE.
>
> https://github.com/aengelberg/lein-4clj
> See the readme for more information and examples.
>
> Enjoy!
> --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.

Re: [ANN] lein-4clj

[Alex Engelberg]

Admittedly these two libraries are very similar; I actually hadn't heard
about lein-fore-prob before (because it wasn't listed on the leiningen
plugin list wiki ).

Because I started working on this without knowledge of the other library,
it naturally has a few differences; one of which is that it creates
separate files while lein-fore-prob puts all the problems into one file
(unless multiple projects are created). Also, lein-4clj supports
project-less template creation, allowing for a quicker workflow if a
4clojure user wants to quickly try out a solution using the REPL.

Anyhow, the two projects are similar and serve essentially the same
purpose, so feel free to use whichever you'd like.

--Alex

--Alex


On Wed, Mar 19, 2014 at 4:55 PM, Alan Malloy  wrote:

> Can you explain the difference between this and
> https://github.com/bfontaine/lein-fore-prob? I haven't really looked
> since back when https://github.com/broquaint/lein-foreclojure-plugin was
> new (in lein 1!), but it seems like there is a lein2 plugin already.
>
>
> On Wednesday, March 19, 2014 4:37:46 PM UTC-7, Alex Engelberg wrote:
>>
>> 4clojure  is a great site for practicing
>> various datatypes and concepts in Clojure. However, the code editor on the
>> website is somewhat limited, mostly because it doesn't have a REPL to test
>> out individual parts of your code. I'm not affiliated with 4clojure in any
>> way, but I've created a leiningen plugin for working on 4clojure problems
>> in the comfort of your own IDE.
>>
>> https://github.com/aengelberg/lein-4clj
>> See the readme for more information and examples.
>>
>> Enjoy!
>> --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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/7kJYUuLk62A/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: STM and persistent data structures performance on mutli-core archs

[Andy C]

So, the following test puzzles me. Not because it takes virtually the same
time (I know that Fork/Join is not cheap and memory is probably the biggest
bottleneck here). But because I do not get why map (as opposed to r/ma)
uses all 8 cores on my MacBookPro.  All of them seem to be running
according to Activity Monitor at more less the same level.

user=> (def l (into [] (range 6000)))
#'user/l
user=> (time (def a (doall (map #(Math/sin (* % %)) l
"Elapsed time: 19986.18 msecs"

user=> (time (def a (doall (into [] (r/map #( Math/sin (* % %)) l)
"Elapsed time: 18980.583 msecs"

-- 
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: STM and persistent data structures performance on mutli-core archs

[Andy C]

On Wed, Mar 19, 2014 at 11:14 AM, Raoul Duke  wrote:

> > I like FSMs, but they do not compose well.
>
> some have argued for generative grammars that generate the fsm,
> because it is generally easier to compose grammars, and then generate
> the final fsm. iiuc.
>

I thought about it too but composing FSMs out of some patterns really
transcends my mind unfortunately. In another words, I have hard time to see
patterns in FSMs - they tend to be quite complex in the first place.
Sometimes a single transition might ruin the perception and completely the
properties of everything.

There is a very good book treating about subject:
http://www.amazon.com/Practical-Statecharts-Quantum-Programming-Embedded-ebook/dp/B0017UASZO/ref=sr_1_3?s=books&ie=UTF8&qid=1395284883&sr=1-3&keywords=C%2B%2B+state+machine


A.

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

honeysql function call limitation

[Brian Craft]

honeysql supports function calls by joining args with commas, e.g.

=> (hsql/format #sql/call [:foo :bar :baz])
["foo(bar, baz)"]


However sql functions have more syntax, for example group_concat(a order by 
b separator ',')

So #sql/call doesn't work. I tried implementing a clause format for 
group_concat:

=> (hsql/format {:group_concat [:value {:order :ordering :separator 
#sql/call [:chr 9]}]})
["GROUP_CONCAT(value order by ordering separator chr(9))"]

However this doesn't work inside a select:

=> (hsql/format {:select {:group_concat [:value {:order :ordering 
:separator #sql/call [:chr 9]}]} :from [:foo]})
["SELECT group_concat AS value AS ( ) FROM foo"]

Is there any solution besides dropping to raw sql?


-- 
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: honeysql function call limitation

[Brian Craft]

ugh, bit by missing [] a second time. Nevermind.

On Wednesday, March 19, 2014 8:46:37 PM UTC-7, Brian Craft wrote:
>
> honeysql supports function calls by joining args with commas, e.g.
>
> => (hsql/format #sql/call [:foo :bar :baz])
> ["foo(bar, baz)"]
>
>
> However sql functions have more syntax, for example group_concat(a order 
> by b separator ',')
>
> So #sql/call doesn't work. I tried implementing a clause format for 
> group_concat:
>
> => (hsql/format {:group_concat [:value {:order :ordering :separator 
> #sql/call [:chr 9]}]})
> ["GROUP_CONCAT(value order by ordering separator chr(9))"]
>
> However this doesn't work inside a select:
>
> => (hsql/format {:select {:group_concat [:value {:order :ordering 
> :separator #sql/call [:chr 9]}]} :from [:foo]})
> ["SELECT group_concat AS value AS ( ) FROM foo"]
>
> Is there any solution besides dropping to raw sql?
>
>
>

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