date:20120723

Hello.

I did a naive simple benchmark of Haskell and Scala recently and now i 
decided to add Clojure to the picture. Here is the idea 
http://blog.worldcognition.com/2012/06/folding-tree-to-list-benchmark-scala-vs.html

So, I wrote the following functions:

(defn generate-tree [[h  t :as coll]]
  (if (seq coll)
(let [lr (generate-tree t)] [h lr lr])
nil))

(defn to-list [[v l r :as node]]
  (if-not (nil? node)
(concat
 (to-list l)
 (lazy-seq (cons v (to-list r
[]))

Now I get these results:

(def tree (generate-tree (range 1 21)))

(do (time (doall (to-list tree))) :done)
Elapsed time: 1681.75 msecs
:done

If I remove the 'lazy-seq' wrapping second 'concat' argument, things become 
worst:

(do (time (doall (to-list tree))) :done)
Elapsed time: 19716.222 msecs

Why is this so? Both results are kind of disappointing for me cause Scala 
gives me ~270ms time using functional code and 5x faster using the mutable 
one (on much slower machine).

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

Re: Any downside of record compared to map

2012-07-23 Thread Ben Mabey


On 7/22/12 5:42 PM, Warren Lynn wrote:
I plan to change all my major data structures to records instead of 
plain maps. Since record has everything a map provides, I figure there 
won't be any harm. But is that really so? Would appreciate the 
opinions from people who know better.



Another downside I have ran into that hasn't been mentioned is with 
(Java) serialization.  If you are using records and defining protocols 
inline you can serialize the record just fine, however if you change the 
implementation then all of your old serialized records are incompatible 
even if the change was superficial.  The Java solution to this problem 
is to define a 'static final long serialVersionUID' however AFAIK there 
is no way to define this on a Clojure record.  (If someone knows better 
please let me know since loosing data after every protocol change is 
very annoying...) If you use multi-methods instead of protocols you 
won't run into this issue.


-Ben

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

Re: Little becnhmark (need insight)

2012-07-23 Thread Sergey Didenko

Hi,

lazy seqs are slow for number crunching, you can try to remove them.

Then you can check that you make (set! *warn-on-reflection* true). And
that your code does not have the warnings.

Then may be use native (Java) data structures or even arrays.

Then you can change defn for definline for sensitive code.

Also see the thread can Clojure 1.3 code always be made as fast as
Java for numeric computations?

Sergey

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

Re: Little becnhmark (need insight)

I would guess you'd get closer to Scala's perf if you use records to
represent your trees, rather than vectors.

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

Re: Any downside of record compared to map

2012-07-23 Thread Aravindh Johendran


On Monday, July 23, 2012 8:20:40 AM UTC-4, Lee wrote: 


 Considering that maps do have upsides compared to records in some cases 
 (as indicated, e.g., by Chas's flowchart), and that struct-maps add a 
 couple of handy features in the context of some uses of maps, can anybody 
 say why struct-maps are deprecated? 

  -Lee 

 
Are struct-maps really deprecated? I don't see a deprecation warning 
anywhere (clojure website, source, api, etc.). All I see is the following 
line in clojure website.
*--- Note: Most uses of StructMaps would now be better served by 
**records*http://clojure.org/datatypes
*.*
Is the use of struct-maps officially being discouraged? Is that the same as 
being almost deprecated? Will struct-maps go away in a future release?
 
 
 

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

Re: Any downside of record compared to map

2012-07-23 Thread Phil Hagelberg

On Mon, Jul 23, 2012 at 11:59 AM, Ben Mabey b...@benmabey.com wrote:
 Another downside I have ran into that hasn't been mentioned is with (Java)
 serialization.  If you are using records and defining protocols inline you
 can serialize the record just fine, however if you change the implementation
 then all of your old serialized records are incompatible even if the change
 was superficial.

Another related downside is that during development, you'll reload
your defrecord forms, and each time you do so it creates a new class
that is visually indistinguishable from the last. Witness:

user (defrecord x [a b c])
user (def x1 (x. 1 2 3))
user (defrecord x [a b c])
user (def x2 (x. 1 2 3))
user (= x1 x2)
false

-Phil

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

Re: Little becnhmark (need insight)

Just tried it out: results are a little worse comparing to vectors (1.75s 
vs 1.68s).

On Monday, July 23, 2012 10:56:01 PM UTC+3, puzzler wrote:

 I would guess you'd get closer to Scala's perf if you use records to 
 represent your trees, rather than vectors.


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

Re: Little becnhmark (need insight)

Thanks. But I don't do any number crunching here - just a huge structure 
creation in memory. I can't get why removing the 'lazy-seq' wrapper from 
the second 'concat' argument make things 10x times slower.

On Monday, July 23, 2012 10:40:51 PM UTC+3, Sergey Didenko wrote:

 Hi, 

 lazy seqs are slow for number crunching, you can try to remove them. 

 Then you can check that you make (set! *warn-on-reflection* true). And 
 that your code does not have the warnings. 

 Then may be use native (Java) data structures or even arrays. 

 Then you can change defn for definline for sensitive code. 

 Also see the thread can Clojure 1.3 code always be made as fast as 
 Java for numeric computations? 

 Sergey 


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

Re: Little becnhmark (need insight)

2012-07-23 Thread Timothy Baldridge

 Thanks. But I don't do any number crunching here - just a huge structure
 creation in memory. I can't get why removing the 'lazy-seq' wrapper from the
 second 'concat' argument make things 10x times slower.

Lazy-seqs require the allocation of a LazySeq object. Due to the lazy
nature of this structure, we have to protect against multiple
evaluation. This means that certain methods have to be synchronized:
(https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java).
All that makes it quite a bit slower than a simple Iterator.


Timothy

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

Re: Little becnhmark (need insight)

On Mon, Jul 23, 2012 at 2:58 PM, Alexander Semenov bohtva...@gmail.com wrote:

 (do (time (doall (to-list tree))) :done)
 Elapsed time: 19716.222 msecs

 Why is this so? Both results are kind of disappointing for me cause Scala
 gives me ~270ms time using functional code and 5x faster using the mutable
 one (on much slower machine).

The comparison doesn't really make sense as internally Scala's :::
uses ListBuffer.

http://github.com/scala/scala/blob/v2.9.2/src/library/scala/collection/immutable/List.scala#L107

David

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

Re: Little becnhmark (need insight)

I see. Just removed the lazyness and got ~800ms.

(defn generate-tree [[h  t :as coll]]
  (if (seq coll)
(let [lr (generate-tree t)] [h lr lr])
nil))

(defn to-list [[v l r :as node]]
  (if-not (nil? node)
(into
 (to-list l)
 (conj (to-list r) v))
[]))

On Monday, July 23, 2012 11:20:50 PM UTC+3, tbc++ wrote:

  Thanks. But I don't do any number crunching here - just a huge structure 
  creation in memory. I can't get why removing the 'lazy-seq' wrapper from 
 the 
  second 'concat' argument make things 10x times slower. 

 Lazy-seqs require the allocation of a LazySeq object. Due to the lazy 
 nature of this structure, we have to protect against multiple 
 evaluation. This means that certain methods have to be synchronized: 
 (
 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java).
  

 All that makes it quite a bit slower than a simple Iterator. 


 Timothy 


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

Re: Little becnhmark (need insight)

2012-07-23 Thread Softaddicts

Did you try flatten ?

Luc P.


 Hello.
 
 I did a naive simple benchmark of Haskell and Scala recently and now i 
 decided to add Clojure to the picture. Here is the idea 
 http://blog.worldcognition.com/2012/06/folding-tree-to-list-benchmark-scala-vs.html
 
 So, I wrote the following functions:
 
 (defn generate-tree [[h  t :as coll]]
   (if (seq coll)
 (let [lr (generate-tree t)] [h lr lr])
 nil))
 
 (defn to-list [[v l r :as node]]
   (if-not (nil? node)
 (concat
  (to-list l)
  (lazy-seq (cons v (to-list r
 []))
 
 Now I get these results:
 
 (def tree (generate-tree (range 1 21)))
 
 (do (time (doall (to-list tree))) :done)
 Elapsed time: 1681.75 msecs
 :done
 
 If I remove the 'lazy-seq' wrapping second 'concat' argument, things become 
 worst:
 
 (do (time (doall (to-list tree))) :done)
 Elapsed time: 19716.222 msecs
 
 Why is this so? Both results are kind of disappointing for me cause Scala 
 gives me ~270ms time using functional code and 5x faster using the mutable 
 one (on much slower machine).
 
 -- 
 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
--
Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad!

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

Re: is their a Clojure framework for handling form validation?

2012-07-23 Thread gaz jones

https://github.com/mikejones/mississippi

again, not specific to web forms. works on clojure maps and is extensible.

On Sun, Jul 22, 2012 at 6:46 PM, larry google groups
lawrencecloj...@gmail.com wrote:
 Since 2000 I've been doing web development, first with PHP and then with
 Ruby On Rails. In the world of PHP, there are some frameworks, such as
 Symfony, that have classes for managing forms, both generating the HTML for
 the forms, and also handling the validation of the forms. In the world of
 Python, the Django framework also has facilities for generating and
 validating forms. These frameworks offer certain time saving conveniences.
 For instance, with the Symfony framework, if you have a database table that
 has a foreign key, then you can get that other table (the target of the
 foreign key) to appear in a form as a pre-populated select box,
 automatically (after filling out some config files).

 I'm now trying to make Clojure my primary development language for
 everything, including web development. I'm curious, are there any libraries
 in the land of Clojure that offer similar conveniences for forms?

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

Re: Little becnhmark (need insight)

Yes, but these are implementation details - API is still functional and 
side-effects free.

On Monday, July 23, 2012 11:23:32 PM UTC+3, David Nolen wrote:

 On Mon, Jul 23, 2012 at 2:58 PM, Alexander Semenov wrote: 
  
  (do (time (doall (to-list tree))) :done) 
  Elapsed time: 19716.222 msecs 
  
  Why is this so? Both results are kind of disappointing for me cause 
 Scala 
  gives me ~270ms time using functional code and 5x faster using the 
 mutable 
  one (on much slower machine). 

 The comparison doesn't really make sense as internally Scala's ::: 
 uses ListBuffer. 


 http://github.com/scala/scala/blob/v2.9.2/src/library/scala/collection/immutable/List.scala#L107
  

 David 


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

Re: Little becnhmark (need insight)

It died with out of memory with a half a minute delay.

On Monday, July 23, 2012 11:30:19 PM UTC+3, Luc wrote:

 Did you try flatten ? 

 Luc P. 


  Hello. 
  
  I did a naive simple benchmark of Haskell and Scala recently and now i 
  decided to add Clojure to the picture. Here is the idea 
  
 http://blog.worldcognition.com/2012/06/folding-tree-to-list-benchmark-scala-vs.html
  
  
  So, I wrote the following functions: 
  
  (defn generate-tree [[h  t :as coll]] 
(if (seq coll) 
  (let [lr (generate-tree t)] [h lr lr]) 
  nil)) 
  
  (defn to-list [[v l r :as node]] 
(if-not (nil? node) 
  (concat 
   (to-list l) 
   (lazy-seq (cons v (to-list r 
  [])) 
  
  Now I get these results: 
  
  (def tree (generate-tree (range 1 21))) 
  
  (do (time (doall (to-list tree))) :done) 
  Elapsed time: 1681.75 msecs 
  :done 
  
  If I remove the 'lazy-seq' wrapping second 'concat' argument, things 
 become 
  worst: 
  
  (do (time (doall (to-list tree))) :done) 
  Elapsed time: 19716.222 msecs 
  
  Why is this so? Both results are kind of disappointing for me cause 
 Scala 
  gives me ~270ms time using functional code and 5x faster using the 
 mutable 
  one (on much slower machine). 
  


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

Re: Little becnhmark (need insight)

Hi,
With the new version without laziness, what exact test do you pass ?

Is it still (do (time (doall (to-list tree))) :done) ?

Because the doall adds an unfair re-traversal of the list, I think

2012/7/23 Alexander Semenov bohtva...@gmail.com

 I see. Just removed the lazyness and got ~800ms.


 (defn generate-tree [[h  t :as coll]]
   (if (seq coll)
 (let [lr (generate-tree t)] [h lr lr])
 nil))

 (defn to-list [[v l r :as node]]
   (if-not (nil? node)
 (into
  (to-list l)
  (conj (to-list r) v))
 []))


 On Monday, July 23, 2012 11:20:50 PM UTC+3, tbc++ wrote:

  Thanks. But I don't do any number crunching here - just a huge
 structure
  creation in memory. I can't get why removing the 'lazy-seq' wrapper
 from the
  second 'concat' argument make things 10x times slower.

 Lazy-seqs require the allocation of a LazySeq object. Due to the lazy
 nature of this structure, we have to protect against multiple
 evaluation. This means that certain methods have to be synchronized:
 (https://github.com/clojure/**clojure/blob/master/src/jvm/**
 clojure/lang/LazySeq.javahttps://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java).

 All that makes it quite a bit slower than a simple Iterator.


 Timothy

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

Re: Little becnhmark (need insight)

Oh yes, you're absolutely right. Now its 570 ms (just removed the 'doall').

On Monday, July 23, 2012 11:34:40 PM UTC+3, lpetit wrote:

 Hi, 
 With the new version without laziness, what exact test do you pass ?

 Is it still (do (time (doall (to-list tree))) :done) ?

 Because the doall adds an unfair re-traversal of the list, I think

 I see. Just removed the lazyness and got ~800ms.


 (defn generate-tree [[h  t :as coll]]
   (if (seq coll)
 (let [lr (generate-tree t)] [h lr lr])
 nil))

 (defn to-list [[v l r :as node]]
   (if-not (nil? node)
 (into
  (to-list l)
  (conj (to-list r) v))
 []))


 On Monday, July 23, 2012 11:20:50 PM UTC+3, tbc++ wrote:

  Thanks. But I don't do any number crunching here - just a huge 
 structure 
  creation in memory. I can't get why removing the 'lazy-seq' wrapper 
 from the 
  second 'concat' argument make things 10x times slower. 

 Lazy-seqs require the allocation of a LazySeq object. Due to the lazy 
 nature of this structure, we have to protect against multiple 
 evaluation. This means that certain methods have to be synchronized: 
 (https://github.com/clojure/**clojure/blob/master/src/jvm/**
 clojure/lang/LazySeq.javahttps://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java).
  

 All that makes it quite a bit slower than a simple Iterator. 


 Timothy 

 http://groups.google.com/group/clojure?hl=en




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

Re: Little becnhmark (need insight)

On Mon, Jul 23, 2012 at 4:30 PM, Alexander Semenov bohtva...@gmail.com wrote:
 Yes, but these are implementation details - API is still functional and
 side-effects free.

So your benchmark is just timing implementation details.

I'm sure you can get get identical numbers to Scala / Haskell if you
provide your own ListBuffer implementation.

David

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

Re: Any downside of record compared to map

2012-07-23 Thread Lee Spector

On Jul 23, 2012, at 4:06 PM, Aravindh Johendran wrote:

Are struct-maps really deprecated? I don't see a deprecation warning anywhere
(clojure website, source, api, etc.). All I see is the following line in
clojure website.
--- Note: Most uses of StructMaps would now be better served by records.
Is the use of struct-maps officially being discouraged? Is that the same as
being almost deprecated? Will struct-maps go away in a future release?

There's also this:

Overall, records will be better than structmaps for all information-bearing
purposes, and you should move such structmaps to defrecord. It is unlikely much
code was trying to use structmaps for programming constructs, but if so, you
will find deftype much more suitable.

from http://clojure.org/datatypes

FWIW there's also a comment on stackoverflow Michał Marczyk: in fact, the
latter is deprecated in 1.2
(http://stackoverflow.com/questions/4288360/clojures-macro-define-a-binding-whose-name-is-composed-from-an-argument).

I don't know if there's any more official statement anywhere. Myself, I really
like struct-maps and I hope they stay around.

-Lee

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

Re: Little becnhmark (need insight)

To some degree. Neither Clojure nor Haskell won't beat direct mutable code 
in Scala which results in 65ms on a machine 2x slower than my current.

On Monday, July 23, 2012 11:44:18 PM UTC+3, David Nolen wrote:

 So your benchmark is just timing implementation details. 

 I'm sure you can get get identical numbers to Scala / Haskell if you 
 provide your own ListBuffer implementation. 

 David 


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

Re: Little becnhmark (need insight)

On Mon, Jul 23, 2012 at 4:52 PM, Alexander Semenov bohtva...@gmail.com wrote:
 To some degree. Neither Clojure nor Haskell won't beat direct mutable code
 in Scala which results in 65ms on a machine 2x slower than my current.

Direct mutable code can be written with little difficulty in Clojure.
It's just discouraged.

David

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

Re: Little becnhmark (need insight)

2012/7/23 Alexander Semenov bohtva...@gmail.com

 Oh yes, you're absolutely right. Now its 570 ms (just removed the 'doall').


Does the timing stabilize to a lesser value if you execute it multiple
times (as they did in the scala test) :

(dotimes [ _ 10] (time (to-list tree)) :done)

?



 On Monday, July 23, 2012 11:34:40 PM UTC+3, lpetit wrote:

 Hi,
 With the new version without laziness, what exact test do you pass ?

 Is it still (do (time (doall (to-list tree))) :done) ?

 Because the doall adds an unfair re-traversal of the list, I think

 I see. Just removed the lazyness and got ~800ms.


 (defn generate-tree [[h  t :as coll]]
   (if (seq coll)
 (let [lr (generate-tree t)] [h lr lr])
 nil))

 (defn to-list [[v l r :as node]]
   (if-not (nil? node)
 (into
  (to-list l)
  (conj (to-list r) v))
 []))


 On Monday, July 23, 2012 11:20:50 PM UTC+3, tbc++ wrote:

  Thanks. But I don't do any number crunching here - just a huge
 structure
  creation in memory. I can't get why removing the 'lazy-seq' wrapper
 from the
  second 'concat' argument make things 10x times slower.

 Lazy-seqs require the allocation of a LazySeq object. Due to the lazy
 nature of this structure, we have to protect against multiple
 evaluation. This means that certain methods have to be synchronized:
 (https://github.com/clojure/**cl**ojure/blob/master/src/jvm/**cloj**
 ure/lang/LazySeq.javahttps://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java).

 All that makes it quite a bit slower than a simple Iterator.


 Timothy

 http://groups.google.com/group/clojure?hl=en


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

Re: Little becnhmark (need insight)

Here's what my code looks like, using records and removing pattern matching:

(defrecord Tree [h l r])

(defn generate-tree [c]
  (when-let [s (seq c)]
(let [lr (generate-tree (rest s))]
  (Tree. (first s) lr lr

(defn to-list [t]
  (if t
(into
  (conj (to-list (:l t)) (:h t))
  (to-list (:r t)))
[]))

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

Re: Little becnhmark (need insight)

No, the results are pretty the same (+-20ms).

In fact I tried using https://github.com/hugoduncan/criterium but it dies 
with 'out of memory' (:reduce-with option doesn't help), so I gave up.

On Monday, July 23, 2012 11:54:28 PM UTC+3, lpetit wrote:


 Does the timing stabilize to a lesser value if you execute it multiple 
 times (as they did in the scala test) : 

 (dotimes [ _ 10] (time (to-list tree)) :done)

 ?  


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

Re: Little becnhmark (need insight)

Don't forget to use the -server flag.  Makes a big difference in the perf
of Clojure code.

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

Re: Any downside of record compared to map

2012-07-23 Thread Warren Lynn


Thank everybody for the discussion. I am now aware of some pitfalls in 
using defrecord.

For me, I like to have type information associated with my data. I still 
prefer defrecord over map in general, but I will proceed with more caution. 
I think some pitfalls here are not due to the greatness of regular map, but 
is because record is not yet so great (e.x. Python has no problem 
serializing typed data). But still, with current state of things, those 
downsides are real.

By the way, it seems record is not necessarily slower than map in map 
operations. Here is my test result:

(defrecord myrec [a b])
(def rec (myrec. 1 2))
(def m {:a 1 :b 2})


user= (time (dotimes [x 1000] (assoc m :a 4)))
Elapsed time: 2499.155478 msecs

user= (time (dotimes [x 1000] (assoc rec :a 4)))
Elapsed time: 802.191248 msecs

But I did not test other operations.

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

Re: Little becnhmark (need insight)

Yes, I tried pretty the same and it gives same timings as without records. 
BTW, I noticed that destructuring brings some little overhead (~50ms).

On Monday, July 23, 2012 11:59:34 PM UTC+3, puzzler wrote:

 Here's what my code looks like, using records and removing pattern 
 matching:

 (defrecord Tree [h l r])

 (defn generate-tree [c]
   (when-let [s (seq c)]
 (let [lr (generate-tree (rest s))] 
   (Tree. (first s) lr lr

 (defn to-list [t]
   (if t
 (into
   (conj (to-list (:l t)) (:h t))
   (to-list (:r t)))
 []))



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

Re: Little becnhmark (need insight)

Hm, currently I run those functions from inside SLIME repl session in emacs 
and I have no idea whereas it starts clojure with that flag. Let me see...

On Tuesday, July 24, 2012 12:00:23 AM UTC+3, puzzler wrote:

 Don't forget to use the -server flag.  Makes a big difference in the perf 
 of Clojure code.



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

Re: Little becnhmark (need insight)

(deftype Tree [n l r]
  clojure.lang.Indexed
  (nth [this idx]
(nth this idx nil))
  (nth [_ idx not-found]
(case idx
  0 n
  1 l
  2 r
  not-found)))

(defn generate-tree [[h  t :as coll]]
  (when (seq coll)
(let [lr (generate-tree t)] (Tree. h lr lr

(defn to-list
  ([node] (persistent! (to-list node (transient []
  ([[v l r :as node] acc]
 (if-not (nil? node)
   (let [lacc (to-list l acc)
 _   (conj! lacc v)
 racc (to-list r lacc)]
 racc)
   acc)))

(defn tree [n]
  (generate-tree (range 1 n)))

(let [t (tree 21)]
   (dotimes [_ 5]
 (time
  (dotimes [_ 1]
(count (to-list t))

Takes ~53ms on my machine.

David

On Mon, Jul 23, 2012 at 5:00 PM, Alexander Semenov bohtva...@gmail.com wrote:
 No, the results are pretty the same (+-20ms).

 In fact I tried using https://github.com/hugoduncan/criterium but it dies
 with 'out of memory' (:reduce-with option doesn't help), so I gave up.


 On Monday, July 23, 2012 11:54:28 PM UTC+3, lpetit wrote:


 Does the timing stabilize to a lesser value if you execute it multiple
 times (as they did in the scala test) :

 (dotimes [ _ 10] (time (to-list tree)) :done)

 ?

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

Re: Little becnhmark (need insight)

(defn to-list
  ([node] (persistent! (to-list node (transient []
  ([[v l r :as node] acc]
 (if-not (nil? node)
   (let [lacc (to-list l acc)
 vacc  (conj! lacc v)
 racc (to-list r vacc)]
 racc)
   acc)))

There was a mistake in my to-list. Timings have not changed.

On Mon, Jul 23, 2012 at 5:07 PM, David Nolen dnolen.li...@gmail.com wrote:
 (deftype Tree [n l r]
   clojure.lang.Indexed
   (nth [this idx]
 (nth this idx nil))
   (nth [_ idx not-found]
 (case idx
   0 n
   1 l
   2 r
   not-found)))

 (defn generate-tree [[h  t :as coll]]
   (when (seq coll)
 (let [lr (generate-tree t)] (Tree. h lr lr

 (defn to-list
   ([node] (persistent! (to-list node (transient []
   ([[v l r :as node] acc]
  (if-not (nil? node)
(let [lacc (to-list l acc)
  _   (conj! lacc v)
  racc (to-list r lacc)]
  racc)
acc)))

 (defn tree [n]
   (generate-tree (range 1 n)))

 (let [t (tree 21)]
(dotimes [_ 5]
  (time
   (dotimes [_ 1]
 (count (to-list t))

 Takes ~53ms on my machine.

 David

 On Mon, Jul 23, 2012 at 5:00 PM, Alexander Semenov bohtva...@gmail.com 
 wrote:
 No, the results are pretty the same (+-20ms).

 In fact I tried using https://github.com/hugoduncan/criterium but it dies
 with 'out of memory' (:reduce-with option doesn't help), so I gave up.


 On Monday, July 23, 2012 11:54:28 PM UTC+3, lpetit wrote:


 Does the timing stabilize to a lesser value if you execute it multiple
 times (as they did in the scala test) :

 (dotimes [ _ 10] (time (to-list tree)) :done)

 ?

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

Re: Little becnhmark (need insight)

And ~44ms on mine. Impressive! Will study your code tomorrow, thanks.

On Tuesday, July 24, 2012 12:07:59 AM UTC+3, David Nolen wrote:

 (deftype Tree [n l r] 
   clojure.lang.Indexed 
   (nth [this idx] 
 (nth this idx nil)) 
   (nth [_ idx not-found] 
 (case idx 
   0 n 
   1 l 
   2 r 
   not-found))) 

 (defn generate-tree [[h  t :as coll]] 
   (when (seq coll) 
 (let [lr (generate-tree t)] (Tree. h lr lr 

 (defn to-list 
   ([node] (persistent! (to-list node (transient [] 
   ([[v l r :as node] acc] 
  (if-not (nil? node) 
(let [lacc (to-list l acc) 
  _   (conj! lacc v) 
  racc (to-list r lacc)] 
  racc) 
acc))) 

 (defn tree [n] 
   (generate-tree (range 1 n))) 

 (let [t (tree 21)] 
(dotimes [_ 5] 
  (time 
   (dotimes [_ 1] 
 (count (to-list t)) 

 Takes ~53ms on my machine. 

 David


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

Re: [ANN] jenkins-leiningen

2012-07-23 Thread Phil Hagelberg

On Wed, Jul 18, 2012 at 7:23 AM, Pierre-Yves Ritschard p...@spootnik.org 
wrote:
 I wanted this for a while so here goes:
 https://github.com/pyr/jenkins-leiningen.
 It is very simplistic and inspired from the sbt one.

This is great. Could you add it to the Leiningen wiki?

https://github.com/technomancy/leiningen/wiki

Thanks!

-Phil

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

Re: Little becnhmark (need insight)

As David was posting his code, I was wrapping up my own experimentation
with how transients apply here.  Mine is similar, but doesn't use pattern
matching -- seems a bit faster:

(defrecord Tree [h l r])

(defn generate-tree [c]
  (when-let [s (seq c)]
(let [lr (generate-tree (rest s))]
  (Tree. (first s) lr lr

(defn to-list
  ([t] (persistent! (to-list t (transient []
  ([t b]
(if t
  (let [b (to-list (:l t) b),
b (conj! b (:h t)),
b (to-list (:r t) b)]
  b)
  b)))

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

Re: Little becnhmark (need insight)

2012/7/23 Mark Engelberg mark.engelb...@gmail.com

 As David was posting his code, I was wrapping up my own experimentation
 with how transients apply here.  Mine is similar, but doesn't use pattern
 matching -- seems a bit faster:


 (defrecord Tree [h l r])

 (defn generate-tree [c]
   (when-let [s (seq c)]
 (let [lr (generate-tree (rest s))]
   (Tree. (first s) lr lr

 (defn to-list
   ([t] (persistent! (to-list t (transient []
   ([t b]
 (if t
   (let [b (to-list (:l t) b),
 b (conj! b (:h t)),
 b (to-list (:r t) b)]
   b)
   b)))


True,

and notice you can also drop records altogether:

(defn generate-tree [c]
  (when-let [s (seq c)]
(let [lr (generate-tree (rest s))]
  [(first s) lr lr])))

(defn to-list
  ([t] (persistent! (to-list t (transient []
  ([t b]
(if t
  (let [b (to-list (t 1) b),
b (conj! b (t 0)),
b (to-list (t 2) b)]
  b)
  b)))
(defn tree [n]
  (generate-tree (range 1 n)))

(let [t (tree 21)]
   (dotimes [_ 10]
 (time
  (dotimes [_ 1]
(println (count (to-list t)))

1048575
Elapsed time: 346.446 msecs
1048575
Elapsed time: 37.2 msecs
1048575
Elapsed time: 32.795 msecs
1048575
Elapsed time: 31.655 msecs
1048575
Elapsed time: 45.388 msecs
1048575
Elapsed time: 30.612 msecs
1048575
Elapsed time: 27.141 msecs
1048575
Elapsed time: 40.887 msecs
1048575
Elapsed time: 27.526 msecs
1048575
Elapsed time: 26.747 msecs
nil

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

Re: Little becnhmark (need insight)

Oh, and finally, note that even without transients, you get 6x better perf
by not calling into directly:

= (defrecord Tree [h l r])

   (defn generate-tree [c]
 (when-let [s (seq c)]
   (let [lr (generate-tree (rest s))]
 (Tree. (first s) lr lr

   (defn to-list
 ([t] (to-list t []))
 ([t b]
   (if t
 (let [b (to-list (:l t) b),
   b (conj b (:h t)),
   b (to-list (:r t) b)]
 b)
 b)))
   (defn tree [n]
 (generate-tree (range 1 n)))

   (let [t (tree 21)]
  (dotimes [_ 10]
(time
 (dotimes [_ 1]
   (println (count (to-list t)))
user.Tree
#'user/generate-tree
#'user/to-list
#'user/tree
1048575
Elapsed time: 174.14 msecs
1048575
Elapsed time: 124.218 msecs
1048575
Elapsed time: 130.186 msecs
1048575
Elapsed time: 109.883 msecs
1048575
Elapsed time: 104.221 msecs
1048575
Elapsed time: 98.387 msecs
1048575
Elapsed time: 98.21 msecs
1048575
Elapsed time: 103.543 msecs
1048575
Elapsed time: 98.663 msecs
1048575
Elapsed time: 101.913 msecs
nil
= (defrecord Tree [h l r])

   (defn generate-tree [c]
 (when-let [s (seq c)]
   (let [lr (generate-tree (rest s))]
 (Tree. (first s) lr lr

   (defn to-list
 ([t] (to-list t []))
 ([t b]
   (if t
 (into (conj (to-list (:l t) b) (:h t)) (to-list (:r t) b))
 b)))
   (defn tree [n]
 (generate-tree (range 1 n)))

   (let [t (tree 21)]
  (dotimes [_ 10]
(time
 (dotimes [_ 1]
   (println (count (to-list t)))
user.Tree
#'user/generate-tree
#'user/to-list
#'user/tree
1048575
Elapsed time: 1149.562 msecs
1048575
Elapsed time: 846.225 msecs
1048575
Elapsed time: 605.007 msecs
1048575
Elapsed time: 604.409 msecs
1048575
Elapsed time: 625.605 msecs
1048575
Elapsed time: 626.066 msecs
1048575
Elapsed time: 605.502 msecs
1048575
Elapsed time: 621.007 msecs
1048575
Elapsed time: 606.064 msecs
1048575
Elapsed time: 642.739 msecs
nil

2012/7/23 Laurent PETIT laurent.pe...@gmail.com

 2012/7/23 Mark Engelberg mark.engelb...@gmail.com

 As David was posting his code, I was wrapping up my own experimentation
 with how transients apply here.  Mine is similar, but doesn't use pattern
 matching -- seems a bit faster:


 (defrecord Tree [h l r])

 (defn generate-tree [c]
   (when-let [s (seq c)]
 (let [lr (generate-tree (rest s))]
   (Tree. (first s) lr lr

 (defn to-list
   ([t] (persistent! (to-list t (transient []
   ([t b]
 (if t
   (let [b (to-list (:l t) b),
 b (conj! b (:h t)),
 b (to-list (:r t) b)]
   b)
   b)))


 True,

 and notice you can also drop records altogether:


 (defn generate-tree [c]
   (when-let [s (seq c)]
 (let [lr (generate-tree (rest s))]
   [(first s) lr lr])))


 (defn to-list
   ([t] (persistent! (to-list t (transient []
   ([t b]
 (if t
   (let [b (to-list (t 1) b),
 b (conj! b (t 0)),
 b (to-list (t 2) b)]
   b)
   b)))

 (defn tree [n]
   (generate-tree (range 1 n)))

 (let [t (tree 21)]
(dotimes [_ 10]
  (time
   (dotimes [_ 1]
 (println (count (to-list t)))

 1048575
 Elapsed time: 346.446 msecs
 1048575
 Elapsed time: 37.2 msecs
 1048575
 Elapsed time: 32.795 msecs
 1048575
 Elapsed time: 31.655 msecs
 1048575
 Elapsed time: 45.388 msecs
 1048575
 Elapsed time: 30.612 msecs
 1048575
 Elapsed time: 27.141 msecs
 1048575
 Elapsed time: 40.887 msecs
 1048575
 Elapsed time: 27.526 msecs
 1048575
 Elapsed time: 26.747 msecs
 nil


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

Logger conflicts

2012-07-23 Thread Eric in San Diego

I'm in the process of upgrading some oldish code, and I'm encountering some 
compatibility problems with the loggers required by various libraries.

See the *appendix* below for my project.clj, which loads a number of 
libraries and to which I've recently added statements like this:

 [com.hp.hpl.jena/jena 2.6.4
  :exclusions [org.slf4j/slf4j-log4j12
   org.slf4j/slf4j-api
   ]
  ]

I added these exclusions to turn off this error:

java.lang.NoSuchMethodError: 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V


Which I gather from reading things like this:

http://stackoverflow.com/questions/3519978/logging-framework-incompatibility

- stem from incompatible logging libraries.

Excluding these dependencies  seems to turn off this error, but now when I 
try load my code, I'm getting this error:

org.slf4j.LoggerFactory
  [Thrown class java.lang.ClassNotFoundException]

See the appendix for a stack trace.

I'm including org.clojure/tools.logging in the project.clj, but it's not 
clear to me how to keep the logger associated with my 'jena' library happy 
without re-introducing my compatibility error.

Up to this point, my logging has 'just worked', so I guess this is an 
opportunity to learn about this stuff. Is there a good way to deal with the 
fact that different supporting libraries will use different logging regimes?

Thanks for any help.


* appendix *

(defproject MyProject 1.0.0-SNAPSHOT

  :jvm-opts [-Xmx8g -XX:+HeapDumpOnOutOfMemoryError -XX:+UseSerialGC]


  :dependencies [[org.clojure/clojure 1.3.0]
 [org.clojure/math.numeric-tower 0.0.1]
 [org.clojure/tools.trace 0.7.1]
 [org.clojure/tools.logging 0.2.3]
 [org.clojure/algo.generic 0.1.0]
 [clojure-csv 1.3.2] 
 ;;statistics...
 [incanter/incanter-core 1.3.0-SNAPSHOT] 
 [incanter/incanter-charts 1.3.0-SNAPSHOT]
 [incanter/incanter-processing 1.3.0-SNAPSHOT]

 ;;web
 [compojure 1.1.1]
 [hiccup 1.0.0]
 [ring 1.1.1]

 ;;jena ...
 [com.hp.hpl.jena/jena 2.6.4
  :exclusions [org.slf4j/slf4j-log4j12
   org.slf4j/slf4j-api
   ]
  ]
 ;;TDB 
 [com.hp.hpl.jena/arq 2.8.8
  :exclusions [org.slf4j/slf4j-api]
  ]
 [com.hp.hpl.jena/iri 0.8]
 [com.ibm.icu/icu4j 3.4.4]
 [com.hp.hpl.jena/tdb 0.8.10
  :exclusions [org.slf4j/slf4j-api]
  ]
 ;;lucene
 [org.apache.lucene/lucene-core 2.3.1]
  ]
  :dev-dependencies [
   [swank-clojure 1.3.2 
:exclusions [org.clojure/clojure]]
 [lein-autodoc 0.9.0]
   
   ]
 
)

-- stack trace:

org.slf4j.LoggerFactory
  [Thrown class java.lang.ClassNotFoundException]
Backtrace:
  0: java.net.URLClassLoader$1.run(URLClassLoader.java:217)
  1: java.security.AccessController.doPrivileged(Native Method)
  2: java.net.URLClassLoader.findClass(URLClassLoader.java:205)
  3: java.lang.ClassLoader.loadClass(ClassLoader.java:321)
  4: sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
  5: java.lang.ClassLoader.loadClass(ClassLoader.java:266)
  6: com.hp.hpl.jena.util.Metadata.clinit(Metadata.java:26)
  7: com.hp.hpl.jena.JenaRuntime.clinit(JenaRuntime.java:25)
  8: 
com.hp.hpl.jena.rdf.model.impl.RDFReaderFImpl.clinit(RDFReaderFImpl.java:85)
  9: com.hp.hpl.jena.rdf.model.impl.ModelCom.clinit(ModelCom.java:42)



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

Re: Little becnhmark (need insight)

And I guess it is so because into, being called numerous times, keeps
transforming bigger and bigger vectors into transient vectors, and back to
persistent vectors, etc.

2012/7/24 Laurent PETIT laurent.pe...@gmail.com

 Oh, and finally, note that even without transients, you get 6x better perf
 by not calling into directly:

 = (defrecord Tree [h l r])


(defn generate-tree [c]
  (when-let [s (seq c)]
(let [lr (generate-tree (rest s))]
  (Tree. (first s) lr lr

(defn to-list
  ([t] (to-list t []))

  ([t b]
(if t
  (let [b (to-list (:l t) b),
b (conj b (:h t)),

b (to-list (:r t) b)]
  b)
  b)))
(defn tree [n]
  (generate-tree (range 1 n)))

(let [t (tree 21)]
   (dotimes [_ 10]
 (time
  (dotimes [_ 1]
(println (count (to-list t)))
  user.Tree
 #'user/generate-tree
 #'user/to-list
 #'user/tree
 1048575
 Elapsed time: 174.14 msecs
 1048575
 Elapsed time: 124.218 msecs
 1048575
 Elapsed time: 130.186 msecs
 1048575
 Elapsed time: 109.883 msecs
 1048575
 Elapsed time: 104.221 msecs
 1048575
 Elapsed time: 98.387 msecs
 1048575
 Elapsed time: 98.21 msecs
 1048575
 Elapsed time: 103.543 msecs
 1048575
 Elapsed time: 98.663 msecs
 1048575
 Elapsed time: 101.913 msecs
 nil
 = (defrecord Tree [h l r])


(defn generate-tree [c]
  (when-let [s (seq c)]
(let [lr (generate-tree (rest s))]
  (Tree. (first s) lr lr

(defn to-list
  ([t] (to-list t []))

  ([t b]
(if t
  (into (conj (to-list (:l t) b) (:h t)) (to-list (:r t) b))

  b)))
(defn tree [n]
  (generate-tree (range 1 n)))

(let [t (tree 21)]
   (dotimes [_ 10]
 (time
  (dotimes [_ 1]
(println (count (to-list t)))
  user.Tree
 #'user/generate-tree
 #'user/to-list
 #'user/tree
 1048575
 Elapsed time: 1149.562 msecs
 1048575
 Elapsed time: 846.225 msecs
 1048575
 Elapsed time: 605.007 msecs
 1048575
 Elapsed time: 604.409 msecs
 1048575
 Elapsed time: 625.605 msecs
 1048575
 Elapsed time: 626.066 msecs
 1048575
 Elapsed time: 605.502 msecs
 1048575
 Elapsed time: 621.007 msecs
 1048575
 Elapsed time: 606.064 msecs
 1048575
 Elapsed time: 642.739 msecs
 nil


 2012/7/23 Laurent PETIT laurent.pe...@gmail.com

 2012/7/23 Mark Engelberg mark.engelb...@gmail.com

 As David was posting his code, I was wrapping up my own experimentation
 with how transients apply here.  Mine is similar, but doesn't use pattern
 matching -- seems a bit faster:


 (defrecord Tree [h l r])

 (defn generate-tree [c]
   (when-let [s (seq c)]
 (let [lr (generate-tree (rest s))]
   (Tree. (first s) lr lr

 (defn to-list
   ([t] (persistent! (to-list t (transient []
   ([t b]
 (if t
   (let [b (to-list (:l t) b),
 b (conj! b (:h t)),
 b (to-list (:r t) b)]
   b)
   b)))


 True,

 and notice you can also drop records altogether:


 (defn generate-tree [c]
   (when-let [s (seq c)]
 (let [lr (generate-tree (rest s))]
   [(first s) lr lr])))


 (defn to-list
   ([t] (persistent! (to-list t (transient []
   ([t b]
 (if t
   (let [b (to-list (t 1) b),
 b (conj! b (t 0)),
 b (to-list (t 2) b)]
   b)
   b)))

 (defn tree [n]
   (generate-tree (range 1 n)))

 (let [t (tree 21)]
(dotimes [_ 10]
  (time
   (dotimes [_ 1]
 (println (count (to-list t)))

 1048575
 Elapsed time: 346.446 msecs
 1048575
 Elapsed time: 37.2 msecs
 1048575
 Elapsed time: 32.795 msecs
 1048575
 Elapsed time: 31.655 msecs
 1048575
 Elapsed time: 45.388 msecs
 1048575
 Elapsed time: 30.612 msecs
 1048575
 Elapsed time: 27.141 msecs
 1048575
 Elapsed time: 40.887 msecs
 1048575
 Elapsed time: 27.526 msecs
 1048575
 Elapsed time: 26.747 msecs
 nil




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

Re: Little becnhmark (need insight)

2012/7/24 Laurent PETIT laurent.pe...@gmail.com

 And I guess it is so because into, being called numerous times, keeps
 transforming bigger and bigger vectors into transient vectors, and back to
 persistent vectors, etc.


Answering to self: I was wrong, problem does not seem to be with internal
use of transients inside into, since removing them makes things worse:

= (defn my-into
 Returns a new coll consisting of to-coll with all of the items of
 from-coll conjoined.
 {:added 1.0
  :static true}
 [to from]
 (reduce conj to from))

   (defrecord Tree [h l r])

   (defn generate-tree [c]
 (when-let [s (seq c)]
   (let [lr (generate-tree (rest s))]
 (Tree. (first s) lr lr

   (defn to-list
 ([t] (to-list t []))
 ([t b]
   (if t
 (my-into (conj (to-list (:l t) b) (:h t)) (to-list (:r t) b))
 b)))
   (defn tree [n]
 (generate-tree (range 1 n)))

   (let [t (tree 21)]
  (dotimes [_ 10]
(time
 (dotimes [_ 1]
   (println (count (to-list t)))
#'user/my-into
user.Tree
#'user/generate-tree
#'user/to-list
#'user/tree
1048575
Elapsed time: 1121.971 msecs
1048575
Elapsed time: 969.479 msecs
1048575
Elapsed time: 991.333 msecs
1048575
Elapsed time: 940.975 msecs
1048575
Elapsed time: 956.785 msecs
1048575
Elapsed time: 1007.633 msecs
1048575
Elapsed time: 984.384 msecs
1048575
Elapsed time: 965.166 msecs
1048575
Elapsed time: 955.469 msecs
1048575
Elapsed time: 963.43 msecs
nil




 2012/7/24 Laurent PETIT laurent.pe...@gmail.com

 Oh, and finally, note that even without transients, you get 6x better
 perf by not calling into directly:

 = (defrecord Tree [h l r])


(defn generate-tree [c]
  (when-let [s (seq c)]
(let [lr (generate-tree (rest s))]
  (Tree. (first s) lr lr

(defn to-list
  ([t] (to-list t []))

  ([t b]
(if t
  (let [b (to-list (:l t) b),
b (conj b (:h t)),

b (to-list (:r t) b)]
  b)
  b)))
(defn tree [n]
  (generate-tree (range 1 n)))

(let [t (tree 21)]
   (dotimes [_ 10]
 (time
  (dotimes [_ 1]
(println (count (to-list t)))
  user.Tree
 #'user/generate-tree
 #'user/to-list
 #'user/tree
 1048575
 Elapsed time: 174.14 msecs
 1048575
 Elapsed time: 124.218 msecs
 1048575
 Elapsed time: 130.186 msecs
 1048575
 Elapsed time: 109.883 msecs
 1048575
 Elapsed time: 104.221 msecs
 1048575
 Elapsed time: 98.387 msecs
 1048575
 Elapsed time: 98.21 msecs
 1048575
 Elapsed time: 103.543 msecs
 1048575
 Elapsed time: 98.663 msecs
 1048575
 Elapsed time: 101.913 msecs
 nil
 = (defrecord Tree [h l r])


(defn generate-tree [c]
  (when-let [s (seq c)]
(let [lr (generate-tree (rest s))]
  (Tree. (first s) lr lr

(defn to-list
  ([t] (to-list t []))

  ([t b]
(if t
  (into (conj (to-list (:l t) b) (:h t)) (to-list (:r t) b))

  b)))
(defn tree [n]
  (generate-tree (range 1 n)))

(let [t (tree 21)]
   (dotimes [_ 10]
 (time
  (dotimes [_ 1]
(println (count (to-list t)))
  user.Tree
 #'user/generate-tree
 #'user/to-list
 #'user/tree
 1048575
 Elapsed time: 1149.562 msecs
 1048575
 Elapsed time: 846.225 msecs
 1048575
 Elapsed time: 605.007 msecs
 1048575
 Elapsed time: 604.409 msecs
 1048575
 Elapsed time: 625.605 msecs
 1048575
 Elapsed time: 626.066 msecs
 1048575
 Elapsed time: 605.502 msecs
 1048575
 Elapsed time: 621.007 msecs
 1048575
 Elapsed time: 606.064 msecs
 1048575
 Elapsed time: 642.739 msecs
 nil


 2012/7/23 Laurent PETIT laurent.pe...@gmail.com

 2012/7/23 Mark Engelberg mark.engelb...@gmail.com

 As David was posting his code, I was wrapping up my own experimentation
 with how transients apply here.  Mine is similar, but doesn't use pattern
 matching -- seems a bit faster:


 (defrecord Tree [h l r])

 (defn generate-tree [c]
   (when-let [s (seq c)]
 (let [lr (generate-tree (rest s))]
   (Tree. (first s) lr lr

 (defn to-list
   ([t] (persistent! (to-list t (transient []
   ([t b]
 (if t
   (let [b (to-list (:l t) b),
 b (conj! b (:h t)),
 b (to-list (:r t) b)]
   b)
   b)))


 True,

 and notice you can also drop records altogether:


 (defn generate-tree [c]
   (when-let [s (seq c)]
 (let [lr (generate-tree (rest s))]
   [(first s) lr lr])))


 (defn to-list
   ([t] (persistent! (to-list t (transient []
   ([t b]
 (if t
   (let [b (to-list (t 1) b),
 b (conj! b (t 0)),
 b (to-list (t 2) b)]
   b)
   b)))

 (defn tree [n]
   (generate-tree (range 1 n)))

 (let [t (tree 21)]
(dotimes [_ 10]
  (time
   (dotimes [_ 1]
 (println (count (to-list t)))

 1048575
 Elapsed time: 346.446 msecs
 1048575
 Elapsed time: 37.2 msecs
 1048575
 Elapsed time: 32.795 msecs
 1048575
 Elapsed

core.match invert match

2012-07-23 Thread Simone Mosciatti

Hi everybody,
I was looking if it is possible to invert the match macro, an example worth 
more than 1000 words.

(def x (match [a b]
   [true true] 0.5
   [false true] 0.6
   [true false] 0.4
   [false false] 0.8))

(max x)
= [false false]
(filter odd? x)
= [true true]

It is possible ?

I am definitely not an expert but it looks like a core.logic task, doesn't ?

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

Re: core.match invert match