From noreply at rubyforge.org Wed Aug 1 04:41:32 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 1 Aug 2007 04:41:32 -0400 (EDT) Subject: [Facets] [ facets-Bugs-12736 ] Dictionary#dup does not work correctly Message-ID: <20070801084133.3E50C52408FF@rubyforge.org> Bugs item #12736, was opened at 2007-08-01 10:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=12736&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Thomas Leitner (gettalong) Assigned to: Nobody (None) Summary: Dictionary#dup does not work correctly Initial Comment: See following irb session: irb(main):001:0> require 'rubygems' => true irb(main):002:0> require 'facets/more/dictionary' => true irb(main):003:0> a = Dictionary.new => {} irb(main):004:0> a.dup => {} irb(main):005:0> a['hallo']=['t',5] => ["t", 5] irb(main):006:0> a.dup ArgumentError: odd number of elements for Hash from /opt/local/lib/ruby/gems/1.8/gems/facets-1.8.54/lib/facets/more/dictionary.rb:86:in `[]' from /opt/local/lib/ruby/gems/1.8/gems/facets-1.8.54/lib/facets/more/dictionary.rb:356:in `dup' from (irb):6 from /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:7 The problems stems from .flatten in dup: 355 def dup 356 self.class[*to_a.flatten] 357 end But I don't have time currently to make a patch. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=12736&group_id=804 From potatosaladx at gmail.com Wed Aug 1 14:51:34 2007 From: potatosaladx at gmail.com (Andrew Bennett) Date: Wed, 1 Aug 2007 14:51:34 -0400 Subject: [Facets] New(?) facets: Array#recursively and Hash#recursively Message-ID: I've been using this for a while now and thought it might be a nice addition to the facets library. I searched around, but couldn't find any implementations for performing recursive operations on a Hash or Array with a block. I actually got the idea from HAML's Hash#rec_merge! which recursively merges two hashes together (http://svn.hamptoncatlin.com/haml/tags/stable/lib/haml/util.rb). Here's my implementation of Array#recursively and Hash#recursively: http://pastie.textmate.org/84094 And here's a few examples of its usage: http://pastie.textmate.org/84101 It's been most useful with Rails when I'm writing helper methods that need to do things like assert_valid_keys on multiple subhashes and I didn't want to have to keep calling options.symbolize_keys! It's very similar to Hash#traverse, but it yields the actual subhash instead of the key-pair. This lets you do nifty stuff like options.recursively!(&:symbolize_keys) From transfire at gmail.com Mon Aug 13 00:58:11 2007 From: transfire at gmail.com (Trans) Date: Mon, 13 Aug 2007 04:58:11 -0000 Subject: [Facets] CLI libs in Facets or not? Message-ID: <1186981091.610504.307180@19g2000hsx.googlegroups.com> I'm still trying to decide if I should keep the CLI libs in Facets or make them a separate project. Actually this is really the last major organizational question I have for Facets 2.0. On one hand, they certainly would make a useful package in their own right. On the other, they fit the modus operandi question of Facets, which is whether one could reasonably see them as part of Ruby's standard library. So I'm torn. Insights welcome. T. From transfire at gmail.com Mon Aug 13 01:17:04 2007 From: transfire at gmail.com (Trans) Date: Mon, 13 Aug 2007 05:17:04 -0000 Subject: [Facets] New(?) facets: Array#recursively and Hash#recursively In-Reply-To: References: Message-ID: <1186982224.399122.18540@19g2000hsx.googlegroups.com> On Aug 1, 11:51 am, "Andrew Bennett" wrote: > I've been using this for a while now and thought it might be a nice > addition to the facets library. I searched around, but couldn't find > any implementations for performing recursive operations on a Hash or > Array with a block. I actually got the idea from HAML's > Hash#rec_merge! which recursively merges two hashes together > (http://svn.hamptoncatlin.com/haml/tags/stable/lib/haml/util.rb). > > Here's my implementation of Array#recursively and Hash#recursively:http://pastie.textmate.org/84094 > > And here's a few examples of its usage:http://pastie.textmate.org/84101 > > It's been most useful with Rails when I'm writing helper methods that > need to do things like assert_valid_keys on multiple subhashes and I > didn't want to have to keep calling options.symbolize_keys! It's very > similar to Hash#traverse, but it yields the actual subhash instead of > the key-pair. This lets you do nifty stuff like > options.recursively!(&:symbolize_keys) The implementations confuse me a bit. For the Hash case it goes through and applies to each element, and at the end it also yeilds the block on the whole new hash. But it doesn't do this last part in the Array case. Why? T. From transfire at gmail.com Mon Aug 13 01:40:51 2007 From: transfire at gmail.com (Trans) Date: Mon, 13 Aug 2007 05:40:51 -0000 Subject: [Facets] New(?) facets: Array#recursively and Hash#recursively In-Reply-To: <1186982224.399122.18540@19g2000hsx.googlegroups.com> References: <1186982224.399122.18540@19g2000hsx.googlegroups.com> Message-ID: <1186983651.692251.13600@g4g2000hsf.googlegroups.com> On Aug 12, 10:17 pm, Trans wrote: > The implementations confuse me a bit. For the Hash case it goes > through and applies to each element, and at the end it also yeilds the > block on the whole new hash. But it doesn't do this last part in the > Array case. Why? Okay, I misread it a tad, but my confusion is still there. > > but it yields the actual subhash instead of > > the key-pair. This lets you do nifty stuff like > > options.recursively!(&:symbolize_keys) That's the part that I don't get. You're yielding on the new hash with every pass of inject, so you are yielding the same pairs over and over. So shouldn't it be: def recursively(&block) yield inject({}) do |hash, (key, value)| if value.is_a?(Hash) hash[key] = value.recursively(&block) end hash[key] = value end hash end end And for the Array case to be equivalent: def recursively(&block) yield map do |item| if item.is_a?(self.class) item.recursively(&block) else item end end end T. From potatosaladx at gmail.com Mon Aug 13 17:11:58 2007 From: potatosaladx at gmail.com (Andrew Bennett) Date: Mon, 13 Aug 2007 17:11:58 -0400 Subject: [Facets] New(?) facets: Array#recursively and Hash#recursively In-Reply-To: <1186983651.692251.13600@g4g2000hsf.googlegroups.com> References: <1186982224.399122.18540@19g2000hsx.googlegroups.com> <1186983651.692251.13600@g4g2000hsf.googlegroups.com> Message-ID: I'll agree with you about my original Hash#recursively, I noticed that it wasn't very efficient when I wrote it, but it worked as intended so I didn't pay much attention to it. The original Array#recursively method may need to be called something else (perhaps Array#traverse since it's similar to Hash#traverse). With the one you supplied, things like array.recursively(&:upcase) no longer work. You have to do: array.recursively do |x| x.map(&:upcase) end To get the same effect. Here's the file I used to get a better grasp about what each method was doing: http://pastie.textmate.org/87340 On 8/13/07, Trans wrote: > > > On Aug 12, 10:17 pm, Trans wrote: > > > The implementations confuse me a bit. For the Hash case it goes > > through and applies to each element, and at the end it also yeilds the > > block on the whole new hash. But it doesn't do this last part in the > > Array case. Why? > > Okay, I misread it a tad, but my confusion is still there. > > > > > but it yields the actual subhash instead of > > > the key-pair. This lets you do nifty stuff like > > > options.recursively!(&:symbolize_keys) > > That's the part that I don't get. You're yielding on the new hash with > every pass of inject, so you are yielding the same pairs over and > over. So shouldn't it be: > > def recursively(&block) > yield inject({}) do |hash, (key, value)| > if value.is_a?(Hash) > hash[key] = value.recursively(&block) > end > hash[key] = value > end > hash > end > end > > And for the Array case to be equivalent: > > def recursively(&block) > yield map do |item| > if item.is_a?(self.class) > item.recursively(&block) > else > item > end > end > end > > T. > > _______________________________________________ > facets-universal mailing list > facets-universal at rubyforge.org > http://rubyforge.org/mailman/listinfo/facets-universal > From noreply at rubyforge.org Wed Aug 15 19:50:16 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 15 Aug 2007 19:50:16 -0400 (EDT) Subject: [Facets] [ facets-Bugs-13114 ] Typo in rdoc documentation for Proc.compose Message-ID: <20070815235016.A4D515240C5B@rubyforge.org> Bugs item #13114, was opened at 2007-08-15 16:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13114&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bill McNeill (billmcn) Assigned to: Nobody (None) Summary: Typo in rdoc documentation for Proc.compose Initial Comment: The rdoc documentation for Proc.compose has a typo in it. The sample code reads in part a.compose(b).call(4) #=> 6 b.compase(a).call(4) #=> 4 The second call is misspelled--should be "compose", not "compase". I noticed this while browsing http://facets.rubyforge.org/rdoc/core/index.html. Presumably it is wrong in the source. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13114&group_id=804 From noreply at rubyforge.org Mon Aug 27 10:50:02 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Aug 2007 10:50:02 -0400 (EDT) Subject: [Facets] [ facets-Bugs-13421 ] range/umberella incorrectly uses .last for ... (3 dots) ranges Message-ID: <20070827145002.8C3705240BA0@rubyforge.org> Bugs item #13421, was opened at 2007-08-27 10:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13421&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: range/umberella incorrectly uses .last for ... (3 dots) ranges Initial Comment: When a user specifies a range as incl_lower...excl_upper, the .last and .max methods of a range are different. Umberella always uses .last, when .max would be more accurate. 33 e = r.last <=> self.last ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13421&group_id=804 From noreply at rubyforge.org Mon Aug 27 11:31:34 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Aug 2007 11:31:34 -0400 (EDT) Subject: [Facets] [ facets-Bugs-13421 ] range/umberella incorrectly uses .last for ... (3 dots) ranges Message-ID: <20070827153134.2946A5240C0C@rubyforge.org> Bugs item #13421, was opened at 2007-08-27 10:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13421&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: range/umberella incorrectly uses .last for ... (3 dots) ranges Initial Comment: When a user specifies a range as incl_lower...excl_upper, the .last and .max methods of a range are different. Umberella always uses .last, when .max would be more accurate. 33 e = r.last <=> self.last ---------------------------------------------------------------------- Comment By: Chris Kappler (chrisk2) Date: 2007-08-27 11:31 Message: Actually, the range.max method is expensive for large ranges. The code below gives a more reliable perforrmance. 31 def umbrella(r) 32 s = self.first <=> r.first 33 r_last = r.last - ((r.exclude_end?) ? 1 : 0) 34 s_last = self.last - ((self.exclude_end?) ? 1 : 0) 35 e = r_last <=> s_last 36 return s,e 37 end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13421&group_id=804 From noreply at rubyforge.org Mon Aug 27 13:37:53 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Aug 2007 13:37:53 -0400 (EDT) Subject: [Facets] [ facets-Bugs-13114 ] Typo in rdoc documentation for Proc.compose Message-ID: <20070827173753.B8DDB5240C45@rubyforge.org> Bugs item #13114, was opened at 2007-08-15 18:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13114&group_id=804 Category: None Group: None >Status: Closed >Resolution: Accepted >Priority: 1 Submitted By: Bill McNeill (billmcn) Assigned to: Nobody (None) Summary: Typo in rdoc documentation for Proc.compose Initial Comment: The rdoc documentation for Proc.compose has a typo in it. The sample code reads in part a.compose(b).call(4) #=> 6 b.compase(a).call(4) #=> 4 The second call is misspelled--should be "compose", not "compase". I noticed this while browsing http://facets.rubyforge.org/rdoc/core/index.html. Presumably it is wrong in the source. ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2007-08-27 12:37 Message: Fixed. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13114&group_id=804 From noreply at rubyforge.org Mon Aug 27 13:52:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Aug 2007 13:52:48 -0400 (EDT) Subject: [Facets] [ facets-Bugs-9424 ] Testing Tracker Message-ID: <20070827175248.5083BA970003@rubyforge.org> Bugs item #9424, was opened at 2007-03-21 07:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=9424&group_id=804 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: 7rans (transami) Assigned to: Nobody (None) Summary: Testing Tracker Initial Comment: This is a test of trackers email system. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-03-22 12:29 Message: Still trying to get tracker to list working properly... ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-03-22 11:53 Message: This is a further test of the bug tracker to mailing list forwarding. Something still not right... ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-03-21 08:44 Message: Dear readers, I've just tied Rubyforge's ticket tracker into the facets-universal mailing list. Up until November of last year this system was hardly ever used. So I rarely checked it. The pace has picked up since then, so I want to make sure all tickets come to my/our attention. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-03-21 08:12 Message: Dear readers, I've just tied Rubyforge's ticket tracker into the facets-universal mailing list. Up until November of last year this system was hardly ever used. So I rarely checked it. The pace has picked up since then, so I want to make sure all tickets come to my/our attention. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-03-21 07:57 Message: Dear readers, I've just tied Rubyforge's ticket tracker into the facets-universal mailing list. Up until November of last year this system was hardly ever used. So I rarely checked it. The pace has picked up since then, so I want to make sure all tickets come to my/our attention. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=9424&group_id=804 From noreply at rubyforge.org Mon Aug 27 14:15:05 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Aug 2007 14:15:05 -0400 (EDT) Subject: [Facets] [ facets-Bugs-4048 ] Issue with RDOC install Message-ID: <20070827181505.EBA3F5240C45@rubyforge.org> Bugs item #4048, was opened at 2006-04-07 17:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=4048&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Issue with RDOC install Initial Comment: When I install facets with the following gem config: [devplp1] ~ $ cat ~/gemrc rdoc: --ri-site It appears that facets screws up the ri/1.8/site RDOC directory, wiping out the other local content, and making the directory unusable for further rdoc installs. Could be related to [3967]. ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2007-08-27 13:15 Message: Going to assume this is closed, since I haven't heard anyone else mention it, plus the new release should make it moot anyway. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-03-21 06:53 Message: Facets is laid out in standard fashion --nothing special is going on. So I don't know why this would happen. This will require further investigation. With any luck it's an issue with rdoc that has since been resolved. I'll investigate further. If anyone has anymore information they can provide about this, please let me know. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=4048&group_id=804 From noreply at rubyforge.org Mon Aug 27 14:15:31 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 27 Aug 2007 14:15:31 -0400 (EDT) Subject: [Facets] [ facets-Bugs-4048 ] Issue with RDOC install Message-ID: <20070827181531.74ADD5240DAB@rubyforge.org> Bugs item #4048, was opened at 2006-04-07 17:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=4048&group_id=804 >Category: Documentation Group: None >Status: Closed >Resolution: Out of Date >Priority: 2 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Issue with RDOC install Initial Comment: When I install facets with the following gem config: [devplp1] ~ $ cat ~/gemrc rdoc: --ri-site It appears that facets screws up the ri/1.8/site RDOC directory, wiping out the other local content, and making the directory unusable for further rdoc installs. Could be related to [3967]. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-08-27 13:15 Message: Going to assume this is closed, since I haven't heard anyone else mention it, plus the new release should make it moot anyway. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-03-21 06:53 Message: Facets is laid out in standard fashion --nothing special is going on. So I don't know why this would happen. This will require further investigation. With any luck it's an issue with rdoc that has since been resolved. I'll investigate further. If anyone has anymore information they can provide about this, please let me know. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=4048&group_id=804 From noreply at rubyforge.org Tue Aug 28 10:50:48 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 28 Aug 2007 10:50:48 -0400 (EDT) Subject: [Facets] [ facets-Bugs-13421 ] range/umberella incorrectly uses .last for ... (3 dots) ranges Message-ID: <20070828145048.2BB835240B0B@rubyforge.org> Bugs item #13421, was opened at 2007-08-27 09:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13421&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: range/umberella incorrectly uses .last for ... (3 dots) ranges Initial Comment: When a user specifies a range as incl_lower...excl_upper, the .last and .max methods of a range are different. Umberella always uses .last, when .max would be more accurate. 33 e = r.last <=> self.last ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2007-08-28 09:50 Message: Good catch. I'm looking at fixing it with something like: def umbrella(r) s = first <=> r.first e = r.last <=> last if exclude_end? unless r.exclude_end? e = 1 if e == 0 end elsif r.exclude_end? e = -1 if e == 0 end return s,e end However, in looking over this code, I'm wondering if I've defined it inverse of what would be best. Eg. (1..4).umbrella(2..3) #=> [1,1] rather than [-1,-1] Any thoughts on the on the utility of this function and the best definition to serve it's intended purpose? T. ---------------------------------------------------------------------- Comment By: Chris Kappler (chrisk2) Date: 2007-08-27 10:31 Message: Actually, the range.max method is expensive for large ranges. The code below gives a more reliable perforrmance. 31 def umbrella(r) 32 s = self.first <=> r.first 33 r_last = r.last - ((r.exclude_end?) ? 1 : 0) 34 s_last = self.last - ((self.exclude_end?) ? 1 : 0) 35 e = r_last <=> s_last 36 return s,e 37 end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13421&group_id=804 From noreply at rubyforge.org Tue Aug 28 11:23:59 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 28 Aug 2007 11:23:59 -0400 (EDT) Subject: [Facets] [ facets-Bugs-13421 ] range/umberella incorrectly uses .last for ... (3 dots) ranges Message-ID: <20070828152359.8E4595240B6C@rubyforge.org> Bugs item #13421, was opened at 2007-08-27 10:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13421&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: range/umberella incorrectly uses .last for ... (3 dots) ranges Initial Comment: When a user specifies a range as incl_lower...excl_upper, the .last and .max methods of a range are different. Umberella always uses .last, when .max would be more accurate. 33 e = r.last <=> self.last ---------------------------------------------------------------------- Comment By: Chris Kappler (chrisk2) Date: 2007-08-28 11:23 Message: The utility of the function is great. I ended up using it as part of Range.within? ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-08-28 10:50 Message: Good catch. I'm looking at fixing it with something like: def umbrella(r) s = first <=> r.first e = r.last <=> last if exclude_end? unless r.exclude_end? e = 1 if e == 0 end elsif r.exclude_end? e = -1 if e == 0 end return s,e end However, in looking over this code, I'm wondering if I've defined it inverse of what would be best. Eg. (1..4).umbrella(2..3) #=> [1,1] rather than [-1,-1] Any thoughts on the on the utility of this function and the best definition to serve it's intended purpose? T. ---------------------------------------------------------------------- Comment By: Chris Kappler (chrisk2) Date: 2007-08-27 11:31 Message: Actually, the range.max method is expensive for large ranges. The code below gives a more reliable perforrmance. 31 def umbrella(r) 32 s = self.first <=> r.first 33 r_last = r.last - ((r.exclude_end?) ? 1 : 0) 34 s_last = self.last - ((self.exclude_end?) ? 1 : 0) 35 e = r_last <=> s_last 36 return s,e 37 end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=13421&group_id=804 From transfire at gmail.com Tue Aug 28 14:48:05 2007 From: transfire at gmail.com (Trans) Date: Tue, 28 Aug 2007 18:48:05 -0000 Subject: [Facets] CLI libs in Facets or not? In-Reply-To: <1186981091.610504.307180@19g2000hsx.googlegroups.com> References: <1186981091.610504.307180@19g2000hsx.googlegroups.com> Message-ID: <1188326885.742241.293280@57g2000hsv.googlegroups.com> On Aug 12, 9:58 pm, Trans wrote: > I'm still trying to decide if I should keep the CLI libs in Facets or > make them a separate project. Actually this is really the last major > organizational question I have for Facets 2.0. > > On one hand, they certainly would make a useful package in their own > right. On the other, they fit the modus operandi question of Facets, > which is whether one could reasonably see them as part of Ruby's > standard library. So I'm torn. > > Insights welcome. BTW, I'm leaving the CLI libs in Facets. Perhaps in the future they'll be spun-off, but for the foreseeable future they'll stay. T. From transfire at gmail.com Tue Aug 28 19:24:46 2007 From: transfire at gmail.com (Trans) Date: Tue, 28 Aug 2007 23:24:46 -0000 Subject: [Facets] [ facets-Bugs-13421 ] range/umberella incorrectly uses .last for ... (3 dots) ranges In-Reply-To: <20070828152359.8E4595240B6C@rubyforge.org> References: <20070828152359.8E4595240B6C@rubyforge.org> Message-ID: <1188343486.190407.19950@w3g2000hsg.googlegroups.com> On Aug 28, 8:23 am, wrote: > When a user specifies a range as incl_lower...excl_upper, the .last and .max > methods of a range are different. Umberella always uses .last, when .max would be more accurate. Looks like the proper definition is: def umbrella(r) s = first <=> r.first e = r.last <=> last if e == 0 if r.exclude_end? and exclude_end? e = r.max <=> max else e = (r.exclude_end? ? 0 : 1) <=> (exclude_end? ? 0 : 1) end end return s,e end Though it's tempting to forgo the max clause for speed. T.