From rogerdpack at gmail.com Sat Aug 1 09:33:16 2009 From: rogerdpack at gmail.com (rogerdpack) Date: Sat, 1 Aug 2009 06:33:16 -0700 (PDT) Subject: [Facets] better __DIR__ Message-ID: I noticed that http://oldrcrs.rubypal.com/rcr/show/309 lists a slightly different __DIR__ would that one be more helpful? Also, maybe we could/should add a / to the end of it? Thanks! =r From noreply at rubyforge.org Tue Aug 11 11:26:03 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Aug 2009 11:26:03 -0400 (EDT) Subject: [Facets] [ facets-Bugs-26635 ] String::each_char always being defined Message-ID: <20090811152603.8A84416782A8@rubyforge.org> Bugs item #26635, was opened at 2009-07-16 11:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26635&group_id=804 Category: Code Group: None >Status: Closed >Resolution: Accepted 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. ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2009-08-11 10:26 Message: Okay. Will be fixed in next release (v2.7). Thanks again for reporting it. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26635&group_id=804 From noreply at rubyforge.org Tue Aug 11 11:34:58 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Aug 2009 11:34:58 -0400 (EDT) Subject: [Facets] [ facets-Bugs-26446 ] __HERE__ can not work. Message-ID: <20090811153458.800B816782A7@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-08-11 10:34 Message: That's a good redefinition. Thanks. ---------------------------------------------------------------------- Comment By: William Mason (william) Date: 2009-07-05 07: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-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 noreply at rubyforge.org Tue Aug 11 11:42:17 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Aug 2009 11:42:17 -0400 (EDT) Subject: [Facets] [ facets-Bugs-18530 ] overload bug Message-ID: <20090811154217.8B0BE16782A8@rubyforge.org> Bugs item #18530, was opened at 2008-03-02 02:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18530&group_id=804 Category: None Group: None Status: Open Resolution: Postponed Priority: 3 Submitted By: ?? ?? (fhopecc) Assigned to: Nobody (None) Summary: overload bug Initial Comment: next unless cmp.size == sig.size cmp.size.times { |i| next unless cmp[i] < sig[i] } hit = cmp this will be failed in the following codition. overload :x, Array do |a| a end overload :x, Symbol do |a| a end i think code should be change in the following sig_matched = true cmp.size.times { |i| next unless sig_matched = cmp[i] < sig[i] } hit = cmp if sig_matched sig_matched indicate that every elements in cmp will be subclass in sig. ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2009-08-11 10:42 Message: Follow-up. This library has been spun-off to it's own package. sudo gem install overload It should have more "breathing room" to improve now that it is is on it's own. See "Death of a Programmer" project. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2008-08-10 09:04 Message: It appears this has already been change to: next unless cmp.size == sig.size if (0...cmp.size).all?{ |i| cmp[i] >= sig[i] } break hit = cmp end It passes all the tests I have. In general this library needs some work however, the current design, while workable, is not very clean or robust. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18530&group_id=804 From noreply at rubyforge.org Tue Aug 11 11:42:29 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Aug 2009 11:42:29 -0400 (EDT) Subject: [Facets] [ facets-Bugs-18530 ] overload bug Message-ID: <20090811154229.6954416782A7@rubyforge.org> Bugs item #18530, was opened at 2008-03-02 02:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18530&group_id=804 Category: None Group: None >Status: Closed Resolution: Postponed Priority: 3 Submitted By: ?? ?? (fhopecc) Assigned to: Nobody (None) Summary: overload bug Initial Comment: next unless cmp.size == sig.size cmp.size.times { |i| next unless cmp[i] < sig[i] } hit = cmp this will be failed in the following codition. overload :x, Array do |a| a end overload :x, Symbol do |a| a end i think code should be change in the following sig_matched = true cmp.size.times { |i| next unless sig_matched = cmp[i] < sig[i] } hit = cmp if sig_matched sig_matched indicate that every elements in cmp will be subclass in sig. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2009-08-11 10:42 Message: Follow-up. This library has been spun-off to it's own package. sudo gem install overload It should have more "breathing room" to improve now that it is is on it's own. See "Death of a Programmer" project. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2008-08-10 09:04 Message: It appears this has already been change to: next unless cmp.size == sig.size if (0...cmp.size).all?{ |i| cmp[i] >= sig[i] } break hit = cmp end It passes all the tests I have. In general this library needs some work however, the current design, while workable, is not very clean or robust. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18530&group_id=804 From transfire at gmail.com Tue Aug 11 12:55:11 2009 From: transfire at gmail.com (Trans) Date: Tue, 11 Aug 2009 12:55:11 -0400 Subject: [Facets] better __DIR__ In-Reply-To: References: Message-ID: <4b6f054f0908110955l2d7bc207j7243c8bd249f5b19@mail.gmail.com> On Sat, Aug 1, 2009 at 9:33 AM, rogerdpack wrote: > I noticed that > http://oldrcrs.rubypal.com/rcr/show/309 > lists a slightly different __DIR__ > would that one be more helpful? Thanks Roger. Unfortunately that doesn't work either. The current version works fairly well, and with 1.9 it should improve more (using #source_location). But Paul is right, implementation i C is doing to be best. I don't know why matz rejected it way back when, but perhaps if others bring it up on ruby-core mailing list... > Also, maybe we could/should add a / to the end of it? Simple because that's not the common practice. Otherwise I would. Actually I wish Ruby had a true object oriented file system library (something like Folio). Ie. it should return a Directory object. T. From transfire at gmail.com Tue Aug 11 18:29:30 2009 From: transfire at gmail.com (Trans) Date: Tue, 11 Aug 2009 15:29:30 -0700 (PDT) Subject: [Facets] Heads-up on upcoming 2.7 release Message-ID: I wanted to give people heads-up about the next release. It will be a significant release --the biggest since 2.4 and quite likely the biggest Facets will ever see again. The reason is b/c rather then trickle-release the changes I had planned over the course of the 2.6.x series I decided to let 2.7 handle them all at once. In so doing this release nearly completes the process of trimming down the MORE library to its essentials. Over 60 high-level libraries have been spun-off and/ or deprecated for varying reasons. To prepare people for the release I thought it would be wise to provide a pre-release list of the libraries effected and how to compensate for them. Here is a excerpt from the ChangeLog I am preparing. Note that a few of the gems mentioned have not yet been released but will be soon. * Spun-Off Projects These libraries have been deprecated from Facets entirely, but are [or will be] available as separate gems. LIBRARY GEM -------------------- ------------------------------ overload.rb overload binreadable.rb binaryio downloader.rb downloader xoxo.rb xoxo bicrypt.rb bicrypt typecast.rb typecast association.rb association syncarray.rb sync synchash.rb sync paramix.rb paramix crypt.rb crypt3 lrucache.rb lrucache net/smtp_tls.rb smtp_tls advisable.rb advisable buildable.rb buildable memoizer.rb memoizer harray.rb sparray sparse_array.rb sparray iteration.rb iteration interval.rb stick infinity.rb stick pool.rb pool linkedlist.rb linkedlist semaphore.rb semaphore pqueue.rb pqueue censor.rb language macther.rb language basex.rb base_n minitar.rb archive-tar-minitar -or- folio * Spun-Off But Still Available These libraries have been spun-off into stand-alone gems, but remain available via Facets too. Ultimately *some* of these will be removed from Facets as well (ie. 2.8). LIBRARY GEM -------------------- -------------------------------- ansicode.rb ansi -or- ansicode progressbar.rb ansi logger.rb ansi (partially) tracepoint.rb tracepoint dictionary.rb dictionary recorder.rb recorder ostructable.rb ostructable -or- openhash openobject.rb openhash opencollection.rb openhash opencascade.rb openhash openhash.rb openhash openmodule.rb openmodule fileable.rb fileable expirable.rb expirable enumerablepass.rb enumargs * Deprecations Without Current Replacement The libraries have been deprecated but do not yet have replacements. Separate gems for these are planned though. * bbcode.rb * ini.rb * settings.rb * xmlhash.rb * Deprecations Merged Into CORE These libraries have been deprecated because their functionality was merged into the CORE library and/or made available in some another way. * 1stclassmethod.rb #method! and #instance_method! are now part of CORE. * elementor.rb #per has been added to CORE. * elementwise.rb #ewise has been added to CORE. * consoleutils.rb #ask is in CORE, for the rest see Ansi or Clio project. * attr.rb Added Module#attr_setter to CORE, and separated the rest in MORE. * General Deprecations These libraries have simply been deprecated because they were found lacking in some significant fashion. * coroutine.rb Depended on continuations, which are not supported in 1.9+. * nilstatus.rb Proved rather useless, not to mention trivial. * heap.rb Heap was just an alias for PQueue anyway. Use 'pqueue' instead. * dependency.rb Other solutions exist that are much better (like Advisable). * classmethods.rb #class_extend solution is more robust. * ziputils.rb Have a look at Folio (gem install folio) for possible replacement. * unheritable.rb Implementation is trivial and usefulness questionable. * instantise.rb Replaced by instance_function.rb. * Other Enhancements * Fixed Proc#curry to work with #define_method (Thanks to R.Potter) * Module#class_extension has been renamed to #class_extend (require 'facets/class_extend'). * kernel#instance is no longer in core; now it is an extra monkey patch for #instance_eval. * Kernel#this has been removed. It is equivalent to 'method (__method__)'. * BlankSlate is now an alias for BasicObject, and will be deprecated in the future. * Kernel#method! and Module#instance_method! now use a global variable for their cache. * #object_state (old name was #state) has been added to core. While 2.7 nearly completes the refinement of Facets, ultimately it will be 2.8 that finishes it, but that will look tiny by comparison to this extensive release. I know this a lot to handle for one release, but I also know that Facets is known more for the CORE lib than it is the MORE lib, which is part of the reason I have taken this course. I believe in the end all the libraries involved will be better served but the spin-offs as will their users. Thanks, T. (Austin, I stand corrected.) From rogerdpack at gmail.com Wed Aug 12 08:19:44 2009 From: rogerdpack at gmail.com (Roger Pack) Date: Wed, 12 Aug 2009 06:19:44 -0600 Subject: [Facets] Heads-up on upcoming 2.7 release In-Reply-To: References: Message-ID: My suggestion for addition to facets would be "attempted backward compatibility" methods [if they're not already in facets] File.binread From transfire at gmail.com Wed Aug 12 10:39:29 2009 From: transfire at gmail.com (Trans) Date: Wed, 12 Aug 2009 07:39:29 -0700 (PDT) Subject: [Facets] Documentation Back Up Message-ID: <9f246540-25e6-4577-9a89-de2f8c4a5882@b15g2000yqd.googlegroups.com> Ruby Facets Documentation is back up, though it is for version 2.7 and still could use a little TLC. I had to use Yard instead of RDoc because the Hanna template does not yet work with the latest version of RDoc, and I need framed docs for Facets b/c it is so extensive (and I'd rather wait for Hanna to upgrade then downgrade my RDoc install). T. From transfire at gmail.com Wed Aug 12 10:50:25 2009 From: transfire at gmail.com (Intransition) Date: Wed, 12 Aug 2009 07:50:25 -0700 (PDT) Subject: [Facets] Heads-up on upcoming 2.7 release In-Reply-To: References: Message-ID: On Aug 12, 8:19?am, Roger Pack wrote: > My suggestion for addition to facets would be "attempted backward > compatibility" methods [if they're not already in facets] > > File.binread Hi Roger, Could you elaborate? T. From transfire at gmail.com Wed Aug 12 11:10:14 2009 From: transfire at gmail.com (Trans) Date: Wed, 12 Aug 2009 08:10:14 -0700 (PDT) Subject: [Facets] Why 2.7? Message-ID: This morning it occurred to me that it might be a good idea to explain why the next version of Facets will have such a huge trimming down of the MORE library. Really it is quite simple. Facets is known primarily for it's CORE library. Much of the MORE library is going unnoticed, unused or underused, and lacking the attention needed for necessary improvements. By spinning-off these libraries as separate projects I believe these libs have a much better chance of flourishing, and in turn Facets will be more stable and easier to maintain. The MORE lib will remain, but it's focus from now on will be "core oriented", i.e. very basic, highly reusable libs. Also, "LORE" has been rolled back into MORE, so there is no longer that (silly named) distinction between extended standard libs and outright additions (Really this only ever effected documentation, and now that there are fewer MORE libs it's easy enough to navigate.) T. From rogerdpack at gmail.com Wed Aug 12 12:40:31 2009 From: rogerdpack at gmail.com (Roger Pack) Date: Wed, 12 Aug 2009 10:40:31 -0600 Subject: [Facets] Heads-up on upcoming 2.7 release In-Reply-To: References: Message-ID: >> File.binread > > Hi Roger, > > Could you elaborate? Sometimes when I'm coding I wonder "is this method available in 1.8?" like File.binread, require_relative, instance_eval, etc. Some type of backwards compatibility helper would be nice, like require 'facets/make_this_ruby_somewhat_1.9_equal' or what not would be nice. -r From rogerdpack at gmail.com Wed Aug 12 12:42:12 2009 From: rogerdpack at gmail.com (Roger Pack) Date: Wed, 12 Aug 2009 10:42:12 -0600 Subject: [Facets] Why 2.7? In-Reply-To: References: Message-ID: > The MORE lib will remain, but it's focus from now on will be "core > oriented", i.e. very basic, highly reusable libs. Also, "LORE" has > been rolled back into MORE, so there is no longer that (silly named) > distinction between extended standard libs and outright additions > (Really this only ever effected documentation, and now that there are > fewer MORE libs it's easy enough to navigate.) Glad to hear it--I never could figure out what lore was referring to--Norse mythology was my only guess. Too bad on the YARD over Hanna. for me YARD has some contrast problems and the downgrade to 2.3 is well worth it :) -r From rogerdpack at gmail.com Wed Aug 12 12:45:31 2009 From: rogerdpack at gmail.com (Roger Pack) Date: Wed, 12 Aug 2009 10:45:31 -0600 Subject: [Facets] 'essentials' Message-ID: Another interesting idea would be to mark a very very few libs as "essential" like "you use these every day" File.write would be one for me. i.e. something like a require 'facets/essentials' Thoughts? -r From transfire at gmail.com Wed Aug 12 17:32:17 2009 From: transfire at gmail.com (Trans) Date: Wed, 12 Aug 2009 14:32:17 -0700 (PDT) Subject: [Facets] Why 2.7? In-Reply-To: References: Message-ID: <038ff2a2-78b0-489e-a11b-b26edd411303@26g2000yqk.googlegroups.com> On Aug 12, 12:42?pm, Roger Pack wrote: > > The MORE lib will remain, but it's focus from now on will be "core > > oriented", i.e. very basic, highly reusable libs. Also, "LORE" has > > been rolled back into MORE, so there is no longer that (silly named) > > distinction between extended standard libs and outright additions > > (Really this only ever effected documentation, and now that there are > > fewer MORE libs it's easy enough to navigate.) > > Glad to hear it--I never could figure out what lore was referring > to--Norse mythology was my only guess. lol. :-) > Too bad on the YARD over Hanna. ?for me YARD has some contrast > problems and the downgrade to 2.3 is well worth it :) I jut talked to mislav about it and he instructed me on how to make it work so I will give it a go here in a bit. T. From rogerdpack at gmail.com Thu Aug 13 07:40:01 2009 From: rogerdpack at gmail.com (Roger Pack) Date: Thu, 13 Aug 2009 05:40:01 -0600 Subject: [Facets] Why 2.7? In-Reply-To: <038ff2a2-78b0-489e-a11b-b26edd411303@26g2000yqk.googlegroups.com> References: <038ff2a2-78b0-489e-a11b-b26edd411303@26g2000yqk.googlegroups.com> Message-ID: >> Too bad on the YARD over Hanna. ?for me YARD has some contrast >> problems and the downgrade to 2.3 is well worth it :) > > I jut talked to mislav about it and he instructed me on how to make it > work so I will give it a go here in a bit. Cool. If you have success would you mind sharing with the rest of us? I could definitely use some updated Hanna info. -r From rogerdpack at gmail.com Thu Aug 13 07:45:02 2009 From: rogerdpack at gmail.com (Roger Pack) Date: Thu, 13 Aug 2009 05:45:02 -0600 Subject: [Facets] =?iso-8859-1?q?10_Oct_2008_=BB_I_Spy_String=23margin?= Message-ID: Hmm. String#margin suggest rename to String#strip_margin or remove_margin that's what it does, isn't it? -r From transfire at gmail.com Thu Aug 13 18:39:39 2009 From: transfire at gmail.com (Trans) Date: Thu, 13 Aug 2009 15:39:39 -0700 (PDT) Subject: [Facets] Why 2.7? In-Reply-To: References: <038ff2a2-78b0-489e-a11b-b26edd411303@26g2000yqk.googlegroups.com> Message-ID: <07750cae-d6d3-44a3-bc7b-42f9788d1202@o15g2000yqm.googlegroups.com> On Aug 13, 7:40?am, Roger Pack wrote: > >> Too bad on the YARD over Hanna. ?for me YARD has some contrast > >> problems and the downgrade to 2.3 is well worth it :) > > > I jut talked to mislav about it and he instructed me on how to make it > > work so I will give it a go here in a bit. > > Cool. ?If you have success would you mind sharing with the rest of us? > ?I could definitely use some updated Hanna info. The trick was to use the 'hanna' commandline tool. It works just like 'rdoc' as far as the options go. T. From transfire at gmail.com Thu Aug 13 18:41:21 2009 From: transfire at gmail.com (Trans) Date: Thu, 13 Aug 2009 15:41:21 -0700 (PDT) Subject: [Facets] =?iso-8859-1?q?10_Oct_2008_=BB_I_Spy_String=23margin?= In-Reply-To: References: Message-ID: On Aug 13, 7:45?am, Roger Pack wrote: > Hmm. ?String#margin suggest rename to String#strip_margin or remove_margin > that's what it does, isn't it? In a sense that's true. But the #margin method has been around a long time. There really is no need to change the name. T. From noreply at rubyforge.org Wed Aug 26 12:55:57 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 12:55:57 -0400 (EDT) Subject: [Facets] [ facets-Bugs-26999 ] String#titlecase doesn't work well with apostrophes Message-ID: <20090826165557.A55EA18581F7@rubyforge.org> Bugs item #26999, was opened at 2009-08-26 10:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26999&group_id=804 Category: Code Group: 2.0 + Status: Open Resolution: None Priority: 3 Submitted By: Angelo Lakra (alakra) Assigned to: Nobody (None) Summary: String#titlecase doesn't work well with apostrophes Initial Comment: Using a string with an apostrophe causes the following letter after the apostrophe to be capitalized. The example in the documentation suggests that the method works on spaces instead of any non-word character. e.g. "can't".titlecase => "Can'T" My solution was to implement the code as follows: class String # Title case. # # "this is a string".titlecase # => "This Is A String" # # CREDIT: Eliazar Parra and Angelo Lakra def titlecase split.map {|w| w.capitalize }.join(" ") end end It's not as elegant as the regex, but it behaves as expected. Please let me know if the intention of the function should work on non-word characters or something similar to the ucwords() function in PHP. Thanks, Angelo Lakra (fozze) angelo.lakra at gmail.com ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26999&group_id=804 From noreply at rubyforge.org Wed Aug 26 13:17:22 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 13:17:22 -0400 (EDT) Subject: [Facets] [ facets-Bugs-26999 ] String#titlecase doesn't work well with apostrophes Message-ID: <20090826171723.08A9218581F5@rubyforge.org> Bugs item #26999, was opened at 2009-08-26 10:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26999&group_id=804 Category: Code Group: 2.0 + Status: Open Resolution: None Priority: 3 Submitted By: Angelo Lakra (alakra) Assigned to: Nobody (None) Summary: String#titlecase doesn't work well with apostrophes Initial Comment: Using a string with an apostrophe causes the following letter after the apostrophe to be capitalized. The example in the documentation suggests that the method works on spaces instead of any non-word character. e.g. "can't".titlecase => "Can'T" My solution was to implement the code as follows: class String # Title case. # # "this is a string".titlecase # => "This Is A String" # # CREDIT: Eliazar Parra and Angelo Lakra def titlecase split.map {|w| w.capitalize }.join(" ") end end It's not as elegant as the regex, but it behaves as expected. Please let me know if the intention of the function should work on non-word characters or something similar to the ucwords() function in PHP. Thanks, Angelo Lakra (fozze) angelo.lakra at gmail.com ---------------------------------------------------------------------- >Comment By: Angelo Lakra (alakra) Date: 2009-08-26 11:17 Message: Forked the project on github, http://github.com/fozze/facets/tree/master ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26999&group_id=804 From noreply at rubyforge.org Wed Aug 26 21:23:07 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 21:23:07 -0400 (EDT) Subject: [Facets] [ facets-Bugs-26999 ] String#titlecase doesn't work well with apostrophes Message-ID: <20090827012307.13B1718581FA@rubyforge.org> Bugs item #26999, was opened at 2009-08-26 11:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26999&group_id=804 Category: Code Group: 2.0 + >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Angelo Lakra (alakra) Assigned to: Nobody (None) Summary: String#titlecase doesn't work well with apostrophes Initial Comment: Using a string with an apostrophe causes the following letter after the apostrophe to be capitalized. The example in the documentation suggests that the method works on spaces instead of any non-word character. e.g. "can't".titlecase => "Can'T" My solution was to implement the code as follows: class String # Title case. # # "this is a string".titlecase # => "This Is A String" # # CREDIT: Eliazar Parra and Angelo Lakra def titlecase split.map {|w| w.capitalize }.join(" ") end end It's not as elegant as the regex, but it behaves as expected. Please let me know if the intention of the function should work on non-word characters or something similar to the ucwords() function in PHP. Thanks, Angelo Lakra (fozze) angelo.lakra at gmail.com ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2009-08-26 20:23 Message: Are there any non-space characters that we would want it to capitalize after though? Eg. this-for-example => This-For-Example ? Let me know of any cases you can imagine. In the mean time: def titlecase gsub(/\b\w/){ $`[-1,1] == "'" ? $& : $&.upcase } end P.S. I'm moving issues over to Github. Please follow up there: http://github.com/trans/facets. ---------------------------------------------------------------------- Comment By: Angelo Lakra (alakra) Date: 2009-08-26 12:17 Message: Forked the project on github, http://github.com/fozze/facets/tree/master ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26999&group_id=804 From noreply at rubyforge.org Wed Aug 26 22:58:11 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 22:58:11 -0400 (EDT) Subject: [Facets] [ facets-Bugs-11544 ] FileUtils.compress('zip', 'filepath', 'filepath.zip') got error when filepath.zip doedn't exist Message-ID: <20090827025811.BA527197827D@rubyforge.org> Bugs item #11544, was opened at 2007-06-13 04:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=11544&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Bin Dong (dongbin) Assigned to: Nobody (None) Summary: FileUtils.compress('zip', 'filepath', 'filepath.zip') got error when filepath.zip doedn't exist Initial Comment: Found the reason: in the compress.rb cmd = "zip -cf #{to_file} #{folder}" should be replace with cmd = "zip #{to_file} #{folder}" The "-c" option of zip is different with tar. ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2009-08-26 21:58 Message: This module has been deprecated from Facets. Equivalent functionality can be found in Folio project. Thanks. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2008-08-10 16:43 Message: This is fixed, but the method in question in now in a library called ziputils.rb. Currently zip format shells out to get the job done. Eventually this should be pure ruby, like gzip does. Which reminds me, is GZip essentially the same as Zip format? ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-07-26 08:37 Message: Thanks. compress.rb is still a work in progress. For Facets 2.0 I renamed it ZipUtils. (I know it's not _all_ about Zip, but hey tissue paper isn't all Kleenex either ;) I'm actually not sure what that line should be. I'm thinking: cmd = "zip -ru #{to_file} #{folder}" recursive with updates. Look right? On the TODO list is to use Ruby's own zlib to create the Zip files (should be possible). Anyone want to take a crack at it? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=11544&group_id=804 From noreply at rubyforge.org Wed Aug 26 22:58:26 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 22:58:26 -0400 (EDT) Subject: [Facets] [ facets-Bugs-11544 ] FileUtils.compress('zip', 'filepath', 'filepath.zip') got error when filepath.zip doedn't exist Message-ID: <20090827025826.11BB0197827F@rubyforge.org> Bugs item #11544, was opened at 2007-06-13 04:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=11544&group_id=804 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Bin Dong (dongbin) Assigned to: Nobody (None) Summary: FileUtils.compress('zip', 'filepath', 'filepath.zip') got error when filepath.zip doedn't exist Initial Comment: Found the reason: in the compress.rb cmd = "zip -cf #{to_file} #{folder}" should be replace with cmd = "zip #{to_file} #{folder}" The "-c" option of zip is different with tar. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2009-08-26 21:58 Message: This module has been deprecated from Facets. Equivalent functionality can be found in Folio project. Thanks. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2008-08-10 16:43 Message: This is fixed, but the method in question in now in a library called ziputils.rb. Currently zip format shells out to get the job done. Eventually this should be pure ruby, like gzip does. Which reminds me, is GZip essentially the same as Zip format? ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2007-07-26 08:37 Message: Thanks. compress.rb is still a work in progress. For Facets 2.0 I renamed it ZipUtils. (I know it's not _all_ about Zip, but hey tissue paper isn't all Kleenex either ;) I'm actually not sure what that line should be. I'm thinking: cmd = "zip -ru #{to_file} #{folder}" recursive with updates. Look right? On the TODO list is to use Ruby's own zlib to create the Zip files (should be possible). Anyone want to take a crack at it? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=11544&group_id=804 From noreply at rubyforge.org Wed Aug 26 23:04:57 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 23:04:57 -0400 (EDT) Subject: [Facets] [ facets-Bugs-18872 ] Bugfix for Dictionary#all? #any? on Ruby 1.9 Message-ID: <20090827030457.24D44177992E@rubyforge.org> Bugs item #18872, was opened at 2008-03-16 17:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18872&group_id=804 Category: Code Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Michael Neumann (mneumann) Assigned to: Nobody (None) Summary: Bugfix for Dictionary#all? #any? on Ruby 1.9 Initial Comment: See test cases in appended patch. Enumerable#all? and #any? in Ruby 1.9 passes only the key as argument to the block whereas Hash passes the key and the value. ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2009-08-26 22:04 Message: 1.9 passes only the key? I can't image that. If it comes up again I will look at it again. In the mean time I will pray that it passes both key and value like I think it should. (Or maybe I misunderstand the point? If so, resubmit issue at http://github.com/trans/facets) Thanks. ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2008-08-10 08:44 Message: *PATCH IS MISSING* Could re-submit. Be sure to check the "Check to Upload & Attach File" box. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18872&group_id=804 From noreply at rubyforge.org Wed Aug 26 23:11:03 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 23:11:03 -0400 (EDT) Subject: [Facets] [ facets-Bugs-26060 ] Dir.recursive() duplicates Find.find() Message-ID: <20090827031103.3F3D6177992E@rubyforge.org> Bugs item #26060, was opened at 2009-05-29 04:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26060&group_id=804 Category: Code Group: None >Status: Closed >Resolution: Postponed Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Dir.recursive() duplicates Find.find() Initial Comment: I think it's better to implement Dir.recursive() as alias of Find.find(). ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2009-08-26 22:11 Message: This issue has been transfered to GitHub site. Will consider in future. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=26060&group_id=804 From noreply at rubyforge.org Wed Aug 26 23:22:26 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 23:22:26 -0400 (EDT) Subject: [Facets] [ facets-Bugs-10424 ] Module#attr_tester bugs and change requests Message-ID: <20090827032226.B6A14177992E@rubyforge.org> Bugs item #10424, was opened at 2007-04-27 19:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=10424&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Tyler Rick (tylerrick) Assigned to: Nobody (None) Summary: Module#attr_tester bugs and change requests Initial Comment: The (apparent) bug is this: Docs claim that " One is used to test the attribute and the other is used to set or toggle it." Yet when I try to *set* it to false, like this, it remains unchanged: x.a! false I assume that is not the desired behavior. Am I correct? It looks like you just copied this line from the a?-generator: @#{a} ? true_value : @#{a} In the attached file, I have included some tests that expose this bug. The other change requests are as follows: * rename attr_tester to bool_attr_accessor to be more like Ruby's core attr_accessor method, since it seems to have such a similar purpose. * move the creation of a? and a! into bool_attr_reader and bool_attr_writer methods, respectively, which can be reused by bool_attr_accessor * That also lets the user create a read-only boolean attribute -- you can have reader without having a setter. The included file has exactly the changes I just described, if you want to consider using them. Including comprehensive unit tests, of course. This change has also been included in qualitysmith_extensions version 0.0.23 at http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/module/bool_attr_accessor.rb or by installing `gem qualitysmith_extensions` (0.0.24 or later). Another thing -- and this is more just a question than a request -- Why does it return make.keys ? Why does it even need to create the 'make' hash? I guess it's a more useful return value than *nil*, but I still can't think of how I'd use it. :) Thanks in advance! Tyler ---------------------------------------------------------------------- >Comment By: 7rans (transami) Date: 2009-08-26 22:22 Message: I have transfered these issues to GitHub (http://github.com/trans/facets). Where they can be considered more in the future. Thanks. ---------------------------------------------------------------------- Comment By: Tyler Rick (tylerrick) Date: 2007-04-30 12:56 Message: "and you want to allow the user to override it" -- that is, override it so that it's *always* on or *always* off rather than the default "sometimes on"... Not sure if that's even a very common use case in practice... but there are bound to be other use cases where nilability would be useful. :-) ---------------------------------------------------------------------- Comment By: Tyler Rick (tylerrick) Date: 2007-04-30 12:51 Message: I have another change request... :) I request that these methods be modified to (optionally, if :allow_nil => true) allow a tri-state switch (true/false/nil, with nil being the default) instead of only allowing true/false. This can be very useful, for example, when you have some default behavior (that's not as simple as "always do it") and you want to allow the user to override it I'm sure there are other use cases. The very fact that there exists a tri-state checkbox in UI designs and a NULL state for boolean columns in database schemas attests to the fact that sometimes a boolean variable is in an "unknown" state, neither false nor true. A suggested implementation of this (with passing tests) is available at: http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/module/bool_attr_accessor.rb An example of something that uses this tri-state ability is http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/test/difference_highlighting.rb --- Oh, I forgot to mention in my last post another addition I've made: a corollary method mbool_attr_accessor for making boolean attribute accessors for module/class variables! (The "m" prefix in the method name seems like at least a somewhat common convention (mattr_accessor, ...). Not sure if there's a better way to name them...) See http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/module/bool_attr_accessor.rb for details. I've also written a guard_method/mguard_method that I'm pretty excited about at http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/module/guard_method.rb --- I'm also curious what use case this logic was meant to allow: def #{a}?(true_value=true) @#{a} ? true_value : @#{a} end Why would you want x?() to return anything other than true if @x is true?? I suggest this as a possible alternative: def #{a}?(true_value=true) @#{a} == true_value ? true : @#{a} end Then you could ask: *a? (is @a true?) *a?(nil) (is @a nil?) *a?(false) (is @a false?) , something you can't easily do as it stands. ( @x.a?.nil? and @x.a? == false are as good as it gets ) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=10424&group_id=804 From noreply at rubyforge.org Wed Aug 26 23:22:44 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 23:22:44 -0400 (EDT) Subject: [Facets] [ facets-Bugs-10424 ] Module#attr_tester bugs and change requests Message-ID: <20090827032244.B5F151779932@rubyforge.org> Bugs item #10424, was opened at 2007-04-27 19:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=10424&group_id=804 Category: None Group: None >Status: Closed >Resolution: Postponed Priority: 3 Submitted By: Tyler Rick (tylerrick) Assigned to: Nobody (None) Summary: Module#attr_tester bugs and change requests Initial Comment: The (apparent) bug is this: Docs claim that " One is used to test the attribute and the other is used to set or toggle it." Yet when I try to *set* it to false, like this, it remains unchanged: x.a! false I assume that is not the desired behavior. Am I correct? It looks like you just copied this line from the a?-generator: @#{a} ? true_value : @#{a} In the attached file, I have included some tests that expose this bug. The other change requests are as follows: * rename attr_tester to bool_attr_accessor to be more like Ruby's core attr_accessor method, since it seems to have such a similar purpose. * move the creation of a? and a! into bool_attr_reader and bool_attr_writer methods, respectively, which can be reused by bool_attr_accessor * That also lets the user create a read-only boolean attribute -- you can have reader without having a setter. The included file has exactly the changes I just described, if you want to consider using them. Including comprehensive unit tests, of course. This change has also been included in qualitysmith_extensions version 0.0.23 at http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/module/bool_attr_accessor.rb or by installing `gem qualitysmith_extensions` (0.0.24 or later). Another thing -- and this is more just a question than a request -- Why does it return make.keys ? Why does it even need to create the 'make' hash? I guess it's a more useful return value than *nil*, but I still can't think of how I'd use it. :) Thanks in advance! Tyler ---------------------------------------------------------------------- Comment By: 7rans (transami) Date: 2009-08-26 22:22 Message: I have transfered these issues to GitHub (http://github.com/trans/facets). Where they can be considered more in the future. Thanks. ---------------------------------------------------------------------- Comment By: Tyler Rick (tylerrick) Date: 2007-04-30 12:56 Message: "and you want to allow the user to override it" -- that is, override it so that it's *always* on or *always* off rather than the default "sometimes on"... Not sure if that's even a very common use case in practice... but there are bound to be other use cases where nilability would be useful. :-) ---------------------------------------------------------------------- Comment By: Tyler Rick (tylerrick) Date: 2007-04-30 12:51 Message: I have another change request... :) I request that these methods be modified to (optionally, if :allow_nil => true) allow a tri-state switch (true/false/nil, with nil being the default) instead of only allowing true/false. This can be very useful, for example, when you have some default behavior (that's not as simple as "always do it") and you want to allow the user to override it I'm sure there are other use cases. The very fact that there exists a tri-state checkbox in UI designs and a NULL state for boolean columns in database schemas attests to the fact that sometimes a boolean variable is in an "unknown" state, neither false nor true. A suggested implementation of this (with passing tests) is available at: http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/module/bool_attr_accessor.rb An example of something that uses this tri-state ability is http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/test/difference_highlighting.rb --- Oh, I forgot to mention in my last post another addition I've made: a corollary method mbool_attr_accessor for making boolean attribute accessors for module/class variables! (The "m" prefix in the method name seems like at least a somewhat common convention (mattr_accessor, ...). Not sure if there's a better way to name them...) See http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/module/bool_attr_accessor.rb for details. I've also written a guard_method/mguard_method that I'm pretty excited about at http://qualitysmithext.rubyforge.org/src/lib/qualitysmith_extensions/module/guard_method.rb --- I'm also curious what use case this logic was meant to allow: def #{a}?(true_value=true) @#{a} ? true_value : @#{a} end Why would you want x?() to return anything other than true if @x is true?? I suggest this as a possible alternative: def #{a}?(true_value=true) @#{a} == true_value ? true : @#{a} end Then you could ask: *a? (is @a true?) *a?(nil) (is @a nil?) *a?(false) (is @a false?) , something you can't easily do as it stands. ( @x.a?.nil? and @x.a? == false are as good as it gets ) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=10424&group_id=804 From transfire at gmail.com Wed Aug 26 23:31:09 2009 From: transfire at gmail.com (Trans) Date: Wed, 26 Aug 2009 20:31:09 -0700 (PDT) Subject: [Facets] Rubyforge tracker shutdown Message-ID: <40d58df4-ef83-4469-9c1f-dc3a7df2caf5@o6g2000yqj.googlegroups.com> Issue tracking will now be done at http://github.com/trans/facets. So you will no longer see those crazy, barely readable posts on this list any longer! :) or :( ? ;) I have finished going through all the remaining tracker submissions. So the queue is empty. Much thanks to everyone who has submitted issues via the tracker over the years. Look forward to submissions via GitHub. ~7rans.