> 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
