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.stra...@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.stra...@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.stra...@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 <wmeiss...@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.stra...@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 <wmeiss...@gmail.com> >>>> wrote: >>>> >> >>>> >> On 25 March 2011 04:58, Charles Strahan <charles.c.stra...@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@rubyforge.org >>>> >> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> > >>>> > >>>> > _______________________________________________ >>>> > Ironruby-core mailing list >>>> > Ironruby-core@rubyforge.org >>>> > http://rubyforge.org/mailman/listinfo/ironruby-core >>>> > >>>> > >>>> >>> >>> >>> >> >
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
