[Ironruby-core] Ruby FFI port

Charles Strahan charles.c.strahan at gmail.com
Thu Mar 31 05:41:06 EDT 2011


Well, with some really, *really *ugly hacking, I've managed to get this far
(the first example from FFI wiki):

irb(main):011:0> module Hello
irb(main):012:1>   extend FFI::Library
irb(main):013:1>   ffi_lib FFI::Library::LIBC
irb(main):014:1>   attach_function 'puts', [ :string ], :int
irb(main):015:1> end
*(Object doesn't support #inspect)*
=>
irb(main):016:0> Hello.puts("Hello, World")
Hello, World
=> 0

(dunno why that *"(Object doesn't support #inspect)"* shows up...)

Anywho, I think we might might have a significant portion of FFI implemented
fairly soon.  The codebase is still pretty unstable/crappy, but I'm hoping
to get it ready for contributions soon.

-Charles



On Sun, Mar 27, 2011 at 6:28 PM, Charles Strahan <
charles.c.strahan at gmail.com> wrote:

> Well, I think I've made a little progress - hoping to attach a simple
> function soon.
>
> I am concerned about one thing though - we need to be able to call function
> pointers, but I think that *Marshal.GetDelegateForFunctionPointer* only
> supports the STD calling convention. Any thoughts on how we might support
> cdecl?  Presently, it's not a blocking concern - so I'll cross that bridge
> when the time comes...
>
>
> Wayne: Sorry - I meant to send that to the mailing list, as opposed to
> sending it directly to you.
>
> -Charles
>
>
>
> On Fri, Mar 25, 2011 at 8:03 AM, Wayne Meissner <wmeissner at gmail.com>wrote:
>
>> That sounds like a good plan.  Much of the CRuby version of FFI used
>> to be written in ruby, until people had the quaint notion that it
>> shouldn't be as slow as it was, and I moved most of the implementation
>> into C.
>>
>> dlopen and friends are usually in the libdl library on most unixen.  I
>> can't remember where the windows equivalents live.
>>
>>
>> On 25 March 2011 20:09, Charles Strahan <charles.c.strahan at gmail.com>
>> wrote:
>> > Sweet - thank you for the tip, Wayne!
>> > Here's my current plan:
>> >
>> > All Ruby classes defined inside of ffi_c will be ported to Ruby, where
>> I'll
>> > call into my C# lib where it makes sense.
>> > Because my poor brain can only handle so much context-switching, I'll
>> stub
>> > out all of the Ruby classes with methods that will simply raise "not
>> > implemented".
>> > I'll follow Wayne's advice to get some simple clib funcs working.
>> > Port the rest of ffi_c
>> >
>> > When all is said and done, it looks like I shouldn't need to touch a
>> single
>> > line of FFI's Ruby code - I should only need to implement classes (or
>> parts
>> > thereof) that are defined in ffi_c.
>> > One thing I will need to figure later is the name of the dll that
>> contains
>> > dlopen/dlsym/etc for each platform.  I'm willing to be that I'll be able
>> to
>> > piece that together with decent accuracy by looking
>> at FFI.map_library_name.
>> >
>> > -Charles
>> >
>> > On Thu, Mar 24, 2011 at 6:11 PM, Wayne Meissner <wmeissner at gmail.com>
>> wrote:
>> >>
>> >> On 25 March 2011 04:58, Charles Strahan <charles.c.strahan at gmail.com>
>> >> wrote:
>> >> >
>> >> >> Another idea… what about starting from http://github.com/ffi and
>> >> >> replacing
>> >> >> the C extension with C# code?
>> >> >
>> >> > That's a great idea, Tomas.  I'll need some immediate gratification
>> to
>> >> > keep
>> >> > me from getting discouraged; porting the C funcs piecemeal sounds
>> like a
>> >> > good way to get something working.  I've forked FFI - I'll try to lay
>> >> > out a
>> >> > foundation tonight.
>> >>
>> >> If you want some easy wins, The first classes you'll want to implement
>> >> are:
>> >>
>> >> 1)  FFI::Type - this is used by much of the rest of the system, e.g.
>> >> to identify arguments and struct field types.  At a minimum, you need
>> >> to implement #size and #alignment, and have FFI::Type instances for 8,
>> >> 16, 32, 64 bit signed/unsigned integers, float, double and pointer
>> >> defined as the constants FFI::Type::UINT8, FFI::Type::INT8, etc.
>> >>
>> >> 2) FFI::Pointer - instances of this are used to represent a native
>> >> pointer.  To get things up and running, you can stub this out with
>> >> just the basic initialize() method.  Most of the accessor methods can
>> >> be done later.
>> >>
>> >> 3) FFI::DynamicLibrary - kinda useful for loading libraries and
>> >> locating symbols within said library.
>> >>
>> >> 4) FFI::Function - the swiss army knife class for calling functions,
>> >> and creating C => ruby callbacks.  Ignore the callback aspect of this
>> >> for now, and just get ruby => C calling working.
>> >>
>> >> That will take you a little while, but you'll be able to at least get
>> >> simple functions like 'puts' from libc callable from FFI.
>> >> _______________________________________________
>> >> Ironruby-core mailing list
>> >> Ironruby-core at rubyforge.org
>> >> http://rubyforge.org/mailman/listinfo/ironruby-core
>> >
>> >
>> > _______________________________________________
>> > Ironruby-core mailing list
>> > Ironruby-core at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/ironruby-core
>> >
>> >
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20110331/407d2834/attachment-0001.html>


More information about the Ironruby-core mailing list