: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit
Hi, Jonathan (and everyone else)! Wednesday on IRC, we discussed the "M2 Bytecode format" milestone. This email is my attempt to formalize a plan for this work. I am hoping you will read through it and tell me how wrong I am. :) First off, I've created a branch (named pdd13pbc) for this. So that's where all this work is going to go. As we discussed, there are two top level goals here: 1. Update the disk format and/or interface to match the PDD13 spec. 2. Move all of the .pbc-handling code into a PackFile.pmc class. At your suggestion, I'm going to be focusing on the second option. It seems to me that I should tackle this in the following order: 2.1. Create some simple PMC classes named as specified in PDD13. 2.2. Toss together some methods which wrap around the existing src/packfile.c, src/packdump.c and src/packout.c functions. 2.3. Write a bunch of tests, test the hell out of it. 2.4. Start moving everything in parrot over to use the new PMC-based packfile API. 2.5. Copypaste pieces of packfile.c, packout.c, packdump.c code into the PMCs, to make them self-reliant. 2.6. Test the hell out of it. (Again.) 2.7. Rip out src/pack*.c and make sure nothing breaks. Questions: Does this plan sound reasonable? Should this PMC implement the "pdump" functionality (src/packdump.c) as well as packfile.c/packout.c? Speaking of "pdump", it seems to be mentioned in various places, mostly documentation and scripts, but it does not actually seem to be buildable. Judging from the documentation, there used to be a "make pdump", but not any more. What's up with that? Should I be tracking these subtasks in RT, or just keeping track of things on my own? Mark
