[MacRuby-devel] macruby on iphone (again) - options and way forward

Laurent Sansonetti lsansonetti at apple.com
Sun Oct 11 12:54:39 PDT 2009


Hi John :)

On Oct 11, 2009, at 1:53 AM, John Shea wrote:

> Hello everyone.
>
> So I think this topic is going to rear its ugly/pretty head until a  
> solution becomes available, and I myself would really like to be  
> able to use macruby code on the iphone.
>
> So I have put down my naive thoughts as to what are the issues.
>
> I am a complete novice when it comes to GC, so I am sorry if this is  
> all obvious or erroneous - but the important part is the discussion  
> - which i hope many of you will add to.
>
> Anyway it could be that I don't know enough about the subject to  
> make sense of it. But a way to perhaps getting more people to work  
> on getting macruby on the phone could be:
>
> 1. Describe the current GC situation on the mac & macruby in terms  
> of architecture.
> 2. Describe an appropriate architecture for how GC would work on the  
> iphone, how the programmer interacts with it in coding or compiling.
> 3. Describe the various parts of work that have to be done to to  
> implement 2.
> 4. Make some suggestions of similar coding efforts or current code  
> files or other references that people can use/copy to build a proof  
> of principle

I agree that having a description of the plan somewhere might help.

> The following are my versions of 1 and 2:
>
> Point 1:
> My assumption is that currently macruby hooks into objective c's GC  
> - autozone (this one ? http://www.opensource.apple.com/source/autozone/autozone-77.1/ 
> ) via ruby's ObjectSpace.
>
> Point 2:
> The iphone does not have GC so therefore in order to run macruby  
> something needs to collect the garbage.

These are correct.

> My other assumption is that you cannot run interpreted code on the  
> iphone (or iphone simulator) so when developing for iphone the ruby  
> code would need to be compiled during the build phase.

Also correct.

> So I can think of two ways to do collect the garbage.
>
> Firstly port autozone to the iphone - integrate macruby more or less  
> as now - include it as a framework or something.
> However,
>  - i am concerned that the separate autozone thread(s) may not play  
> well with the iphone processor
>  - in addition the threads need to be interruptible, when phone  
> calls come in or the home button is pressed - i can imagine  
> including the autozone controller in the responder chain (in order  
> to receive the shutdown command) would not be trivial.

One could technically port autozone to the iPhone so that the MacRuby  
runtime can still use it, but it wouldn't work for Cocoa APIs still.  
The version of Cocoa on the iPhone is not autozone-aware (objects  
can't be allocated from the autozone, no write barriers, etc.) so this  
solution would still need to use the default malloc zone for pure  
Objective-C objects and retain/release them.

> I am wondering if the above complexity is why Laurent always refers  
> to "emulating" autozone rather than including it or porting it.
>
> The other option i can think of is in the build phase insert the  
> necessary retains, releases and autoreleases into the code. By either:
>
> 	i) the developer including the calls manually, which are then  
> compiled/translated to the appropriate C/ObjC commands. (I have gone  
> off this idea a bit because the code would be hard to test in  
> isolation (unless there were special compiler codes normally ignored  
> by the ruby interpreter), and would make it hard to drop in any nice  
> ruby code/libraries, and later on hard to fix code if an official GC  
> ever arrives).
>
> 	ii) have a script which traverses the ruby code - and adds dealloc  
> methods for instance methods, adds releases to scope bound variables  
> etc, etc.
> (I like this option the best, though i have little idea how to  
> implement)

This is definitely the idea I have in mind. I think we can do both.  
First the compiler should be smart enough to automatically insert  
autorelease pools in the code. Second, the developer will still have  
the possibility to create an autorelease pool by himself for edge  
cases that the compiler is not able to handle.

Laurent


More information about the MacRuby-devel mailing list