[MacRuby-devel] The Future of MacRuby

[Henry Maddocks]

On 7/04/2012, at 1:13 PM, Joshua Ballanco <jballanc at gmail.com> wrote:

> I gave a talk last year to Boston.rb that they graciously taped and put online. You can find it here: http://bostonrb.org/presentations/macruby-what-is-it-and-why-should-i-care-part-1 . Hopefully it should answer most of your questions around how MacRuby works. If not, hit me up on IRC! :-)

Thanks, I'll take a look.



>> I'm not sure the world needs another ruby VM. With Evan Pheonix's involvement is now the time to investigate merging the Rubinius and MacRuby VMs or are they too different? Can MacRuby leverage the work of the Rubinius team in some way?
> 
> The MacRuby VM is very nicely tailored to the job of running on top of the Objective-C runtime. It is also fairly mature. Personally, I see no technical reason that a proliferation of VMs should be a problem (there are at least 3 major Java VMs…4 if you disregard Oracle's lawyers and count Dalvik).

That's fine if the MacRuby VM is " fairly mature". I was thinking more from a sharing of resources position. More people available to work on the VM.


>> With the death of Obj-C GC why isn't MacRuby being ported to use ARC or even retain/release? Why does it need it's own memory handling scheme?
> 
> I would assert that Ruby without automatic memory management can hardly be called Ruby. ARC is a compile-time tool, so using it directly is not an option. Whether we call memory management a garbage collector or an automated reference counter is, I think, a matter of semantics. However, memory needs to be managed "somehow".

What are we talking about here, the ruby language GC or the ruby implementation GC? Take MRI; it implements a GC in a non GC language (C), it uses malloc and free.

I was talking about to ARC in the Obj-c implementation, not removing GC from ruby the language.

Henry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20120407/025395f3/attachment.html>