Changes between Version 2 and Version 3 of HBDBPlanning

Show
Ignore:
Timestamp:
08/03/11 06:43:45 (10 years ago)
Author:
cotto
Comment:

add a description of this page's purpose, remove some unneeded bits from the original timeline

Legend:

Unmodified
Added
Removed
Modified
  • HBDBPlanning

    v2 v3  
     1This page exists to help plan out soh_cah_toa's GSoC project.  Unfortunately it turns out to depend heavily on parts of imcc which were substantially more broken than anyone realized.   Although imcc has gotten the attention of our developers, the GSoC project's schedule shouldn't make any assumptions as to whether imcc will improve. 
     2My (cotto) plan is to rework hbdb's schedule so that it can be a maximally useful debugger by the end of GSoC within the limitations of what imcc can provide.  The first step is to break the original schedule into a list of discrete features and to divide those features into three groups: those that are completed, those that depend on imcc's broken line number annotations and those that don't.  From there, we can work out a new schedule that will show measurable progress and be completable while avoiding some of the more egregious landmines provided by imcc. 
     3 
     4the original schedule (with some omissions unrelated to features) is included below as a starting point. 
     5 
     6 
    17Specific Details 
    28 
     
    511        This would effectively extend the debugger's "vocabulary" from PIR to all Parrot-supported HLL's. 
    612 
    7     Add an interface for code instrumentation and introspection. 
    8  
    9         This would not take very long as I may just borrow the code already present in parrot-instrument. 
     13    Add an interface for code instrumentation and introspection, possibly stealing from parrot-instrument. 
    1014 
    1115    Create an extension that would open an interpreter and be able to run code within it one opcode at a time. 
     
    4953 Timeline: 
    5054 
    51 * To avoid redundancy, referring to "design" here will imply code design, unit test design, and documentation design. * 
    52  
    53 At 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. 
    54  
    5555    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