[m-dev.] for review: the new debugger command set (part 1 of 5)

[Tyson Dowd]

On 21-Sep-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:

> When you discover the need
> for a bug fix or enhancement after having accumulated some diffs,
> you have two unpalatable choices: fix it only in your current workspace,
> which links the two changes, or fix it also in a fresh workspace, which
> doubles your work.

I wouldn't say "double" *unless* the bug fix is for a bug that can
only be tested in conjunction with another change. 
I am in much the same dilemma with my typeclassinfo for stack
layout change.

> > A compromise will be fine.  Clearly we have both indicated that this is
> > too much at once -- you could probably have halved it into
> > "documentation" and "everything else" and got it past without comment.
> 
> Huh? I *tried* that, and it got knocked back because "it wasn't documented".

Sorry, I meant documentation + help system + other changes, as separate
from the redo even change, for instance.

> 
> > So perhaps we can split off the "redo event" change from the online
> > documentation change at least, and then work on getting them commited
> > separately.
> 
> The documentation stuff is mostly add-on, and it can be committed separately.
> The problem is, whichever order the commits take place in, for some time
> the code and the doc will be inconsistent.

That's not too bad, as long as it comes into line eventually, and the
documentation is marked as being out of date (or ahead of date ;-).

> 
> If I were to try to divide this diff into several significantly smaller parts,
> it would take me another two weeks of work (taking probably two months of
> calendar time due to the need to bootcheck each change before building on it).
> This is not acceptable.

This is why I am willing to tolerate the change going through.

It has been reviewed now, and I think the only major issue is the
runtime/library dependency problem, which you have outlined a solution
to below.  This will require that section to be reviewed again.

> 
> I propose the following.
> 
> 1. I will fix the problem of the runtime depending on the standard library
> by creating two new libraries, corresponding to (a) the call-tree of MR_trace
> in the runtime and (b) the call-tree of MR_trace in the library (help.m,
> any browsing code we add later, and maybe debugger_interface.m).
> 
> 2. I will remove from the diff whatever changes can be removed without
> excessive work duplication, for separate review later.
> 
> 3. I will give names to each item in my log message (which correspond, more
> or less, with the 17 items Tyson identified), and annotate each component of
> the diff with the name(s) of the item(s) that the diff implements. This way,
> a reviewer can check whether an item is implemented properly by looking at
> only the differences tagged by the name of the item. For a reviewer, the
> effect should be quite similar to reviewing a sequence of smaller diffs,
> with the only difference being the requirement to be aware of other,
> interacting changes.

This would be nice -- although as you have pointed out eariler the 17
bits are sometimes very closely related, so it can be turned into just
a couple of basic threads.

> 
> 4. To supply this awareness if you don't have it, I can conduct a walkthrough
> of the annotated diff for the reviewers. I nominate thursday afternoon.

Since I spent some time going through the diff, I don't know that that
is necessary, I expect to be in a much better position to review the
change after these changes have been made. 

Thanks Zoltan,


Tyson.