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

Ctypes for Perl: Intro and API spec | Log In/Create an Account | Top | 6 comments | Search Discussion
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • 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');

  • Name change (Score:1)

    by kwilliams (1467) on 2010.05.24 14:18 (#72001)

    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 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.

    Very nice work you're proposing. I'd totally use it.

  • 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 can be used directly in Python, rather than compiled" (but "idea how good that is though.") so it may be worth to investigate. Cython is not a core Python module though, which has been the case for ctypes for a few years now.

    Otherwise, note that your first interface is procedural rather than functional (see Functional programming on the wikipedia [wikipedia.org], which is not the opposite of Object Oriented programming). The interface looks fine, but I think we may eventually overgrow the pack/unpack like notation because ctypes and the C programming language supports quite a bit more than what unpack gives. Also see the Data-ParseBinary CPAN module [cpan.org], which also has origins in the Python "construct" module, and which is far superior to pack/unpack.

    I agree with the other people here that we should call it "ctypes" or something and not "ptypes". I tried to log-in into twitter and follow your tweets, but it said that "Twitter is over capacity." and wouldn't let me. I'm not visiting Twitter a lot often. In any case, I'm subscribed to the use.perl.org master Perl feed, and you should see about getting it syndicated on the various Perl planets [perl-begin.org].

    Good luck with perlifying ctypes.

  • 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!
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.