Changes between Version 1 and Version 2 of HBDBPlanning

Show
Ignore:
Timestamp:
08/02/11 00:23:25 (10 years ago)
Author:
cotto
Comment:

remove timeline items that don't list specific features

Legend:

Unmodified
Added
Removed
Modified

  • HBDBPlanning

    v1 v2  
    5353At the beginning of each week, there will be a discussion with the mentor(s) to make a weekly outline and a set of goals describing what needs to be accomplished each week. 
    5454 
    55     Week 1 – Begin designing initial set of commands. A good starting point would be: enable/disable breakpoints, start/continue execution, stepping, print registers, source listing, help, etc. 
     55    Begin designing initial set of commands. A good starting point would be: enable/disable breakpoints, start/continue execution, stepping, print registers, source listing, help, etc 
    5656 
    57     Week 2 – Begin writing unit tests for basic command set and shell. Once the unit tests are in place, begin writing code for commands. Verify that unit tests now pass. 
    58  
    59     Week 3 – Begin designing backtrace command. Once the unit tests are in place, begin writing code for backtrace. Verify that unit tests now pass. 
    60  
    61     Week 4 – Begin design and plan how to integrate parrot-instrument. This may mean borrowing code directly or using it as a guideline. Once the unit tests are in place, begin writing instrumentation code. Verify that unit tests now pass. 
    62  
    63     Week 5 – With parrot-instrument in place, design framework for owning an interpreter for running code. 
    64  
    65     Week 6 – Begin coding phase for interpreter. Once the unit tests are in place, begin writing code. Verify that unit tests now pass. 
    66  
    67     Week 7 – At this point, it may be best to add a few more advanced commands. This could include: bytecode disassembly, command scripting, printing information about the interpreter, etc. This week would be spent on the design. 
    68  
    69     Week 8 – Begin coding phase for new set of commands. Once the unit tests are in place, begin writing code. Verify that unit tests now pass. 
    70  
    71     Week 9 – Begin design of commands for dynamic memory analysis. 
    72  
    73     Week 10 – Begin coding phase for dynamic memory analysis. Once the unit tests are in place, begin writing code. Verify that unit tests now pass. This may not take too long so if things get finished early, get a head start on documentation. 
    74  
    75     Week 11 – Review documentation and code examples, making any necessary improvements. At this point, it should be complete but if it's necessary, we can always include some more examples and documentation. 
    76  
    77     Week 12 – Review code and units tests, making an necessary improvements. Go over it with a fine-tooth comb, so to speak. 
    78  
    79     Week 13 – Reserved just in case things take a little longer. 
     57    commands for bytecode disassembly, command scripting, printing information about the interpreter, etc.