From: Chuck Remes <cremes.devlist@...>
Date: 2010-01-26T04:52:13+09:00
Subject: Re: ruby bounties--list of bounties

--Boundary_(ID_2WBp0WqaQfs/NX/IBRWaTw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT


On Jan 25, 2010, at 1:34 PM, Mike Dalessio wrote:

> On Mon, Jan 25, 2010 at 2:17 PM, Chuck Remes <cremes.devlist@mac.com> wrote:
>> 
>> FFI originated with rubinius, so I would wager that it will work once the
>> FFI APIs get synched up again. Also, MacRuby has FFI support on its roadmap.
>> That changes your picture a bit.
>> 
> 
> If you're interested in helping out in standardizing the FFI specs, please
> subscribe to the ruby-ffi list and offer to help out! We're always looking
> for extra hands, because the specs are not in good shape right now. So I'm
> likely to take your wager. ;)
> 
> I stand by the chart as an accurate reflection of the options that
> developers are forced to choose from today and for the likely near future.

While it may be true that *some* C extensions work with rubinius and MacRuby today, I'd say it doesn't matter much in the long term.

For one, Rubinius does not support the entire MRI C API nor will it ever. Extensions that directly access memory structures are not supported. FFI is a better long-term choice for Rubinius.

MacRuby is months away from catching up to Rubinius, JRuby or IronRuby for handling straight ruby code. I don't mean to disparage MacRuby (it will likely be my go-to-guy for future Cocoa apps) but it ain't ready for prime time for *ruby* code let alone hooking in C extensions. And like Rubinius, it won't support all of the MRI C API.

IronRuby does not support any C extensions though it's on the roadmap. I don't know for certain how extensive their support will be, but I will *wager* they'll avoid supporting the same elements that Rubinius and MacRuby are avoiding. :)

So for the likely near future (next 6 months), Rubinius is the only one that might be able to run a random C extension (as long as it doesn't use unsafe direct access to memory structures). 

I understand what you are saying, truly I do. But I disagree that it is important to continue building extensions using the C API for the *long* term. The best way to get FFI firmed up and ready for prime-time is to port existing extensions to it.

cr


--Boundary_(ID_2WBp0WqaQfs/NX/IBRWaTw)--