[#10492] Ruby 1.8.6 preview3 has been released — "Akinori MUSHA" <knu@...>

Hi,

26 messages 2007/03/04
[#10500] Re: Ruby 1.8.6 preview3 has been released — Hugh Sasse <hgs@...> 2007/03/05

On Mon, 5 Mar 2007, Akinori MUSHA wrote:

[#10507] Dynamic Array#join with block — <noreply@...>

Patches item #9055, was opened at 2007-03-05 19:57

12 messages 2007/03/05
[#10520] Re: [ ruby-Patches-9055 ] Dynamic Array#join with block — Nobuyoshi Nakada <nobu@...> 2007/03/06

Hi,

[#10594] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org>

In ext/thread/thread.c, remove_one leaves the list in an inconsistent state.

15 messages 2007/03/14
[#10596] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 00:15:57 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10597] Re: [PATCH] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/14

> > The fix is in thread-mutex-remove_one.diff.

[#10598] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 01:19:04 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10599] Re: [PATCH] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/14

On Wednesday 14 March 2007 17:29, MenTaLguY wrote:

[#10600] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 01:48:42 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10615] Multiton in standard library — TRANS <transfire@...>

Hi--

16 messages 2007/03/15
[#10619] Re: Multiton in standard library — Tom Pollard <tomp@...> 2007/03/16

[#10620] Re: Multiton in standard library — TRANS <transfire@...> 2007/03/16

On 3/15/07, Tom Pollard <tomp@earthlink.net> wrote:

[#10646] Marshal.dump shouldn't complain about singletons if the _dump method is defined — <noreply@...>

Bugs item #9376, was opened at 2007-03-19 15:58

12 messages 2007/03/19
[#10647] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Urabe Shyouhei <shyouhei@...> 2007/03/19

noreply@rubyforge.org wrote:

[#10648] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/19

On Monday 19 March 2007 18:01, Urabe Shyouhei wrote:

[#10651] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Yukihiro Matsumoto <matz@...> 2007/03/19

Hi,

[#10665] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — "Chris Carter" <cdcarter@...> 2007/03/20

On 3/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#10712] Ruby Method Signatures (was Re: Multiton in standard library) — "Rick DeNatale" <rick.denatale@...>

On 3/19/07, TRANS <transfire@gmail.com> wrote:

10 messages 2007/03/21
[#10715] Re: Ruby Method Signatures (was Re: Multiton in standard library) — Jos Backus <jos@...> 2007/03/22

On 3/19/07, TRANS <transfire@gmail.com> wrote:

[#10798] Virtual classes and 'real' classes -- why? — "John Lam (CLR)" <jflam@...>

I was wondering if someone could help me understand why there's a parallel =

12 messages 2007/03/28
[#10799] Re: Virtual classes and 'real' classes -- why? — MenTaLguY <mental@...> 2007/03/28

On Thu, 29 Mar 2007 04:44:16 +0900, "John Lam (CLR)" <jflam@microsoft.com> wrote:

Re: [ ruby-Bugs-8384 ] Discrepancy between GetoptLong.new and documentation

From: "Berger, Daniel" <Daniel.Berger@...>
Date: 2007-03-21 18:09:38 UTC
List: ruby-core #10702
> -----Original Message-----
> From: noreply@rubyforge.org [mailto:noreply@rubyforge.org] 
> Sent: Wednesday, March 21, 2007 12:02 PM
> To: ruby-core@ruby-lang.org
> Subject: [ ruby-Bugs-8384 ] Discrepancy between 
> GetoptLong.new and documentation
> 
> 
> Bugs item #8384, was opened at 2007-02-02 10:06
> You can respond by visiting: 
> http://rubyforge.org/tracker/?func=detail&atid=1698&aid=8384&g
> roup_id=426
> 
> Category: Standard Library
> Group: 1.8.5
> Status: Open
> Resolution: None
> Priority: 3
> Submitted By: Roel Harbers (rharbers)
> Assigned to: Nobody (None)
> Summary: Discrepancy between GetoptLong.new and documentation
> 
> Initial Comment:
> According to the documentation for getoptlong.rb, the 
> GetoptLong.new method requires an array of arrays to be passed:
> 
>   # The options to support are passed to new() as an array of arrays.
>   # Each sub-array contains any number of String option names 
> which carry 
>   # the same meaning, and one of the following flags:
> 
> However, this code fails:
>   require 'getoptlong'
>   options = GetoptLong.new(
>     [
>       ['-a', GetoptLong::NO_ARGUMENT],
>       ['-b', GetoptLong::NO_ARGUMENT],
>     ]
>   )
> 
> This works:
>   require 'getoptlong'
>   options = GetoptLong.new(
>     ['-a', GetoptLong::NO_ARGUMENT],
>     ['-b', GetoptLong::NO_ARGUMENT]
>   )
> 
> Either the documentation could be fixed, or the call could 
> accept an array of arrays. Personally, I prefer the latter, 
> since it allows something like this:
> 
>   options = GetoptLong.new(
>     [
>       ['-a', GetoptLong::NO_ARGUMENT],
>       ['-b', GetoptLong::NO_ARGUMENT],
> #     ['--debug', GetoptLong::NO_ARGUMENT],
>     ]
>   )
> 
> which the other form does not allow without removing the 
> comma from the -b line too.
> 
> I made a patch againt 1.8.5 that lets set_options (and by 
> extension initialize) accept both forms.
> 
> What do you people think?
> 
> ----------------------------------------------------------------------
> 
> >Comment By: Roel Harbers (rharbers)
> Date: 2007-03-21 19:01
> 
> Message:
> Anyone? class? Bueller?

Wait - people actually use that module? :-P

But seriously, I think either way is fine - i.e. fix the docs, or allow
the explicitly nested arrays.

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.


In This Thread