Re: Ruby/Python - mixed language apps, and garbage collection
Re: Ruby/Python - mixed language apps, and garbage collection
- Subject: Re: Ruby/Python - mixed language apps, and garbage collection
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 19 Nov 2007 09:53:09 -0800
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden