[#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:25102] Re: [Backport #1975] Backport Dir.mktmpdir

From: Urabe Shyouhei <shyouhei@...>
Date: 2009-08-24 18:58:27 UTC
List: ruby-core #25102
Kirk Haines wrote:
> That distinction is somewhat blurry, though.  Some of the bugfixes
> have introduced implicit behavioral changes, and IMHO, that is OK so
> long as the behavioral change is required to fix the bug, or is more
> correct (as in some of the recent fixes with handling of Bignums,
> infinity, etc....).

I strongly agree with this.  I wrote it before but "to fix a bug is to change
something".  Bugfixes and behavioral changes are sometimes distinguishable, but
not always.  On really delicate situations, I don't know a way to say which.
That's one of a reason for me to believe Kirk on his decision; I may not have
other tactics than that.

> In general, I'm not adopting new features from
> 1.8.7, but where there is something that won't break existing code
> that depends on 1.8.6, and where there's an arguable benefit to
> backporting something that has already percholated through 1.8 HEAD
> and 1.8.7, I don't see harm in allowing that capability to fall
> through to 1.8.6.  There are a lot of changes that can't easily move
> from 1.8.7 to 1.8.6 because of larger, fundamental changes to the
> code.  In the case of Dir.mktmpdir, which is just a pure ruby addition
> to a class, and doesn't have a larger API that goes with it, I don't
> see a problem, especially since it, in turn, simplifies the test case
> code in at least two instances.

It's *my* preference when I was the 1.8.6 mentor, but if a change itself isn't
a bugfix, I might leave it unapplied.  That's the policy Tanaka-san stated as
"No new feature".  I analyzed myself and now I think it's because I think
people should move to a newer ruby in a long term.  More radically speaking, I
believe no new scripts should be written targeted to 1.8.6.  1.8.6 is for those
scripts that has already been written for it.  From that point, non-bugfix
changes aren't welcomed because I want to encourage people NOT to write a
script for 1.8.6.

> Contrast this with String#start_with?. That is also being used by the
> test_file_exhaustive.rb test set, but I won't consider backporting it
> because it is a far larger change that lives in the context of a
> number of other String class changes which are unlikely to be truly
> backwards compatible with existing 1.8.6 behavior.  1.8.6 should not
> mirror 1.8.7, because, IMHO, the progression in the 1.8 and 1.9 lines
> should encourage people to eventually move to those versions because
> of the advancements to be found there, but there are still a large
> number of people entrenched in 1.8.6, so modest refinements which can
> be backported without risk of breaking someone's code, and which offer
> some other tangible advantage, should be considered.

So policy differences between you and me is due to our difference in standing
points.  I want to make this world as ideal as I dream, while you have more
realistic point of view that this world is not as ideal as I dream.  People are
still living on top of 1.8.6.  It's true.  And we decided to let you manage
1.8.6.  The policy difference is easy to accept once I know this point.

> I am completely open to discussion regarding my perspective, though.
> If anyone thinks I should have a different policy, please speak up and
> tell me why.

I don't think you should have one.  What I wrote in this mail is I have a
different one.  Follow the path you believe.

Attachments (1)

signature.asc (260 Bytes, application/pgp-signature)

In This Thread