Re: ANN: babbage 1.0.0, a library for easily gathering data and computing summary measures in a declarative way

2013-02-02 Thread john
I would be very interested to learn which kind of practical problems these 
engines can solve?
Any real-world examples would help me understand the benefit of this 
approach.
Many greetings
John 

Am Samstag, 2. Februar 2013 07:44:25 UTC+1 schrieb AtKaaZ:

 seems a bit similar to https://github.com/Prismatic/plumbing


 On Sat, Feb 2, 2013 at 1:12 AM, Ben Wolfson wol...@gmail.comjavascript:
  wrote:

 ReadyForZero is open-sourcing our library for easily gathering data
 and computing summary measures in a declarative way:

 https://github.com/ReadyForZero/babbage

 The summary measure functionality allows you to compute multiple
 measures over arbitrary partitions of your input data simultaneously
 and in a single pass. You just say what you want to compute:

  (def my-fields {:y (stats :y count)
   :x (stats :x count)
   :both (stats #(+ (or (:x %) 0) (or (:y %) 0)) count
 sum mean)})

 and the sets that are of interest:

  (def my-sets (- (sets {:has-y #(contains? % :y})
(complement :has-y))) ;; could also take
 intersections, unions

 And then run it with some data:

  (calculate my-sets my-fields [{:x 1 :y 2} {:x 10} {:x 4 :y 3} {:x 5}])
 {:not-has-y
  {:y {:count 0}, :x {:count 2}, :both {:mean 7.5, :sum 15, :count 2}},
  :has-y
  {:y {:count 2}, :x {:count 2}, :both {:mean 5.0, :sum 10, :count 2}},
  :all
  {:y {:count 2}, :x {:count 4}, :both {:mean 6.25, :sum 25, :count 4}}}

 The functions :x, :y, and #(+ (or (:x %) 0) (or (:y %) 0)) defined in
 the fields map are called once per input element no matter how many
 sets the element contributes to. The function #(contains? % y) is also
 called once per input element, no matter how many unions,
 intersections, complements, etc. the set :has-y contributes to.

 A variety of measure functions, and structured means of combining
 them, are supplied; it's also easy to define additional measures.

 babbage also supplies a method for running computations structured as
 dependency graphs; this can make gathering the initial data for
 summarizing simpler to express. To give an example that's probably
 familiar from another context:

  (defgraphfn sum [xs]
 (apply + xs))
  (defgraphfn sum-squared [xs]
 (sum (map #(* % %) xs)))
  (defgraphfn count-input :count [xs]
 (count xs))
  (defgraphfn mean [count sum]
 (double (/ sum count)))
  (defgraphfn mean2 [count sum-squared]
 (double (/ sum-squared count)))
  (defgraphfn variance [mean mean2]
 (- mean2 (* mean mean)))
  (run-graph {:xs [1 2 3 4]} sum variance sum-squared count-input mean 
 mean2)
 {:sum 10
  :count 4
  :sum-squared 30
  :mean 2.5
  :variance 1.25
  :mean2 7.5
  :xs [1 2 3 4]}

 Options are provided for parallel, sequential, and lazy computation of
 the elements of the result map, and for resolving the dependency graph
 in advance of running the computation for a given input, either at
 runtime or at compile time.

 Please see the README at the github repo for more details.

 Enjoy!

 --
 Ben Wolfson
 Human kind has used its intelligence to vary the flavour of drinks,
 which may be sweet, aromatic, fermented or spirit-based. ... Family
 and social life also offer numerous other occasions to consume drinks
 for pleasure. [Larousse, Drink entry]

 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.comjavascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.





 -- 
 Please correct me if I'm wrong or incomplete,
 even if you think I'll subconsciously hate it.

  

-- 
-- 
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/groups/opt_out.




Migrate from IDEs to emacs or vim (already experienced with it) ?

2013-02-02 Thread Ersin Er
Hi all,

Just as Colin Yates announced in the thread emacs - how to wean me off the
family of Java IDEs I am in the process of moving to emacs or vim for
active development with Clojure.

My question is a bit different: I am already an experienced vim user. I
have been using vim mostly for editing shell scripts, config files etc. but
not for active development. I am also not a vim expert such as one who can
write at the speed of thought! (So this is a signal that I am not that much
bound to vim and I can make a switch.)

As far as I can see I need to type a little more in emacs for getting stuff
done than I do with vim. Despite this disadvantage(?) does emacs really
shine for begin an environment? On the other hand, vim-foreplay also looks
promising at vim's side.

I don't want to restart an editor flame war here but I really need advice.

Thanks.

-- 
Ersin Er

-- 
-- 
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/groups/opt_out.




Re: Migrate from IDEs to emacs or vim (already experienced with it) ?

2013-02-02 Thread Wolodja Wentland
On Sat, Feb 02, 2013 at 12:09 +0200, Ersin Er wrote:
 Just as Colin Yates announced in the thread emacs - how to wean me off the
 family of Java IDEs I am in the process of moving to emacs or vim for active
 development with Clojure.
 
 My question is a bit different: I am already an experienced vim user. I have
 been using vim mostly for editing shell scripts, config files etc. but not for
 active development. I am also not a vim expert such as one who can write at 
 the
 speed of thought! (So this is a signal that I am not that much bound to vim 
 and
 I can make a switch.)
 
 As far as I can see I need to type a little more in emacs for getting stuff
 done than I do with vim. Despite this disadvantage(?) does emacs really shine
 for begin an environment? On the other hand, vim-foreplay also looks promising
 at vim's side.

vim-foreplay does indeed work fine and I can only recommend it. I have been
using vim for a long time and while I wouldn't consider myself an expert I am
still very used to its vocabulary and miss its feel dearly whenever I use
something else.

I've tried Emacs (with evil), because I perceived that the Clojure community
was strongly biased in its favour, but switched back eventually because I was
working much more productively in vim. I am quite happy with the recent
developments (foreplay, vimclojure-static) that was/is being driven by gifted
plugin developers and it certainly wouldn't be a bad idea for you to use it.

I think it should be mentioned that Emacs is probably the editor with the
larger number of users in the Clojure community, which leads to a wider
variety of packages being available for it. It might make sense to switch
Emacs if Clojure integration and availability of third-party packages is your
/only/ concern. (I haven't missed anything apart from some midje integration
so far)
-- 
Wolodja babi...@gmail.com

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature


How to use pmap over a partition-all list of list?

2013-02-02 Thread Leandro Moreira
Hi there,

I have this:

*user=* (partition-all 5 (range 1 20))
((1 2 3 4 5) (6 7 8 9 10) (11 12 13 14 15) (16 17 18 19))

And I would like to apply the *pmap* over the partitions, something like: 
(the line bellow doesn't work)
*user=* (pmap + (partition-all 5 (range 1 20)))

*I would like to have this (pmap + (1 2 3 4 5) (6 7 8 9 10) (11 12 13 14 
15) (16 17 18 19)) instead of this (pmap + ((1 2 3 4 5) (6 7 8 9 10) (11 12 
13 14 15) (16 17 18 19)))*

How can I apply pmap over a partition-all result?
If it's possible, by doing that am I distributing the load better than if I 
used the pmap with the whole list?

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/groups/opt_out.




Re: Migrate from IDEs to emacs or vim (already experienced with it) ?

2013-02-02 Thread Jay Fields
If you knew neither, I'm convinced emacs would be the right answer. You'll
have more peers to using both that can help you work through problems. You
can edit the environment using a language that is similar to clojure...
There are many small reasons like that.

But, you're desire to stay in vim (which you already know) may outweigh any
of those reasons. Only you will be able to answer your question. I would
give emacs 3-6 months of a trial period and then you'll know which you
want.

2 guys on my team had previous vim experience and no previous emacs
experience. I offered to try vim with Clojure if after using emacs they
found they still preferred clojure in vim. So far, we're all still using
emacs.

Sent from my iPhone

On Feb 2, 2013, at 5:09 AM, Ersin Er ersin...@gmail.com wrote:

Hi all,

Just as Colin Yates announced in the thread emacs - how to wean me off the
family of Java IDEs I am in the process of moving to emacs or vim for
active development with Clojure.

My question is a bit different: I am already an experienced vim user. I
have been using vim mostly for editing shell scripts, config files etc. but
not for active development. I am also not a vim expert such as one who can
write at the speed of thought! (So this is a signal that I am not that much
bound to vim and I can make a switch.)

As far as I can see I need to type a little more in emacs for getting stuff
done than I do with vim. Despite this disadvantage(?) does emacs really
shine for begin an environment? On the other hand, vim-foreplay also looks
promising at vim's side.

I don't want to restart an editor flame war here but I really need advice.

Thanks.

-- 
Ersin Er

-- 
-- 
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/groups/opt_out.

-- 
-- 
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/groups/opt_out.




Re: How to use pmap over a partition-all list of list?

2013-02-02 Thread Jim - FooBar();

Use this:

(pmap #(reduce + %) (partition-all 5 (range 1 20)))

OR as you yourself said you can use 'apply' instead of reduce

Jim



On 02/02/13 12:31, Leandro Moreira wrote:

Hi there,

I have this:

*user=* (partition-all 5 (range 1 20))
((1 2 3 4 5) (6 7 8 9 10) (11 12 13 14 15) (16 17 18 19))

And I would like to apply the *pmap* over the partitions, something 
like: (the line bellow doesn't work)

*user=* (pmap + (partition-all 5 (range 1 20)))

/I would like to have this (pmap + (1 2 3 4 5) (6 7 8 9 10) (11 12 13 
14 15) (16 17 18 19)) instead of this (pmap + ((1 2 3 4 5) (6 7 8 9 
10) (11 12 13 14 15) (16 17 18 19)))/


How can I apply pmap over a partition-all result?
If it's possible, by doing that am I distributing the load better than 
if I used the pmap with the whole list?


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/groups/opt_out.




--
--
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/groups/opt_out.




Re: How to use pmap over a partition-all list of list?

2013-02-02 Thread Jim - FooBar();

aaa you want a scalar as the result? then use an outer reduce as well:

(reduce +
(pmap #(reduce + %) (partition-all 5 (range 1 20
=190

Jim


On 02/02/13 13:10, Jim - FooBar(); wrote:

Use this:

(pmap #(reduce + %) (partition-all 5 (range 1 20)))

OR as you yourself said you can use 'apply' instead of reduce

Jim



On 02/02/13 12:31, Leandro Moreira wrote:

Hi there,

I have this:

*user=* (partition-all 5 (range 1 20))
((1 2 3 4 5) (6 7 8 9 10) (11 12 13 14 15) (16 17 18 19))

And I would like to apply the *pmap* over the partitions, something 
like: (the line bellow doesn't work)

*user=* (pmap + (partition-all 5 (range 1 20)))

/I would like to have this (pmap + (1 2 3 4 5) (6 7 8 9 10) (11 12 13 
14 15) (16 17 18 19)) instead of this (pmap + ((1 2 3 4 5) (6 7 8 9 
10) (11 12 13 14 15) (16 17 18 19)))/


How can I apply pmap over a partition-all result?
If it's possible, by doing that am I distributing the load better 
than if I used the pmap with the whole list?


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/groups/opt_out.






--
--
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/groups/opt_out.




Re: How to use pmap over a partition-all list of list?

2013-02-02 Thread Leandro Moreira
Hi Jim,

Thanks for your help  time, how do I apply instead of reduce?

I was looking the documentation of pmap and it says

*(pmap fn coll  colls)*

So I think we can use pmap this way:

*(pmap + '(1 2 3) '(4 5 6) '(7 8 9) )*

Which gives us the result: *(12 15 18)*

My intention it's only to *use range and partition to substitute that*, but 
I think partition-all doesn't work like separated argument as list, 
instead. When we type:

(*partition-all 5 (range 1 20))*
Results in this:
*((1 2 3 4 5) (6 7 8 9 10) ...*

There is any way of *transforming* (maybe a macro or destruct way) this 
list in *several colls argument as expected by pmap* signature (fn coll  
colls)? 


On Saturday, February 2, 2013 11:10:35 AM UTC-2, Jim foo.bar wrote:

  Use this:

 (pmap #(reduce + %) (partition-all 5 (range 1 20)))

 OR as you yourself said you can use 'apply' instead of reduce

 Jim



 On 02/02/13 12:31, Leandro Moreira wrote:
  
 Hi there, 

  I have this:

  *user=* (partition-all 5 (range 1 20))
 ((1 2 3 4 5) (6 7 8 9 10) (11 12 13 14 15) (16 17 18 19))
  
  And I would like to apply the *pmap* over the partitions, something 
 like: (the line bellow doesn't work)
 *user=* (pmap + (partition-all 5 (range 1 20)))
  
  *I would like to have this (pmap + (1 2 3 4 5) (6 7 8 9 10) (11 12 13 14 
 15) (16 17 18 19)) instead of this (pmap + ((1 2 3 4 5) (6 7 8 9 10) (11 12 
 13 14 15) (16 17 18 19)))*

  How can I apply pmap over a partition-all result?
 If it's possible, by doing that am I distributing the load better than if 
 I used the pmap with the whole list?

  Thanks
 -- 
 -- 
 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 javascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  


  

-- 
-- 
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/groups/opt_out.




Re: How to use pmap over a partition-all list of list?

2013-02-02 Thread Leonardo Borges
this works:

(apply pmap + (partition-all 5 (range 1 20)))

And then reducing the overall result:

(reduce + (apply pmap + (partition-all 5 (range 1 20


Leonardo Borges
www.leonardoborges.com


On Sun, Feb 3, 2013 at 12:35 AM, Leandro Moreira
leandro.rhc...@gmail.com wrote:
 Hi Jim,

 Thanks for your help  time, how do I apply instead of reduce?

 I was looking the documentation of pmap and it says

 (pmap fn coll  colls)

 So I think we can use pmap this way:

 (pmap + '(1 2 3) '(4 5 6) '(7 8 9) )

 Which gives us the result: (12 15 18)

 My intention it's only to use range and partition to substitute that, but I
 think partition-all doesn't work like separated argument as list, instead.
 When we type:

 (partition-all 5 (range 1 20))
 Results in this:
 ((1 2 3 4 5) (6 7 8 9 10) ...

 There is any way of transforming (maybe a macro or destruct way) this list
 in several colls argument as expected by pmap signature (fn coll  colls)?


 On Saturday, February 2, 2013 11:10:35 AM UTC-2, Jim foo.bar wrote:

 Use this:

 (pmap #(reduce + %) (partition-all 5 (range 1 20)))

 OR as you yourself said you can use 'apply' instead of reduce

 Jim



 On 02/02/13 12:31, Leandro Moreira wrote:

 Hi there,

 I have this:

 user= (partition-all 5 (range 1 20))
 ((1 2 3 4 5) (6 7 8 9 10) (11 12 13 14 15) (16 17 18 19))

 And I would like to apply the pmap over the partitions, something like:
 (the line bellow doesn't work)
 user= (pmap + (partition-all 5 (range 1 20)))

 I would like to have this (pmap + (1 2 3 4 5) (6 7 8 9 10) (11 12 13 14
 15) (16 17 18 19)) instead of this (pmap + ((1 2 3 4 5) (6 7 8 9 10) (11 12
 13 14 15) (16 17 18 19)))

 How can I apply pmap over a partition-all result?
 If it's possible, by doing that am I distributing the load better than if
 I used the pmap with the whole list?

 Thanks
 --
 --
 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/groups/opt_out.




 --
 --
 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/groups/opt_out.



-- 
-- 
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/groups/opt_out.




Re: How to use pmap over a partition-all list of list?

2013-02-02 Thread Jim - FooBar();
apply does exactly what you're describing...it treats a collection as 
several arguments:


(apply + [1 2 3 4]) is equivalent to: (+ 1 2 3 4)
= 10

so (pmap + '(1 2 3) '(4 5 6) '(7 8 9) ) is equivalent to: (apply pmap + 
['(1 2 3) '(4 5 6) '(7 8 9)])


no need for macros and stuff...actually apply is a macro...

hope that helps

Jim

On 02/02/13 13:35, Leandro Moreira wrote:

Hi Jim,

Thanks for your help  time, how do I apply instead of reduce?

I was looking the documentation of pmap and it says

*(pmap fn coll  colls)*

So I think we can use pmap this way:

*(pmap + '(1 2 3) '(4 5 6) '(7 8 9) )*

Which gives us the result: *(12 15 18)*

My intention it's only to *use range and partition to substitute 
that*, but I think partition-all doesn't work like separated argument 
as list, instead. When we type:


(*partition-all 5 (range 1 20))*
Results in this:
*((1 2 3 4 5) (6 7 8 9 10) ...*

There is any way of *transforming* (maybe a macro or destruct way) 
this list in *several colls argument as expected by pmap* signature 
(fn coll  colls)?



On Saturday, February 2, 2013 11:10:35 AM UTC-2, Jim foo.bar wrote:

Use this:

(pmap #(reduce + %) (partition-all 5 (range 1 20)))

OR as you yourself said you can use 'apply' instead of reduce

Jim



On 02/02/13 12:31, Leandro Moreira wrote:

Hi there,

I have this:

*user=* (partition-all 5 (range 1 20))
((1 2 3 4 5) (6 7 8 9 10) (11 12 13 14 15) (16 17 18 19))

And I would like to apply the *pmap* over the partitions,
something like: (the line bellow doesn't work)
*user=* (pmap + (partition-all 5 (range 1 20)))

/I would like to have this (pmap + (1 2 3 4 5) (6 7 8 9 10) (11
12 13 14 15) (16 17 18 19)) instead of this (pmap + ((1 2 3 4 5)
(6 7 8 9 10) (11 12 13 14 15) (16 17 18 19)))/

How can I apply pmap over a partition-all result?
If it's possible, by doing that am I distributing the load better
than if I used the pmap with the whole list?

Thanks
-- 
-- 
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
javascript:
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 javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
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 javascript:.
For more options, visit https://groups.google.com/groups/opt_out
https://groups.google.com/groups/opt_out.




--
--
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/groups/opt_out.




--
--
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/groups/opt_out.




Re: How to use pmap over a partition-all list of list?

2013-02-02 Thread Marko Topolnik


 no need for macros and stuff...actually apply is a macro...


Not really, it's a function. But it does rely on the low-level IFn 
interface methods. 

-- 
-- 
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/groups/opt_out.




Re: *read-eval* vulnerability

2013-02-02 Thread Chas Emerick
Hi Baishampayan,

I got such errors when I first started working on the patch; they were caused 
by the compiler using print-dup'd strings to create namespaces instead of 
emitting bytecode (which the patched build includes).  Is it possible that you 
have both an org.clojure/clojure jar and the patched com.cemerick/clojure jar 
on your classpath?

FWIW, such metadata happens to exist in some nREPL namespaces, and some of my 
projects as well, so I presume that that's not the actual problem.

Just out of curiosity, do things work well if you use e.g. inferior-lisp or 
ritz?

Thanks for testing!

- Chas

On Feb 1, 2013, at 11:10 PM, Baishampayan Ghose wrote:

 Just did some testing with our code-base and Clojure 1.5.0-RC4 (with
 and without Chas' read-eval patch).
 
 There is definitely something strange going on. Things worked just
 fine with 1.5.0-RC4 but with the read-eval patch `lein swank` is
 completely broken but more than that, our code is failing to compile
 with this weird error -
 
 eval-reader: (clojure.lang.PersistentArrayMap/create {:author Joe Dev
 j...@helpshift.com, :doc Some doc here.})
 RuntimeException EvalReader not allowed when *read-eval* is false.
 clojure.lang.Util.runtimeException (Util.java:219)
 
 Almost all our namespaces have documentation attached via metadata like this -
 
 (ns ^{:doc Some doc here.
  :author Joe Dev j...@helpshift.com}
  com.helpshift.some.ns
  (:require [com.helpshift.other.ns :as chon])
  (:use clojure.test
midje.sweet))
 
 FWIW, the file that will fail to compile is random and I couldn't
 reproduce this error on a fresh project with just a couple of files.
 
 It's quite clear that the eval-reader is getting used from inside
 Clojure and we need to test out the edge cases a bit more.
 
 This is clearly not a low-impact fix, but IMHO we should take the time
 and get it right before 1.5.0
 
 Regards,
 BG
 
 
 On Sat, Feb 2, 2013 at 4:01 AM, Chas Emerick c...@cemerick.com wrote:
 I have added a patch to CLJ-1153 that appears to address the *read-eval* 
 problem:
 
 http://dev.clojure.org/jira/browse/CLJ-1153?focusedCommentId=30523#comment-30523
 
 code on github: 
 https://github.com/cemerick/clojure/commit/1f5c19c07443d2535ede4ff71d23b40c195d617f
 
 artifact on Clojars: [com.cemerick/clojure 1.5.0-SNAPSHOT]
 
 The Leiningen dependency above is 1.5.0-RC4 + the patch on the ticket.  Note 
 that you'll need to set your project's global :exclusions to 
 [org.clojure/clojure] in order for the com.cemerick/clojure artifact to 
 supersede it.
 
 It tests well for me, but needs to be exercised as much as possible.  Some 
 have already done so (there's an ongoing discussion on the clojure-dev ML 
 with some initial test experiences: 
 http://groups.google.com/group/clojure-dev/browse_frm/thread/cc6f747919db6c94),
  but I'm hoping that we can get as many eyes as possible on this — doing 
 both testing as well as code/patch examination — so as to ensure correctness 
 and maximize the chances of 1.5.0 final going out with this vulnerability 
 buttoned up.
 
 Thanks,
 
 - Chas
 
 --
 --
 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/groups/opt_out.
 
 
 
 
 
 -- 
 Baishampayan Ghose
 b.ghose at gmail.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/groups/opt_out.
 
 

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

Re: *read-eval* vulnerability

2013-02-02 Thread Baishampayan Ghose
I put the canonical clojure artefact in a global exclusions vector in
my project.clj. The classpath doesn't have any duplicate clojure jar
in it. I was testing it out with `lein repl`, since swank-clojure is
broken in different ways.

Regards,
BG

On Sat, Feb 2, 2013 at 7:43 PM, Chas Emerick c...@cemerick.com wrote:
 Hi Baishampayan,

 I got such errors when I first started working on the patch; they were caused 
 by the compiler using print-dup'd strings to create namespaces instead of 
 emitting bytecode (which the patched build includes).  Is it possible that 
 you have both an org.clojure/clojure jar and the patched com.cemerick/clojure 
 jar on your classpath?

 FWIW, such metadata happens to exist in some nREPL namespaces, and some of my 
 projects as well, so I presume that that's not the actual problem.

 Just out of curiosity, do things work well if you use e.g. inferior-lisp or 
 ritz?

 Thanks for testing!

 - Chas

 On Feb 1, 2013, at 11:10 PM, Baishampayan Ghose wrote:

 Just did some testing with our code-base and Clojure 1.5.0-RC4 (with
 and without Chas' read-eval patch).

 There is definitely something strange going on. Things worked just
 fine with 1.5.0-RC4 but with the read-eval patch `lein swank` is
 completely broken but more than that, our code is failing to compile
 with this weird error -

 eval-reader: (clojure.lang.PersistentArrayMap/create {:author Joe Dev
 j...@helpshift.com, :doc Some doc here.})
 RuntimeException EvalReader not allowed when *read-eval* is false.
 clojure.lang.Util.runtimeException (Util.java:219)

 Almost all our namespaces have documentation attached via metadata like this 
 -

 (ns ^{:doc Some doc here.
  :author Joe Dev j...@helpshift.com}
  com.helpshift.some.ns
  (:require [com.helpshift.other.ns :as chon])
  (:use clojure.test
midje.sweet))

 FWIW, the file that will fail to compile is random and I couldn't
 reproduce this error on a fresh project with just a couple of files.

 It's quite clear that the eval-reader is getting used from inside
 Clojure and we need to test out the edge cases a bit more.

 This is clearly not a low-impact fix, but IMHO we should take the time
 and get it right before 1.5.0

 Regards,
 BG


 On Sat, Feb 2, 2013 at 4:01 AM, Chas Emerick c...@cemerick.com wrote:
 I have added a patch to CLJ-1153 that appears to address the *read-eval* 
 problem:

 http://dev.clojure.org/jira/browse/CLJ-1153?focusedCommentId=30523#comment-30523

 code on github: 
 https://github.com/cemerick/clojure/commit/1f5c19c07443d2535ede4ff71d23b40c195d617f

 artifact on Clojars: [com.cemerick/clojure 1.5.0-SNAPSHOT]

 The Leiningen dependency above is 1.5.0-RC4 + the patch on the ticket.  
 Note that you'll need to set your project's global :exclusions to 
 [org.clojure/clojure] in order for the com.cemerick/clojure artifact to 
 supersede it.

 It tests well for me, but needs to be exercised as much as possible.  Some 
 have already done so (there's an ongoing discussion on the clojure-dev ML 
 with some initial test experiences: 
 http://groups.google.com/group/clojure-dev/browse_frm/thread/cc6f747919db6c94),
  but I'm hoping that we can get as many eyes as possible on this — doing 
 both testing as well as code/patch examination — so as to ensure 
 correctness and maximize the chances of 1.5.0 final going out with this 
 vulnerability buttoned up.

 Thanks,

 - Chas

 --
 --
 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/groups/opt_out.





 --
 Baishampayan Ghose
 b.ghose at gmail.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/groups/opt_out.



 --
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, 

Re: *read-eval* vulnerability

2013-02-02 Thread Baishampayan Ghose
By the way, this is how swank-clojure 1.4.4 is failing to compile with
the patched clojure jar -

Exception in thread main java.lang.IllegalArgumentException: No
matching ctor found for class clojure.lang.Compiler$CompilerException,
compiling:(swank/commands/basic.clj:183:24)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6607)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6588)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$ThrowExpr$Parser.parse(Compiler.java:2306)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6600)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5748)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6600)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$IfExpr$Parser.parse(Compiler.java:2679)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6600)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6588)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5748)
at clojure.lang.Compiler$TryExpr$Parser.parse(Compiler.java:2158)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6600)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5748)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5179)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3753)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6598)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3575)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6602)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$TryExpr$Parser.parse(Compiler.java:2129)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6600)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5748)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6049)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6600)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6588)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6588)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6588)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.access$100(Compiler.java:39)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6013)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6600)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6588)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5748)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5179)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3753)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6598)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6588)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.access$100(Compiler.java:39)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:531)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6600)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6588)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3626)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6602)
at clojure.lang.Compiler.analyze(Compiler.java:6401)
at clojure.lang.Compiler.analyze(Compiler.java:6362)
at clojure.lang.Compiler.compile1(Compiler.java:7185)
at clojure.lang.Compiler.compile(Compiler.java:7255)
at clojure.lang.RT.compile(RT.java:389)
at clojure.lang.RT.load(RT.java:429)
at clojure.lang.RT.load(RT.java:402)
at clojure.core$load$fn__5043.invoke(core.clj:5520)
at clojure.core$load.doInvoke(core.clj:5519)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5326)
at clojure.core$load_lib$fn__4992.invoke(core.clj:5365)
at clojure.core$load_lib.doInvoke(core.clj:5364)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at 

Re: How to use pmap over a partition-all list of list?

2013-02-02 Thread Leandro Moreira
Thanks all, you were really helpful ! 

-- 
-- 
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/groups/opt_out.




Re: *read-eval* vulnerability

2013-02-02 Thread Chas Emerick
Ah, I didn't grok that you were reporting two separate breakages (one in swank, 
one in your app).

I think the problem is in how the lein-swank plugin sets up dependencies (or, 
how Leiningen itself applies :exclusions).  If you don't have an 
org.clojure/clojure dependency in your project, then lein-swank will add one, 
its default (v1.2.1).  In this case, I found I did have two clojure jars; my 
1.5.0-SNAPSHOT, and [org.clojure/clojure 1.2.1].  This explains the bizarre 
message of No
matching ctor found for class clojure.lang.Compiler$CompilerException.  In my 
verification of swank, I ended up just temporarily swapping the 
com.cemerick/clojure build in where the official RC4 sits in ~/.m2/repository; 
once I did that, swank was happy.

I haven't yet been able to duplicate the other fault you saw.  If it was really 
due to namespace metadata, then `lein repl` wouldn't ever start, given 
clojure.tools.nrepl.server's namespace metadata 
(https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/server.clj).
  I wonder if you could produce a cut-down example that exhibits the issue 
repeatably?

Thanks,

- Chas

On Feb 2, 2013, at 9:22 AM, Baishampayan Ghose wrote:

 I put the canonical clojure artefact in a global exclusions vector in
 my project.clj. The classpath doesn't have any duplicate clojure jar
 in it. I was testing it out with `lein repl`, since swank-clojure is
 broken in different ways.
 
 Regards,
 BG
 
 On Sat, Feb 2, 2013 at 7:43 PM, Chas Emerick c...@cemerick.com wrote:
 Hi Baishampayan,
 
 I got such errors when I first started working on the patch; they were 
 caused by the compiler using print-dup'd strings to create namespaces 
 instead of emitting bytecode (which the patched build includes).  Is it 
 possible that you have both an org.clojure/clojure jar and the patched 
 com.cemerick/clojure jar on your classpath?
 
 FWIW, such metadata happens to exist in some nREPL namespaces, and some of 
 my projects as well, so I presume that that's not the actual problem.
 
 Just out of curiosity, do things work well if you use e.g. inferior-lisp or 
 ritz?
 
 Thanks for testing!
 
 - Chas
 
 On Feb 1, 2013, at 11:10 PM, Baishampayan Ghose wrote:
 
 Just did some testing with our code-base and Clojure 1.5.0-RC4 (with
 and without Chas' read-eval patch).
 
 There is definitely something strange going on. Things worked just
 fine with 1.5.0-RC4 but with the read-eval patch `lein swank` is
 completely broken but more than that, our code is failing to compile
 with this weird error -
 
 eval-reader: (clojure.lang.PersistentArrayMap/create {:author Joe Dev
 j...@helpshift.com, :doc Some doc here.})
 RuntimeException EvalReader not allowed when *read-eval* is false.
 clojure.lang.Util.runtimeException (Util.java:219)
 
 Almost all our namespaces have documentation attached via metadata like 
 this -
 
 (ns ^{:doc Some doc here.
 :author Joe Dev j...@helpshift.com}
 com.helpshift.some.ns
 (:require [com.helpshift.other.ns :as chon])
 (:use clojure.test
   midje.sweet))
 
 FWIW, the file that will fail to compile is random and I couldn't
 reproduce this error on a fresh project with just a couple of files.
 
 It's quite clear that the eval-reader is getting used from inside
 Clojure and we need to test out the edge cases a bit more.
 
 This is clearly not a low-impact fix, but IMHO we should take the time
 and get it right before 1.5.0
 
 Regards,
 BG
 
 
 On Sat, Feb 2, 2013 at 4:01 AM, Chas Emerick c...@cemerick.com wrote:
 I have added a patch to CLJ-1153 that appears to address the *read-eval* 
 problem:
 
 http://dev.clojure.org/jira/browse/CLJ-1153?focusedCommentId=30523#comment-30523
 
 code on github: 
 https://github.com/cemerick/clojure/commit/1f5c19c07443d2535ede4ff71d23b40c195d617f
 
 artifact on Clojars: [com.cemerick/clojure 1.5.0-SNAPSHOT]
 
 The Leiningen dependency above is 1.5.0-RC4 + the patch on the ticket.  
 Note that you'll need to set your project's global :exclusions to 
 [org.clojure/clojure] in order for the com.cemerick/clojure artifact to 
 supersede it.
 
 It tests well for me, but needs to be exercised as much as possible.  Some 
 have already done so (there's an ongoing discussion on the clojure-dev ML 
 with some initial test experiences: 
 http://groups.google.com/group/clojure-dev/browse_frm/thread/cc6f747919db6c94),
  but I'm hoping that we can get as many eyes as possible on this — doing 
 both testing as well as code/patch examination — so as to ensure 
 correctness and maximize the chances of 1.5.0 final going out with this 
 vulnerability buttoned up.
 
 Thanks,
 
 - Chas
 
 --
 --
 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 

Re: *read-eval* vulnerability

2013-02-02 Thread Chas Emerick
One thing that hasn't been mentioned so far is that AOT-compiled classfiles 
generated using prior builds of Clojure will not load using a build of Clojure 
that includes a patch like this.  Just something to consider for those of you 
taking the time to test, etc.

- Chas

-- 
-- 
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/groups/opt_out.




Re: ANN: babbage 1.0.0, a library for easily gathering data and computing summary measures in a declarative way

2013-02-02 Thread Ben Wolfson
On Sat, Feb 2, 2013 at 12:28 AM, john john.vie...@gmail.com wrote:
 I would be very interested to learn which kind of practical problems these
 engines can solve?
 Any real-world examples would help me understand the benefit of this
 approach.

We're using it for (nearly) all of our analytics stuff now, and all
new analytics code being written; rewritten old analytics code is now
shorter, faster, and clearer.

If you are, say, selling things, and there are some attributes you
want to compute regarding items sold (say, total price, average price,
average # of items per sale, and also all that information per type of
item sold), you can declare those fields in one place. You can then
also easily declare sets of interest, say, sales made in the last day,
last week, last month, last year; sales made where at least one of the
items was over a particular price point; sales made where where the
shipping option was X, and then perform various set operations on
them, so that when you end up computing the measures you want, you get
them not only for all the input, but you also get, at a go, the
average price of sales of items in the electronics category where
the sale was made in the last week and at least one item in the sale
was over a particular price point or the shipping option was not X.
Etc.

This is admittedly a hypothetical real-world example, since we do not
sell or ship things, but it's a realer-world example than just summing
the values of :x keys in maps, which could easily be done with vanilla
reduce and map. Where this shines is when you want to get *multiple*
summary values out of your data across a variety of partitions of it.

The graph function--related stuff is admittedly similar to (and
inspired by) the Prismatic library, which wasn't released when I
started adding the functionality to babbage, but I prefer it, in part
because functions defined with defgraphfn can be called just as
ordinary clojure functions with no knowledge of their extra metadata,
whereas functions defined with defnk/fnk have an idiosyncratic calling
convention, AFAICT. The motivation in my case was that code for some
of the analytics stuff being rewritten could have shared data between
different computed analytics, but it wasn't obvious what the
dependency relations were and reorganizing things to use a gigantic
let, for instance, would have been a colossal PITA (in addition to
being very brittle). It's much simpler to have a bunch of functions
defined with defgraphfn that declare what they need to do their own
work and what they provide themselves, supply a few initial values,
and let run-graph figure out what has to be run before what.

-- 
Ben Wolfson
Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure. [Larousse, Drink entry]

-- 
-- 
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/groups/opt_out.




Re: clojure web developer job offer

2013-02-02 Thread Denis Labaye
On Fri, Feb 1, 2013 at 12:01 AM, Vagif Verdi vagif.ve...@gmail.com wrote:

 Our company is looking for a full time or consultant developer.

 The job is to maintain and continue actively develop web application /
 internal webservices written in clojure.

 We use compojure web framework, darcs for repository.

 Remote work via ssh is ok.

 Haskell knowledge is a big plus. We have internal web services written in
 haskell.

 We are located in San Dimas, CA. But relocation is not necessary.

 Requirements: good grasp of functional programming, at least one year of
 production coding with clojure or haskell.

 Contact me if intrested.


Is it an option to work from Europe?


  --
 --
 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/groups/opt_out.




-- 
-- 
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/groups/opt_out.




Re: ANN: babbage 1.0.0, a library for easily gathering data and computing summary measures in a declarative way

2013-02-02 Thread Jason Wolfe
Hi -- author of Prismatic's Graph here.  (just released last week: 
https://github.com/prismatic/plumbing)

This looks like a very cool library -- thanks for the release!

You're right that our fnk and defnk take keyword rather than positional 
arguments, and in that sense are 'idiosyncratic'.  But the really nice 
thing about this, IMO, is that nodes and graphs are nicely parallel.  Both 
fnks and graphs have the same keyword calling convention, and support the 
same metadata about input and output structure.  This makes it a breeze to 
support hierarchical graphs, which we use extensively -- a node can be a 
fnk, or another graph (uncompiled), or that same graph pre-compiled to a 
fnk.  

Surface differences aside, it would be really great if we could converge on 
a common protocol and structure for graph/node input and output metadata, 
since that could allow people to write code that worked with both 
libraries, rather than forcing people to choose and end up with separate 
silos.  I'd love to discuss this (and hear your comments on our 
implementation) here or off-list.

Cheers, 
Jason

On Saturday, February 2, 2013 9:38:03 AM UTC-8, Ben wrote:

 On Sat, Feb 2, 2013 at 12:28 AM, john john@gmail.com javascript: 
 wrote: 
  I would be very interested to learn which kind of practical problems 
 these 
  engines can solve? 
  Any real-world examples would help me understand the benefit of this 
  approach. 

 We're using it for (nearly) all of our analytics stuff now, and all 
 new analytics code being written; rewritten old analytics code is now 
 shorter, faster, and clearer. 

 If you are, say, selling things, and there are some attributes you 
 want to compute regarding items sold (say, total price, average price, 
 average # of items per sale, and also all that information per type of 
 item sold), you can declare those fields in one place. You can then 
 also easily declare sets of interest, say, sales made in the last day, 
 last week, last month, last year; sales made where at least one of the 
 items was over a particular price point; sales made where where the 
 shipping option was X, and then perform various set operations on 
 them, so that when you end up computing the measures you want, you get 
 them not only for all the input, but you also get, at a go, the 
 average price of sales of items in the electronics category where 
 the sale was made in the last week and at least one item in the sale 
 was over a particular price point or the shipping option was not X. 
 Etc. 

 This is admittedly a hypothetical real-world example, since we do not 
 sell or ship things, but it's a realer-world example than just summing 
 the values of :x keys in maps, which could easily be done with vanilla 
 reduce and map. Where this shines is when you want to get *multiple* 
 summary values out of your data across a variety of partitions of it. 

 The graph function--related stuff is admittedly similar to (and 
 inspired by) the Prismatic library, which wasn't released when I 
 started adding the functionality to babbage, but I prefer it, in part 
 because functions defined with defgraphfn can be called just as 
 ordinary clojure functions with no knowledge of their extra metadata, 
 whereas functions defined with defnk/fnk have an idiosyncratic calling 
 convention, AFAICT. The motivation in my case was that code for some 
 of the analytics stuff being rewritten could have shared data between 
 different computed analytics, but it wasn't obvious what the 
 dependency relations were and reorganizing things to use a gigantic 
 let, for instance, would have been a colossal PITA (in addition to 
 being very brittle). It's much simpler to have a bunch of functions 
 defined with defgraphfn that declare what they need to do their own 
 work and what they provide themselves, supply a few initial values, 
 and let run-graph figure out what has to be run before what. 

 -- 
 Ben Wolfson 
 Human kind has used its intelligence to vary the flavour of drinks, 
 which may be sweet, aromatic, fermented or spirit-based. ... Family 
 and social life also offer numerous other occasions to consume drinks 
 for pleasure. [Larousse, Drink entry] 


-- 
-- 
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/groups/opt_out.




Re: ANN: babbage 1.0.0, a library for easily gathering data and computing summary measures in a declarative way

2013-02-02 Thread David Powell
I'm sure these libraries do the job better, but just for interest, here is
a fun example of using finger-trees to maintain stats for a collection as
it gets updated:

https://gist.github.com/672592

-- 
Dave

-- 
-- 
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/groups/opt_out.




ANN: Simulant: a framework for simulation-based testing

2013-02-02 Thread Stuart Halloway
I am pleased to announce the release of Simulant, an open-source framework
for simulation-based testing built using Datomic and Clojure:

https://github.com/Datomic/simulant

Feedback welcome!

Stu

-- 
-- 
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/groups/opt_out.




Re: Migrate from IDEs to emacs or vim (already experienced with it) ?

2013-02-02 Thread Kris Jenkins
For what it's worth, I'm a diehard vi user and have been for many years, 
but Emacs' latest Vim-emulation (called evil-mode) is really very, very 
good. So good that Emacs is fighting to be my favourite version of Vi yet.

You'll be walking a lonely road, but if you want Emacs *and* Vim, it's 
actually possible these days...

Kris


On Saturday, 2 February 2013 10:09:00 UTC, Ersin Er wrote:

 Hi all,

 Just as Colin Yates announced in the thread emacs - how to wean me off 
 the family of Java IDEs I am in the process of moving to emacs or vim for 
 active development with Clojure.

 My question is a bit different: I am already an experienced vim user. I 
 have been using vim mostly for editing shell scripts, config files etc. but 
 not for active development. I am also not a vim expert such as one who can 
 write at the speed of thought! (So this is a signal that I am not that much 
 bound to vim and I can make a switch.)

 As far as I can see I need to type a little more in emacs for getting 
 stuff done than I do with vim. Despite this disadvantage(?) does emacs 
 really shine for begin an environment? On the other hand, vim-foreplay also 
 looks promising at vim's side.

 I don't want to restart an editor flame war here but I really need advice.

 Thanks.

 -- 
 Ersin Er 


-- 
-- 
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/groups/opt_out.




Re: Migrate from IDEs to emacs or vim (already experienced with it) ?

2013-02-02 Thread Curtis Gagliardi
I've been using vim pretty exclusively for the last 5 years or so, but in 
the last few weeks I've been using emacs with evil mode and I couldn't be 
happier.  It's a beautiful thing to have emacs extreme extensibility with 
vim's vastly superior keybindings.  I have my config here if you're 
interested https://github.com/cgag/dotfiles/blob/master/.emacs

Still, if you don't want to deal with emacs, vim is definitely viable. 
 Vimclojure is a pain to get set up, but once you do it's solid.  Foreplay 
is definitely worth checking out, but I couldn't stand not having a real 
repl buffer personally.

-- 
-- 
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/groups/opt_out.




Re: Migrate from IDEs to emacs or vim (already experienced with it) ?

2013-02-02 Thread Gregory Graham
I first learned vi (the predecessor to vim) working on a senior project in 
college in the early 1980s, and then learned Gosling emacs at my first job 
in the late 1980s. Since then, I have gone back and forth between the two 
for various reasons, and I'm about equally comfortable in each of them. For 
a while, I preferred vim since it had better GUI font rendering than emacs, 
but since I started playing with Clojure, I got back into emacs, using 
nrepl, and I must say it's a pretty nice setup. The font rendering is no 
longer an issue, and emacs now has a cool package install feature that 
makes adding advanced features a breeze.


My perception is that emacs has an edge in the Lisp/Clojure world, but I 
see plenty of people using vim. I have not tried a vim clojure setup 
because once I got emacs setup, I was happy. If you are used to vim, and 
you find it works well for Clojure, then there's nothing wrong with going 
with that. After all, its about finding a tool that works for you, whether 
or not it's the most popular or the coolest.

-- 
-- 
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/groups/opt_out.




Why is this code so slow?

2013-02-02 Thread Alexandros Bantis
Hello all. I'm working through the Project Euler problems in Java, 
Scala,  Clojure (trying to learn all three?!?). I notice that for one 
particular problem, I use--more or less--a similar algorithm for all 
three, but the clojure code runs about 20-30 times slower than the 
java/scala versions. Does anyone have any idea why this might be? It 
strikes me that it might have something to do with every? but I don't 
know because I'm a newbie with Clojure.


http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code

thanks,

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/groups/opt_out.




ANN: http-kit 2.0.0.RC2, high performance HTTP Server Client for Clojure

2013-02-02 Thread Shen, Feng
Hi,

After extensive test,  known bugs  fixed, documentation ready,  http-kit
reaches 2.0.0.RC2

[http-kit 2.0.0-RC2] ; Add to your project.clj

Documentation: http://http-kit.org
Github: https://github.com/http-kit/http-kit

The goal of http-kit is to provide a clean, robust HTTP server/client, with
Nginx alike performance and concurrency, for Clojure.
The server is ring compliant adapter with async and websocket support.
 I expect it to be faster than node.
The client has a clj-http alike API,  asynchronous in nature, synchronous
with @promise.

I invite everybody who interested to have a look,
questions/comments/suggestions/whatever are welcome!

Thanks @ptaoussanis and others for their contribution.

Feng

-- 
-- 
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/groups/opt_out.




Re: ANN: http-kit 2.0.0.RC2, high performance HTTP Server Client for Clojure

2013-02-02 Thread Baishampayan Ghose
Congratulations, Feng. HTTP-Kit is awesome! ~BG

On Sun, Feb 3, 2013 at 8:50 AM, Shen, Feng shen...@gmail.com wrote:
 Hi,

 After extensive test,  known bugs  fixed, documentation ready,  http-kit
 reaches 2.0.0.RC2


 [http-kit 2.0.0-RC2] ; Add to your project.clj

 Documentation: http://http-kit.org
 Github: https://github.com/http-kit/http-kit

 The goal of http-kit is to provide a clean, robust HTTP server/client, with
 Nginx alike performance and concurrency, for Clojure.
 The server is ring compliant adapter with async and websocket support.  I
 expect it to be faster than node.
 The client has a clj-http alike API,  asynchronous in nature, synchronous
 with @promise.

 I invite everybody who interested to have a look,
 questions/comments/suggestions/whatever are welcome!

 Thanks @ptaoussanis and others for their contribution.

 Feng

 --
 --
 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/groups/opt_out.





-- 
Baishampayan Ghose
b.ghose at gmail.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/groups/opt_out.




Re: Why is this code so slow?

2013-02-02 Thread Feng Shen
I can only think about a bit faster version:   46555ms = 23846ms for 20

(defn smallest-multiple-of-1-to-n
 [n]
  (let [divisors (range 2 (inc n))]
   (loop [i n]
 (if (loop [d 2]
(cond ( d n) true
  (not= 0 (mod i d)) false
  :else (recur (inc d
 i
 (recur (inc i))


I am not familiar with how Clojure's numeric works.  There should be a 
faster way of doing it in Clojure.

On Sunday, February 3, 2013 10:28:09 AM UTC+8, Alexandros Bantis wrote:

 Hello all. I'm working through the Project Euler problems in Java, 
 Scala,  Clojure (trying to learn all three?!?). I notice that for one 
 particular problem, I use--more or less--a similar algorithm for all 
 three, but the clojure code runs about 20-30 times slower than the 
 java/scala versions. Does anyone have any idea why this might be? It 
 strikes me that it might have something to do with every? but I don't 
 know because I'm a newbie with Clojure. 


 http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code
  

 thanks, 

 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/groups/opt_out.




Performance issue with hashing records

2013-02-02 Thread Mark Engelberg
I just went through the process of converting my map-based program over to
records, hoping it would improve speed.  Much to my dismay, it actually
slowed my program down substantially.  With some profiling, I discovered
that one possible explanation is that (at least in RC4) hashing of records
is about 60x slower than their map-based counterpart.

(defrecord A [x y])
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 90.631072 msecs
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 5549.788311 msecs

Any thoughts about why this is the case?

-- 
-- 
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/groups/opt_out.




Re: Performance issue with hashing records

2013-02-02 Thread Leonardo Borges
Are you running these in Clojure 1.5 RC-1 by any chance? That's when I
got results similar to yours.

In Clojure 1.4, I get this:

user (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 5993.331 msecs
nil
user  (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 3144.368 msecs

No clue as to the reason though - but it seems something might have
changed from 1.4 to 1.5?


Leonardo Borges
www.leonardoborges.com


On Sun, Feb 3, 2013 at 5:07 PM, Mark Engelberg mark.engelb...@gmail.com wrote:
 I just went through the process of converting my map-based program over to
 records, hoping it would improve speed.  Much to my dismay, it actually
 slowed my program down substantially.  With some profiling, I discovered
 that one possible explanation is that (at least in RC4) hashing of records
 is about 60x slower than their map-based counterpart.

 (defrecord A [x y])
 = (time (dotimes [n 1000] (hash {:x a :y 3})))
 Elapsed time: 90.631072 msecs
 = (time (dotimes [n 1000] (hash (A. a 3
 Elapsed time: 5549.788311 msecs

 Any thoughts about why this is the case?

 --
 --
 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/groups/opt_out.



-- 
-- 
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/groups/opt_out.




Re: Performance issue with hashing records

2013-02-02 Thread AtKaaZ
he's in RC4
= *clojure-version*
{:major 1, :minor 5, :incremental 0, :qualifier RC4}

= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 70.037502 msecs

= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 5307.93947 msecs


On Sun, Feb 3, 2013 at 8:22 AM, Leonardo Borges leonardoborges...@gmail.com
 wrote:

 Are you running these in Clojure 1.5 RC-1 by any chance? That's when I
 got results similar to yours.

 In Clojure 1.4, I get this:

 user (time (dotimes [n 1000] (hash {:x a :y 3})))
 Elapsed time: 5993.331 msecs
 nil
 user  (time (dotimes [n 1000] (hash (A. a 3
 Elapsed time: 3144.368 msecs

 No clue as to the reason though - but it seems something might have
 changed from 1.4 to 1.5?


 Leonardo Borges
 www.leonardoborges.com


 On Sun, Feb 3, 2013 at 5:07 PM, Mark Engelberg mark.engelb...@gmail.com
 wrote:
  I just went through the process of converting my map-based program over
 to
  records, hoping it would improve speed.  Much to my dismay, it actually
  slowed my program down substantially.  With some profiling, I discovered
  that one possible explanation is that (at least in RC4) hashing of
 records
  is about 60x slower than their map-based counterpart.
 
  (defrecord A [x y])
  = (time (dotimes [n 1000] (hash {:x a :y 3})))
  Elapsed time: 90.631072 msecs
  = (time (dotimes [n 1000] (hash (A. a 3
  Elapsed time: 5549.788311 msecs
 
  Any thoughts about why this is the case?
 
  --
  --
  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/groups/opt_out.
 
 

 --
 --
 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/groups/opt_out.





-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

-- 
-- 
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/groups/opt_out.




Re: Performance issue with hashing records

2013-02-02 Thread Mark Engelberg
Clojure 1.5 RC-4

-- 
-- 
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/groups/opt_out.




Re: Performance issue with hashing records

2013-02-02 Thread AtKaaZ
= (def m {:x a :y 3})
#'runtime.q_test/m
= (time (dotimes [n 1000] (hash m)))
Elapsed time: 154.650091 msecs
nil
= (time (dotimes [n 1000] (hash m)))
Elapsed time: 164.724641 msecs
nil
= (time (dotimes [n 1000] (hash m)))
Elapsed time: 150.194984 msecs
nil
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 57.981602 msecs
nil
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 70.803223 msecs
nil
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 67.395947 msecs
nil


= (def r (A. a 3))
#'runtime.q_test/r
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 4906.641334 msecs
nil
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 4959.124395 msecs
nil
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 4842.496589 msecs
nil
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 4856.855515 msecs
nil




On Sun, Feb 3, 2013 at 8:26 AM, AtKaaZ atk...@gmail.com wrote:

 he's in RC4
 = *clojure-version*
 {:major 1, :minor 5, :incremental 0, :qualifier RC4}


 = (time (dotimes [n 1000] (hash {:x a :y 3})))
 Elapsed time: 70.037502 msecs


 = (time (dotimes [n 1000] (hash (A. a 3
 Elapsed time: 5307.93947 msecs


 On Sun, Feb 3, 2013 at 8:22 AM, Leonardo Borges 
 leonardoborges...@gmail.com wrote:

 Are you running these in Clojure 1.5 RC-1 by any chance? That's when I
 got results similar to yours.

 In Clojure 1.4, I get this:

 user (time (dotimes [n 1000] (hash {:x a :y 3})))
 Elapsed time: 5993.331 msecs
 nil
 user  (time (dotimes [n 1000] (hash (A. a 3
 Elapsed time: 3144.368 msecs

 No clue as to the reason though - but it seems something might have
 changed from 1.4 to 1.5?


 Leonardo Borges
 www.leonardoborges.com


 On Sun, Feb 3, 2013 at 5:07 PM, Mark Engelberg mark.engelb...@gmail.com
 wrote:
  I just went through the process of converting my map-based program over
 to
  records, hoping it would improve speed.  Much to my dismay, it actually
  slowed my program down substantially.  With some profiling, I discovered
  that one possible explanation is that (at least in RC4) hashing of
 records
  is about 60x slower than their map-based counterpart.
 
  (defrecord A [x y])
  = (time (dotimes [n 1000] (hash {:x a :y 3})))
  Elapsed time: 90.631072 msecs
  = (time (dotimes [n 1000] (hash (A. a 3
  Elapsed time: 5549.788311 msecs
 
  Any thoughts about why this is the case?
 
  --
  --
  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/groups/opt_out.
 
 

 --
 --
 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/groups/opt_out.





 --
 Please correct me if I'm wrong or incomplete,
 even if you think I'll subconsciously hate it.




-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

-- 
-- 
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/groups/opt_out.




Re: Performance issue with hashing records

2013-02-02 Thread AtKaaZ
ok i like this variant:
= (def r (memoize (A. a 3)))
#'runtime.q_test/r
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 342.363961 msecs
nil
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 361.66747 msecs
nil

= (time (dotimes [n 1000] (hash (memoize (A. a 3)
Elapsed time: 1812.016478 msecs
nil
= (time (dotimes [n 1000] (hash (memoize (A. a 3)
Elapsed time: 1847.244062 msecs
nil




On Sun, Feb 3, 2013 at 8:29 AM, AtKaaZ atk...@gmail.com wrote:

 = (def m {:x a :y 3})
 #'runtime.q_test/m
 = (time (dotimes [n 1000] (hash m)))
 Elapsed time: 154.650091 msecs
 nil
 = (time (dotimes [n 1000] (hash m)))
 Elapsed time: 164.724641 msecs
 nil
 = (time (dotimes [n 1000] (hash m)))
 Elapsed time: 150.194984 msecs
 nil

 = (time (dotimes [n 1000] (hash {:x a :y 3})))
 Elapsed time: 57.981602 msecs
 nil

 = (time (dotimes [n 1000] (hash {:x a :y 3})))
 Elapsed time: 70.803223 msecs
 nil

 = (time (dotimes [n 1000] (hash {:x a :y 3})))
 Elapsed time: 67.395947 msecs
 nil


 = (def r (A. a 3))
 #'runtime.q_test/r
 = (time (dotimes [n 1000] (hash r)))
 Elapsed time: 4906.641334 msecs
 nil
 = (time (dotimes [n 1000] (hash r)))
 Elapsed time: 4959.124395 msecs
 nil

 = (time (dotimes [n 1000] (hash (A. a 3
 Elapsed time: 4842.496589 msecs
 nil

 = (time (dotimes [n 1000] (hash (A. a 3
 Elapsed time: 4856.855515 msecs
 nil




 On Sun, Feb 3, 2013 at 8:26 AM, AtKaaZ atk...@gmail.com wrote:

 he's in RC4
 = *clojure-version*
 {:major 1, :minor 5, :incremental 0, :qualifier RC4}


 = (time (dotimes [n 1000] (hash {:x a :y 3})))
 Elapsed time: 70.037502 msecs


 = (time (dotimes [n 1000] (hash (A. a 3
 Elapsed time: 5307.93947 msecs


 On Sun, Feb 3, 2013 at 8:22 AM, Leonardo Borges 
 leonardoborges...@gmail.com wrote:

 Are you running these in Clojure 1.5 RC-1 by any chance? That's when I
 got results similar to yours.

 In Clojure 1.4, I get this:

 user (time (dotimes [n 1000] (hash {:x a :y 3})))
 Elapsed time: 5993.331 msecs
 nil
 user  (time (dotimes [n 1000] (hash (A. a 3
 Elapsed time: 3144.368 msecs

 No clue as to the reason though - but it seems something might have
 changed from 1.4 to 1.5?


 Leonardo Borges
 www.leonardoborges.com


 On Sun, Feb 3, 2013 at 5:07 PM, Mark Engelberg mark.engelb...@gmail.com
 wrote:
  I just went through the process of converting my map-based program
 over to
  records, hoping it would improve speed.  Much to my dismay, it actually
  slowed my program down substantially.  With some profiling, I
 discovered
  that one possible explanation is that (at least in RC4) hashing of
 records
  is about 60x slower than their map-based counterpart.
 
  (defrecord A [x y])
  = (time (dotimes [n 1000] (hash {:x a :y 3})))
  Elapsed time: 90.631072 msecs
  = (time (dotimes [n 1000] (hash (A. a 3
  Elapsed time: 5549.788311 msecs
 
  Any thoughts about why this is the case?
 
  --
  --
  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/groups/opt_out.
 
 

 --
 --
 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/groups/opt_out.





 --
 Please correct me if I'm wrong or incomplete,
 even if you think I'll subconsciously hate it.




 --
 Please correct me if I'm wrong or incomplete,
 even if you think I'll subconsciously hate it.




-- 
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to

Re: Why is this code so slow?

2013-02-02 Thread Curtis Gagliardi
I took your version Feng and used rem instead of mod and added a type hint 
and got down from:
23217.321626 = 11398.389942

No idea where to go from here though.  I'm surprised there's such a 
difference even not using any sort of collection.

(defn smallest-multiple-of-1-to-n-hinted-rem
  [^long n]
  (loop [i n]
(if (loop [d 2]
  (cond ( d n) true
(not= 0 (rem i d)) false
:else (recur (inc d
  i
  (recur (inc i

-- 
-- 
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/groups/opt_out.