From: Aaron Patterson Date: 2010-01-26T05:56:48+09:00 Subject: Re: ruby bounties--list of bounties On Tue, Jan 26, 2010 at 04:52:13AM +0900, Chuck Remes wrote: > > On Jan 25, 2010, at 1:34 PM, Mike Dalessio wrote: > > > On Mon, Jan 25, 2010 at 2:17 PM, Chuck Remes 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. It doesn't need to support the entire API. It supports enough of the C API to get nokogiri running, and believe me, we use a *lot* of the C API. Why pay the FFI speed penalty when you can write C code that works cross implementation? > 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. Again, it doesn't need to support the entire 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. As I pointed out in an earlier email, dealing with FFI wrapped libraries is error prone, difficult to debug (not just during development, but also when helping people get things installed), doesn't work cross implementation, requires id2ref (the bane of Charlie's existence. I'm sorry. :-( ), etc. I even have real world examples of *all* of the issues I pointed out. Even if FFI were the cross implementation messiah it's supposed to be, our FFI applications will *still* not work on GAE or Android. Rubinius has already proved that you can implement a *subset* of the C API and get complex extensions to work. Why can't we run with that? I think it would be a better long term solution. We would get the same "cross implementation" behavior as FFI, but not have to pay FFI's runtime conversion penalties. We also get the ability to do compile time checks of C library functionality (i.e. check for #defines, function existence, etc). People keep saying that FFI is the better way to go, but as someone who has to support both an FFI version and a C version, I can tell you the support / development problems with FFI are much more difficult. -- Aaron Patterson http://tenderlovemaking.com/