doubi

I'm currently at the stage of reading the Python docs and considering what I'll have to keep track of as regards C type objects, and how to do so. The Python ctypes code is delightfully well documented, particularly this nugget. The Ruby and JS projects unfortunately seem to be entirely lacking in any documentation of their internal functioning, but I think I've got enough to work on.

While reading rurban's Illustrated Perlguts (which is fantastic, hugely enlightening and should be included in the core perldoc pages if at all possible), I've started thinking that it might be a good idea to implement C type classes using magic. My understanding of it all is admittedly infantile, but I'm thinking that if I used magic then everything would be kept inside the understood 'structure' of special abilities of Perl SV's, so I wouldn't have to worry so much about bespoke structs floating around not being free()'d or something. It could also help encapsulation / general architectural discipline by forcing me to express all the special weirdness of C types through the standard magic vtable functions.

It was suggested to me earlier in #p5p though that 'manipulating basic C types from Perl' isn't all that complex really, and magic mightn't be necessary. Then again, it might all get more complicated later, if Ctypes classes are to be tie'able and whatnot, in which case I'd be better using magic from the start rather than building incrementally and having to rewrite for each new level of complexity I need to support. I'd love to get some more input on this. I could certainly have a stab at this based on the Python docs, but I don't feel I know enough about the Perl internals to know the best way to go about it.

In other news, it's been a mixed week this week. First the good news: I got the basis of the library, ffi_call(), working on Linux and Win32. The repo is at http://gitorious.org/perl-ctypes/perl-ctypes/. It doesn't do that much in its raw form, but it's the first important milestone.

The bad news is it seems to be failing profusely on 64bit Linux. When I say profusely, I mean in the .asm code that ships with libffi itself. Not at all sure where to start trying to fix that, although it might indicate that I just need some platform checking code in there somewhere.

A problem of course is that I don't have access to a 64bit machine. Googling around for a solution there, I found this post which seems to imply that I could run a 64bit Linux image under VirtualBox on my laptop, since it does seem to support Intel's VT extensions (at least, I think I do, based on the method given in this other post). Will try it later.

Another setback-kinda-thing this week was spending 3-4 days working on code to automatically turn Perl arrays of numbers or strings into C arrays and vice versa. I was almost there, but in the end it hit me that I was almost certainly trying to be Too Clever. Bit of a waste of time.

On the other hand, now that I've started looking at implementing the actual C type classes in Perl, the experience of the preceding folly hasn't been entirely unhelpful. I certainly got a better feel for pointers and memory allocation. Part of my code for translating Perl-to-C arrays and back was allocating a struct which tracked the type of the array (IV, NV or PV -> int, double or char*), the number of items, and a pointer to the original Perl AV on the stack. In retrospect it was kinda going in the same ~direction~ as the way C type classes are implemented in Python with the tagCDataObject struct.

Thanks all for your feedback :-)