Garrett Goebel wrote:
Nick Glencross wrote:
As mentioned on the list yesterday I started evaluating ffcall
as a way of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I actually really like the current NCI implementation, although
it suffers from a large nci.c file and all the usable prototypes
need to be specified at compile time in call_list.txt. Over time
as more libraries become supported this list will quickly grow.
Here's a reference to the last time this thread came up:
http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/8b1b5e
7e343ce3c4/
and a shortened URL forwarded version:
http://ffcall-perl6-internals.notlong.com
Thanks for that Garrett.
It's great that you've talked to Bruno in the past about this! Although
I had planned to look at both ffcall and libffi, ffcall has so far
looked more compelling to me.
I started looking for the latest version of libffi, couldn't be sure
which it was so I put it on the backburner. Then I looked at ffcall,
instantly thought 'perfect' because it provided a really usable API, and
then knocked up a quick POC.
I certainly agree about what was being said about supporting multiple
backends as it protects us against future nasty platforms. However, I'm
unclear what the benefits of the favoured option of using JIT code was;
that sounds like reinventing a ff library.
One thing that would be nice would be extend build_native.pl so that it
builds the other supported NCI layers; that way they would all support
the same types and not get out of sync with one another. I'd be
interested in trying this if no one objects...
My word of the week seems to be 'callbacks' because the current
implementation doesn't seem to cut it (in my opinion), which is really
the driving reason for looking at other alternatives.
Cheers,
Nick
