#142: Infinite loop creating new Monitor object ---------------------------------------+------------------------------------ Reporter: dev@petermcm.dircon.co.uk | Owner: lsansonetti@apple.com Type: defect | Status: new Priority: major | Milestone: MacRuby 0.3 Component: MacRuby | Resolution: Keywords: | ---------------------------------------+------------------------------------ Comment(by jamis@37signals.com): This can actually be duplicated easily with something like the following: {{{ module A def initialize super end end class B include A end B.new }}} I ran into this when trying to get Capistrano to run under MacRuby (since Capistrano depends on Net::SSH, which depends on Ruby's Logger, which depends on Monitor, etc.). I've tried digging through MacRuby to figure out where the error is coming from, but my ruby-internals-fu is yet weak. I'll keep digging, but hopefully someone smarter than me can figure this out more quickly. :) -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:2> MacRuby <http://macruby.org/>

#142: Infinite loop creating new Monitor object ---------------------------------------+------------------------------------ Reporter: dev@petermcm.dircon.co.uk | Owner: lsansonetti@apple.com Type: defect | Status: new Priority: major | Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords: | ---------------------------------------+------------------------------------ Changes (by lsansonetti@apple.com): * milestone: MacRuby 0.3 => MacRuby 0.4 -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:4> MacRuby <http://macruby.org/>

#142: Infinite loop creating new Monitor object ---------------------------------------+------------------------------------ Reporter: dev@petermcm.dircon.co.uk | Owner: lsansonetti@apple.com Type: defect | Status: new Priority: major | Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords: | ---------------------------------------+------------------------------------ Comment(by lsansonetti@apple.com): Thanks for the patch Jamis, it clearly demonstrates that the current mixin implementation suffers from problems. I have an idea to rewrite it by duplicating the module class and interposing it into the ancestors chain during include, I think it should fix this problem and also eliminate some of the dirty code paths in the VM. -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:6> MacRuby <http://macruby.org/>

#142: Infinite loop creating new Monitor object ---------------------------------------+------------------------------------ Reporter: dev@… | Owner: lsansonetti@… Type: defect | Status: closed Priority: major | Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Changes (by lsansonetti@…): * status: new => closed * resolution: => fixed Comment: So I have been investigating different solutions to re-implement the mixin feature, but I was unsuccessful. My first attempt was to create intermediate classes and interpose them inside the ancestor chain, but this causes some problem with the 64-bit libobjc runtime (which does not authorize you to change the superclass of NSObject), it requires to allocate a complete class-pair (both the class and its metaclass) every time, and it does not work if you extend a singleton class. My second attempt was to monkey-patch the libobjc method lookup functionality to also look inside mixed modules at runtime. This was working but I could not make it stable (and also it's really evil). This was just to experiment a potential change that I would submit to the libobjc guys. My third attempt was the successful one, I basically used a solution very similar to Jamis' patch and removed the unnecessary code paths. When dispatching the super message we no longer forward it to the real superclass but use the Ruby ancestors chain. The problem should be fixed in r750. -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:8> MacRuby <http://macruby.org/>