[Ironruby-core] Ruby FFI port

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


> 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/20110331/4620d000/attachment.html>


More information about the Ironruby-core mailing list