[#11439] comments needed for Random class — "NAKAMURA, Hiroshi" <nakahiro@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2007/06/12

[#11450] Re: new method dispatch rule (matz' proposal) — David Flanagan <david@...>

This is a late response to the very long thread that started back in

17 messages 2007/06/13

[#11482] Ruby Changes Its Mind About Non-Word Characters — James Edward Gray II <james@...>

Does this look like a bug to anyone else?

10 messages 2007/06/16

[#11505] Question about the patchlevel release cycle — Sylvain Joyeux <sylvain.joyeux@...4x.org>

1.8.6 thread support was broken in bad ways. It stayed for three months

20 messages 2007/06/20
[#11512] Re: Question about the patchlevel release cycle — Urabe Shyouhei <shyouhei@...> 2007/06/20

Hi, I'm the 1.8.6 branch manager.

[#11543] Re: Apple reportedly to ship with ruby 1.8.6-p36 unless informed what to patch — James Edward Gray II <james@...>

On Jun 27, 2007, at 4:47 PM, Bill Kelly wrote:

10 messages 2007/06/27

[BUG] delete_if with destructive methods in block

From: Florian Gross <florgro@...>
Date: 2007-06-29 02:10:25 UTC
List: ruby-core #11556
Hi,

Here's some odd Hash#delete_if behaviour:

h = {1 => 2, 3 => 4, 5 => 6}
h.delete_if do |*a|
  p a
  h.shift

  p h
  puts

  true
end

It outputs the following:

[5, 6]
{1=>2, 3=>4}

[5]
{3=>4}

[3, 4]
{}

[3]
{}

The same behaviour can be produced by replacing h.shift with
h.delete(h.keys.first).

It happens for me on ruby 1.9.0 (2007-04-02 patchlevel 0) and ruby
1.8.4 (2005-12-24).

I'm not sure why this happens instead of a hash modified during
iteration exception being raised.

Kind regards,
Florian Gross


In This Thread

Prev Next