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 wrote: > On Aug 5, 10:10 pm, Luc Prefontaine > 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 : > > 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 :
>
> On Aug 6, 8:31 pm, Howard Lewis Ship 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:
>
>
>
>
>
> 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 Pesonen wrote:
>
> 2009/8/6 James Reeves :
>>
>> On Aug 6, 8:31 pm, Howard Lewis Ship 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:
>>
>>
>>
>>
>>
>> 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 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: Package manager proposal
On Fri, Aug 7, 2009 at 11:07 AM, Howard Lewis Ship wrote: > > Or really work this into core and add :packages to the (ns) macro. +1 I have been thinking about this recently anyway. Java is too rigid to work something like this into it's syntax, but Clojure could do it. The benefits that I see coming from this would be that you actually could declare OSGi style dependencies in the code. OSGi declares dependencies not on JARs, but on packages (which are then resolved and imported), and uses an optional range notation (in addition to a fixed version). So you could declare something like (ns example (:use clojure.contrib.json.read (1.5 == x)) (:use compojure.html (1.5 <= x < 2.0))) For the version 'function' a macro is probably needed, because I don't know if the OSGi API can resolve versions with a function, it might need some range datastructure, or even an equivalent string "[1.5,2.0)". This approach has the benefit that the code itself expresses, with which versions it's supposed to run (against which versions it was tested. Another benefit is that OSGi tools can actually be used as a resolver (a la ivy/maven), and they can resolve against OSGi repos, or Maven repos. Check "Cooking with Maven and OSGi" http://www.sonatype.com/books/mcookbook/reference/osgi.html The obvious drawback is that you don't know all future versions which it actually might run against. For that to work, there would still have to be a plug into the resolver, so it's possible to override dependencies (maybe in the first file that's loaded for the application you can tell the resolver that he should try to coalesce dependencies if possible, but that for namespace x.y which imports z in version 1.2, the version is actually 2.0 (and this isn't specified in the original code). Whatever module versioning proposal you take that is on the Java Platform, it needs some kind of annotation for the dependencies. In this way, the annotation could be where it's actually necessary (in the code), and not again outside the code, difficult to keep in sync. And keep in mind that this proposal doesn't mean that you have to run inside an OSGi container, or even use OSGi tools for dependency resolution. It just means that it's very compatible if you want to use OSGi, but you can still have the clojure core resolver use Corkscrew, Clod, or whatever we want (it would make sense to keep it plugable though). I would be interested to hear what people think about something along those lines. Whether you can see some benefits coming from this, or if you think that this presents too much of a hassle (I think it can be simplified to just have a single fixed version in the import statement, so you have a simpler version and it doesn't change so much from the status quo). 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: Current API doc (for HEAD)
On Fri, Aug 7, 2009 at 1:41 PM, Tom Faulhaber 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: a better reductions?
On Thu, Aug 6, 2009 at 4:09 PM, Stuart Halloway 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. > Good call, the version in contrib predates lazy-seq and full laziness. You can see the challenges faced in its implementation (back in the lazy-cons days) here: http://groups.google.com/group/clojure/browse_thread/thread/3edf6e82617e18e0/58d9e319ad92aa5f?#58d9e319ad92aa5f But, the version you have isn't fully lazy either. As a general rule, lazy-seq should wrap the entire body: (defn reductions ([f coll] (lazy-seq (if (seq coll) (cons (first coll) (reductions f (first coll) (rest coll))) (cons (f) nil ([f acc coll] (lazy-seq (if (seq coll) (let [nextval (f acc (first coll))] (cons nextval (reductions f nextval (rest coll 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: Package manager proposal
.car +1 (jar pun)
On Aug 7, 5:45 am, Howard Lewis Ship 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 Pesonen wrote:
>
> > 2009/8/6 James Reeves :
>
> >> On Aug 6, 8:31 pm, Howard Lewis Ship 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:
>
> >>
> >>
> >>
>
> >> 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 wrote:
> > On Aug 5, 10:10 pm, Luc Prefontaine
> > 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 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 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 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 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 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 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
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 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 wrote:
> > > On Aug 5, 10:10 pm, Luc Prefontaine
> > > 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
Err assoc! obviously ;-)
(Sorry for the double post, didn't want to confuse Cristophe).
On Aug 7, 8:15 am, Patrick Sullivan
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 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 wrote:
> > > > On Aug 5, 10:10 pm, Luc Prefontaine
> > > > 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 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 wrote:
> > > > On Aug 5, 10:10 pm, Luc Prefontaine
> > > > 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
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 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 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 wrote:
> > > > > On Aug 5, 10:10 pm, Luc Prefontaine
> > > > > 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 Johnson wrote: >> car: "Clojure Archive" (half-assed pun on Lisp's car, plus you can >> imagine the icon!) > > +1 > > > > -- Chris Wilson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
enhancement request: a simple way to read a file
Hi all, There is an omission in the core clojure library: there is no way to create a file reader. I follow the scheme of regex: all the verbosity of java.util.regex.* classes is hidden away, in a beautiful set of small (and heavily used) functions. For file I/O, though, core clojure has functions that deal with readers, like for example line-seq, but there is not a single function to create a reader trivially. 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))) ... which require writing in imports or fully qualified names for java classes whose existence I wish I could forget about. In order to use clojure from a REPL, just like I'd use Matlab or R or similar programs, a file-reader generator is missing. Every clojure user is going to have to reinvent the wheel, in the form of custom code in the user.clj to avoid excessive and avoidable typing. I understand one of the main problems is the required ".close" call on the reader, which so far is taken care of by the macro with-open. So: why not have a file-reader function in core clojure, that MUST be invoked from within a with-open macro (or throws an exception)? This would be the same scheme of dosync and alter/commute/etc. Then we'd write: (with-open [rdr (file-reader "/home/albert/test.xml")] (doseq [line (line-seq stream)] (println line))) The above would only be necssary when lazyness is a requirement. So, even better, in the spirit of the do-it-all "slurp" function, how about a non-lazy (hence no ".close" call issue) slurp-lines function? (Sure, one can write (vec (.split (slurp "/home/albert/test.xml") "\n")) but that again implies one knows the java API by heart.) Adding the above 2 functions and moving spit from clojure-contrib into core would finally make the clojure REPL a great REPL for text data I/O, and thus for data analysis in a research lab. 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: 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 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 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 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 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 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 wrote: > > On Aug 7, 10:17 am, Lauri Pesonen 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 wrote: > Hi, > > On Aug 7, 7:12 am, samppi 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 -~--~~~~--~~--~--~---
Test a random function
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
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 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 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 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 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 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 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 -~--~~~~--~~--~--~---
Durable transactions in practice?
Assuming people aren't patching clojure ala dave griffith's external transactions patch in the group files, what are people doing in practice to durably store the state of refs? Storing within a transaction and somehow ensuring your store operation is idempotent (not to mention reversible)? Sending off an agent from a transaction and not worrying about race conditions? Forgoing the use of STM in favor of locks + try / catch? I'm not so much asking about what particular store (RDBMS, prn to a file, whatever) is being used, as I am curious what kind of coordination is being used. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
