(copy to editor, edit, hand in to appropriate asgns directory with
filename AUTHOR_by_REVIEWER.txt)

Specifications Author: Lincoln Quirk
Project Title: Thread Debugger
Reviewer: Colin Stebbins Gordon

Evaluate the elements below on a scale from 1-5.  Add comments after
each as needed.  Copy in any text from the specification to make
appropriate comments.  Address comments to the author of the
specification.

	1) description of the project (from requirements);
	5
	This would be a great project.  The OCaml choice may see some
	resistance, though.  It's true that most people in the class know OCaml
	better than C++, but one of the course requirements is a C++ project.
	Also, why display code for threads where a pane of code has no
	particular meaning?  Threads which are running just fine don't have any
	clear block of code to point to, so are these panes just updated when a
	thread hits a breakpoint or segfaults?  And even then, what of the other
	threads?  Also, since many threads may take the same codepath, it's more
	likely that most of the threads will want the *same* code window - so
	I'm not sure that a one to one code<-->thread correspondence is the way
	to go.

	2) system model diagram;
	0
	Absent

	3) annotations describing each component of the system model;
	5
	Sounds good - though at one point you mention "each process."  This
	isn't bad, but just as a clarification, does this mean we could debug a
	heirarchy of separate processes, in addition to a basic multi-threaded
	app?  Because that would be awesome, and useful since some apps are
	built with separate processes and shared mmap-ed regions.

	4) user interface diagrams and descriptions;
	5
	Looks good, though see the comment in section 1 about thread to code
	mappings.

	5) written description of the above;
	4
	Brief, but sort of covered in the initial description.

	6) non-functional requirements (performance, testing,
		reliability, ease of use, portability, documentation,
		dependencies on other systems);
	5
	Good.

	7) updated requirements (with priorities, etc.);
	5
	Looks well fleshed out

	8) any risky parts.
	4
	I think you nailed the main issues.  I might also proffer that since
	there are some project members who have no OCaml experience at all, the
	language could end up being a hindrance rather than a boon.

Other comments:

================================================================

Additional comments/changes after presentation: