[Ironruby-core] Ruby FFI port

Charles Strahan charles.c.strahan at gmail.com
Mon Apr 4 07:40:18 EDT 2011


All,

IronRuby FFI is coming along well.  So far, I support most of the
FFI::Function uses, including attaching to function pointers, library
functions, and wrapping Procs.

Structs are at 50%, and callbacks need to be implemented.

I'll need just another week or two to cut the first release.

-Charles


On Thu, Mar 31, 2011 at 5:00 AM, Charles Strahan <
charles.c.strahan at gmail.com> wrote:

>
>
>> 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...
>
>
> D'oh! I overlooked the UnmanagedFunctionPointerAttribute<http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.unmanagedfunctionpointerattribute.aspx>
> .
>
> -Charles
>
>
> On Thu, Mar 31, 2011 at 4:41 AM, Charles Strahan <
> charles.c.strahan at gmail.com> wrote:
>
>> 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/20110404/08b1498b/attachment.html>


More information about the Ironruby-core mailing list