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

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.
  • Because ctypes has such a good reputation, I'd hijack their brand as much as possible.

    So, distribution name "ctypes".

    Main namespace, "CDLL".

    So in python...

    cdll.LoadLibrary('libc.so.6'); ...becomes something like this in Perl...

    CDLL->load_library('libc.so.6');

    • Good point about the branding.

      Also, in the effort of articulating why I was never keen on the Python API, it's just 'clicked' with me. Thanks for that ;)

      I take it you can't just simply ask for 'libc' on *nix 'cause you might have several libc.so.x lying around.

      Why is that? Could there be a way to mitigate for it? I do like the ol' automatic accessor style: cdll->libc->function('arg').

      If that wasn't available cross platform I wouldn't even bother making it an optional syntax for Windows.
  • Another reason not to use "ptypes" - you're not replacing the C with Perl, you're replacing the Python with Perl.

    I agree with Alias that somehow we should piggy-back off the existing "ctypes" brand, so that (e.g.) when someone googles for "ctypes" they find the new implementation too. I'm not experienced enough with it to know if this is the correct term to piggyback off of, but some pig should be backed.

    Do you envision any special-purpose stuff for creating wrapper modules? One thing that's been fairly c

    • Another reason not to use "ptypes" - you're not replacing the C with Perl, you're replacing the Python with Perl.

      Granted. In my head, it was meant to be some kind of weird pun. I don't think it worked :F

      some pig should be backed.

      As they say, when the world gives you pigs, all you can do is back.

      Do you envision any special-purpose stuff for creating wrapper modules? One thing that's been fairly clear in the Inline::C world is that the needs of people writing wrapper modules & people writing little scripts that call libraries are pretty different.

      If it's not useful for fully wrapping libs, I will consider it a bit of a failure. As you say, there are already a few modules on CPAN you could probably coerce into working for you for the purposes of tinkering, so I do want to go well beyond that.

  • Hi doubi,

    I'm glad you have the enthusiasm to work on this project. As you know (and some other readers here may), I've also proposed a CTypes for Perl project to the TPF two or three times, but it wasn't accepted, so I'm glad it was accepted as part of GSoC.

    I'd like to note that when I requested help with some ctypes (in Python) problems on #python on Freenode, some of the people there told me that they now prefer to use Cython over ctypes [wikipedia.org] and that "it also has a strict subset so that a cython module c

  • This is the best news I've read all week! I am one of the developers of Reaper, an audio recording/editing application. Reaper supports user scripting via Python::ctypes and Perl::FFI. Python of course works out of the box, and Perl is a constant portability headache (good luck finding a functional Perl::FFI on OS X or x64). http://forum.cockos.com/showthread.php?t=59436 [cockos.com] If there's any support we can offer, please let us know, we have the maximum enthusiasm for your project!