[#24648] [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Run Paint Run Run <redmine@...>

Bug #1852: Enumerable's #hash Raises ArgumentError When Recursive Values are Present

20 messages 2009/08/01
[#24649] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Tanaka Akira <akr@...> 2009/08/01

In article <4a73e51b5a4f9_138119f2a982704e@redmine.ruby-lang.org>,

[#24652] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Run Paint Run Run <runrun@...> 2009/08/01

> Is it valuable to implement such function?

[#24682] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Tanaka Akira <akr@...> 2009/08/02

In article <67e307490908010125r6fa76654pa8e2224f714588fc@mail.gmail.com>,

[#24673] [Feature #1857] install *.h and *.inc — Roger Pack <redmine@...>

Feature #1857: install *.h and *.inc

21 messages 2009/08/01

[#24732] [Bug #1873] MatchData#[]: Omits All But Last Captures Corresponding to the Same Named Group — Run Paint Run Run <redmine@...>

Bug #1873: MatchData#[]: Omits All But Last Captures Corresponding to the Same Named Group

12 messages 2009/08/03

[#24775] [Feature #1889] Teach Onigurma Unicode 5.0 Character Properties — Run Paint Run Run <redmine@...>

Feature #1889: Teach Onigurma Unicode 5.0 Character Properties

30 messages 2009/08/05

[#24786] [Bug #1893] Recursive Enumerable#join is surprising — Jeremy Kemper <redmine@...>

Bug #1893: Recursive Enumerable#join is surprising

24 messages 2009/08/06
[#28422] [Bug #1893] Recursive Enumerable#join is surprising — Yusuke Endoh <redmine@...> 2010/03/02

Issue #1893 has been updated by Yusuke Endoh.

[#28438] Re: [Bug #1893] Recursive Enumerable#join is surprising — Yukihiro Matsumoto <matz@...> 2010/03/03

Hi,

[#24854] embedding ruby 1.9 frustration — Rolando Abarca <funkaster@...>

Hello,

12 messages 2009/08/10

[#24982] [Feature #1961] Kernel#__dir__ — Yutaka HARA <redmine@...>

Feature #1961: Kernel#__dir__

26 messages 2009/08/19
[#28898] [Feature #1961] Kernel#__dir__ — Roger Pack <redmine@...> 2010/03/23

Issue #1961 has been updated by Roger Pack.

[#28900] Re: [Feature #1961] Kernel#__dir__ — Kornelius Kalnbach <murphy@...> 2010/03/23

On 23.03.10 19:10, Roger Pack wrote:

[#25025] [Backport #1975] Backport Dir.mktmpdir — Kirk Haines <redmine@...>

Backport #1975: Backport Dir.mktmpdir

12 messages 2009/08/21

[#25041] Proposal: Simpler block format — Yehuda Katz <wycats@...>

I'd like to propose that we add the following syntax for procs in Ruby:

45 messages 2009/08/23
[#25046] Re: Proposal: Simpler block format — Caleb Clausen <caleb@...> 2009/08/23

Yehuda Katz wrote:

[#25049] Re: Proposal: Simpler block format — Yehuda Katz <wycats@...> 2009/08/23

On Sat, Aug 22, 2009 at 7:38 PM, Caleb Clausen <caleb@inforadical.net>wrote:

[#25058] Re: Proposal: Simpler block format — Yukihiro Matsumoto <matz@...> 2009/08/23

Hi,

[#25059] Re: Proposal: Simpler block format — Yehuda Katz <wycats@...> 2009/08/23

On Sun, Aug 23, 2009 at 3:33 PM, Yukihiro Matsumoto <matz@ruby-lang.org>wrote:

[#25063] Re: Proposal: Simpler block format — "David A. Black" <dblack@...> 2009/08/23

Hi --

[#25068] Re: Proposal: Simpler block format — brian ford <brixen@...> 2009/08/24

Hi,

[#25086] [Bug #1991] ruby should use twolevel namespace on OS X — Michal Suchanek <redmine@...>

Bug #1991: ruby should use twolevel namespace on OS X

12 messages 2009/08/24

[#25208] Module#prepend and Array#prepend — Yehuda Katz <wycats@...>

Matz,

23 messages 2009/08/30

[#25210] [Feature #2022] Patch for ruby-1.8.6 and openssl-1.0 — Jeroen van Meeuwen <redmine@...>

Feature #2022: Patch for ruby-1.8.6 and openssl-1.0

15 messages 2009/08/30

[#25220] [Bug #2026] String encodings are not supported by most of IO on Linux — Vit Ondruch <redmine@...>

Bug #2026: String encodings are not supported by most of IO on Linux

18 messages 2009/08/31

[ruby-core:25153] Re: [Feature #1889] Teach Onigurma Unicode 5.0 Character Properties

From: "Martin J. Dürst" <duerst@...>
Date: 2009-08-27 04:05:34 UTC
List: ruby-core #25153
In this context, please also see 
http://www.unicode.org/mail-arch/unicode-ml/y2009-m08/0207.html, which 
says (From: announcements@unicode.org; Date: Wed Aug 26 2009 - 19:48:45 
CDT):

 >>>>
The data files in the Unicode Character Database for Unicode 5.2 have
been revised to include all of the authorized changes from the last UTC
meeting. If you use any of the Unicode data in your implementations,
please update a test version of your implementation to use those files
and run your tests. If there are any showstopper bugs, please report
them (using http://www.unicode.org/reporting.html) as soon as possible.

  From this point, the only adjustments that will be made to the data
will be on the basis of showstopper bugs, including bugs uncovered in
the process of updating the Unicode Collation data files for UCA 5.2.
 >>>>

This means:
a) Unicode 5.2 is close to being ready for release in October.
b) Implementations (such as Ruby) should test the data.

Regards,   Martin.


On 2009/08/26 19:39, Martin J. D端rst wrote:
> Hello Yui, others,
>
> [I'd really like to hear from Yugui, because she is responsible for
> 1.9.1 and 1.9.2.]
>
> On 2009/08/26 18:46, Yui NARUSE wrote:
>> Issue #1889 has been updated by Yui NARUSE.
>>
>>
>> I see.
>> ruby_1_9_2 release branch will be created sooner.
>
> Good point. According to [ruby-core:23977], there is a feature freeze on
> Sept. 25. The release of Unicode 5.2 (final!) is planned for October
> 2009 (see to http://www.unicode.org/versions/beta.html).
>
> [My personal guess is that this might happen in the week of October 12,
> you can guess the reason for why I guess this date at
> http://www.unicodeconference.org/. This would be before release
> candidate 1 of 1.9.2.]
>
> Last year, additions of transcodings (in essence just more data) were
> allowed even after the feature freeze. In my view, moving to the latest
> stable Unicode data version is very similar. Another way to think about
> it is that it's possible to include Unicode 5.2 beta in 1.9.2 while
> 1.9.2 is not yet final. This runs the risk that we have to move back
> from Unicode 5.2 to Unicode 5.1 if Unicode 5.2 doesn't go final before
> December or so, but I consider this risk very low (the Unicode
> consortium has an extremely well established release process). On the
> other hand, I consider the fact that a final Ruby release contains the
> latest stable Unicode data a big plus, both for usage and for
> 'marketing'. Also, if I were the maintainer of one of the 'earlier'
> branches, I would try to follow stable Unicode versions, too.
>
> So my proposal would be:
> - Stay with Unicode 5.1 to allow maintainers of 1.9.1 (and below) to
> update to latest stable Unicode version.
> - Move to Unicode 5.2 (beta) for trunk and 1.9.2.
> - Update trunk (and 1.9.2) whenever Unicode 5.2 (beta) gets updated.
> - Update trunk (and 1.9.2, 1.9.1 (and below)) to Unicode 5.2 when
> Unicode 5.2 goes final.
>
> My main concern currently would be that, as far as I understand, not all
> properties are currently automatically updated. But I think that can be
> fixed by September 25th.
>
> Regards, Martin.
>
>> ----------------------------------------
>> http://redmine.ruby-lang.org/issues/show/1889
>>
>> ----------------------------------------
>> http://redmine.ruby-lang.org
>

-- 
#-# Martin J. D端rst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

In This Thread