Alright, I have a hankering again to port Ruby FFI ;). One question: should the port be written in pure Ruby, or should this be a C# library in the same vein as YAML (IronRuby.Libraries.Yaml)? I was leaning towards the latter, where I would branch from IronLanguages/Main, adding a *Libraries.FFI* folder beside *Libraries.Yaml*. Cheers, -Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20110322/794c2634/attachment.html>
It would be easier to write the core implementation as regular C# library (i.e. not IronRuby.Libraries.*) and write the public API in Ruby that would internally call to that library. The Ruby file could call load_assembly ''CoreFFI.dll'' and then use the classes defined there. This way you don''t even need to include the code to IronRuby main repo, it could be a separate gem. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Strahan Sent: Tuesday, March 22, 2011 6:30 PM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Ruby FFI port Alright, I have a hankering again to port Ruby FFI ;). One question: should the port be written in pure Ruby, or should this be a C# library in the same vein as YAML (IronRuby.Libraries.Yaml)? I was leaning towards the latter, where I would branch from IronLanguages/Main, adding a Libraries.FFI folder beside Libraries.Yaml. Cheers, -Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20110323/9dbc8ced/attachment-0001.html>
Another idea... what about starting from http://github.com/ffi and replacing the C extension with C# code? Not sure if it will work but it''s at least worth looking at. Or perhaps you can also look at what JRuby is doing. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Strahan Sent: Tuesday, March 22, 2011 6:30 PM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Ruby FFI port Alright, I have a hankering again to port Ruby FFI ;). One question: should the port be written in pure Ruby, or should this be a C# library in the same vein as YAML (IronRuby.Libraries.Yaml)? I was leaning towards the latter, where I would branch from IronLanguages/Main, adding a Libraries.FFI folder beside Libraries.Yaml. Cheers, -Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20110323/53eab35c/attachment.html>
> 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<https://github.com/cstrahan/iron-ffi>- I''ll try to lay out a foundation tonight. -Charles On Wed, Mar 23, 2011 at 12:29 AM, Tomas Matousek < Tomas.Matousek at microsoft.com> wrote:> Another idea? what about starting from http://github.com/ffi and > replacing the C extension with C# code? > > Not sure if it will work but it?s at least worth looking at. Or perhaps you > can also look at what JRuby is doing. > > > > Tomas > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Charles Strahan > *Sent:* Tuesday, March 22, 2011 6:30 PM > *To:* ironruby-core at rubyforge.org > *Subject:* [Ironruby-core] Ruby FFI port > > > > Alright, I have a hankering again to port Ruby FFI ;). > > > > One question: should the port be written in pure Ruby, or should this be a > C# library in the same vein as YAML (IronRuby.Libraries.Yaml)? I was > leaning towards the latter, where I would branch from IronLanguages/Main, > adding a *Libraries.FFI* folder beside *Libraries.Yaml*. > > > > Cheers, > > > > -Charles > > _______________________________________________ > 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/20110324/ee4b35c7/attachment.html>
I''ve successfully built the FFI gem on my Win7 x64 machine, but the specs currently fail: *E:/Source/ffi/lib/ffi/library.rb:147:in `attach_function'': Function ''strdup'' not* * found in [msvcrt.dll] (FFI::NotFoundError)* * from E:/Source/ffi/spec/ffi/strptr_spec.rb:33:in `<module:StrPtr>''* This is a known problem, but it hasn''t been fixed yet: http://groups.google.com/group/ruby-ffi/browse_thread/thread/c40766b574a15962> Thats just a symbol lookup problem. All the traditional libc symbols > in msvcrt.dll have an underscore prepended, so that test should have a > special case for win32 in it.My first goal is to fix any failing specs. Any help would be appreciated. -Charles On Thu, Mar 24, 2011 at 1:58 PM, 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<https://github.com/cstrahan/iron-ffi>- I''ll try to lay out a foundation tonight. > > -Charles > > On Wed, Mar 23, 2011 at 12:29 AM, Tomas Matousek < > Tomas.Matousek at microsoft.com> wrote: > >> Another idea? what about starting from http://github.com/ffi and >> replacing the C extension with C# code? >> >> Not sure if it will work but it?s at least worth looking at. Or perhaps >> you can also look at what JRuby is doing. >> >> >> >> Tomas >> >> >> >> *From:* ironruby-core-bounces at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Charles Strahan >> *Sent:* Tuesday, March 22, 2011 6:30 PM >> *To:* ironruby-core at rubyforge.org >> *Subject:* [Ironruby-core] Ruby FFI port >> >> >> >> Alright, I have a hankering again to port Ruby FFI ;). >> >> >> >> One question: should the port be written in pure Ruby, or should this be a >> C# library in the same vein as YAML (IronRuby.Libraries.Yaml)? I was >> leaning towards the latter, where I would branch from IronLanguages/Main, >> adding a *Libraries.FFI* folder beside *Libraries.Yaml*. >> >> >> >> Cheers, >> >> >> >> -Charles >> >> _______________________________________________ >> 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/20110324/2b5be73c/attachment.html>
I''ve fixed the problem in the spec <https://github.com/ffi/ffi/pull/82>, and all specs pass now. Time to start porting the C code to C#. -Charles On Thu, Mar 24, 2011 at 3:19 PM, Charles Strahan < charles.c.strahan at gmail.com> wrote:> I''ve successfully built the FFI gem on my Win7 x64 machine, but the specs > currently fail: > > *E:/Source/ffi/lib/ffi/library.rb:147:in `attach_function'': Function > ''strdup'' not* > * found in [msvcrt.dll] (FFI::NotFoundError)* > * from E:/Source/ffi/spec/ffi/strptr_spec.rb:33:in > `<module:StrPtr>''* > > This is a known problem, but it hasn''t been fixed yet: > > > http://groups.google.com/group/ruby-ffi/browse_thread/thread/c40766b574a15962 > >> Thats just a symbol lookup problem. All the traditional libc symbols >> in msvcrt.dll have an underscore prepended, so that test should have a >> special case for win32 in it. > > > My first goal is to fix any failing specs. Any help would be appreciated. > > -Charles > > On Thu, Mar 24, 2011 at 1:58 PM, 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<https://github.com/cstrahan/iron-ffi>- I''ll try to lay out a foundation tonight. >> >> -Charles >> >> On Wed, Mar 23, 2011 at 12:29 AM, Tomas Matousek < >> Tomas.Matousek at microsoft.com> wrote: >> >>> Another idea? what about starting from http://github.com/ffi and >>> replacing the C extension with C# code? >>> >>> Not sure if it will work but it?s at least worth looking at. Or perhaps >>> you can also look at what JRuby is doing. >>> >>> >>> >>> Tomas >>> >>> >>> >>> *From:* ironruby-core-bounces at rubyforge.org [mailto: >>> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Charles Strahan >>> *Sent:* Tuesday, March 22, 2011 6:30 PM >>> *To:* ironruby-core at rubyforge.org >>> *Subject:* [Ironruby-core] Ruby FFI port >>> >>> >>> >>> Alright, I have a hankering again to port Ruby FFI ;). >>> >>> >>> >>> One question: should the port be written in pure Ruby, or should this be >>> a C# library in the same vein as YAML (IronRuby.Libraries.Yaml)? I was >>> leaning towards the latter, where I would branch from IronLanguages/Main, >>> adding a *Libraries.FFI* folder beside *Libraries.Yaml*. >>> >>> >>> >>> Cheers, >>> >>> >>> >>> -Charles >>> >>> _______________________________________________ >>> 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/20110324/7e95a53e/attachment.html>
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.
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20110325/56a05fcc/attachment.html>
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 > >
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/20110327/b4bc6218/attachment.html>
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/407d2834/attachment-0001.html>
> 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>
Are you coming to ALT.NET Seattle? We have an OSS track this year to help people learn how to contribute to projects. Interested? Ryan 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. > > -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 > > > > > > > > _______________________________________________ > 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/4309f349/attachment-0001.html>
Ryan, I''m *absolutely* interested, but, as much as it shames me to say, the ALT.NET Seattle conference wasn''t on my radar until just now. I''m down for next year though, especially if you plan to give an F# workshop. -Charles On Thu, Mar 31, 2011 at 8:40 AM, Ryan Riley <ryan.riley at panesofglass.org>wrote:> Are you coming to ALT.NET Seattle? We have an OSS track this year to help > people learn how to contribute to projects. Interested? > > Ryan > > 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. > > -Charles > > > > On Sun, Mar 27, 2011 at 6:28 PM, Charles Strahan <<charles.c.strahan at gmail.com> > 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> >> 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> >>> 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> >>> wmeissner at gmail.com> wrote: >>> >> >>> >> On 25 March 2011 04:58, Charles Strahan <<charles.c.strahan at gmail.com> >>> charles.c.strahan at gmail.com> >>> >> wrote: >>> >> > >>> >> >> Another idea? what about starting from <http://github.com/ffi> >>> 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>Ironruby-core at rubyforge.org >>> >> <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> > >>> > >>> > _______________________________________________ >>> > Ironruby-core mailing list >>> > <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org >>> > <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> 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 > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20110331/2b9aab0e/attachment.html>
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>
> I''ll need just another week or two to cut the first release.Maybe it can merge with mainline ffi gem at some point? -r -- Posted via http://www.ruby-forum.com/.
That''s a possibility, but it might have to come further down the road. -Charles On Thu, Apr 14, 2011 at 3:29 PM, Roger Pack <lists at ruby-forum.com> wrote:> > I''ll need just another week or two to cut the first release. > > Maybe it can merge with mainline ffi gem at some point? > -r > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > 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/20110423/0e21d9fd/attachment.html>