[#15707] Schedule for the 1.8.7 release — "Akinori MUSHA" <knu@...>

Hi, developers,

21 messages 2008/03/01

[#15740] Copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

31 messages 2008/03/03
[#15742] Re: Copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/03/03

Hi,

[#15829] Re: Copy-on-write friendly garbage collector — Daniel DeLorme <dan-ml@...42.com> 2008/03/08

Yukihiro Matsumoto wrote:

[#15756] embedding Ruby 1.9.0 inside pthread — "Suraj Kurapati" <sunaku@...>

Hello,

18 messages 2008/03/03
[#15759] Re: embedding Ruby 1.9.0 inside pthread — Nobuyoshi Nakada <nobu@...> 2008/03/04

Hi,

[#15760] Re: embedding Ruby 1.9.0 inside pthread — Yukihiro Matsumoto <matz@...> 2008/03/04

Hi,

[#15762] Re: embedding Ruby 1.9.0 inside pthread — "Suraj N. Kurapati" <sunaku@...> 2008/03/04

Yukihiro Matsumoto wrote:

[#15783] Adding startup and shutdown to Test::Unit — Daniel Berger <Daniel.Berger@...>

Hi all,

15 messages 2008/03/04

[#15835] TimeoutError in core, timeouts for ConditionVariable#wait — MenTaLguY <mental@...>

I've been reworking JRuby's stdlib to improve performance and fix

10 messages 2008/03/09

[#15990] Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...>

Hi,

35 messages 2008/03/23
[#15991] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#15993] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/23

Hi Dave,

[#15997] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/23

[#16024] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

Hi Dave,

[#16025] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16026] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16027] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16029] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16030] Re: Recent changes in Range#step behavior — Yukihiro Matsumoto <matz@...> 2008/03/26

Hi,

[#16031] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16032] Re: Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...> 2008/03/26

On Wed, Mar 26, 2008 at 7:01 PM, Dave Thomas <dave@pragprog.com> wrote:

[#16033] Re: Recent changes in Range#step behavior — Dave Thomas <dave@...> 2008/03/26

[#16041] Re: Recent changes in Range#step behavior — David Flanagan <david@...> 2008/03/26

Dave Thomas wrote:

Evaluation order of block pass versus arguments

From: Charles Oliver Nutter <charles.nutter@...>
Date: 2008-03-22 20:06:15 UTC
List: ruby-core #15981
I was writing up some specs for evaluation order today and discovered 
something rather interesting:

   before :each do
     @obj = Object.new
     def @obj.foo(a, b, &c)
       [a, b, c ? c.call : nil]
     end
   end

   it "evaluates block pass before arguments" do
     a = 0
     p = proc {true}
     @obj.foo(a += 1, a += 1, &(a += 1; p)).should == [2, 3, true]
     a.should == 3
   end

   it "evaluates block pass before receiver" do
     p1 = proc {true}
     p2 = proc {false}
     p1.should_not == p2

     p = p1
     (p = p2; @obj).foo(1, 1, &p).should == [1, 1, true]
   end

This was unexpected for me. Argument order being left-to-right seems 
reasonable, and I think it's what most people would expect looking at 
the code. But having the block pass argument evaluated not only before 
the other args but before the receiver seems broken.

Unlike Ruby 1.8, Ruby 1.9 and JRuby behave the same, with the order 
being exactly what you'd expect:

CODE
obj = Object.new
def obj.foo(a, b, &c)
   [a, b, c ? c.call : nil]
end
pr = proc {3}
p ((p 'a'; obj).foo((p 'b'; 1), (p 'c'; 2), &(p 'd'; pr)))"
Ruby 1.8:
"d"
"a"
"b"
"c"
[1, 2, 3]

Ruby 1.9:
"a"
"b"
"c"
"d"
[1, 2, 3]

JRuby:
"a"
"b"
"c"
"d"
[1, 2, 3]

Rubinius still evaluates arguments in reverse order, and then evaluates 
block pass after the arguments but before the receiver. I believe this 
is being "fixed", but at the moment it's the most unexpected behavior of 
the four:

"c"
"b"
"d"
"a"
[1, 2, 3]

- Charlie

In This Thread

Prev Next