On Thu, Apr 17, 2008 at 10:59 AM, Mark Glines <[EMAIL PROTECTED]> wrote: > : > 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.
+1 > 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? RT works. Thanks! > Mark > > -- Will "Coke" Coleda
