Re: Ruby/Python - mixed language apps, and garbage collection

FROM : Bill Bumgarner
DATE : Mon Nov 19 18:53:09 2007

On Nov 19, 2007, at 5:12 AM, Graham Perks wrote:
> I looked for "embedding" documentation but all I came up with was 
> people embedding the runtime, Tiger-style. Similarly, your comment 
> below is implying I'm on Tiger, right? I would be targeting Leopard 
> so the Python/Ruby runtime is already compiled and in place, isn't it?


You still have to link against the appropriate language and bring up 
the interpreter.

See the result of "new project" and creating a Cocoa / Python or 
Cocoa / Ruby application.  There is no magic;  the main source files 
for both contain everything necessary to bootstrap the interpreters 
for either language, optimized for Leopard.

> On Nov 18, 2007, at 11:32 AM, Bill Bumgarner wrote:
>

>> (Technically, there really isn't a reason why you couldn't enable 
>> GC for RubyCocoa and PyObjC.  You would need to recompile the 
>> bridges and Python/Ruby interpreters with GC enabled.

>
> In my head I would like to take an existing Objective-C application, 
> and switch over to developing it in Python or Ruby. I'd be 
> subclassing ObjC, creating objects on both sides of the bridge - all 
> the stuff you do in a regular single-language application. Is this 
> beyond what the bridge is intended for? If it is, that's OK, I'd 
> just like to know!


That is definitely in scope of the bridges;  exactly what they are 
designed for and exactly what many people are already doing with them.

>> Objective-C Garbage Collection cannot be enabled in Ruby/Python 
>> based Cocoa applications.  Specifically, you can't use Objective-C 
>> objects on the scripting language side of the bridges.

>
> So I can't pass NSString objects? I am limited to ints & floats and 
> the like? GC on the Python/Ruby side is enabled, right - I don't 
> have to start managing memory in Python do I?


If you have an existing Cocoa application that is non-GC, I would 
leave it non-GC and just use the bridges as is.  If you have a GC'd 
Cocoa app and really want to use the bridges, it might be easier to 
add all the retain/release/autorelease noise back into the code.    Do 
not underestimate the difficulty of enabling GC support for either 
bridge.

To enable GC with the ruby or python bridge will *require*:

- recompiling the target language with GC enabled (this can be skipped 
only if there is not a single line of objective-c code in the source 
of ruby or python)

- recompiling the bridges to be GC enabled

- dealing with the fallout of bridging between two completely 
different GC subsystems.

In other words, I wouldn't go there until the bridge developers get 
around to having a look.

b.bum