From noreply at rubyforge.org Fri Jul 3 22:39:47 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 3 Jul 2009 22:39:47 -0400 (EDT) Subject: [Facets] [ facets-Bugs-26446 ] __HERE__ can not work. Message-ID: <20090704023947.3C6C21779935@rubyforge.org> Bugs item #26446, was opened at 2009-06-28 02:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26446&group_id=804 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: William Mason (william) Assigned to: Nobody (None) Summary: __HERE__ can not work. Initial Comment: The facets kernel extension __HERE__ is based on a false premise that it would show you the line of code that it is called from. At least that is how it "appears". Of course when I thought about it, all it can ever do is report its OWN file name and line number. So a line like ... puts " * Exception in #{self.name.to_s}, (#{__HERE__})." Can only ever, always emit: * Exception in someclass, (... lib/ruby/gems/1.8/gems/facets-2.5.2/lib/core/facets/kernel/__here__.rb: 4). The __HERE__ idea is a really good one, this isn't a way to implement it. At the very least the existing implementation should use the Caller method and report the caller for the function. That at least would give a good shot at a more effective answer. Otherwise remove it from Facets and document that it is not workable. w. ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2009-07-03 21:39 Message: Indeed. You are correct. Thankfully it doesn't so much matter though. Ruby 1.9.x will be gaining #source_location, which will cover this idea. So I have removed this method. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26446&group_id=804 From transfire at gmail.com Fri Jul 3 22:37:02 2009 From: transfire at gmail.com (Trans) Date: Fri, 3 Jul 2009 19:37:02 -0700 (PDT) Subject: [Facets] Facets 2.6 Released Message-ID: Facets 2.6.0 removes htmlfilter.rb and cssfilter.rb due to licensing incompatability. These scripts are now available as a separate package called 'htmlfilter'. Also removed are a few MORE libs that were too experimental and/or not robust enough. Effectively this finishes up the "spring cleaning" of the MORE lib mentioned a few releases back. Yet it also marks a new start in trimming MORE down further. This is being done for three reasons 1) Some of the MORE libs would be better served as separate projects. 2) Facets will become a tighter library, primarily focused on extensions. And 3) all libraries involved will become easier to maintain and thus more robust in the long run. This trimming will occur slowly and incrementally based on perceived "core-ish-ness". This release also fixes an important arity bug with the recently added Module#extend method --one of the very few actual core overrides in Facets. ### 2.6.0 / 2009-07-03 * 7 Major Enhancements * Removed htmlfilter.rb due to licensing issues. * Also removed cssfilter.rb ('gem install htmlfilter' now) * Removed rwdelegator.rb, simply not a robust solution. * Removed buildable.rb, api is too confusing. * Removed meta.rb which was not very useful and too experimental anyway. * Removed prototype.rb, which needs it's own project. * 3 Minor Enhancements * Removed Kernel#__HERE__ as it simply cannot work. (Ruby 1.9.2 will offer #source_location for the same, btw) * Returned binding/opvars to core. * Added Integer#length as suggested by Victor H. Goff III. * 1 Bug Fix * Fixed arity issue with Module#extend. From noreply at rubyforge.org Sun Jul 5 08:08:02 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 5 Jul 2009 08:08:02 -0400 (EDT) Subject: [Facets] [ facets-Bugs-26446 ] __HERE__ can not work. Message-ID: <20090705120802.A8E3B1678217@rubyforge.org> Bugs item #26446, was opened at 2009-06-28 17:30 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26446&group_id=804 Category: None Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: William Mason (william) Assigned to: Nobody (None) Summary: __HERE__ can not work. Initial Comment: The facets kernel extension __HERE__ is based on a false premise that it would show you the line of code that it is called from. At least that is how it "appears". Of course when I thought about it, all it can ever do is report its OWN file name and line number. So a line like ... puts " * Exception in #{self.name.to_s}, (#{__HERE__})." Can only ever, always emit: * Exception in someclass, (... lib/ruby/gems/1.8/gems/facets-2.5.2/lib/core/facets/kernel/__here__.rb: 4). The __HERE__ idea is a really good one, this isn't a way to implement it. At the very least the existing implementation should use the Caller method and report the caller for the function. That at least would give a good shot at a more effective answer. Otherwise remove it from Facets and document that it is not workable. w. ---------------------------------------------------------------------- >Comment By: William Mason (william) Date: 2009-07-05 22:08 Message: One follow-up, for anyone wanting the __HERE__ functionality; I made-up a simple quick answer. # Replaces the facets/kernel/__HERE__ method module Kernel def __HERE__ caller(1).first end #__HERE_ method end #Kernel module It isn't the same format -- reformatting the output string would be simple for anyone to fit-out. w. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2009-07-04 12:39 Message: Indeed. You are correct. Thankfully it doesn't so much matter though. Ruby 1.9.x will be gaining #source_location, which will cover this idea. So I have removed this method. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26446&group_id=804 From noreply at rubyforge.org Thu Jul 16 12:20:27 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 16 Jul 2009 12:20:27 -0400 (EDT) Subject: [Facets] [ facets-Bugs-26635 ] String::each_char always being defined Message-ID: <20090716162027.6E9AB1D787EB@rubyforge.org> Bugs item #26635, was opened at 2009-07-16 09:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26635&group_id=804 Category: Code Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rick Ohnemus (joast) Assigned to: Nobody (None) Summary: String::each_char always being defined Initial Comment: lib/core/facets/string/each_char.rb uses "unless defined? each_char" to see if each_char needs to be included in the String class. Using both ruby 1.8.7 and 1.9.1, both already have String::each_char defined, results in each_char being defined by this code. Shouldn't the code be using method_defined?('each_char') instead? At least 3 others files use similar code: lib/core/facets/enumerable/group_by.rb; lib/core/facets/string/chars.rb; lib/core/facets/time/to_time.rb. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26635&group_id=804 From transfire at gmail.com Sat Jul 18 12:52:36 2009 From: transfire at gmail.com (Intransition) Date: Sat, 18 Jul 2009 09:52:36 -0700 (PDT) Subject: [Facets] [ facets-Bugs-26635 ] String::each_char always being defined In-Reply-To: <20090716162027.6E9AB1D787EB@rubyforge.org> References: <20090716162027.6E9AB1D787EB@rubyforge.org> Message-ID: On Jul 16, 12:20?pm, wrote: > Bugs item #26635, was opened at 2009-07-16 09:20 > You can respond by visiting:http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26635&group_i... > > Category: Code > Group: None > Status: Open > Resolution: None > Priority: 3 > Submitted By: Rick Ohnemus (joast) > Assigned to: Nobody (None) > Summary: String::each_char always being defined > > Initial Comment: > lib/core/facets/string/each_char.rb uses "unless defined? each_char" to see if each_char needs to be included in the String class. Using both ruby 1.8.7 and 1.9.1, both already have String::each_char defined, results in each_char being defined by this code. Shouldn't the code be using method_defined?('each_char') instead? > > At least 3 others files use similar code: lib/core/facets/enumerable/group_by.rb; lib/core/facets/string/chars.rb; lib/core/facets/time/to_time.rb. Thanks. I'll look at this and get it fixed. T.