Will FFI make it into macruby?
Hi -- I read on a previous post in the mailing list that some/basic support for C extensions will be implemented for 0.6 .. Great work! And that brought me onto my question, will FFI be distributed with MacRuby whenever it becomes a little more stable? I think it'd be a great addition if a fully-featured FFI library was apart of MacRuby. Thanks, Rob
Hi Robert, There is currently no plan about implementing the FFI API in MacRuby. It was my plan originally but apparently the API is not really used, so I preferred to support C extensions instead, which will be in the next release, 0.6. This being said, patches are always welcome :) Laurent On Mar 15, 2010, at 12:30 PM, robert gleeson wrote:
Hi --
I read on a previous post in the mailing list that some/basic support for C extensions will be implemented for 0.6 .. Great work! And that brought me onto my question, will FFI be distributed with MacRuby whenever it becomes a little more stable? I think it'd be a great addition if a fully-featured FFI library was apart of MacRuby.
Thanks, Rob _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Wed, Mar 17, 2010 at 2:02 AM, Laurent Sansonetti <lsansonetti@apple.com>wrote:
Hi Robert,
There is currently no plan about implementing the FFI API in MacRuby. It was my plan originally but apparently the API is not really used, so I preferred to support C extensions instead, which will be in the next release, 0.6.
Ouch! I'm getting ready to make an initial release of FFI bindings to LLVM 2.6. So far they run on MRI 1.8.7, 1.9.1, and JRuby. I'd very much like to use them with MacRuby as well. At a minimum, they require attach_function, MemoryPointer and enums. I'll also readily admit that lack of FFI is the biggest reason I've *not* been using MacRuby for my current projects, as well as why my bindings don't have thorough support for managing LLVMContexts. I see that MacRuby uses llvm/ModuleProvider.h which is removed in LLVM 2.7. Am I right in assuming that MacRuby requires LLVM 2.6, and will this be the case for the forseeable future? Best Jeremy
Hi Jeremy, On Mar 17, 2010, at 5:03 PM, Jeremy Voorhis wrote:
On Wed, Mar 17, 2010 at 2:02 AM, Laurent Sansonetti <lsansonetti@apple.com> wrote: Hi Robert,
There is currently no plan about implementing the FFI API in MacRuby. It was my plan originally but apparently the API is not really used, so I preferred to support C extensions instead, which will be in the next release, 0.6.
Ouch! I'm getting ready to make an initial release of FFI bindings to LLVM 2.6.
Cool!
So far they run on MRI 1.8.7, 1.9.1, and JRuby. I'd very much like to use them with MacRuby as well. At a minimum, they require attach_function, MemoryPointer and enums.
We already have a basic implementation of attach_function in MacRuby based on LLVM, but it has not been tested well. And we have a class similar to MemoryPointer too (called Pointer) which also uses LLVM to generate conversion stubs. I think it shouldn't be hard to finish FFI inside MacRuby, it's just that I'm the only person really working on the project so far and this isn't very high on the TODO list. If one wants to help... :-)
I'll also readily admit that lack of FFI is the biggest reason I've *not* been using MacRuby for my current projects, as well as why my bindings don't have thorough support for managing LLVMContexts.
I see that MacRuby uses llvm/ModuleProvider.h which is removed in LLVM 2.7. Am I right in assuming that MacRuby requires LLVM 2.6, and will this be the case for the forseeable future?
MacRuby is progressively following LLVM. However we do at the moment require a revision where ModuleProvider.h exists (I have a local patch that makes it work for future revisions too but it's not applied yet). # The LLVM_TOT variable can be passed to rake in order to sometimes build with more recent revisions than the one specified in the README.rdoc file, but it is only used for internal development and targets a special internal branch of LLVM, so it might not always work against the public trunk. Ideally we will target the final 2.7 once it's out, which shouldn't be long now. Laurent
We already have a basic implementation of attach_function in MacRuby based on LLVM, but it has not been tested well. And we have a class similar to MemoryPointer too (called Pointer) which also uses LLVM to generate conversion stubs.
I think it shouldn't be hard to finish FFI inside MacRuby, it's just that I'm the only person really working on the project so far and this isn't very high on the TODO list. If one wants to help... :-)
Implementing FFI in terms of existing BridgeSupport makes sense, and afaik Rubinius' FFI support also depends heavily on their LLVM JIT compiler, so it seems like a good approach.
MacRuby is progressively following LLVM. However we do at the moment require a revision where ModuleProvider.h exists (I have a local patch that makes it work for future revisions too but it's not applied yet).
# The LLVM_TOT variable can be passed to rake in order to sometimes build with more recent revisions than the one specified in the README.rdoc file, but it is only used for internal development and targets a special internal branch of LLVM, so it might not always work against the public trunk.
Ideally we will target the final 2.7 once it's out, which shouldn't be long now.
Do you intend to continue progressively tracking LLVM? LLVM-trunk is such a moving target, but so long as the llvm-c interface stays compatible this is no problem. Linkage may also be problematic since my FFI bindings depend on LLVM dylibs. I'm not sure how they would work with MacRuby yet. Best, Jeremy Laurent
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Mar 17, 2010, at 6:11 PM, Jeremy Voorhis wrote:
MacRuby is progressively following LLVM. However we do at the moment require a revision where ModuleProvider.h exists (I have a local patch that makes it work for future revisions too but it's not applied yet).
# The LLVM_TOT variable can be passed to rake in order to sometimes build with more recent revisions than the one specified in the README.rdoc file, but it is only used for internal development and targets a special internal branch of LLVM, so it might not always work against the public trunk.
Ideally we will target the final 2.7 once it's out, which shouldn't be long now.
Do you intend to continue progressively tracking LLVM? LLVM-trunk is such a moving target, but so long as the llvm-c interface stays compatible this is no problem.
We don't really have a choice, the C API does not offer all the features we need and we also need to follow the new LLVM changes internally. Hopefully, the LLVM team is always helping us :-)
Linkage may also be problematic since my FFI bindings depend on LLVM dylibs. I'm not sure how they would work with MacRuby yet.
It will very likely collide at runtime... until we un-export all symbols (but the C extension ones) from the link phase, which should happen in theory for our next release, 0.6. Laurent
We don't really have a choice, the C API does not offer all the features we need and we also need to follow the new LLVM changes internally. Hopefully, the LLVM team is always helping us :-)
I wouldn't expect you to use the C API internally, but it's convenient to wrap it with FFI. That's how bindings were created for e.g. Lua and Ocaml.
Linkage may also be problematic since my FFI bindings depend on LLVM dylibs. I'm not sure how they would work with MacRuby yet.
It will very likely collide at runtime... until we un-export all symbols (but the C extension ones) from the link phase, which should happen in theory for our next release, 0.6.
That sounds promising. Thanks for the explanation. Best, Jeremy
Laurent
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (3)
-
Jeremy Voorhis
-
Laurent Sansonetti
-
robert gleeson