Thread Debugger Design

Top-level diagram

• Debugger: the interface to all the internal state for the debugger
• GDBInterface: the GDB specific code (knows how to 'speak' GDB)
• Thread: model of a single thread -- its run state, current function, and what it thinks it is blocked on
• PosixThread: the interface that knows how to speak pthreads. It knows about the debugging interface (it can examine backtraces and set breakpoints in order to figure out the state of the pthreads) but it's not coupled to GDB.

External Dependencies

• GDB, although we should be able to swap this for another debugger if one is present (i.e., Mono debugger)
• OCaml's parser library (ocamllex and ocamlyacc)
• OCaml's gtk library

Task breakdown

Potential tasks (breakdown based on design)
GUI (2-5 people)
 - Miscellaneous (1 person)
 - ThreadView (1-4 people)
   - displaying code (.5 people)
   - examining variables (1 person)
   - displaying misc state (1-2 people)
   - stack trace (.5 people)
   - setting bp + control flow (1 person)
   
Debugger (1-3 people)
 - Thread interactions manager (1 person)
 - Thread (1 person)
 - GDBParser (.5 people)
 - GDBInterface (1-2 people)
 
Main (1-2 people)
 - Miscellaneous (.5 people)
 - EventLoop (.5 people)
 - PersistentState (1 person)


Potential group oriented tasks (breakdown based on group need):
- Lead (1 person) - administrative lead, makes final decisions
- Architect (1 person) - technical lead
- Programmer (5-10 people)
- Documentation
  - Lead (1 person) - decides on quality, organizes + keeps people honest
  - Documentors - everyone on their own code
- Testing + Release Engineering
  - Lead (1 person) - decides on product quality, maintains repository (branches/tags)
  - Test Engineers
    - auto unittest suite maintainer (1 person)
    - unit test creation - everyone on their own code
    - system testers (2 people)

Possible Group Organization

Lead: tara
Architect: lincoln
System Programming Breakdown. Pair Programming. (lead,alternate)
  - GUI.CodeView: (owen,kevin)
  - GUI.Miscellaneous: (lincoln,tara)
  - Debugger: (nate,brendan)
  - GDBInterface: (sean,josh)
  - Main + Miscellaneous: (colin,)

Documentation lead: dominic
Release lead: sean
AutoTest maintainer: kevin
System testers: dominic, josh

(This was based on the following inferences I made from who I know personally
and their profiles online):

People who are likely to be able to lead in OCaml programming:
- lincoln, owen, colin, sean, nate

People who want to be heavier coders:
- lincoln, colin, josh, nate, sean, 

People who want to play a leadership role:
- tara, dominic, sean, lincoln

Weekly Schedule (totally crazy!)

• 3/2: Have working stubs for primary sections of code: Main, GUI, Debugger, EventLoop (i.e., GUI just displays a blank window, Main starts the program, GDBInterface loads GDB process, etc.)
• 3/9: Display something from the GDB process into a ThreadView. Detailed GUI/Debugger interface design -- determine what GUI needs of model. Requires detailed UI specification.
• 3/16: Get EventLoop working and test. Tie into GDB and GUI. Get GDBParser/GDBInterface working and test. Develop interface between GDBInterface and Debugger.
• 3/23: Get Thread and PosixThread implemented and test. Debugger should be implementation-complete (but open to interface changes as needed from GUI). GUI should have basic elements (buttons, panes) implemented (against dummy backend) and tested.
• 3/30: Implement base GUI features and hook into model. Integration. System test.
• 4/6: System and user test. Continue implementing miscellaneous features (PersistentState, MiniPane). Perform user testing. Get feedback.
• 4/13: Specify additional features requested by users. User test more. Fix bugs. Demo release.
• 4/20: Incrementally implement additional features from users (on separate source branch) as appropriate. Selectively merge into final branch. Demo additional functionality as needed.
• 4/27 and beyond: Ditto.

Assumptions

None. My specifications were clear to me...

Testing

Extremely important. Unit tests early for all appropriate functionality. System tests where appropriate, and heavy iterative user testing as long as we can go near the end.