Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Saturday May 06, 2006
06:47 PM

P5NCI Released

[ #29541 ]

Almost two years ago I realized that Perl 5 has calling conventions just as Parrot does.

That is, just as every Parrot function that passes two integers and a PMC to function and receives a string back looks the same in terms of the registers used, every Perl 5 function that passes two integers and a blessed scalar looks the same in terms of what's on the stack and where.

The same goes for C.

Any Perl function that passes arguments to a C function passes them the same way. The thunking layer that pulls arguments off of Perl's stack and passes them to the C function is the same for all Perl and C functions with the same signatures. The only difference is the C function to call.

Why write all that code more than once? Why compile all that code more than once? Why make people who may not even have compilers installed compile that code when you could have done it when you built Perl and now they never need to have a compiler installed to use pre-compiled C libraries?

One answer (not a good answer, but an answer) is "Because it's difficult to do."

Difficult is not impossible.

I just released P5NCI to the CPAN today. (That link won't work for a couple of hours after I posted it.) I've mentioned it before. I even added a hack about it to Perl Hacks (so I knew I needed to make it work sufficiently to release soon.)

It's not perfect and it's not complete, but it works. I know -- I spent a couple of hours last night and a couple of hours this afternoon wondering at platform-specific differences until I realized that higher-order C isn't entirely portable.

Yet now it works.

Now I need TPF Summer of Code 2006 student to make it perfect. Do you know anyone?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I had wondered why ActiveState could do this with DCOM DLLs in Win32::OLE [cpan.org] but we needed at least Inline or and sometimes XS explicit wrappers on the *nix side.

    Thank you!

    In P5NCI.pm [cpan.org], for

      my $library      = P5NCI::find_lib( 'nci_test' );
      my $library_path = P5NCI::load_lib( $library_path );

    do you perhaps mean

      my $library_path = P5NCI::find_lib( 'nci_test' );
      my $library      = P5NCI::load_lib( $library_path );

    The POD doesn't say that 'v' is invali

    --
    Bill
    # I had a sig when sigs were cool
    use Sig;
    • You're right about the two documenation issues. The first is a typo and the second is true -- v is only valid as the output parameter type.

      Adding support for read-only pointers (void *) is easy. Enforcing it isn't difficult either; Perl SVs can contain plain integers and I think I can toggle the read-only flag on them. I hesitated to add those until I could make writing to struct pointers easy, but as long as people know that that's the trickiest part and it's possible, I can release this in bits and p