Squawks of the Parrot

Inching towards merengue...

So, I've been working on and off with Python::Bytecode, getting it up to snuff. The basic code itself looks to be a simple translation of the Python unfreezing code, though it's needed some thumping for Python 2.3. (Things have changed sizes since the code was originally written, and some conditional things were a bit dodgy)

I've actually got it fully working, which I wrote about earlier (I think) with one caveat--the code assumes that there's only one code object around at any one time, which isn't generally true. That is, when you disassemble a piece of bytecode you normally have multiple code objects. And a disassembler that only does one code object is sub-optimal. (This, by the way, is why the tests I was doing didn't match what python's dis module showed. It had the same problem, disassembling only one code object, it just chose a different one to disassemble. (First rather than last. Or vice versa, I don't remember)) Anyway, now I'm rejigging the relatively simple internals to be less simple, splitting out the bytecode management chunks from the code object chunks.

Hopefully by the end of the day (or, rather, end of the night, since I shouldn't burn work time on this, though a working python bytecode transcoder would make writing library code easier than doing it in PIR (well, other than the whole 'writing it in Python' thing (more because I don't know the language well enough to use it. I'll save rants about the language proper until such a time as I actually do, since it's kinda stupid to rant about things I don't know anything about, and I prefer to save that for other things... :))) I'll have a working disassembler. At which point we're in a position to write the transcoder, and from there we can fill in the blanks with the library code.

FWIW, if you're following along at home, the library code is by far the biggest potential issue. The bytecode disassembly and translation's not that big a deal, relatively speaking, though the library code is.

I've got to admit, at this point I am nervous about winning, not because I think parrot can't perform but because I'm not sure there'll be time to finish. This has been held up in part by machine problems (my laptop's in the shop again, dammit) but mostly by real world concerns. Work and family's keeping me busy (maybe you can tell your six year old daughter you can't go to the park with her because you need to throw a pie at Guido, but I can't :) so I've had a lot less time to put into this than I thought. On the other hand, we've gotten Leo involved, so things may well progress... rapidly.

The translation code's a single-threaded bottleneck, but once the translator's done we can get more folks involved, since library work can be done multithreaded. And as a side-effect, parrot'll get a good chunk 'o runtime library implemented, and I can't complain about that. One way or another this will get done, even if we don't make OSCON. That'll give us a nice, working python to parrot translator, which isn't a bad thing at all.