[#23657] [Bug #1550] String#lstrip! raises RuntimeError on Frozen String Despite Making No Changes — Run Paint Run Run <redmine@...>

Bug #1550: String#lstrip! raises RuntimeError on Frozen String Despite Making No Changes

13 messages 2009/06/01

[#23729] [Bug #1583] Time + String no Longer Raises TypeError? — Run Paint Run Run <redmine@...>

Bug #1583: Time + String no Longer Raises TypeError?

14 messages 2009/06/05

[#23770] [Bug #1595] rake unusable on windows install — Robert Gonzalez <redmine@...>

Bug #1595: rake unusable on windows install

10 messages 2009/06/09

[#23869] [Bug #1640] [PATCH] Documentation for the Rational Class — Run Paint Run Run <redmine@...>

Bug #1640: [PATCH] Documentation for the Rational Class

12 messages 2009/06/16

[#23903] [Bug #1648] Rational#div Raises NoMethodError for Invalid Argument — Run Paint Run Run <redmine@...>

Bug #1648: Rational#div Raises NoMethodError for Invalid Argument

9 messages 2009/06/17

[#23977] [ANN] meeting log of RubyDeveloperKaigi20090622 — "Yugui (Yuki Sonoda)" <yugui@...>

Hi,

41 messages 2009/06/23
[#23979] Re: [ANN] meeting log of RubyDeveloperKaigi20090622 — Run Paint Run Run <runrun@...> 2009/06/23

Thanks for the update. :-)

[#24173] Re: [ANN] meeting log of RubyDeveloperKaigi20090622 — "NARUSE, Yui" <naruse@...> 2009/07/07

Sorry for late response,

[#24174] Re: [ANN] meeting log of RubyDeveloperKaigi20090622 — Luis Lavena <luislavena@...> 2009/07/07

On Tue, Jul 7, 2009 at 12:12 AM, NARUSE, Yui<naruse@airemix.jp> wrote:

[#24242] Re: [ANN] meeting log of RubyDeveloperKaigi20090622 — Charles Oliver Nutter <headius@...> 2009/07/09

On Mon, Jul 6, 2009 at 10:18 PM, Luis Lavena<luislavena@gmail.com> wrote:

[#24010] [Bug #1685] Some windows unicode path issues remain — B Kelly <redmine@...>

Bug #1685: Some windows unicode path issues remain

26 messages 2009/06/24
[#29189] [Bug #1685] Some windows unicode path issues remain — Yuki Sonoda <redmine@...> 2010/04/01

Issue #1685 has been updated by Yuki Sonoda.

[#29200] Re: [Bug #1685] Some windows unicode path issues remain — Bill Kelly <billk@...> 2010/04/01

Yuki Sonoda wrote:

[#29892] Re: [Bug #1685] Some windows unicode path issues remain — Bill Kelly <billk@...> 2010/04/29

Hi,

[#24058] [Bug #1696] http downloads are unuseably slow — Steven Hartland <redmine@...>

Bug #1696: http downloads are unuseably slow

19 messages 2009/06/27

[#24063] [Feature #1697] Object#<=> — Marc-Andre Lafortune <redmine@...>

Feature #1697: Object#<=>

15 messages 2009/06/28

[ruby-core:23667] Re: [Bug #1545] Patches for the Hash Documentation

From: Run Paint Run Run <runrun@...>
Date: 2009-06-02 01:22:37 UTC
List: ruby-core #23667
On Sun, May 31, 2009 at 12:10 PM, Eero Saynatkari
<ruby-ml@kittensoft.org> wrote:
[deletia]
>> I've attached a couple of patches against hash.c to fix minor documentation
>> typos. The 7th is an attempt to fix the verbiage regarding the ordering of
>> hashes which states "The order in which you traverse a hash by either key or
>> value may seem arbitrary, and will generally not be in the insertion order."
>> This contradicts the doc/NEWS-1.9.1 file which, correctly, explains "Hash
>> preserves order.  It enumerates its elements in the order in which the keys are
>> inserted." I've tried to use the latter wording as much as possible in my
>> suggested modification.
>
> The wording should maybe *not* be changed? Even though I
> have no doubt that everyone and their mothers will rely on
> insertion order in the future, it is specified that it is
> implementation-specific behaviour. (In my mind, using it
> implies Hash being the wrong data structure, but that is
> naturally debatable.)

It was my impression that hashes preserving insertion order was
considered a feature, as opposed to an implementation detail, so we
probably need clarification on this point.

> Of course, if we view the RDoc as strictly applying to MRI
> only, it is fine to change...a small mention of possible
> unportability is OK in that case. But I am not sure if it
> is feasible to make that assumption.

I hadn't considered that as being an aim for the RDoc. Again, we need
clarification, I suppose.

Regardless, even if new wording is not added to describe the new
ordering, do we agree that we cannot continue to describe "the order
in which you traverse a hash" as "arbitrary" and "generally
not...in...insertion order."? :-)

-- 
Run Paint Run Run

In This Thread