Re: Current API doc (for HEAD)
Tom, are you amenable? Yup, happy to. Where should it go? I'm generating real html now, not wiki-text (for a bunch of reasons, among them the ability to download a tree and use your browser offline, old version support, etc.), so the current system wouldn't post back to clojure.org very efficiently. But I could throw something onto the github pages for clojure, for instance. Let me know how you want to proceed, or we can chat in #clojure. Tom --~--~-~--~~~---~--~~ 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: Transient Data Structures
Testing Transient w/Hashmaps (Thanks Cristophe!) and it seems like the object won't store more then 8 keys. At first I thought it was my frequency function that was rolling it up, but then I simply tried creating a transient object and manually assoc! ing a bunch of items into it. After the 8th it seemed to stop taking new keys. Am I doing something silly here or is this a bug? ~Patrick Sullivan On Aug 6, 5:53 am, Rich Hickey richhic...@gmail.com wrote: On Aug 5, 10:10 pm, Luc Prefontaine lprefonta...@softaddicts.ca wrote: I like this very much... that's the kind of clever optimizations that preserves Clojure principles and can yield significant performance increases. This could also help dealing with performance critics in these small mutable languages benchmarks that newbies attempt to clone in Clojure. Thank's Rich ! You're welcome! And special thanks to Christophe Grand, who (quickly!) applied the same technique to the hash maps and contributed that yesterday. So now, in the master branch, vectors and hash maps support transients. Everyone please try them out (where appropriate :). Rich --~--~-~--~~~---~--~~ 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: a better reductions?
Hi Stuart, 2009/8/6 Stuart Halloway stuart.hallo...@gmail.com: On the plus side, it appears to be faster (as collections grow large), and it doesn't cheat by introducing an atom. On the minus side it isn't as pretty as the one in contrib. While maybe not as pretty as the one in contrib, it's not a monster either. Shouldn't we aim for efficiency rather than elegance in library routines (within reason)? I think the user will appreciate the speedy version more than the pretty version. Since this change retains the original interface, I would say go for it. I'm a bit confused by the (cons (f) nil) form in the else clause. It is going to fail unless f is of 0 arity. If f is of arity 2 we get an IllegalArgumentException from eval. So wouldn't it be more correct to return an empty list? Stu -- ! Lauri --~--~-~--~~~---~--~~ 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: Package manager proposal
2009/8/6 James Reeves weavejes...@googlemail.com:
On Aug 6, 8:31 pm, Howard Lewis Ship hls...@gmail.com wrote:
I'm cringing at the sight of XML here.
XML is frequently overused, but it is a good format for representing
dense, structured data. For example:
repository name=third-party
package name=Compojure href=/compojure.xml/
/repository
Compared to:
{:type :repository
:name third-party
:content [{ :type :package
:name Compojure
:href /compojure.xml }]}
Surely we can do better with s-expressions:
(:repository third-party [(:package Compojure /compojure.xml)])
I guess it might get a bit trickier if you have a lot of optional attributes...
And you can use the s-expressions as an on the wire interchange format
as well, which works especially well if both ends are written in lisp.
--
! Lauri
--~--~-~--~~~---~--~~
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: a better reductions?
On Aug 7, 2009, at 2:59 AM, Lauri Pesonen wrote: While maybe not as pretty as the one in contrib, it's not a monster either. Shouldn't we aim for efficiency rather than elegance in library routines (within reason)? I think the user will appreciate the speedy version more than the pretty version. Since this change retains the original interface, I would say go for it. This is the difference between FreeBSD and NetBSD. I agree, but I also find it useful to crack open core and contrib to see coding examples and to understand algorithms. It's a balancing act. I'm definitely for this change though. I use reductions from time to time. — Daniel Lyons --~--~-~--~~~---~--~~ 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: Package manager proposal
Ruby and Gem is such great terminology, can we come up with something
half as cool?
Want something short (3 - 4 letters) suitable as a file extension perhaps.
Brainstorming some ideas:
cap: Clojure Archive Package
cpa: Clojure Package Archive
ca: Clojure Archive
car: Clojure Archive (half-assed pun on Lisp's car, plus you can
imagine the icon!)
clib: Clojure Library
clip: Clojure Library Package
On Fri, Aug 7, 2009 at 2:17 AM, Lauri Pesonenlauri.peso...@iki.fi wrote:
2009/8/6 James Reeves weavejes...@googlemail.com:
On Aug 6, 8:31 pm, Howard Lewis Ship hls...@gmail.com wrote:
I'm cringing at the sight of XML here.
XML is frequently overused, but it is a good format for representing
dense, structured data. For example:
repository name=third-party
package name=Compojure href=/compojure.xml/
/repository
Compared to:
{:type :repository
:name third-party
:content [{ :type :package
:name Compojure
:href /compojure.xml }]}
Surely we can do better with s-expressions:
(:repository third-party [(:package Compojure /compojure.xml)])
I guess it might get a bit trickier if you have a lot of optional
attributes...
And you can use the s-expressions as an on the wire interchange format
as well, which works especially well if both ends are written in lisp.
--
! Lauri
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
--~--~-~--~~~---~--~~
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: Package manager proposal
Hi, On Aug 7, 11:45 am, Howard Lewis Ship hls...@gmail.com wrote: car: Clojure Archive (half-assed pun on Lisp's car, plus you can imagine the icon!) The other half of the pun's ass is on Java's jar. ;) .cljp: clojure package .clja: clojure archive Playing with Clojure's source extension .clj. Sincerely Meikel --~--~-~--~~~---~--~~ 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: Package manager proposal
On 07/08/2009, at 7:15 PM, Howard Lewis Ship wrote: Ruby and Gem is such great terminology, can we come up with something half as cool? Closure and Resolution, are a pair of parallel hononymic puns. Or Clojure/Seal - you close the package and seal it. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre --~--~-~--~~~---~--~~ 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: Clojure performance tests and clojure a little slower than Java
On Thu, Aug 6, 2009 at 6:57 PM, Andy Fingerhut andy_finger...@alum.wustl.edu wrote: You are correct. I've updated that file: http://github.com/jafingerhut/clojure-benchmarks/blob/bb9755bdeeccae84a9b09fbf34e45f6d45d4b627/RESULTS Could you post the Mandelbrot code you use? Because I know for a fact that Clojure can do FP calcs as fast as native C code, given the -server vm and a loop/recur with unboxed doubles, and my understanding of Mandelbrot is that it's just FP calcs. --~--~-~--~~~---~--~~ 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: Current API doc (for HEAD)
On Fri, Aug 7, 2009 at 1:41 PM, Tom Faulhabertomfaulha...@gmail.com wrote: Tom, are you amenable? Yup, happy to. Where should it go? I'm generating real html now, not wiki-text (for a bunch of reasons, among them the ability to download a tree and use your browser offline, old version support, etc.), so the current system wouldn't post back to clojure.org very efficiently. But I could throw something onto the github pages for clojure, for instance. IIRC you can use plain HTML on the github pages. They are only processed by Jekyll, if you have the YAML front-matter in the file (http://wiki.github.com/mojombo/jekyll/usage see index.html section). And I personally like to have offline docs. I figure that this is a side effect of not ever-present internet connections. Your work style actually changes quite drastic if you know that you'll be offline if it happens to be a rainy day ;) DVCS, local VMs (as opposed to remote servers for testing), offline docs etc. become all of a sudden extremely attractive. Cheers, Daniel --~--~-~--~~~---~--~~ 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: Package manager proposal
.car +1 (jar pun)
On Aug 7, 5:45 am, Howard Lewis Ship hls...@gmail.com wrote:
Ruby and Gem is such great terminology, can we come up with something
half as cool?
Want something short (3 - 4 letters) suitable as a file extension perhaps.
Brainstorming some ideas:
cap: Clojure Archive Package
cpa: Clojure Package Archive
ca: Clojure Archive
car: Clojure Archive (half-assed pun on Lisp's car, plus you can
imagine the icon!)
clib: Clojure Library
clip: Clojure Library Package
On Fri, Aug 7, 2009 at 2:17 AM, Lauri Pesonenlauri.peso...@iki.fi wrote:
2009/8/6 James Reeves weavejes...@googlemail.com:
On Aug 6, 8:31 pm, Howard Lewis Ship hls...@gmail.com wrote:
I'm cringing at the sight of XML here.
XML is frequently overused, but it is a good format for representing
dense, structured data. For example:
repository name=third-party
package name=Compojure href=/compojure.xml/
/repository
Compared to:
{:type :repository
:name third-party
:content [{ :type :package
:name Compojure
:href /compojure.xml }]}
Surely we can do better with s-expressions:
(:repository third-party [(:package Compojure /compojure.xml)])
I guess it might get a bit trickier if you have a lot of optional
attributes...
And you can use the s-expressions as an on the wire interchange format
as well, which works especially well if both ends are written in lisp.
--
! Lauri
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
--~--~-~--~~~---~--~~
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: Package manager proposal
car: Clojure Archive (half-assed pun on Lisp's car, plus you can imagine the icon!) +1 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Transient Data Structures
Hi Patrick !
Can you post some code. here is what I get:
user= (- {} transient (assoc! :a 1) (assoc! :b 2) (assoc! :c 3) (assoc! :d
4)
(assoc! :e 5) (assoc! :f 6) (assoc! :g 7) (assoc! :h 8) (assoc! :i 9)
persistent!)
{:a 1, :c 3, :b 2, :f 6, :g 7, :d 4, :e 5, :i 9, :h 8}
user= (persistent! (reduce #(assoc! %1 (str k %2) %2) (transient {})
(range 2
0)))
{k0 0, k1 1, k2 2, k3 3, k4 4, k5 5, k10 10, k6 6, k11 11,
k7
7, k12 12, k8 8, k13 13, k9 9, k14 14, k15 15, k16 16, k17
17,
k18 18, k19 19}
Christophe
On Fri, Aug 7, 2009 at 10:07 AM, Patrick Sullivan
wizardofwestma...@gmail.com wrote:
Testing Transient w/Hashmaps (Thanks Cristophe!) and it seems like the
object won't store more then 8 keys. At first I thought it was my
frequency function
that was rolling it up, but then I simply tried creating a transient
object and manually assoc! ing a bunch of items into it. After the
8th it seemed to stop taking new
keys.
Am I doing something silly here or is this a bug?
~Patrick Sullivan
On Aug 6, 5:53 am, Rich Hickey richhic...@gmail.com wrote:
On Aug 5, 10:10 pm, Luc Prefontaine lprefonta...@softaddicts.ca
wrote:
I like this very much... that's the kind of clever optimizations that
preserves Clojure principles and
can yield significant performance increases. This could also help
dealing with performance critics
in these small mutable languages benchmarks that newbies attempt to
clone in Clojure.
Thank's Rich !
You're welcome!
And special thanks to Christophe Grand, who (quickly!) applied the
same technique to the hash maps and contributed that yesterday. So
now, in the master branch, vectors and hash maps support transients.
Everyone please try them out (where appropriate :).
Rich
--
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (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: a better reductions?
I have to revise my last recommendation. The signature of the second call should be [f val coll] in order to match reduce. Admittedly, this is a tiny detail. Sean On Aug 6, 4:28 pm, Sean Devlin francoisdev...@gmail.com wrote: One more thought. I'd change the signature of the second call to [f init coll] This matches the original reductions. On Aug 6, 4:20 pm, Sean Devlin francoisdev...@gmail.com wrote: It seems to have the same signature, so as a consumer of the library it's the same to me. If the speedup holds, I say make the change to your version. The only warning is that I couldn't find any regression tests for seq- utils. Perhaps this is a chance to add some. My $.02 Sean On Aug 6, 4:09 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: Is the following an improvement on clojure.contrib.seq-utils/ reductions, or a step backwards? (defn my-reductions ([f coll] (if (seq coll) (cons (first coll) (my-reductions f (first coll) (rest coll))) (cons (f) nil))) ([f acc coll] (if (seq coll) (let [nextval (f acc (first coll))] (lazy-seq (cons nextval (my-reductions f nextval (rest coll On the plus side, it appears to be faster (as collections grow large), and it doesn't cheat by introducing an atom. On the minus side it isn't as pretty as the one in contrib. 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 -~--~~~~--~~--~--~---
Re: Transient Data Structures
This is awesome. I'm curious if support for maps is planned in addition to vectors? A lot of my code makes heavy use of maps, and it would be great to get a performance boost. Travis On Aug 3, 5:25 pm, Rich Hickey richhic...@gmail.com wrote: I've been doing some work on Transient Data Structures. You can read about them here: http://clojure.org/transients Feedback welcome, Rich --~--~-~--~~~---~--~~ 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: Transient Data Structures
Oops, only saw the first page of this thread (still getting used to Google Groups). I apologize for missing this one. And special thanks to Christophe Grand, who (quickly!) applied the same technique to the hash maps and contributed that yesterday. So now, in the master branch, vectors and hash maps support transients. Everyone please try them out (where appropriate :). On Aug 7, 10:07 am, tmountain tinymount...@gmail.com wrote: This is awesome. I'm curious if support for maps is planned in addition to vectors? A lot of my code makes heavy use of maps, and it would be great to get a performance boost. Travis On Aug 3, 5:25 pm, Rich Hickey richhic...@gmail.com wrote: I've been doing some work on Transient Data Structures. You can read about them here: http://clojure.org/transients Feedback welcome, Rich --~--~-~--~~~---~--~~ 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: Transient Data Structures
Err assoc! obviously ;-)
(Sorry for the double post, didn't want to confuse Cristophe).
On Aug 7, 8:15 am, Patrick Sullivan wizardofwestma...@gmail.com
wrote:
I don't have the EXACT code handy to c/p (at work now) but I did
something like the following.
(apologies for doing it such an iterative looking way, never got
comfortable with - ;-))
(def transhashmap (transient {})
(assoc transhashmap a 1)
(assoc transhashmap b 2)
etc
Then when I did (count transhashmap) I never got higher than 8.
Perhaps something about the way it is handling strings/characters as a
hash is broken? I know my original code that screwed me up was taking
a long text and breaking it down into wordcounts.
~Patrick
On Aug 7, 7:38 am, Christophe Grand christo...@cgrand.net wrote:
Hi Patrick !
Can you post some code. here is what I get:
user= (- {} transient (assoc! :a 1) (assoc! :b 2) (assoc! :c 3) (assoc! :d
4)
(assoc! :e 5) (assoc! :f 6) (assoc! :g 7) (assoc! :h 8) (assoc! :i 9)
persistent!)
{:a 1, :c 3, :b 2, :f 6, :g 7, :d 4, :e 5, :i 9, :h 8}
user= (persistent! (reduce #(assoc! %1 (str k %2) %2) (transient {})
(range 2
0)))
{k0 0, k1 1, k2 2, k3 3, k4 4, k5 5, k10 10, k6 6, k11 11,
k7
7, k12 12, k8 8, k13 13, k9 9, k14 14, k15 15, k16 16, k17
17,
k18 18, k19 19}
Christophe
On Fri, Aug 7, 2009 at 10:07 AM, Patrick Sullivan
wizardofwestma...@gmail.com wrote:
Testing Transient w/Hashmaps (Thanks Cristophe!) and it seems like the
object won't store more then 8 keys. At first I thought it was my
frequency function
that was rolling it up, but then I simply tried creating a transient
object and manually assoc! ing a bunch of items into it. After the
8th it seemed to stop taking new
keys.
Am I doing something silly here or is this a bug?
~Patrick Sullivan
On Aug 6, 5:53 am, Rich Hickey richhic...@gmail.com wrote:
On Aug 5, 10:10 pm, Luc Prefontaine lprefonta...@softaddicts.ca
wrote:
I like this very much... that's the kind of clever optimizations that
preserves Clojure principles and
can yield significant performance increases. This could also help
dealing with performance critics
in these small mutable languages benchmarks that newbies attempt to
clone in Clojure.
Thank's Rich !
You're welcome!
And special thanks to Christophe Grand, who (quickly!) applied the
same technique to the hash maps and contributed that yesterday. So
now, in the master branch, vectors and hash maps support transients.
Everyone please try them out (where appropriate :).
Rich
--
Professional:http://cgrand.net/(fr)
On Clojure:http://clj-me.blogspot.com/(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: Transient Data Structures
(def transhashmap (transient {})
(assoc transhashmap a 1)
(assoc transhashmap b 2)
etc
Isn't that what Rich was talking about, about not bashing in place?
On Fri, Aug 7, 2009 at 6:45 PM, Patrick Sullivan
wizardofwestma...@gmail.com wrote:
I don't have the EXACT code handy to c/p (at work now) but I did
something like the following.
(apologies for doing it such an iterative looking way, never got
comfortable with - ;-))
(def transhashmap (transient {})
(assoc transhashmap a 1)
(assoc transhashmap b 2)
etc
Then when I did (count transhashmap) I never got higher than 8.
Perhaps something about the way it is handling strings/characters as a
hash is broken? I know my original code that screwed me up was taking
a long text and breaking it down into wordcounts.
~Patrick
On Aug 7, 7:38 am, Christophe Grand christo...@cgrand.net wrote:
Hi Patrick !
Can you post some code. here is what I get:
user= (- {} transient (assoc! :a 1) (assoc! :b 2) (assoc! :c 3) (assoc!
:d
4)
(assoc! :e 5) (assoc! :f 6) (assoc! :g 7) (assoc! :h 8) (assoc! :i 9)
persistent!)
{:a 1, :c 3, :b 2, :f 6, :g 7, :d 4, :e 5, :i 9, :h 8}
user= (persistent! (reduce #(assoc! %1 (str k %2) %2) (transient {})
(range 2
0)))
{k0 0, k1 1, k2 2, k3 3, k4 4, k5 5, k10 10, k6 6, k11
11,
k7
7, k12 12, k8 8, k13 13, k9 9, k14 14, k15 15, k16 16,
k17
17,
k18 18, k19 19}
Christophe
On Fri, Aug 7, 2009 at 10:07 AM, Patrick Sullivan
wizardofwestma...@gmail.com wrote:
Testing Transient w/Hashmaps (Thanks Cristophe!) and it seems like the
object won't store more then 8 keys. At first I thought it was my
frequency function
that was rolling it up, but then I simply tried creating a transient
object and manually assoc! ing a bunch of items into it. After the
8th it seemed to stop taking new
keys.
Am I doing something silly here or is this a bug?
~Patrick Sullivan
On Aug 6, 5:53 am, Rich Hickey richhic...@gmail.com wrote:
On Aug 5, 10:10 pm, Luc Prefontaine lprefonta...@softaddicts.ca
wrote:
I like this very much... that's the kind of clever optimizations
that
preserves Clojure principles and
can yield significant performance increases. This could also help
dealing with performance critics
in these small mutable languages benchmarks that newbies attempt
to
clone in Clojure.
Thank's Rich !
You're welcome!
And special thanks to Christophe Grand, who (quickly!) applied the
same technique to the hash maps and contributed that yesterday. So
now, in the master branch, vectors and hash maps support transients.
Everyone please try them out (where appropriate :).
Rich
--
Professional:http://cgrand.net/(fr)
On Clojure:http://clj-me.blogspot.com/(en)
--
John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Transient Data Structures
On 7 Aug., 10:07, Patrick Sullivan wizardofwestma...@gmail.com
wrote:
Am I doing something silly here or is this a bug?
You probably are using conj! for the side-effect, but after growing
the hashmap to size 8 conj! returns a different map.
user (def foo (transient {1 1 2 2 3 3 4 4 5 5 6 6 7 7 8
8}))
#'user/
foo
user (class
foo)
clojure.lang.PersistentArrayMap
$TransientArrayMap
user (def new-foo (conj! foo {9
9}))
#'user/new-
foo
user (class
foo)
clojure.lang.PersistentArrayMap
$TransientArrayMap
user (class new-
foo)
clojure.lang.PersistentHashMap
$TransientHashMap
user (identical? foo new-
foo)
false
user (def foo (conj! foo {9
9}))
#'user/
foo
user (persistent!
foo)
{1 1, 2 2, 3 3, 4 4, 5 5, 6 6, 7 7, 8 8, 9
9}
remember to capture the return value of the modifying function calls.
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
-~--~~~~--~~--~--~---
Re: Transient Data Structures
Ah hah, yeah I'm dumb, thanks to you and AlexK for catching my
silliness.
Funny how when I'm using normal clojure persistant structs I don't
think about doing it the right way twice, but when doing it as a
transient I slip into old imperative habits *headslap*
~Patrick
On Aug 7, 8:20 am, John Newman john...@gmail.com wrote:
(def transhashmap (transient {})
(assoc transhashmap a 1)
(assoc transhashmap b 2)
etc
Isn't that what Rich was talking about, about not bashing in place?
On Fri, Aug 7, 2009 at 6:45 PM, Patrick Sullivan
wizardofwestma...@gmail.com wrote:
I don't have the EXACT code handy to c/p (at work now) but I did
something like the following.
(apologies for doing it such an iterative looking way, never got
comfortable with - ;-))
(def transhashmap (transient {})
(assoc transhashmap a 1)
(assoc transhashmap b 2)
etc
Then when I did (count transhashmap) I never got higher than 8.
Perhaps something about the way it is handling strings/characters as a
hash is broken? I know my original code that screwed me up was taking
a long text and breaking it down into wordcounts.
~Patrick
On Aug 7, 7:38 am, Christophe Grand christo...@cgrand.net wrote:
Hi Patrick !
Can you post some code. here is what I get:
user= (- {} transient (assoc! :a 1) (assoc! :b 2) (assoc! :c 3) (assoc!
:d
4)
(assoc! :e 5) (assoc! :f 6) (assoc! :g 7) (assoc! :h 8) (assoc! :i 9)
persistent!)
{:a 1, :c 3, :b 2, :f 6, :g 7, :d 4, :e 5, :i 9, :h 8}
user= (persistent! (reduce #(assoc! %1 (str k %2) %2) (transient {})
(range 2
0)))
{k0 0, k1 1, k2 2, k3 3, k4 4, k5 5, k10 10, k6 6, k11
11,
k7
7, k12 12, k8 8, k13 13, k9 9, k14 14, k15 15, k16 16,
k17
17,
k18 18, k19 19}
Christophe
On Fri, Aug 7, 2009 at 10:07 AM, Patrick Sullivan
wizardofwestma...@gmail.com wrote:
Testing Transient w/Hashmaps (Thanks Cristophe!) and it seems like the
object won't store more then 8 keys. At first I thought it was my
frequency function
that was rolling it up, but then I simply tried creating a transient
object and manually assoc! ing a bunch of items into it. After the
8th it seemed to stop taking new
keys.
Am I doing something silly here or is this a bug?
~Patrick Sullivan
On Aug 6, 5:53 am, Rich Hickey richhic...@gmail.com wrote:
On Aug 5, 10:10 pm, Luc Prefontaine lprefonta...@softaddicts.ca
wrote:
I like this very much... that's the kind of clever optimizations
that
preserves Clojure principles and
can yield significant performance increases. This could also help
dealing with performance critics
in these small mutable languages benchmarks that newbies attempt
to
clone in Clojure.
Thank's Rich !
You're welcome!
And special thanks to Christophe Grand, who (quickly!) applied the
same technique to the hash maps and contributed that yesterday. So
now, in the master branch, vectors and hash maps support transients.
Everyone please try them out (where appropriate :).
Rich
--
Professional:http://cgrand.net/(fr)
On Clojure:http://clj-me.blogspot.com/(en)
--
John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Package manager proposal
+1 on .car here too. Plus, I imagine the icon to be a 1950's-era muscle car; a nod to Lisp's age. On Fri, Aug 7, 2009 at 8:13 AM, Justin Johnsonjus...@honesthacker.com wrote: car: Clojure Archive (half-assed pun on Lisp's car, plus you can imagine the icon!) +1 -- Chris Wilson christopher.j.wil...@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 -~--~~~~--~~--~--~---
Re: Clojure as a First Language
Thanks for all the responses, both on the list and off. Many good counter-arguments were given, but I think the most compelling one was the issue of Java-interop. Without a doubt, at least some knowledge of Java is necessary to really do much of anything interesting. It's unfortunate that such a strength, Java-interop, is also such a dependency in terms of knowledge. I guess I took my Java knowledge for granted. So it seems like, as it stands now, Clojure is a tool made for people already preoccupied with getting things done and not so much a tool for learning to program. It's designed for a certain purpose and that's OK. Perhaps a better argument at this point would be that, if you are a novice programmer and you already know Java, Clojure should be your next language :) --~--~-~--~~~---~--~~ 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: a better reductions?
I believe that if you're going for speed, another trick is to use if-let to bind a name to (seq coll) and reuse the new name, rather than coll, when applying first and rest later in the function. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
with-out-str assumes Unix line ends
Anne's recent attempt to start a new thread for this question seems not to have worked. I'd hate for her and ataggart to be frustrated by further back-and-forth over the identity of the thread he started, so I'm starting a new thread for her question. === begin content from Anne === Sorry for the confusion - I read this list on an email feed. Turns out replying to a message from there and changing the subject isn't sufficient to start a new thread. Apparently it renames the thread. (suboptimal). original question: (use 'clojure.contrib.duck-streams) (spit C:\\test.txt (with-out-str (println foo) (println bar) (flush))) On my XP Tablet OS computer results in a file with unix line endings. Is this proper behavior? Mike Hinchey's response: What does this return on Windows? (with-out-str (.println (java.io.PrintWriter. *out*))) If it's \r\n, then maybe (newline) should be changed to print (System/getProperty line.separator) instead of \newline as it does now. Thoughts? -Mike === On XP tablet user= (seq (with-out-str (.println (java.io.PrintWriter. *out* (\return \newline) --~--~-~--~~~---~--~~ 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: enhancement request: a simple way to read a file
Try contrib library duck-streams. --~--~-~--~~~---~--~~ 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: a better reductions?
On Aug 7, 1:23 am, Daniel Lyons fus...@storytotell.org wrote: This is the difference between FreeBSD and NetBSD. I agree, but I also find it useful to crack open core and contrib to see coding examples and to understand algorithms. I'd suggest to include into library for teaching purposes variants of unoptimized functions with a suffix -naive. Say reduction-naive. This way you could have both beautiful algorithm for teaching purposes, and optimized function for practical purposes. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
combining methods
Hey All, Does clojure have an equivalent of either CLOS's `call-next-method' or java's super? For example, given the multi-method, and the interfaces ICDISCElement and IODMDef, where IODMDef extends ICDISCElement (defmulti validate class) (defmethod validate ICDISCElement [elem] ;;generic validation of all elements) (defmethod validate IODMDef [def] ;;how can I do stuff in here then pass control to the other validate method) --~--~-~--~~~---~--~~ 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: enhancement request: a simple way to read a file
Vagif Verdi wrote: Try contrib library duck-streams. I know duck-streams rather well. You missed the point, Vagif. Albert -- Albert Cardona http://albert.rierol.net --~--~-~--~~~---~--~~ 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: Package manager proposal
I like the name Clojure Archive. On another note, I always wondered why xml was such a requirement for Java dependency management. Couldn't we design some sort of url schema, that you could just pass to a package importer in the program. First time you run, it could fetch the packages or automatically check for upgrades etc. This could be managed in an external file if that seems safer. Just a simple manager that could wget the jars (which is all essentially that package managers like ruby gems do). On a slightly unrelated note, how might we index packages for exploration? I think that packages should be indexed both by descriptions provided by the author and by comments within the code itself, in the docstrings of the fn's. Eventually, maybe we could cherry pick namespaces and even pull specific functions! Mark --~--~-~--~~~---~--~~ 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: Clojure performance tests and clojure a little slower than Java
On Aug 6, 6:49 pm, John Harrop jharrop...@gmail.com wrote: On Thu, Aug 6, 2009 at 6:57 PM, Andy Fingerhut andy_finger...@alum.wustl.edu wrote: You are correct. I've updated that file: http://github.com/jafingerhut/clojure-benchmarks/blob/bb9755bdeeccae8... Could you post the Mandelbrot code you use? Because I know for a fact that Clojure can do FP calcs as fast as native C code, given the -server vm and a loop/recur with unboxed doubles, and my understanding of Mandelbrot is that it's just FP calcs. Here is the root of the clojure-benchmarks github directory tree. They are all in there: http://github.com/jafingerhut/clojure-benchmarks/tree/master You can get specific files by browsing the directory tree on the web site, or if you use git, you can git clone the whole thing and have a local copy on your computer: git clone git://github.com/jafingerhut/clojure-benchmarks.git It is mandelbrot/mandelbrot.clj-1.clj. There is a mandelbrot.clj-2.clj that is the same, except it uses my modified-pmap to compute separate rows in parallel. I'm still investigating reasons why parallelism isn't getting me much bang for the buck in the questions about pmap thread before worrying performance turning more complex programs using floats/doubles in parallel. I did go back to the archives for a discussion in early April, 2009 when others on this list were discussing how to tweak the core of the mandelbrot code (the function dot in my version), and I used the fastest of those versions I could find, but I may have missed some opportunities for speeding it up, and I definitely welcome any and all improved versions. I'd recommend comparing the speed on your machine vs. the Java version that is in the same directory as the Clojure source. Andy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: enhancement request: a simple way to read a file
On Aug 7, 2009, at 12:19 PM, Albert Cardona wrote: Currently, one must resort to incantations like: (with-open [stream (java.io.BufferedReader. (java.io.FileReader. /home/albert/test.xml))] (doseq [line (line-seq stream)] (println line))) (use 'clojure.contrib.duck-streams) (doseq [line (read-lines /home/albert/test.xml)] (println line)) (Sure, one can write (vec (.split (slurp /home/albert/test.xml) \n)) but that again implies one knows the java API by heart.) (vec (read-lines /home/albert/test.xml)) — Daniel Lyons --~--~-~--~~~---~--~~ 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: Package manager proposal
On Aug 7, 1:51 pm, Sean Devlin francoisdev...@gmail.com wrote: .car +1 (jar pun) I'll go against the crowd and say I don't like this name. It seems confusing to have a car symbol in your source code that has an entirely different purpose to its traditional binding. - James --~--~-~--~~~---~--~~ 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: Package manager proposal
On Aug 7, 10:17 am, Lauri Pesonen lauri.peso...@iki.fi wrote: Surely we can do better with s-expressions: (:repository third-party [(:package Compojure /compojure.xml)]) Not very forward compatible, though. Perhaps we should sidestep the whole question about the format of package metadata. At some point, the metadata will have to be parsed into a Clojure data structure, so we could have a parsing multimethod that could take a variety of different input formats. This would allow Maven repositories (in XML) to co-exist with Clojure repositories (in S-Exprs). - James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
zipping together two lists
Most languages I've used define a zip method, where you can take two lists and get a list of the pairs of elements in those lists. So, (zip '(1 2 3) '(4 5 6)) would give ([1 4] [2 5] [3 6]). Does clojure have a core function like that? I've been poking around, but all I'm finding is zipmap, which is close but it builds a map instead of a list of pairs. Writing my own isn't a big deal, but it seems like something that has to be in the core somewhere. --~--~-~--~~~---~--~~ 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: zipping together two lists
On Aug 7, 2009, at 3:04 PM, tsuraan wrote: Most languages I've used define a zip method, where you can take two lists and get a list of the pairs of elements in those lists. So, (zip '(1 2 3) '(4 5 6)) would give ([1 4] [2 5] [3 6]). Does clojure have a core function like that? I've been poking around, but all I'm finding is zipmap, which is close but it builds a map instead of a list of pairs. Writing my own isn't a big deal, but it seems like something that has to be in the core somewhere. map can do this. user (map vector '(1 2 3) '(4 5 6)) ([1 4] [2 5] [3 6]) — Daniel Lyons --~--~-~--~~~---~--~~ 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: zipping together two lists
map can do this. user (map vector '(1 2 3) '(4 5 6)) ([1 4] [2 5] [3 6]) Yeah, that works pretty well. 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 -~--~~~~--~~--~--~---
Re: Clojure as a First Language
As a Noob to clojure, one thing that scares me is the comment-to-code ratio. I mean, the meaning that can be packed into clojure can be immense, which is great, but it seems like that means that a lack of commenting is all the more dire of a problem. The best commented clojure code that I've seen so far is probably the github clojure repository, and that seems to have devolved to the minimum comment density of a single comment per function. Maybe I've just been looking at the wrong pieces of clojure code, but so far it's been a turn-off in the code that I've looked through. --~--~-~--~~~---~--~~ 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: zipping together two lists
On Fri, Aug 7, 2009 at 5:04 PM, tsuraan tsur...@gmail.com wrote: Most languages I've used define a zip method, where you can take two lists and get a list of the pairs of elements in those lists. So, (zip '(1 2 3) '(4 5 6)) would give ([1 4] [2 5] [3 6]). Does clojure have a core function like that? I've been poking around, but all I'm finding is zipmap, which is close but it builds a map instead of a list of pairs. Writing my own isn't a big deal, but it seems like something that has to be in the core somewhere. Yea! A clojure question I can answer, instead of just ask! Woohoo! You can replace zip with map list, like: user= (map list [ 1 2 3] [4 5 6]) ((1 4) (2 5) (3 6)) user= Brian --~--~-~--~~~---~--~~ 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: Package manager proposal
I like this idea too, because if you end up wanting to port this package manager to CLR, Parrot, or JS, you're less tied down to the package formats of specific platforms. Heck, even if Clojure was ported to Ruby (not that there'd be any point to do that), you could wrap the Gems framework. On Sat, Aug 8, 2009 at 1:30 AM, James Reeves weavejes...@googlemail.comwrote: On Aug 7, 10:17 am, Lauri Pesonen lauri.peso...@iki.fi wrote: Surely we can do better with s-expressions: (:repository third-party [(:package Compojure /compojure.xml)]) Not very forward compatible, though. Perhaps we should sidestep the whole question about the format of package metadata. At some point, the metadata will have to be parsed into a Clojure data structure, so we could have a parsing multimethod that could take a variety of different input formats. This would allow Maven repositories (in XML) to co-exist with Clojure repositories (in S-Exprs). - James -- John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure performance tests and clojure a little slower than Java
Your core loop seems to be: (loop [zr (double 0.0) zi (double 0.0) zr2 (double 0.0) zi2 (double 0.0) iterations-remaining iterations-remaining] (if (and (not (neg? iterations-remaining)) ( (+ zr2 zi2) limit-square)) (let [new-zi (double (+ (* (* f2 zr) zi) pi)) new-zr (double (+ (- zr2 zi2) pr)) new-zr2 (double (* new-zr new-zr)) new-zi2 (double (* new-zi new-zi))] (recur new-zr new-zi new-zr2 new-zi2 (dec iterations-remaining))) What I suggest is (loop [zr (double 0.0) zi (double 0.0) i (int (inc iterations-remaining))] (let [zr2 (* zr zr) zi2 (* zi zi)] (if (and (not (= 0 i)) ( (+ zr2 zi2 limit-square))) (recur (+ (- zr2 zi2) pr) (+ (* (* f2 zr) zi) pi) (unchecked-inc i)) (whatever... * Same calculations * Less items in recur rebind * Counter is also primitive (untested, may need slight tweakage) --~--~-~--~~~---~--~~ 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: binding and bundles of variables
Great, thanks. Is clojure.lang.Var/pushThreadBindings a public, supported part of the API? Can I use it without fear of suddenly dropped support? On Aug 6, 10:56 pm, Meikel Brandmeyer m...@kotka.de wrote: Hi, On Aug 7, 7:12 am, samppi rbysam...@gmail.com wrote: So is this possible without arcane stuff? Inhttp://groups.google.com/group/clojure/browse_thread/thread/23fe1a5c9..., I asked about using a macro to do this, and the consensus seems to be that it's possible with magic, but it's generally a bad idea. So what should I do—is there anything I can do, other than using only one map variable? And in the above thread I wrote the following: For this special case however you can solve the issue as follows: (defn with-bundle* [the-map thunk] (clojure.lang.Var/pushThreadBindings the-map) (try (thunk) (finally (clojure.lang.Var/popThreadBindings (defmacro with-bundle [the-map body] `(with-bundle* ~the-map (fn [] ~...@body))) Hope this helps. Sincerely Meikel --~--~-~--~~~---~--~~ 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: Test a random function
Generally, if you're testing something that is supposed to be truly random (like shuffle and rand-elt), you do a large sample and make sure the distribution of results is truly (close to) uniform. -SS On Aug 7, 9:17 pm, Sean Devlin francoisdev...@gmail.com wrote: Ok, I need some help. I'm writing some tests for c.c.seq-utils, and I ran into a problem defining a test for both shuffle and rand-elt. Does anyone here have any experience writing tests for random functions? Am I going to need to use serious statistics the answer this? Ideas? --~--~-~--~~~---~--~~ 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: combining methods
There isn't an equivalent right now. The simplest workaround is to factor out the common code into an ordinary function, and call it from your multimethods. -SS On Aug 7, 2:55 pm, Andy Chambers achambers.h...@googlemail.com wrote: Hey All, Does clojure have an equivalent of either CLOS's `call-next-method' or java's super? For example, given the multi-method, and the interfaces ICDISCElement and IODMDef, where IODMDef extends ICDISCElement (defmulti validate class) (defmethod validate ICDISCElement [elem] ;;generic validation of all elements) (defmethod validate IODMDef [def] ;;how can I do stuff in here then pass control to the other validate method) --~--~-~--~~~---~--~~ 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: Test a random function
The problem is how do you define close to uniform? All I remember my signals noise classes is that this really hard, and Zed Shaw's rant has convinced me that in order to do this right it takes time. I'm going to punt on the issue for now. Quick, is there a statistician in the house? Sean PS - I'm finding some interesting things testing seq-utils. I'll post my findings when I'm done. I would LOVE to get your feedback Stuart. On Aug 7, 9:35 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: Generally, if you're testing something that is supposed to be truly random (like shuffle and rand-elt), you do a large sample and make sure the distribution of results is truly (close to) uniform. -SS On Aug 7, 9:17 pm, Sean Devlin francoisdev...@gmail.com wrote: Ok, I need some help. I'm writing some tests for c.c.seq-utils, and I ran into a problem defining a test for both shuffle and rand-elt. Does anyone here have any experience writing tests for random functions? Am I going to need to use serious statistics the answer this? Ideas? --~--~-~--~~~---~--~~ 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: Test a random function
On Aug 7, 6:17 pm, Sean Devlin francoisdev...@gmail.com wrote:
Ok, I need some help. I'm writing some tests for c.c.seq-utils, and I
ran into a problem defining a test for both shuffle and rand-elt.
Does anyone here have any experience writing tests for random
functions? Am I going to need to use serious statistics the answer
this?
Ideas?
It depends upon what you want to test. If you want to test that rand-
elt selects an item from the seq s independently on each run, and with
equal probability for all elements, then that is effectively like
testing rand-int for the same properties, and yes, you will have to
get into some statistics to do so.
However, if you back off from testing the random part of the function,
there are some invariants that are always true that you could test,
such as:
(1) the value x returned by rand-elt should always be a member of the
seq s
(2) the value returned by shuffle should always have the same number
of each item as the input seq s. That is, if you evaluate the
function 'tally' below on the input seq s and on the returned seq t,
you should always find (= (tally s) (tally t)) is true.
(defn tally [s]
(loop [s s
t (transient {})]
(if-let [s (seq s)]
(let [item (first s)]
(recur (next s) (assoc! t item (inc (get t item 0)
(persistent! t
Andy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure performance tests and clojure a little slower than Java
On Aug 7, 5:14 pm, John Harrop jharrop...@gmail.com wrote: Your core loop seems to be: (loop [zr (double 0.0) zi (double 0.0) zr2 (double 0.0) zi2 (double 0.0) iterations-remaining iterations-remaining] (if (and (not (neg? iterations-remaining)) ( (+ zr2 zi2) limit-square)) (let [new-zi (double (+ (* (* f2 zr) zi) pi)) new-zr (double (+ (- zr2 zi2) pr)) new-zr2 (double (* new-zr new-zr)) new-zi2 (double (* new-zi new-zi))] (recur new-zr new-zi new-zr2 new-zi2 (dec iterations-remaining))) What I suggest is (loop [zr (double 0.0) zi (double 0.0) i (int (inc iterations-remaining))] (let [zr2 (* zr zr) zi2 (* zi zi)] (if (and (not (= 0 i)) ( (+ zr2 zi2 limit-square))) (recur (+ (- zr2 zi2) pr) (+ (* (* f2 zr) zi) pi) (unchecked-inc i)) (whatever... * Same calculations * Less items in recur rebind * Counter is also primitive (untested, may need slight tweakage) Needed unchecked-dec in place of unchecked-inc, and I used (zero? i) instead of (= 0 i) (not sure if that makes much difference), and the results are much better -- the time went down to a little less than half of what it was before. http://github.com/jafingerhut/clojure-benchmarks/blob/fe10ef25ec17b77dd03f6d1ccff4f35273764f3b/RESULTS I also tried it with 4 parallel threads on my 2-core machine, and this problem parallelizes significantly better than the simpler problem in the questions about pmap discussion thread -- nearly half the elapsed time, and only 6% more total CPU time for the 4-thread version vs. the sequential version. Thanks! Andy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure as a First Language
A bit of history (or archaeology ?) We are now back to the old times were we used to struggle about comments in the code. When I started coding, code was self-understandable according to the legend, especially assembly code. If you could not understand the code without comments, you did not even merit the privilege of modifying it. That led to the God syndrome which I still suffer from today :))) Of course that's an extreme and that does not make sense most of the time. Having the ability to read and understand systems of 100,000 un commented code lines and above is great but you still have to work with teams of mere mortals if you want to achieve something significant today, so it's best to keep away from that drug :) There is a balance between the # of code lines versus the # of comment lines but it's more based on the quality of the comments and the language being used than the actual ratio. Assembly code required most of the time one comment every two lines, Lisp much more less. Today some will say, we have JavaDoc like tools to save us... The OO approach can lead to myriads of objects and that requires a tool just to navigate in all the references in the code. But that automation does not capture the essence, just the ground level details. JavaDoc is very verbose about the insignificant details but useless in understanding the core behaviour of all these objects floating around and their interactions because most developers do not want to write decent synopsis in each class with all these HTML tags. That's why we see all these books written on how to use this framework, this library, ... That's good for them, they get paid to write their comments in a book instead of the code, why not ? JavaDoc tries to fill the voids by spitting so many details of microscopic scope that I find it better to read the source code when available to get a better understanding on how the components interact. Here we typically in Clojure code use a module header comment block and a function comment block plus some single comment lines if the code becomes a bit obscure. Each module comment block has a number of items: title, synopsis, author, history and each function comment block contains a synopsis, warnings, ... We emphasize explaining what the major chunks do (modules, functions). Clojure being expressive, no need to get entangled in the details IF the module and function goals are described with sufficient details. In this context being concise in comments makes sense. You can read the code much more like a book, you just print it and that's it (I read on paper, never was able to stand reading documents on my computer screen for very long times). Of course, I used to write 30,000 lines of code and more using a simple text editor (no language sensitivity), a compiler, a text search tool (no regexp), a linker and it's cross reference facility... I am used to travel lean and this approach is similar to the one I used in the last 25 years:))) I remember a custom tool a customer wrote to extract the detailed specs document directly from the code comments and processing this in a text processor to obtain a clear and well formatted document. It also made the code quite clear to read as is. I totally agree no comments is not good at all but JavaDoc style comments in Clojure ? I pray you all, please stay away of it : Luc On Fri, 2009-08-07 at 13:58 -0700, Tchalvak wrote: As a Noob to clojure, one thing that scares me is the comment-to-code ratio. I mean, the meaning that can be packed into clojure can be immense, which is great, but it seems like that means that a lack of commenting is all the more dire of a problem. The best commented clojure code that I've seen so far is probably the github clojure repository, and that seems to have devolved to the minimum comment density of a single comment per function. Maybe I've just been looking at the wrong pieces of clojure code, but so far it's been a turn-off in the code that I've looked through. Luc Préfontaine Armageddon was yesterday, today we have a real problem... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
seq-utils testing reveals potential flatten bugs
See Assembla ticket 13 in for clojure contrib to view the diff containing the test cases I just finished writing tests for the following functions in seq- utils: flatten separate includes? indexed group-by partition-by frequencies reductions rotations partition-all shuffle (invariants) rand-elt (invariants) find-first As best I can tell, all of these functions except flatten behave as they should. There were no surprises with them. flatten is a different story. I wrote my test cases to deliberately make flatten pass. This way it can be used as a regression testing tool. That being said, I found several behaviors with flatten that I think are bugs. Check the flatten test function at the beginning of the file for examples. The executive summary is 1. flattening a set at the top level always returns an empty seq. Wrapping the set in a seq call enables normal behavior 2. flattening a map at the top level always returns an empty seq. Wrapping the map in a seq call enables normal behavior 3. flattening a vector containing a set does not recursively enter the set. 4. flattening a vector containing a map does not recursively enter the map. 5. flattening nil returns an empty seq. The doc string explicitly states that (flatten nil) should return nil. In my opinion, flatten to behave more like this: http://gist.github.com/164291 It seems to me that the differnce is the sequential? call in flatten. One way to reconcile this is to have a proper seqable? function, like the one specified in clojure.contrib.core.seqable? (recently discussed here: http://groups.google.com/group/clojure/browse_thread/thread/9dbaff59e8de9a8a/7db470140505a92d ). There would still be some minor tweaking required, but I think this will enable maps and sets to behave properly. Hope this helps, Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
