[Ironruby-core] Ruby FFI port
ryan.riley at panesofglass.org
Thu Mar 31 09:40:45 EDT 2011
Are you coming to ALT.NET Seattle? We have an OSS track this year to help people learn how to contribute to projects. Interested?
Sent from my iPhone
On Mar 31, 2011, at 2: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.
> 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.
> 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
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironruby-core