From noreply at rubyforge.org  Sun Mar  2 02:49:05 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  2 Mar 2008 02:49:05 -0500 (EST)
Subject: [Facets] [ facets-Bugs-18530 ] overload bug
Message-ID: <20080302074905.AE5EB185868B@rubyforge.org>

Bugs item #18530, was opened at 2008-03-02 07: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: None
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.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18530&group_id=804

From transfire at gmail.com  Mon Mar  3 04:17:52 2008
From: transfire at gmail.com (Trans)
Date: Mon, 3 Mar 2008 01:17:52 -0800 (PST)
Subject: [Facets] [ facets-Bugs-18530 ] overload bug
In-Reply-To: <20080302074905.AE5EB185868B@rubyforge.org>
References: <20080302074905.AE5EB185868B@rubyforge.org>
Message-ID: <9f2d30cc-7dd3-4e26-a408-a8ab2801973a@p73g2000hsd.googlegroups.com>



On Mar 2, 2:49 am, <nore... at rubyforge.org> wrote:
> Bugs item #18530, was opened at 2008-03-02 07:49
> You can respond by visiting:http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18530&group_i...
>
> Category: None
> Group: None
> Status: Open
> Resolution: None
> 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.

Thanks. I will look at this --hopefully today.

T.

From calamitates at gmail.com  Mon Mar  3 04:44:53 2008
From: calamitates at gmail.com (Calamitas)
Date: Mon, 3 Mar 2008 10:44:53 +0100
Subject: [Facets] [ facets-Bugs-18530 ] overload bug
In-Reply-To: <20080302074905.AE5EB185868B@rubyforge.org>
References: <20080302074905.AE5EB185868B@rubyforge.org>
Message-ID: <c4a653370803030144qd0db260o7656136823a97cb5@mail.gmail.com>

On 02/03/2008, noreply at rubyforge.org <noreply at rubyforge.org> wrote:
>           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.

Is it just me, or do neither of these two versions of the code make
sense? next skips to the next iteration of the loop, which is only
useful if next is followed by other statements. In both cases, the
condition of the unless statement is evaluated in *each* iteration,
and in some iterations next is executed but it skips over nothing.

Hmmmm, looking at the full method, I'd say you were expecting to jump
to the next iteration of the surrounding loop (the one that iterates
over faces). Maybe you could use something like this:

  hit = cmp if (0...cmp.size).all? { |i| cmp[i] < sig[i] }

Peter

From transfire at gmail.com  Wed Mar  5 09:55:38 2008
From: transfire at gmail.com (Trans)
Date: Wed, 5 Mar 2008 06:55:38 -0800 (PST)
Subject: [Facets] Facets 3
Message-ID: <ecd547f1-1dab-4e58-9520-b761e37a5b61@e25g2000prg.googlegroups.com>

Hi all--

After some recent discussions on ruby-talk as well as some lengthy
considerations of my own --on Facets, how it is structured, and where
to go with it in the future, I've drawn some important conclusions.

1) The original idea of Facets --every method in it's own file, while
excellent for it's granular control of what a project uses and doesn't
use, has one unfortunate problem: when it comes to inter-library
compatibility, there is no easy determinate as to which particular
facets are being used and which are not --a developer may even change
the particular methods used from version to version. We expect this to
some degree with any project, but occurring within a single project
dependency, and one that is all about extensions, it is especially
difficult.  What ends up happening I think, is that people ultimately
replace any use of Facets' extensions by copying the code to their
project --which ultimately makes our extension conflict issues even
worse.  To be on the safe side one would have to ASSUME that ALL
Facets libs could be used. People don't do that of course. So this
subtle fact effectively mitigates the advantages of fine-grain
requires.

2) Part of the original idea was to allow Facets to be a kind of
database of possible extensions. That's a great idea, but it works
against the goal of being a production ready resource that anyone can
use. Facets is basically supporting two opposing goals.

3) I've been spending too much time fussing with Facets (mostly b/c I
simply did not not fully realize the above two facts until recently)
and I'd really like to focus more of my time on other projects these
days.

So, given these three points, this is what I have concluded to do
(assuming you all generally concur). I will make Facets effectively
into two projects, "Facets" and "Facets Online".

The first will be the library much like we have now, but with a
"prime" set of core methods that one can always expect to be loaded
when using Facets. These methods are the cream of the crop. I've been
doing this long enough now to know fairly well which methods those
are, and I encourage your input in helping decide on some of the
tougher "edge" choices. Having this "prime" extension library will
give Facets a solid basis on which everyone using it can depend,
without exception. Facets will still offer a few extra extensions
libraries one can optionally load, but these will be used infrequently
enough to allow the traditional "fix it if breaks" approach to be more
than enough to handle the rare case of conflict --I also plan to wrap
most of these extra extensions in modules to help further mitigate any
potential of conflict. (A good example of these extra extensions are a
set of Enumerable methods related to statistics and probability.) I
believe taking this course will make Facets a much more solid and
reusable library.

The second project will be an online database of extensions. I will
put together a Rails app[1] that will keep a database of Ruby
extensions that anyone can add too. I will set it up to work like a
dictionary --methods will get index numbers to avoid conflicts, eg.
Kernel#ergo_1, Kernel#ergo_2, etc. There will be a ranking systen for
people to vote for the best versions, those with the highest ranking
will get to be labled w/o the added index (eg. alias ergo ergo_2). The
app will work like a cross between Pastie and a regular Wiki.
Ultimately, if this site works out, the "cream of the crop" of the
Facets library can be determined by what ranks on the online database;
and perhaps we can go a step further and allow extensions to be
required remotely? In any case, I can put together the basis of this
app quickly enough, but I will need help in adding the features that
will make the site truly appealing. In fact, I would like best if some
one else would like to manage the project (see #3 above) If you are
interested please get in touch. I also need to decide where to host
the site.

So that's the plan. My first priority is project #1. This is a
significant enough departure from the current design, so the version
will be bumped to Facets 3.0. I might not get to project #2 right way,
unless someone steps forward to run with it, but I'll keep you posted.

Finally, let me say "thanks" to everyone that has been supportive of
the project! And three cheers for all those great programmer who have
written a Ruby extension!

T.


[1] Likely I would have made a Nitro app instead, but George
Moschovitis recently abandoned his project.

From jackc at hylesanderson.edu  Thu Mar  6 11:51:03 2008
From: jackc at hylesanderson.edu (Jack Christensen)
Date: Thu, 06 Mar 2008 10:51:03 -0600
Subject: [Facets] Facets 3
In-Reply-To: <ecd547f1-1dab-4e58-9520-b761e37a5b61@e25g2000prg.googlegroups.com>
References: <ecd547f1-1dab-4e58-9520-b761e37a5b61@e25g2000prg.googlegroups.com>
Message-ID: <47D020F7.7090609@hylesanderson.edu>

Trans wrote:
> Hi all--
>
> After some recent discussions on ruby-talk as well as some lengthy
> considerations of my own --on Facets, how it is structured, and where
> to go with it in the future, I've drawn some important conclusions.
>
> 1) The original idea of Facets --every method in it's own file, while
> excellent for it's granular control of what a project uses and doesn't
> use, has one unfortunate problem: when it comes to inter-library
> compatibility, there is no easy determinate as to which particular
> facets are being used and which are not --a developer may even change
> the particular methods used from version to version. We expect this to
> some degree with any project, but occurring within a single project
> dependency, and one that is all about extensions, it is especially
> difficult.  What ends up happening I think, is that people ultimately
> replace any use of Facets' extensions by copying the code to their
> project --which ultimately makes our extension conflict issues even
> worse.  To be on the safe side one would have to ASSUME that ALL
> Facets libs could be used. People don't do that of course. So this
> subtle fact effectively mitigates the advantages of fine-grain
> requires.
>
>   

I suppose this ship may have already sailed, but I really like being 
able to cherry-pick methods. Especially when Facets has to co-exist with 
other support libraries like ActiveSupport. I did that in Facets 1.x but 
it seems to already be gone in Facets 2.x. Here's an example from one of 
my current Rails projects. I want to use a very simple extension like 
Enumerable#none?. So I can require 'facets/enumerable/none'. However 
that actually only requires 'facets/enumerable/count' which also defines 
sum. The problem is ActiveSupport defines sum differently which broke 
Rails in some weird way.

So I have this code in my environment.rb:
# The sum method defined in 'facets/enumerable/count' conflicts with the 
method
# defined in ActiveSupport. It causes blank screens instead of error 
messages
# on an exception. So we keep the ActiveSupport version of sum.
module Enumerable
  alias_method :active_support_sum, :sum
end
require 'facets/enumerable/count'
module Enumerable
  remove_method :sum
  alias_method :sum, :active_support_sum
  remove_method :active_support_sum
end


> 2) Part of the original idea was to allow Facets to be a kind of
> database of possible extensions. That's a great idea, but it works
> against the goal of being a production ready resource that anyone can
> use. Facets is basically supporting two opposing goals.
>
> 3) I've been spending too much time fussing with Facets (mostly b/c I
> simply did not not fully realize the above two facts until recently)
> and I'd really like to focus more of my time on other projects these
> days.
>
> So, given these three points, this is what I have concluded to do
> (assuming you all generally concur). I will make Facets effectively
> into two projects, "Facets" and "Facets Online".
>
> The first will be the library much like we have now, but with a
> "prime" set of core methods that one can always expect to be loaded
> when using Facets. These methods are the cream of the crop. I've been
> doing this long enough now to know fairly well which methods those
> are, and I encourage your input in helping decide on some of the
> tougher "edge" choices. Having this "prime" extension library will
> give Facets a solid basis on which everyone using it can depend,
> without exception. Facets will still offer a few extra extensions
> libraries one can optionally load, but these will be used infrequently
> enough to allow the traditional "fix it if breaks" approach to be more
> than enough to handle the rare case of conflict --I also plan to wrap
> most of these extra extensions in modules to help further mitigate any
> potential of conflict. (A good example of these extra extensions are a
> set of Enumerable methods related to statistics and probability.) I
> believe taking this course will make Facets a much more solid and
> reusable library.
>
> The second project will be an online database of extensions. I will
> put together a Rails app[1] that will keep a database of Ruby
> extensions that anyone can add too. I will set it up to work like a
> dictionary --methods will get index numbers to avoid conflicts, eg.
> Kernel#ergo_1, Kernel#ergo_2, etc. There will be a ranking systen for
> people to vote for the best versions, those with the highest ranking
> will get to be labled w/o the added index (eg. alias ergo ergo_2). The
> app will work like a cross between Pastie and a regular Wiki.
> Ultimately, if this site works out, the "cream of the crop" of the
> Facets library can be determined by what ranks on the online database;
> and perhaps we can go a step further and allow extensions to be
> required remotely? In any case, I can put together the basis of this
> app quickly enough, but I will need help in adding the features that
> will make the site truly appealing. In fact, I would like best if some
> one else would like to manage the project (see #3 above) If you are
> interested please get in touch. I also need to decide where to host
> the site.
>
>   
Sounds cool. But what happens when one version of a method supplants 
another? People can't rely on ergo if the external behavior of the 
method is going to change out from under them. If the change is 
completely transparent from the outside then why have multiple versions 
at all? Just use the implementation with cleanest code and/or best 
performance.

> So that's the plan. My first priority is project #1. This is a
> significant enough departure from the current design, so the version
> will be bumped to Facets 3.0. I might not get to project #2 right way,
> unless someone steps forward to run with it, but I'll keep you posted.
>
> Finally, let me say "thanks" to everyone that has been supportive of
> the project! And three cheers for all those great programmer who have
> written a Ruby extension!
>
> T.
>
>
> [1] Likely I would have made a Nitro app instead, but George
> Moschovitis recently abandoned his project.
> _______________________________________________
> facets-universal mailing list
> facets-universal at rubyforge.org
> http://rubyforge.org/mailman/listinfo/facets-universal
>
>   


-- 
Jack Christensen
jackc at hylesanderson.edu


From transfire at gmail.com  Thu Mar  6 14:27:36 2008
From: transfire at gmail.com (Trans)
Date: Thu, 6 Mar 2008 11:27:36 -0800 (PST)
Subject: [Facets] Facets 3
In-Reply-To: <47D020F7.7090609@hylesanderson.edu>
References: <ecd547f1-1dab-4e58-9520-b761e37a5b61@e25g2000prg.googlegroups.com>
	<47D020F7.7090609@hylesanderson.edu>
Message-ID: <fd560acb-dfe0-456e-9485-57bec6081e28@x41g2000hsb.googlegroups.com>

On Mar 6, 11:51 am, Jack Christensen <ja... at hylesanderson.edu> wrote:

> I suppose this ship may have already sailed, but I really like being
> able to cherry-pick methods. Especially when Facets has to co-exist with
> other support libraries like ActiveSupport. I did that in Facets 1.x but
> it seems to already be gone in Facets 2.x. Here's an example from one of
> my current Rails projects. I want to use a very simple extension like
> Enumerable#none?. So I can require 'facets/enumerable/none'. However
> that actually only requires 'facets/enumerable/count' which also defines
> sum. The problem is ActiveSupport defines sum differently which broke
> Rails in some weird way.

I agree. I like cherry picking too. Although, over time I became a
little less enamored with it as I had many requires to handle, often
the same ones, in every project. But it wasn't a big deal --and I
still like that design overall. But what happened from 1.x to 2.x is
that I started to realize the issues this design was causing. Because
people were cherry picking, you never knew who was cherry picking
what. This actually increased potential conflicts. And I also noticed
more and more users will ultimately just replacing there use of Facets
with copies of the methods --after all, why have a whole dependency
for just a handful of methods? I can understand it, but ultimately it
makes potential conflicts ever worse. So for 2.0 I started heading in
the other direction --but I was reluctant to commit, so I ended up
with a sort of compromise of small groups roughly related methods --
but it was a mistake. In that last couple of months I've come to
realize that a compromise position it the worst choice. And your
example is good demo of why. So that is why I'm working hard right now
to get it fixed. It's either back to full cherry picking, or on to a
central foundation. And given the issues that have proven themselves
with the former, I think you right, that ship has sailed. I think
everyone can understand why. It was an interesting experiment, I'm
glad I explored it, but without proper selector name space support
from Ruby, it just doesn't look work out well in the end.

> So I have this code in my environment.rb:
> # The sum method defined in 'facets/enumerable/count' conflicts with the
> method
> # defined in ActiveSupport. It causes blank screens instead of error
> messages
> # on an exception. So we keep the ActiveSupport version of sum.
> module Enumerable
>   alias_method :active_support_sum, :sum
> end
> require 'facets/enumerable/count'
> module Enumerable
>   remove_method :sum
>   alias_method :sum, :active_support_sum
>   remove_method :active_support_sum
> end

An important part of what I'm doing for the next version is ensuring
compatibility with ActiveSupport. There are actually very few
conflicts in the first place, and in all the cases I've so far
encountered it's not a very big deal to just defer to ActiveSupport's
design. If a substantial issue of some sort does arise, I will bring
it up with the Rails team and see what we can work out. My guess is
that probably won't be necessary, but we will see.  ---  And you will
be able to get rid of your "patch". I'm sorry you had to fuss with it
all.

> > The second project will be an online database of extensions. I will
> > put together a Rails app[1] that will keep a database of Ruby
> > extensions that anyone can add too. I will set it up to work like a
> > dictionary --methods will get index numbers to avoid conflicts, eg.
> > Kernel#ergo_1, Kernel#ergo_2, etc. There will be a ranking systen for
> > people to vote for the best versions, those with the highest ranking
> > will get to be labled w/o the added index (eg. alias ergo ergo_2). The
> > app will work like a cross between Pastie and a regular Wiki.
> > Ultimately, if this site works out, the "cream of the crop" of the
> > Facets library can be determined by what ranks on the online database;
> > and perhaps we can go a step further and allow extensions to be
> > required remotely? In any case, I can put together the basis of this
> > app quickly enough, but I will need help in adding the features that
> > will make the site truly appealing. In fact, I would like best if some
> > one else would like to manage the project (see #3 above) If you are
> > interested please get in touch. I also need to decide where to host
> > the site.
>
> Sounds cool. But what happens when one version of a method supplants
> another? People can't rely on ergo if the external behavior of the
> method is going to change out from under them. If the change is
> completely transparent from the outside then why have multiple versions
> at all? Just use the implementation with cleanest code and/or best
> performance.

That's a good point. I doubt it will be a problem though. Once a
method has been around a while it will settle in to a "long life as
king". Any method that comes along to supplant it will more than
likely just be an improvement in performance or fix some subtle
overlooked bug. It will be rare for a method of the same name to be
swapped out for a wholly different functionality. Also, that won't be
something that is automatic --it will be done manually, when a ranking
holds sway for a reasonable period of time. At least, that's the idea.
We will see how it plays out in practice. At first (and perhaps
forever) this site will simply be a reference resource anyway.

Thanks for replying, btw. The feedback really helps.

T.

From transfire at gmail.com  Fri Mar  7 15:03:58 2008
From: transfire at gmail.com (Trans)
Date: Fri, 7 Mar 2008 12:03:58 -0800 (PST)
Subject: [Facets] Couple of Enumerable methods being replaced
Message-ID: <71033be6-e883-46e3-a986-78b04c7c8a93@b64g2000hsa.googlegroups.com>

Hi--

The following Enumerable methods are going to be removed:

    # Collects/Maps and filters items out in one single step.
    # You can use throw(:skip) in the supplied block to indicate that
the
    # current item should not end up in the resulting array.
    #
    #   # Return names of all person with an age of at least 18.
    #   persons.filter_collect do |person|
    #     throw(:skip) if person.age < 18
    #     person.name
    #   end
    #
    # Also see Enumerable#collect, Enumerable#find_all.
    #
    #  CREDIT: Florian Gross

    def filter_collect #:yield:
      result = []
      self.each do |item|
        catch(:skip) do
          new_item = yield(item)
          result << new_item
        end
      end
      return result
    end

    # Alias for #filter_collect.

    alias_method :filter_map, :filter_collect

    # Collects/Maps and compacts items in one single step.
    # The items for which the supplied block returns +nil+ will not
    # end up in the resulting array.
    #
    #   # Return telephone numbers of all persons that have a
telephone number.
    #   persons.compact_collect { |person| person.telephone_no }
    #
    # Also see Enumerable#collect, Enumerable#map, Array#compact.
    #
    # TODO: What about having compact take a block instead, acts just
like map but no nil results?
    #
    #  CREDIT: Florian Gross

    def compact_collect #:yield:
      filter_collect do |item|
        new_item = yield(item)
        throw(:skip) if new_item.nil?
        new_item
      end
    end

    # Alias for #compact_collect.

    alias_method :compact_map, :compact_collect

They will be replaced by one method:

  # A more versitle #compact method. It can be used to
  # collect and filter items out in one single step.
  #
  #   [1,2,3].compact_map do |n|
  #     n < 1 ? nil : n
  #   end
  #
  # _produces_
  #
  #   [2,3]

  def compact(trash=nil, &block)
    a = []
    if block_given?
      each do |*a|
        r = yeild(*a)
        a << r unless trash == r
      end
    else
      each do |r|
        a << r unless trash == r
      end
    end
  end

Of course, while I would prefer to define #compact this way, I realize
I shouldn't override the built-in method. So anyone have a better
name? If not I'll go with #compact_map again.

Thanks,
T.

From simonis.christophe at gmail.com  Sun Mar  9 06:45:54 2008
From: simonis.christophe at gmail.com (Christophe Simonis)
Date: Sun, 9 Mar 2008 03:45:54 -0700 (PDT)
Subject: [Facets] Test
In-Reply-To: <98f45375-050a-43fa-bb98-eec03a000b37@j78g2000hsd.googlegroups.com>
References: <ce4e5e13-225e-44b9-92ee-d520a13380b6@j78g2000hsd.googlegroups.com>
	<98f45375-050a-43fa-bb98-eec03a000b37@j78g2000hsd.googlegroups.com>
Message-ID: <45eeb0e0-16e5-4bd9-b6c7-5f5208c2665e@m34g2000hsc.googlegroups.com>

test from google-group web interface.

On 28 jan, 20:03, Trans <transf... at gmail.com> wrote:
> If any of you might take a moment and respond to this post, I'd really
> appreciate it. I'm trying to figure out why some posts aren't getting
> through.
>
> Please specify how you are posting --via Google Group Web interface,
> via the Google Group email address or via the original Rubyforge
> address.
>
> Thanks,
> T.
> _______________________________________________
> facets-universal mailing list
> facets-univer... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/facets-universal

From simonis.christophe at gmail.com  Sun Mar  9 07:14:50 2008
From: simonis.christophe at gmail.com (Christophe Simonis)
Date: Sun, 9 Mar 2008 04:14:50 -0700 (PDT)
Subject: [Facets] [ facets-Bugs-18530 ] overload bug
In-Reply-To: <c4a653370803030144qd0db260o7656136823a97cb5@mail.gmail.com>
References: <20080302074905.AE5EB185868B@rubyforge.org>
	<c4a653370803030144qd0db260o7656136823a97cb5@mail.gmail.com>
Message-ID: <00472abf-af19-43b8-ba0d-1c6f1e191911@p25g2000hsf.googlegroups.com>

The condition seems to be wrong. The arguments must be subclasses of
what the function expects. And no need to go foward if we found the
correct sign.

        faces.each do |cmp|
          next unless cmp.size == sig.size
          if (0...cmp.size).all? { |i| cmp[i] >= sig[i] }
            break hit = cmp
        end

In addition, a verification of that the "signiture" is correct must be
done at declaration-time. The first instruction of overload method
must be

   raise ArgumentError unless signiture.all? {|p| p.instance_of?
Class}


--
Christophe
On 3 mar, 10:44, Calamitas <calamita... at gmail.com> wrote:
> On 02/03/2008, nore... at rubyforge.org <nore... at rubyforge.org> wrote:
>
>
>
> > ? ? ? ? ? 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.
>
> Is it just me, or do neither of these two versions of the code make
> sense? next skips to the next iteration of the loop, which is only
> useful if next is followed by other statements. In both cases, the
> condition of the unless statement is evaluated in *each* iteration,
> and in some iterations next is executed but it skips over nothing.
>
> Hmmmm, looking at the full method, I'd say you were expecting to jump
> to the next iteration of the surrounding loop (the one that iterates
> over faces). Maybe you could use something like this:
>
> ? hit = cmp if (0...cmp.size).all? { |i| cmp[i] < sig[i] }
>
> Peter
> _______________________________________________
> facets-universal mailing list
> facets-univer... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/facets-universal

From transfire at gmail.com  Sun Mar  9 09:38:39 2008
From: transfire at gmail.com (Trans)
Date: Sun, 9 Mar 2008 06:38:39 -0700 (PDT)
Subject: [Facets] [ facets-Bugs-18530 ] overload bug
In-Reply-To: <c4a653370803030144qd0db260o7656136823a97cb5@mail.gmail.com>
References: <20080302074905.AE5EB185868B@rubyforge.org>
	<c4a653370803030144qd0db260o7656136823a97cb5@mail.gmail.com>
Message-ID: <83f8b150-1110-4f22-a437-b5ee1f435a5b@m36g2000hse.googlegroups.com>



On Mar 3, 5:44 am, Calamitas <calamita... at gmail.com> wrote:
> On 02/03/2008, nore... at rubyforge.org <nore... at rubyforge.org> wrote:
>
>
>
> >           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.
>
> Is it just me, or do neither of these two versions of the code make
> sense? next skips to the next iteration of the loop, which is only
> useful if next is followed by other statements. In both cases, the
> condition of the unless statement is evaluated in *each* iteration,
> and in some iterations next is executed but it skips over nothing.

You're right. That next was meant for the faces loop.

> Hmmmm, looking at the full method, I'd say you were expecting to jump
> to the next iteration of the surrounding loop (the one that iterates
> over faces). Maybe you could use something like this:
>
>   hit = cmp if (0...cmp.size).all? { |i| cmp[i] < sig[i] }

Looks good.

Also, I removed the sorting of the faces:

  faces = ovr.keys  #.sort { |a,b| b.size <=> a.size }

Anyone else see a good reason that was in there --I don't recall one.

T.

From transfire at gmail.com  Sun Mar  9 09:49:41 2008
From: transfire at gmail.com (Trans)
Date: Sun, 9 Mar 2008 06:49:41 -0700 (PDT)
Subject: [Facets] [ facets-Bugs-18530 ] overload bug
In-Reply-To: <00472abf-af19-43b8-ba0d-1c6f1e191911@p25g2000hsf.googlegroups.com>
References: <20080302074905.AE5EB185868B@rubyforge.org>
	<c4a653370803030144qd0db260o7656136823a97cb5@mail.gmail.com> 
	<00472abf-af19-43b8-ba0d-1c6f1e191911@p25g2000hsf.googlegroups.com>
Message-ID: <8333676a-327d-43e0-9d13-89ebb879a935@8g2000hse.googlegroups.com>



On Mar 9, 7:14 am, Christophe Simonis <simonis.christo... at gmail.com>
wrote:
> The condition seems to be wrong. The arguments must be subclasses of
> what the function expects. And no need to go foward if we found the
> correct sign.
>
>         faces.each do |cmp|
>           next unless cmp.size == sig.size
>           if (0...cmp.size).all? { |i| cmp[i] >= sig[i] }
>             break hit = cmp
>         end

Great. The new code has this.

I will add a testcase for the bug --think you could create one real
quick?

> In addition, a verification of that the "signiture" is correct must be
> done at declaration-time. The first instruction of overload method
> must be
>
>    raise ArgumentError unless signiture.all? {|p| p.instance_of?
> Class}

Hmmm... If the signature doesn't match it falls back to the generic
method (if one exists) --so that should catch any argument error if
there is one. This way duck-typing is still viable, even for
overloaded methods. If there is no genric method, of course, it raises
a NoMethodError.

T.

From simonis.christophe at gmail.com  Sun Mar  9 10:33:19 2008
From: simonis.christophe at gmail.com (Christophe Simonis)
Date: Sun, 9 Mar 2008 07:33:19 -0700 (PDT)
Subject: [Facets] [ facets-Bugs-18530 ] overload bug
In-Reply-To: <8333676a-327d-43e0-9d13-89ebb879a935@8g2000hse.googlegroups.com>
References: <20080302074905.AE5EB185868B@rubyforge.org>
	<c4a653370803030144qd0db260o7656136823a97cb5@mail.gmail.com> 
	<00472abf-af19-43b8-ba0d-1c6f1e191911@p25g2000hsf.googlegroups.com> 
	<8333676a-327d-43e0-9d13-89ebb879a935@8g2000hse.googlegroups.com>
Message-ID: <b9b0a555-4408-4fc3-bcf3-595a02f74567@p25g2000hsf.googlegroups.com>



On 9 mar, 14:49, Trans <transf... at gmail.com> wrote:
> On Mar 9, 7:14 am, Christophe Simonis <simonis.christo... at gmail.com>
> wrote:
>
> > The condition seems to be wrong. The arguments must be subclasses of
> > what the function expects. And no need to go foward if we found the
> > correct sign.
>
> > ? ? ? ? faces.each do |cmp|
> > ? ? ? ? ? next unless cmp.size == sig.size
> > ? ? ? ? ? if (0...cmp.size).all? { |i| cmp[i] >= sig[i] }
> > ? ? ? ? ? ? break hit = cmp
> > ? ? ? ? end
>
> Great. The new code has this.
>
> I will add a testcase for the bug --think you could create one real
> quick?
>

Yes, I did. See below.

> > In addition, a verification of that the "signiture" is correct must be
> > done at declaration-time. The first instruction of overload method
> > must be
>
> > ? ?raise ArgumentError unless signiture.all? {|p| p.instance_of?
> > Class}
>
> Hmmm... If the signature doesn't match it falls back to the generic
> method (if one exists) --so that should catch any argument error if
> there is one. This way duck-typing is still viable, even for
> overloaded methods. If there is no genric method, of course, it raises
> a NoMethodError.
>
> T.
> _______________________________________________
> facets-universal mailing list
> facets-univer... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/facets-universal


No, you don't understand what I mean. The signature of the overloaded
functions must be a array of Classes.
Look at "test_raise" in the unit tests.

-> http://facets-universal.googlegroups.com/web/overload_test.rb

From transfire at gmail.com  Sun Mar  9 13:50:52 2008
From: transfire at gmail.com (Trans)
Date: Sun, 9 Mar 2008 10:50:52 -0700 (PDT)
Subject: [Facets] [ facets-Bugs-18530 ] overload bug
In-Reply-To: <b9b0a555-4408-4fc3-bcf3-595a02f74567@p25g2000hsf.googlegroups.com>
References: <20080302074905.AE5EB185868B@rubyforge.org>
	<c4a653370803030144qd0db260o7656136823a97cb5@mail.gmail.com> 
	<00472abf-af19-43b8-ba0d-1c6f1e191911@p25g2000hsf.googlegroups.com> 
	<8333676a-327d-43e0-9d13-89ebb879a935@8g2000hse.googlegroups.com> 
	<b9b0a555-4408-4fc3-bcf3-595a02f74567@p25g2000hsf.googlegroups.com>
Message-ID: <41446764-3bf2-48fa-a506-0c392152a145@2g2000hsn.googlegroups.com>



On Mar 9, 10:33 am, Christophe Simonis <simonis.christo... at gmail.com>
wrote:
> On 9 mar, 14:49, Trans <transf... at gmail.com> wrote:
>
>
>
> > On Mar 9, 7:14 am, Christophe Simonis <simonis.christo... at gmail.com>
> > wrote:
>
> > > The condition seems to be wrong. The arguments must be subclasses of
> > > what the function expects. And no need to go foward if we found the
> > > correct sign.
>
> > >         faces.each do |cmp|
> > >           next unless cmp.size == sig.size
> > >           if (0...cmp.size).all? { |i| cmp[i] >= sig[i] }
> > >             break hit = cmp
> > >         end
>
> > Great. The new code has this.
>
> > I will add a testcase for the bug --think you could create one real
> > quick?
>
> Yes, I did. See below.
>
>
>
> > > In addition, a verification of that the "signiture" is correct must be
> > > done at declaration-time. The first instruction of overload method
> > > must be
>
> > >    raise ArgumentError unless signiture.all? {|p| p.instance_of?
> > > Class}
>
> > Hmmm... If the signature doesn't match it falls back to the generic
> > method (if one exists) --so that should catch any argument error if
> > there is one. This way duck-typing is still viable, even for
> > overloaded methods. If there is no genric method, of course, it raises
> > a NoMethodError.
>
> > T.
> > _______________________________________________
> > facets-universal mailing list
> > facets-univer... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/facets-universal
>
> No, you don't understand what I mean. The signature of the overloaded
> functions must be a array of Classes.
> Look at "test_raise" in the unit tests.

Ah, okay I got ya. Thanks.

> ->http://facets-universal.googlegroups.com/web/overload_test.rb

Nice.

T.

> _______________________________________________
> facets-universal mailing list
> facets-univer... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/facets-universal

From transfire at gmail.com  Mon Mar 10 12:50:10 2008
From: transfire at gmail.com (Trans)
Date: Mon, 10 Mar 2008 09:50:10 -0700 (PDT)
Subject: [Facets] Core Kernel Methods?
Message-ID: <623741a0-5dad-44d1-b127-8206187a42fc@m34g2000hsc.googlegroups.com>

Hi--

I have a few methods I'm torn on whether to include in the core or
not. Like to get some feedback. These are the ones for Kernel:

  module Kernel

    # Is self included in other?
    #
    #   5.in?(0..10)       #=> true
    #   5.in?([0,1,2,3])   #=> false
    #
    def in?(other)
      other.include?(self)
    end

    # Return object after running block.
    #
    #   returning Book.new do |book|
    #     book.title = "Imperium"
    #     book.author = "Ulick Varange"
    #   end
    #
    def returning(obj=self)
      yield obj
      obj
    end

    # Alias for #returning.
    #
    #   def foo
    #     with values = [] do
    #       values << 'bar'
    #       values << 'baz'
    #     end
    #   end
    #
    #   foo # => ['bar', 'baz']
    #
    alias_method :with, :returning

    # Like #p but gives file and line number.
    #
    #   d("hi")
    #
    # produces
    #
    #   /home/dave/projects/foo.rb, 38
    #   "hi"
    #
    # TODO: Core Or DebugUtils ?

    def d(*x)
      puts "#{__FILE__}, #{__LINE__}"
      x.each{ |e| puts e.inspect } #p(*x)
      x.size > 1 ? x : x.last #x.last
    end

  end

T.


From transfire at gmail.com  Mon Mar 10 12:54:00 2008
From: transfire at gmail.com (Trans)
Date: Mon, 10 Mar 2008 09:54:00 -0700 (PDT)
Subject: [Facets] Cherry Picking
Message-ID: <78ee3e79-12cf-4331-bc11-5928e0223204@k13g2000hse.googlegroups.com>

BTW, I decided to go ahead and break out all the core methods. So it
will still be possible to cherry pick. BUT!!!!! That's primarily as a
temporary backward compatibility -OR- for those who full understand
that just because you cherry pick a method doesn't mean that the rest
of the methods are defacto avoided. Of course that may be the case, if
your app is fully stand-alone, but otherwise one must expect that
anyone reusing you lib/app can be confident that it won't prevent any
of the other core Facets methods from working.

T.


From ! at phrogz.net  Mon Mar 10 23:08:35 2008
From: ! at phrogz.net (Gavin Kistner)
Date: Mon, 10 Mar 2008 21:08:35 -0600
Subject: [Facets] Core Kernel Methods?
In-Reply-To: <623741a0-5dad-44d1-b127-8206187a42fc@m34g2000hsc.googlegroups.com>
References: <623741a0-5dad-44d1-b127-8206187a42fc@m34g2000hsc.googlegroups.com>
Message-ID: <D53FF13B-020D-4E4E-B216-614395645D61@phrogz.net>

On Mar 10, 2008, at 10:50 AM, Trans wrote:
>    # Is self included in other?

I vote yes to this.


>    # Return object after running block.

I vote yes to this.


>    alias_method :with, :returning

I vote no to this. I love the name 'with' far more than 'returning',  
but I personally use it for instance_eval; I don't think it  makes  
sense in the 'yield' usage.


>    # Like #p but gives file and line number.

On the one hand, this is a rather generic name and debug-centric.
On the other hand, it's in Kernel, and as such any name 'conflict'  
would be resolved in the lower usage, so it shouldn't be an issue.

I abstain on this one :)


From noreply at rubyforge.org  Wed Mar 12 17:02:22 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 12 Mar 2008 17:02:22 -0400 (EDT)
Subject: [Facets] [ facets-Bugs-18792 ] Enumerable.modulate throws error:
	"undefined local variable or method `level'"
Message-ID: <20080312210222.C7D501858653@rubyforge.org>

Bugs item #18792, was opened at 2008-03-12 17:02
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18792&group_id=804

Category: Code
Group: 2.0 +
Status: Open
Resolution: None
Priority: 3
Submitted By: Dan Bernier (danbernier)
Assigned to: Nobody (None)
Summary: Enumerable.modulate throws error: "undefined local variable or method `level'"

Initial Comment:
It seems like a simple typo...the method is calling a var/method 'level', which doesn't exist.  I'm guessing the method's parameter, 'modulo', was originally named 'level', and this is a spot that was missed?  Anyway, a fix is included in the attached file.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18792&group_id=804

From transfire at gmail.com  Wed Mar 12 21:14:32 2008
From: transfire at gmail.com (Trans)
Date: Wed, 12 Mar 2008 18:14:32 -0700 (PDT)
Subject: [Facets] Parametric module or injecting code via class method?
Message-ID: <8f2d5f48-698f-4227-9e38-296ce58f0485@n75g2000hsh.googlegroups.com>

Which approach is better: parametric module or an injecting class
method.

  # Generates identity/key methods based on specified attributes.
  #
  #   include EquateOn(:a, :b)
  #
  # is equivalent to including a module containing:
  #
  #   def ==(other)
  #     self.a == other.a && self.b == other.b
  #   end
  #
  #   def eql?(other)
  #     self.a.eql?(other.a) && self.b.eql?(other.b)
  #   end
  #
  #   def hash()
  #     self.a.hash ^ self.b.hash
  #   end
  #

  def EquateOn(*fields)
    code = ""
    code << "def ==(o) "   << fields.map {|f| "self.#{f} ==
o.#{f}" }.join(" && ")    << " end\n"
    code << "def eql?(o) " << fields.map {|f| "self.#{f}.eql?
(o.#{f})" }.join(" && ") << " end\n"
    code << "def hash() "  << fields.map {|f|
"self.#{f}.hash" }.join(" ^ ")          << " end\n"
    mod = Module.new
    mod.module_eval( code )
    mod
  end

- Or -

  # Generates identity/key methods based on specified attributes.
  #
  #   equate_on :a, :b
  #
  # _is equivalent to_
  #
  #   def ==(o)
  #     self.a == o.a && self.b == o.b
  #   end
  #
  #   def eql?(o)
  #     self.a.eql?(o.a) && self.b.eql?(o.b)
  #   end
  #
  #   def hash()
  #     self.a.hash ^ self.b.hash
  #   end

  def equate_on(*fields)
    code = ""
    code << "def ==(o) "   << fields.map {|f| "self.#{f} ==
o.#{f}" }.join(" && ")    << " end\n"
    code << "def eql?(o) " << fields.map {|f| "self.#{f}.eql?
(o.#{f})" }.join(" && ") << " end\n"
    code << "def hash() "  << fields.map {|f|
"self.#{f}.hash" }.join(" ^ ")          << " end\n"
    class_eval( code )
    fields
  end

T.

From noreply at rubyforge.org  Wed Mar 12 21:18:24 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 12 Mar 2008 21:18:24 -0400 (EDT)
Subject: [Facets] [ facets-Bugs-18792 ] Enumerable.modulate throws error:
	"undefined local variable or method `level'"
Message-ID: <20080313011824.B63871858617@rubyforge.org>

Bugs item #18792, was opened at 2008-03-12 16:02
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18792&group_id=804

Category: Code
Group: 2.0 +
>Status: Closed
>Resolution: Accepted
>Priority: 2
Submitted By: Dan Bernier (danbernier)
Assigned to: Nobody (None)
>Summary: Enumerable.modulate throws error: "undefined local variable or method `level'"

Initial Comment:
It seems like a simple typo...the method is calling a var/method 'level', which doesn't exist.  I'm guessing the method's parameter, 'modulo', was originally named 'level', and this is a spot that was missed?  Anyway, a fix is included in the attached file.

----------------------------------------------------------------------

>Comment By: 7rans  (transami)
Date: 2008-03-12 20:18

Message:
You are right, modulo was named level. Thanks. Typo fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18792&group_id=804

From noreply at rubyforge.org  Thu Mar 13 19:30:37 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 13 Mar 2008 19:30:37 -0400 (EDT)
Subject: [Facets] [ facets-Bugs-18819 ] Kernel#respond bug
Message-ID: <20080313233037.636F2185866C@rubyforge.org>

Bugs item #18819, was opened at 2008-03-13 16:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18819&group_id=804

Category: Code
Group: 2.0 +
Status: Open
Resolution: None
Priority: 3
Submitted By: Tim Morgan (riscfuture)
Assigned to: Nobody (None)
Summary: Kernel#respond bug

Initial Comment:
Existing source:

  def respond(sym, *args)
    return nil if not respond_to?(sym, *args)
    send(sym, *args)
  end

Corrected source:

  def respond(sym, *args)
    return nil if not respond_to?(sym)
    send(sym, *args)
  end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18819&group_id=804

From noreply at rubyforge.org  Fri Mar 14 14:35:02 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 14 Mar 2008 14:35:02 -0400 (EDT)
Subject: [Facets] [ facets-Bugs-18819 ] Kernel#respond bug
Message-ID: <20080314183502.5156E18585C1@rubyforge.org>

Bugs item #18819, was opened at 2008-03-13 18:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18819&group_id=804

Category: Code
Group: 2.0 +
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Tim Morgan (riscfuture)
Assigned to: Nobody (None)
Summary: Kernel#respond bug

Initial Comment:
Existing source:

  def respond(sym, *args)
    return nil if not respond_to?(sym, *args)
    send(sym, *args)
  end

Corrected source:

  def respond(sym, *args)
    return nil if not respond_to?(sym)
    send(sym, *args)
  end



----------------------------------------------------------------------

>Comment By: 7rans  (transami)
Date: 2008-03-14 13:35

Message:
Fixed. Thanks.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18819&group_id=804

From noreply at rubyforge.org  Fri Mar 14 15:06:04 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 14 Mar 2008 15:06:04 -0400 (EDT)
Subject: [Facets] [ facets-Bugs-18841 ] The "modulate" method has a bug --
	refers to unbound variable
Message-ID: <20080314190605.0E660185868E@rubyforge.org>

Bugs item #18841, was opened at 2008-03-14 15:06
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18841&group_id=804

Category: Code
Group: 2.0 +
Status: Open
Resolution: None
Priority: 3
Submitted By: Nick Caruso (nzc)
Assigned to: Nobody (None)
Summary: The "modulate" method has a bug -- refers to unbound variable

Initial Comment:
If you try to run it, you get an error complaining about an undefined variable "level".  Inspection of the code reveals this to be an edit-o -> the name "level" should be replaced with "modulo".  This is in the Enumerable module.



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18841&group_id=804

From noreply at rubyforge.org  Sun Mar 16 18:33:12 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 16 Mar 2008 18:33:12 -0400 (EDT)
Subject: [Facets] [ facets-Bugs-18872 ] Bugfix for Dictionary#all? #any? on
	Ruby 1.9
Message-ID: <20080316223312.5136418586A5@rubyforge.org>

Bugs item #18872, was opened at 2008-03-16 23:33
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18872&group_id=804

Category: Code
Group: None
Status: Open
Resolution: None
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.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=18872&group_id=804

From transfire at gmail.com  Wed Mar 19 16:42:50 2008
From: transfire at gmail.com (Trans)
Date: Wed, 19 Mar 2008 13:42:50 -0700 (PDT)
Subject: [Facets] [ facets-Bugs-18872 ] Bugfix for Dictionary#all? #any?
	on Ruby 1.9
In-Reply-To: <20080316223312.5136418586A5@rubyforge.org>
References: <20080316223312.5136418586A5@rubyforge.org>
Message-ID: <f04d4807-727e-45e0-94fa-f1b4f67f9f83@d62g2000hsf.googlegroups.com>


On Mar 16, 6:33 pm, <nore... at rubyforge.org> wrote:
> 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.

Patch seems to be missing. Can you drop it into the Google Group files
section, that worked well before.

Thanks,
T.

From transfire at gmail.com  Wed Mar 19 17:05:56 2008
From: transfire at gmail.com (Trans)
Date: Wed, 19 Mar 2008 14:05:56 -0700 (PDT)
Subject: [Facets] Next Facets Release
Message-ID: <8044caf0-9d80-430f-b66e-6eb08bb308f9@a1g2000hsb.googlegroups.com>

Hi all--

The next release of Facets is going very well (for a change). I've
worked it out so it will be more compatible with 2.3.x then I thought
in my last pot. So I'm satisfied to release it as 2.4. And if things
go smooth tonight, I may even be able to release it tomorrow. Yea!

While I still have a few minor things left to work on, the last major
question I have is concerning the Console namespace. I'm wondering if
I should bother with it or not. Currently I have:

  Console::ANSICode
  Console::Command
  Console::Arguments
  Console::Logger
  Console::ProgressBar
  Console::Downloader

However the first is aliased as just ANSICode too, b/c people are used
to that.

Command and Arguments are command line interface parsers. Logger is a
subclass of Ruby's Logger that adds ANSICodes, and Downloader uses the
ProgressBar. So that's why they are "Console" libs.

Some points of consideration:

* It feels odd to have this namespace b/c it is the ONLY one in
Facets.
* Console::Arguments was once (and could be) named ArgVector.
* Not sure what to name Logger w/o the namespace.
* Same for Command, though maybe Command is okay as is.
* I wonder if it makes more sense to split these off into their own
separate project instead?

If you have any thoughts on this, please let me know. It will help me
get this release out faster.

Thanks,
T.

From transfire at gmail.com  Wed Mar 19 18:26:11 2008
From: transfire at gmail.com (Trans)
Date: Wed, 19 Mar 2008 15:26:11 -0700 (PDT)
Subject: [Facets] Core Kernel Methods?
In-Reply-To: <D53FF13B-020D-4E4E-B216-614395645D61@phrogz.net>
References: <623741a0-5dad-44d1-b127-8206187a42fc@m34g2000hsc.googlegroups.com>
	<D53FF13B-020D-4E4E-B216-614395645D61@phrogz.net>
Message-ID: <1a39ad07-b709-4910-9672-046e6a6c0a7c@e60g2000hsh.googlegroups.com>



On Mar 10, 11:08 pm, Gavin Kistner <!... at phrogz.net> wrote:
> On Mar 10, 2008, at 10:50 AM, Trans wrote:
>
> >    # Is self included in other?
>
> I vote yes to this.
>
> >    # Return object after running block.
>
> I vote yes to this.
>
> >    alias_method :with, :returning
>
> I vote no to this. I love the name 'with' far more than 'returning',
> but I personally use it for instance_eval; I don't think it  makes
> sense in the 'yield' usage.

I took your advice up to here with the exception of #with b/c I'd
didn't understand what you meant by using it for instance_eval. Could
you elaborate?

> >    # Like #p but gives file and line number.
>
> On the one hand, this is a rather generic name and debug-centric.
> On the other hand, it's in Kernel, and as such any name 'conflict'
> would be resolved in the lower usage, so it shouldn't be an issue.
>
> I abstain on this one :)

I'm went ahead and included it.

Thanks, your input was helpful.
T.


From ! at phrogz.net  Wed Mar 19 23:33:55 2008
From: ! at phrogz.net (Gavin Kistner)
Date: Wed, 19 Mar 2008 21:33:55 -0600
Subject: [Facets] Core Kernel Methods?
In-Reply-To: <1a39ad07-b709-4910-9672-046e6a6c0a7c@e60g2000hsh.googlegroups.com>
References: <623741a0-5dad-44d1-b127-8206187a42fc@m34g2000hsc.googlegroups.com>
	<D53FF13B-020D-4E4E-B216-614395645D61@phrogz.net>
	<1a39ad07-b709-4910-9672-046e6a6c0a7c@e60g2000hsh.googlegroups.com>
Message-ID: <D03A7C60-1FF7-48E6-A163-283C541250BB@phrogz.net>

On Mar 19, 2008, at 4:26 PM, Trans wrote:
> On Mar 10, 11:08 pm, Gavin Kistner <!... at phrogz.net> wrote:
>> On Mar 10, 2008, at 10:50 AM, Trans wrote:
>>>   alias_method :with, :returning
>>
>> I vote no to this. I love the name 'with' far more than 'returning',
>> but I personally use it for instance_eval; I don't think it  makes
>> sense in the 'yield' usage.
>
> I took your advice up to here with the exception of #with b/c I'd
> didn't understand what you meant by using it for instance_eval. Could
> you elaborate?

The word 'with' makes me think the following would work:

   class Foo; def bar; end; end
   with( Foo.new ){
     bar
   }

That's what I mean by instance_eval. For example, that's what the  
'with' statement does in JavaScript:
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Object_Manipulation_Statements#with_Statement

As I understood it, the 'returning' method doesn't instance_eval, and  
so I think that a straight alias of 'with' is inappropriate.



From transfire at gmail.com  Thu Mar 20 01:09:19 2008
From: transfire at gmail.com (Trans)
Date: Thu, 20 Mar 2008 01:09:19 -0400
Subject: [Facets] Core Kernel Methods?
In-Reply-To: <D03A7C60-1FF7-48E6-A163-283C541250BB@phrogz.net>
References: <623741a0-5dad-44d1-b127-8206187a42fc@m34g2000hsc.googlegroups.com>
	<D53FF13B-020D-4E4E-B216-614395645D61@phrogz.net>
	<1a39ad07-b709-4910-9672-046e6a6c0a7c@e60g2000hsh.googlegroups.com>
	<D03A7C60-1FF7-48E6-A163-283C541250BB@phrogz.net>
Message-ID: <4b6f054f0803192209t44220ce6pa91efe8981445e5d@mail.gmail.com>

On Wed, Mar 19, 2008 at 11:33 PM, Gavin Kistner <!@phrogz.net> wrote:
> On Mar 19, 2008, at 4:26 PM, Trans wrote:
>  > On Mar 10, 11:08 pm, Gavin Kistner <!... at phrogz.net> wrote:
>  >> On Mar 10, 2008, at 10:50 AM, Trans wrote:
>
> >>>   alias_method :with, :returning
>  >>
>  >> I vote no to this. I love the name 'with' far more than 'returning',
>  >> but I personally use it for instance_eval; I don't think it  makes
>  >> sense in the 'yield' usage.
>  >
>  > I took your advice up to here with the exception of #with b/c I'd
>  > didn't understand what you meant by using it for instance_eval. Could
>  > you elaborate?
>
>  The word 'with' makes me think the following would work:
>
>    class Foo; def bar; end; end
>    with( Foo.new ){
>      bar
>    }
>
>  That's what I mean by instance_eval. For example, that's what the
>  'with' statement does in JavaScript:
>  http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Object_Manipulation_Statements#with_Statement
>
>  As I understood it, the 'returning' method doesn't instance_eval, and
>  so I think that a straight alias of 'with' is inappropriate.

Ah... yes I see. I agree.

Thanks,
T.

From transfire at gmail.com  Mon Mar 24 20:19:38 2008
From: transfire at gmail.com (Trans)
Date: Mon, 24 Mar 2008 17:19:38 -0700 (PDT)
Subject: [Facets] Next Facets Release
In-Reply-To: <8044caf0-9d80-430f-b66e-6eb08bb308f9@a1g2000hsb.googlegroups.com>
References: <8044caf0-9d80-430f-b66e-6eb08bb308f9@a1g2000hsb.googlegroups.com>
Message-ID: <6f302475-eeeb-4225-93cb-3971bed62f40@e60g2000hsh.googlegroups.com>



On Mar 19, 5:05 pm, Trans <transf... at gmail.com> wrote:
> Hi all--
>
> The next release of Facets is going very well (for a change). I've
> worked it out so it will be more compatible with 2.3.x then I thought
> in my last pot. So I'm satisfied to release it as 2.4. And if things
> go smooth tonight, I may even be able to release it tomorrow. Yea!
>
> While I still have a few minor things left to work on, the last major
> question I have is concerning the Console namespace. I'm wondering if
> I should bother with it or not. Currently I have:
>
>   Console::ANSICode
>   Console::Command
>   Console::Arguments
>   Console::Logger
>   Console::ProgressBar
>   Console::Downloader

FYI Ended up with:

 ANSICode
 CLI::Command
 CLI::Arguments
 Logger (extended)
 ProgressBar
 Downloader

T.

From transfire at gmail.com  Mon Mar 24 20:50:25 2008
From: transfire at gmail.com (Trans)
Date: Mon, 24 Mar 2008 17:50:25 -0700 (PDT)
Subject: [Facets] Facets 2.4 -- Spring Release
Message-ID: <4da62642-10b2-48f0-a282-eed922bb8d64@m44g2000hsc.googlegroups.com>

I just released Facets 2.4. This is big improvement over 2.3 --it gets
the organization of the library down to it's simplest form and re-
atomizes much of the core extensions as the should have been, while
improving namespaces for the rest of the library. All in all, this is
what I would have liked 2.0 to have been, but of course, this release
would not have been possible without the lessons learned from 2.0.

Some work remains in order to complete the implementation of the
"philosophy" of this release, but the vast majority of it is in place
and I wanted to get this release out sooner rather than later, so
users could begin getting away from of the quarks that have been fixed
from the previous 2.x releases.

As I mentioned in previous posts, the emphases of the new release is
on using "require 'facets'" when using the core extensions, rather
than cherry-picking. While you can still cherry-pick methods, you have
to keep in mind that others my cherry-pick different methods. Using
"require 'facets'" helps ensure interoperability between libraries
that use Facets.

ActiveSupport and Ruby 1.9 compatibility has been greatly furthered
with this release too, but it's not quite 100% yet. This will be the
major focus of the next few minor releases.

To go along with the 2.4 release, the website has been updated with a
nice new shine. I think you'll like it. Documentation has been
improved to boot. I'm working toward making the documentation more
like a manual. What I currently have in place is about half way
through that process and is now included in the package itself under
doc/html if you'd like to access it locally.

  http://facets.rubyforge.org
  http://facets.rubyforge.org/doc/index.html

Hope you like!
T.

From transfire at gmail.com  Sat Mar 29 10:01:27 2008
From: transfire at gmail.com (Trans)
Date: Sat, 29 Mar 2008 07:01:27 -0700 (PDT)
Subject: [Facets] #populate better name?
Message-ID: <a8258f3a-6b91-4f66-b2fd-772c9312518a@l42g2000hsc.googlegroups.com>

Hi--

Working on some refinements, one that's been bugging me is the name of
#populate --a relatively new name for what was called #set_with. I
felt the use of "with" was poor, so I went with #populate, but I'm not
so sure about that either because it's such a generic word. I'm
looking for something more technical. Any suggestions?

Here's the method in question:

 module Kernel

  # Assign via accessor methods using a hash, associative
  # array or block.
  #
  #   object.populate( :a => 1, :b => 2 )
  #   object.populate( :a, 1, :b, 2 )
  #   object.populate( [:a, 1], [:b, 2] )
  #   object.populate( *[[:a, 1], [:b, 2]] )
  #   object.populate{ |s| s.a = 1; s.b = 2 }
  #
  # These are all the same as doing:
  #
  #   object.a = 1
  #   object.b = 2
  #
  # Using an associative array instead of hash guarentees
  # order of assignment.
  #
  # Using a hash or array will not raise an error if the
  # accessor does not exits --it will simply be skipped.
  #
  # TODO: Better name, #set_with ?

  def populate(data=nil) #:yield:
    if data
      data.each do |k,v|
        send("#{k}=", v) if respond_to?("#{k}=")
      end
    end
    yield(self) if block_given?
    self
  end

 end

Thanks,
T.