Module.new(&block) in Ruby 1.9

[murphy]

Hello!

This pattern doesn't work 1.9:

def new_module(&block)
Module.new(&block)
end

mod = new_module do
def foo
end
end

Ruby 1.8:

mod.instance_methods # => ["foo"]

Ruby 1.9:

mod.instance_methods # => []

The change broke Rails' fascinating association proxy extensions. I
assumed Module.new was changed, but calling it directly with a block of
method definitions works as expected in Ruby 1.9:

mod = Module.new do
def foo
end
end

mod.instance_methods # => [:foo]

Bug or feature?
[murphy]

[Cheah Chu Yeow]

This looks like a related bug with passing block arguments to
#module_eval (and #module_exec) mentioned here:
http://www.ruby-forum.com/topic/136456

Still hasn't been fixed as of yesterday (r14798).

Cheers,
Chu Yeow

PS. I'm new to this - is there a bug tracker for ruby where I can
track the progress of bugs?

--
Chu Yeow

[murphy]

Cheah Chu Yeow wrote:
> This looks like a related bug with passing block arguments to
> #module_eval (and #module_exec) mentioned here:
> http://www.ruby-forum.com/topic/136456
>
> Still hasn't been fixed as of yesterday (r14798).

ah, thanks for spotting that this was the same thing. I didn't search
properly. sorry :)
[murphy]

[SASADA Koichi]

Hi,

This issue is in bootstraptest/pending.rb. I'll fix until next
release. On current VM structure, it's hard to fix. So, I must
change VM frame stack structure for this issue. sigh.

--
// SASADA Koichi at atdot dot net

[ts]

>>>>> "S" == SASADA Koichi <k...@atdot.net> writes:

S> This issue is in bootstraptest/pending.rb. I'll fix until next
S> release. On current VM structure, it's hard to fix. So, I must
S> change VM frame stack structure for this issue. sigh.

Well, I'll surely say a stupidity but, for this case, this is
iseq->cref_stack which has a problem, no ?

Why no do like blockptr with block.iseq (i.e. a copy of iseq) and change
iseq.cref_stack or do it exist some another problem ?

Guy Decoux

[SASADA Koichi]

Hi,

ah, great! i missed "copying" iseq!

sizeof(iseq) is big, so i'll separate iseq (bytecode information)
and dynamic information such as cref.

Regards,

[Jeremy Kemper]

Hi,

Any progress on this? I checked that it's still unresolved on latest trunk.

This is the only issue blocking Rails compatibility with Ruby 1.9 :)

Best,
jeremy

[Sylvain Joyeux]

On Tue, Apr 01, 2008 at 05:43:34PM +0900, ts wrote:
> Jeremy Kemper wrote:
> > This is the only issue blocking Rails compatibility with Ruby 1.9
>
>

> Well, if I'm right this will give, also, the possibility to resolve
> [ruby-bugs:16493] and [ruby-core:15833]

Event if I did not investigate the issues further, I would not be
surprised if it also fixes

http://rubyforge.org/tracker/?func=detail&aid=18967&group_id=426&atid=1698
http://rubyforge.org/tracker/?func=detail&aid=19304&group_id=426&atid=1698

Sylvain Joyeux

[Sylvain Joyeux]

About bug [#19304]
http://rubyforge.org/tracker/?func=detail&aid=19304&group_id=426&atid=1698

Shyouhei mentionned that it could be an intended behaviour. I really
doubt it, but I wanted to check and hit other bugs of the same flavour
with lambda (see attached file).

So, first question: is it a bug or a feature ?

Second question: if it is a bug, should I submit a new bug for it or is
it better to add it as a follow up for the return-in-method bug ?

Finally, I'm not sure my last mail actually reached the list. Guy: I
wanted to ask you if the tests you did are actually on a patched version
of 1.9 (in which case, could you send it to me ?), or is it that your
build of ruby trunk do not show the issues in question ?

Best regards,
Sylvain

[Sylvain Joyeux]

> > Finally, I'm not sure my last mail actually reached the list. Guy: I
> > wanted to ask you if the tests you did are actually on a patched version
> > of 1.9 (in which case, could you send it to me ?), or is it that your
> > build of ruby trunk do not show the issues in question ?
>

> patched version of ruby : the solution to this problem was given in
> [ruby-core:14791]

OK. Added as a follow-up to the bugreport, along with the implementation
of your suggestion.

And for the 'def in module_eval' issue ? I saw the thread, but frankly
the description of the fix do not speak to me. Since you already have
fixed it, maybe you could provide us with the patch ?

Thanks,
Sylvain

[Sylvain Joyeux]

> > And for the 'def in module_eval' issue ? I saw the thread, but frankly
> > the description of the fix do not speak to me. Since you already have
> > fixed it, maybe you could provide us with the patch ?
>

> I can't because I was lazy on this patch, rather than waiting a
> modified version of rb_iseq_t, in my private version I duplicate it
> even if it's a big structure
Well, I'd rather have a slow, but working version of ruby instead than a
fast buggy one. So, thanks for your input, I'll do the same on my
private version.

Did you actually do some benchmarks for the performance hit ?

Sylvain

[Sylvain Joyeux]

On Tue, Apr 08, 2008 at 09:23:07PM +0900, ts wrote:
> Sylvain Joyeux wrote:
> > Did you actually do some benchmarks for the performance hit ?
>

> A benchmark is just a non-sense, for me, when a program just don't
> work like I want.
We definitely agree on that ...

Sylvain

[Jeremy Kemper]

This is fixed in r16486. Thanks! All Rails tests pass on 1.9 now :)

jeremy