[m-rev.] for review: document coverage testing

[Zoltan Somogyi]

On 25-Sep-2006, Ian MacLarty <maclarty at csse.unimelb.edu.au> wrote:
> > +A program with debugging enabled may be run in a special mode
> > +that causes it to write out to a @emph{trace count file}
> > +a record of how many times each @emph{debugger event} in the program
> > +was executed during that run.
> 
> I introduced the term "label" and used that instead of "debugger event",
> since I thought using the term "event" would be misleading.  The
> same label may generate two different events, with different event
> numbers.  The trace count feature counts the number of times the
> label was executed, not how may times each event was executed (each
> event is always executed exactly once in the absence of retries).
> 
> I therefore think it'd be better to keep the definition of the term
> "label" and use that to describe what the trace counts are counting.

I disagree.

(1) An event such as "call procedure p/n" can be viewed either statically or
dynamically, not just dynamically. This duality is pervasive in programming,
so expecting programmers to understand it is ok. The static interpretation
is exactly what we want in this case.

(2) Readers of this section already know about events, which is a notion
visible to users of the debugger. They don't need to know about labels,
which are an implementation technique.

> > +Unlike @samp{mtc_union}, @samp{mtc_diff} does not preserve
> > +
> 
> You're missing some text here.

Fixed.

> > +For labels that generate interface events this column displays the event port,
> > +while for labels that generate internal events it displays the goal path.
> > +(See @ref{Tracing of Mercury programs} for an explanation
> > +of interface and internal events.)
> 
> You must definitely keep the definition of label if you're going to use
> that term here.

Changed to use events here too.

> ...
> > -For example the string "SF" means sort the table by suspicion in descending
> > -order, and if any two suspicions are the same, then by number of executions in
> > -the failing run(s), also in descending order.
> > - at sp 1
> > -The option @samp{-l} or @samp{--limit} can be used to limit the number of lines
> > -displayed.
> > - at sp 1
> > -The @samp{-m} or @samp{--module} option limits the output to the given module
> > -and any submodules.
> > +For example the string "SF" means
> > +sort the table by suspicion in descending order,
> > +and if any two suspicions are the same,
> > +then by number of executions in the failing run(s), also in descending order.
> > + at sp 1
> > +The option @samp{-l} or @samp{--limit}
> > +can be used to limit the number of lines displayed.
> > + at sp 1
> > +The @samp{-m} or @samp{--module} option
> > +limits the output to the given module and any submodules.
> > +the count of the test cases that contributed to its contents in any useful way.
> 
> The text above seems out of place.

That is the line missing after
	> > +Unlike @samp{mtc_union}, @samp{mtc_diff} does not preserve
above. I have no idea how it got there.

> I am planning on removing the dice mdb command, since if you want to
> view a dice from within mdb you can always use the shell command with
> mdice.  Do you have any objections to me removing the dice command?

Conceptually, no, but we should talk about the appropriate place
for trace counts related tests first.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------