bug affecting clojure.core/bean?
Hi, I'm wondering if I found a bug. I have the latest source from svn (r1291). user= (bean 1) java.lang.IllegalArgumentException: Wrong number of args passed to: core$bean--5161$fn--5179$thisfn It used to show the bean properties of the java.lang.Integer. Rob --~--~-~--~~~---~--~~ 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 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: bug affecting clojure.core/bean?
On Wed, Feb 18, 2009 at 12:35 AM, Rob rob.nikan...@gmail.com wrote: I'm wondering if I found a bug. I have the latest source from svn (r1291). user= (bean 1) java.lang.IllegalArgumentException: Wrong number of args passed to: core$bean--5161$fn--5179$thisfn You sure did. The conversion to lazy-seq code appears to introduce a paren typo and an incorrect nil pun. Patch attached. Rich, I think it'd be pretty useful to have as you mentioned in IRC a variant of destructuring that provided an unforced lazy-seq. It seems pretty common to want, in the body of a lazy-seq, a destructured 'first' but an unforced 'rest'. This is already the third or fourth time I've wanted to be able to do something like: (fn thisfn [plseq] (lazy-seq (when-let [[pkey rest etc] plseq] (cons (new clojure.lang.MapEntry pkey (v pkey)) (thisfn etc) --Chouser --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~--- commit 539242b543c99bf430c5b821f9c4a0ca769a8a26 Author: Chouser chou...@n01se.net Date: Wed Feb 18 10:57:25 2009 -0500 Fix bean lazy-seq diff --git a/trunk/src/clj/clojure/core_proxy.clj b/trunk/src/clj/clojure/core_proxy.clj index 2b2d01d..120ffbf 100644 --- a/trunk/src/clj/clojure/core_proxy.clj +++ b/trunk/src/clj/clojure/core_proxy.clj @@ -340,11 +340,11 @@ (count [] (count pmap)) (assoc [k v] (assoc (snapshot) k v)) (without [k] (dissoc (snapshot) k)) - (seq [] ((fn thisfn [pseq] + (seq [] ((fn thisfn [plseq] (lazy-seq - (when pseq + (when-let [pseq (seq plseq)] (cons (new clojure.lang.MapEntry (first pseq) (v (first pseq))) - (thisfn (rest pseq) (keys pmap))) + (thisfn (rest pseq)) (keys pmap))
Re: bug affecting clojure.core/bean?
On Feb 18, 11:04 am, Chouser chou...@gmail.com wrote: On Wed, Feb 18, 2009 at 12:35 AM, Rob rob.nikan...@gmail.com wrote: I'm wondering if I found a bug. I have the latest source from svn (r1291). user= (bean 1) java.lang.IllegalArgumentException: Wrong number of args passed to: core$bean--5161$fn--5179$thisfn You sure did. The conversion to lazy-seq code appears to introduce a paren typo and an incorrect nil pun. Patch attached. Patch applied, svn 1293 - thanks! Rich, I think it'd be pretty useful to have as you mentioned in IRC a variant of destructuring that provided an unforced lazy-seq. It seems pretty common to want, in the body of a lazy-seq, a destructured 'first' but an unforced 'rest'. This is already the third or fourth time I've wanted to be able to do something like: (fn thisfn [plseq] (lazy-seq (when-let [[pkey rest etc] plseq] (cons (new clojure.lang.MapEntry pkey (v pkey)) (thisfn etc) Yes, sure. It just comes down to the name: rest others? 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 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: bug affecting clojure.core/bean?
Or maybe: next ??? :- Frantisek On Feb 18, 5:27 pm, Rich Hickey richhic...@gmail.com wrote: On Feb 18, 11:04 am, Chouser chou...@gmail.com wrote: On Wed, Feb 18, 2009 at 12:35 AM, Rob rob.nikan...@gmail.com wrote: I'm wondering if I found a bug. I have the latest source from svn (r1291). user= (bean 1) java.lang.IllegalArgumentException: Wrong number of args passed to: core$bean--5161$fn--5179$thisfn You sure did. The conversion to lazy-seq code appears to introduce a paren typo and an incorrect nil pun. Patch attached. Patch applied, svn 1293 - thanks! Rich, I think it'd be pretty useful to have as you mentioned in IRC a variant of destructuring that provided an unforced lazy-seq. It seems pretty common to want, in the body of a lazy-seq, a destructured 'first' but an unforced 'rest'. This is already the third or fourth time I've wanted to be able to do something like: (fn thisfn [plseq] (lazy-seq (when-let [[pkey rest etc] plseq] (cons (new clojure.lang.MapEntry pkey (v pkey)) (thisfn etc) Yes, sure. It just comes down to the name: rest others? 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 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: bug affecting clojure.core/bean?
2009/2/18 Mark Volkmann r.mark.volkm...@gmail.com On Wed, Feb 18, 2009 at 10:27 AM, Rich Hickey richhic...@gmail.com wrote: On Feb 18, 11:04 am, Chouser chou...@gmail.com wrote: On Wed, Feb 18, 2009 at 12:35 AM, Rob rob.nikan...@gmail.com wrote: I'm wondering if I found a bug. I have the latest source from svn (r1291). user= (bean 1) java.lang.IllegalArgumentException: Wrong number of args passed to: core$bean--5161$fn--5179$thisfn You sure did. The conversion to lazy-seq code appears to introduce a paren typo and an incorrect nil pun. Patch attached. Patch applied, svn 1293 - thanks! Rich, I think it'd be pretty useful to have as you mentioned in IRC a variant of destructuring that provided an unforced lazy-seq. It seems pretty common to want, in the body of a lazy-seq, a destructured 'first' but an unforced 'rest'. This is already the third or fourth time I've wanted to be able to do something like: (fn thisfn [plseq] (lazy-seq (when-let [[pkey rest etc] plseq] (cons (new clojure.lang.MapEntry pkey (v pkey)) (thisfn etc) Yes, sure. It just comes down to the name: rest others? Of those I prefer rest because its meaning is more explicit. Maybe I miss the point totally, but didn't the recent change give the function 'next the meaning of not forcing the seq ? So next instead of rest ? ... and maybe either rest or next , and not just anymore ? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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: bug affecting clojure.core/bean?
If I've been following things correct: rest _used_ to force the seq, it does no longer. next forces the seq In my own mind i'm thinking next to mean (return the seq with the next value computed), rest now means just give me the uncomputed remaining values of the seq. On Wed, Feb 18, 2009 at 12:00 PM, Laurent PETIT laurent.pe...@gmail.comwrote: 2009/2/18 Mark Volkmann r.mark.volkm...@gmail.com On Wed, Feb 18, 2009 at 10:27 AM, Rich Hickey richhic...@gmail.com wrote: On Feb 18, 11:04 am, Chouser chou...@gmail.com wrote: On Wed, Feb 18, 2009 at 12:35 AM, Rob rob.nikan...@gmail.com wrote: I'm wondering if I found a bug. I have the latest source from svn (r1291). user= (bean 1) java.lang.IllegalArgumentException: Wrong number of args passed to: core$bean--5161$fn--5179$thisfn You sure did. The conversion to lazy-seq code appears to introduce a paren typo and an incorrect nil pun. Patch attached. Patch applied, svn 1293 - thanks! Rich, I think it'd be pretty useful to have as you mentioned in IRC a variant of destructuring that provided an unforced lazy-seq. It seems pretty common to want, in the body of a lazy-seq, a destructured 'first' but an unforced 'rest'. This is already the third or fourth time I've wanted to be able to do something like: (fn thisfn [plseq] (lazy-seq (when-let [[pkey rest etc] plseq] (cons (new clojure.lang.MapEntry pkey (v pkey)) (thisfn etc) Yes, sure. It just comes down to the name: rest others? Of those I prefer rest because its meaning is more explicit. Maybe I miss the point totally, but didn't the recent change give the function 'next the meaning of not forcing the seq ? So next instead of rest ? ... and maybe either rest or next , and not just anymore ? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
