Super not passing init: through to NSObject correctly?
Hi all, I searched a few months of the list archives and trac, but wasn't able to find reference to this. Calling `super` inside of an overridden #init function where no ruby ancestors define #init causes a segmentation fault. If I'm not mistaken, shouldn't the init: message be passed to NSObject? --------------------------------------------------------- class HasInit def init super p 'HasInit' self end end class A < HasInit; end class B < A; end A.new p 'A' B.new p 'B' class HasNoInit; end class C < HasNoInit; end class D < C def init super self end end C.new p 'C' D.new p 'D' --------------------------------------------------------- You should see the segfault happen when trying to init D, but HasInit passes the message through to NSObject just fine, it seems. Tested with the 2009-10-05-1158 nightly. Thanks! --Mike
Thanks for the report, I added your snippet in our test suite. At a glance it looks like an infinite loop in the dispatcher. Definitely a bug :) Laurent On Oct 5, 2009, at 6:37 PM, Michael Shapiro wrote:
Hi all, I searched a few months of the list archives and trac, but wasn't able to find reference to this.
Calling `super` inside of an overridden #init function where no ruby ancestors define #init causes a segmentation fault. If I'm not mistaken, shouldn't the init: message be passed to NSObject?
--------------------------------------------------------- class HasInit def init super p 'HasInit' self end end
class A < HasInit; end
class B < A; end
A.new p 'A' B.new p 'B'
class HasNoInit; end
class C < HasNoInit; end
class D < C def init super self end end
C.new p 'C' D.new p 'D' ---------------------------------------------------------
You should see the segfault happen when trying to init D, but HasInit passes the message through to NSObject just fine, it seems.
Tested with the 2009-10-05-1158 nightly.
Thanks! --Mike _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
What should be the exact output? In Ruby 1.9.1, I see the following output: $ ruby test.rb "A" "B" "C" "D" Note: When <class>.new is called allocate method is called. Then the object's initialize method is called and the instance is returned to the caller. $ macruby test.rb "HasInit" "A" "HasInit" "B" "C" Segmentation fault Now, changing the init methods to initialize, the following output is generated: $ ruby test.rb "HasInit" "A" "HasInit" "B" "C" "D" $ macruby test.rb "HasInit" "A" "HasInit" "B" "C" "D" Next, will there be an implementation of BasicObject in MacRuby as it is in Ruby 1.9.x? -Conrad On Mon, Oct 5, 2009 at 7:45 PM, Laurent Sansonetti <lsansonetti@apple.com>wrote:
Thanks for the report, I added your snippet in our test suite.
At a glance it looks like an infinite loop in the dispatcher. Definitely a bug :)
Laurent
On Oct 5, 2009, at 6:37 PM, Michael Shapiro wrote:
Hi all,
I searched a few months of the list archives and trac, but wasn't able to find reference to this.
Calling `super` inside of an overridden #init function where no ruby ancestors define #init causes a segmentation fault. If I'm not mistaken, shouldn't the init: message be passed to NSObject?
--------------------------------------------------------- class HasInit def init super p 'HasInit' self end end
class A < HasInit; end
class B < A; end
A.new p 'A' B.new p 'B'
class HasNoInit; end
class C < HasNoInit; end
class D < C def init super self end end
C.new p 'C' D.new p 'D' ---------------------------------------------------------
You should see the segfault happen when trying to init D, but HasInit passes the message through to NSObject just fine, it seems.
Tested with the 2009-10-05-1158 nightly.
Thanks! --Mike _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Oct 5, 2009, at 8:01 PM, Conrad Taylor wrote:
What should be the exact output? In Ruby 1.9.1, I see the following output:
$ ruby test.rb "A" "B" "C" "D"
[snip] #init is actually a NSObject thing. MacRuby's default initializer calls it. The mainstream Ruby doesn't, which explains your output.
Next, will there be an implementation of BasicObject in MacRuby as it is in Ruby 1.9.x?
There is one already (maybe not 100% compatible): $ macruby -e "p BasicObject" BasicObject Laurent
On Mon, Oct 5, 2009 at 7:45 PM, Laurent Sansonetti <lsansonetti@apple.com
wrote: Thanks for the report, I added your snippet in our test suite.
At a glance it looks like an infinite loop in the dispatcher. Definitely a bug :)
Laurent
On Oct 5, 2009, at 6:37 PM, Michael Shapiro wrote:
Hi all, I searched a few months of the list archives and trac, but wasn't able to find reference to this.
Calling `super` inside of an overridden #init function where no ruby ancestors define #init causes a segmentation fault. If I'm not mistaken, shouldn't the init: message be passed to NSObject?
--------------------------------------------------------- class HasInit def init super p 'HasInit' self end end
class A < HasInit; end
class B < A; end
A.new p 'A' B.new p 'B'
class HasNoInit; end
class C < HasNoInit; end
class D < C def init super self end end
C.new p 'C' D.new p 'D' ---------------------------------------------------------
You should see the segfault happen when trying to init D, but HasInit passes the message through to NSObject just fine, it seems.
Tested with the 2009-10-05-1158 nightly.
Thanks! --Mike _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (3)
-
Conrad Taylor
-
Laurent Sansonetti
-
Michael Shapiro