[m-rev.] for review: add mdb `dice' command

[Ian MacLarty]

On Mon, Feb 07, 2005 at 04:06:41PM +1100, Julien Fischer wrote:
> 
> 
> On Sun, 6 Feb 2005, Ian MacLarty wrote:
> 
> > +A dice is a comparison between some successful test runs of the program and a
> > +failing test run.  Before using the @samp{dice} command one or more passing
> > +execution summaries and one failing execution summary should be generated.
> s/should be/need to be/
> 

Changed.

> > +This can be done by compiling the program with deep tracing enabled (either by
> > +compiling in the .debug or .decldebug grades or with the @samp{--trace deep}
> > +compiler option) and then running the program with the MERCURY_OPTIONS
> > +environment variable set to @samp{--trace-count}.
> > +This will generate a file called
> > + at samp{.mercury_trace_counts} which contains a summary of the program's execution
> > +(called a slice).
> I suggest making that aside an actual sentence. e.g.
> 
> 	This summary is called a slice.

Okay.

> ...
> 
> > +NEGE, NEGS and NEGF events where the goal path and port is displayed.
> s/is/are/
> 

Fixed.

> The whole discussion below would be improved if you included an example
> of a program dice.
> 

Okay I've added the following:

 @sp 1
 Once one or more passing slices and a failing slice have been generated the
 @samp{dice} command can be used to display a table of statistics comparing the
-passing test runs to the failing run.  Each row in the table contains statistics
+passing test runs to the failing run.  Here is an example of a dice displayed
+in an mdb session:
+ at sp 1
+ at example
+mdb> dice -f fail -p passes -s S -n 4
+Procedure        Path/Port  File:Line Pass (3) Fail Suspicion
+pred s.mrg/3-0   <s2;c2;e;> s.m:74       0 (0)    1      1.00
+pred s.mrg/3-0   <s2;c2;t;> s.m:67      10 (3)    4      0.29
+pred s.mrg/3-0   CALL       s.m:64      18 (3)    7      0.28
+pred s.mrg/3-0   EXIT       s.m:64      18 (3)    7      0.28
+ at end example
+ at sp 1
+This example tells us that the @samp{else} in @samp{s.m} on line 74 was 
+executed once in the failing test run, but never in the passing test runs, so
+this would be a good place to start looking for a bug.
+ at sp 1
+Each row in the table contains statistics
 about the execution of a separate goal in the program.  Six columns are
 displayed:
 @sp 1
@@ -3435,11 +3450,12 @@
 The total number of times the goal was executed in all the passing test runs.
 This is followed by a number in braces which indicates the number of test runs
 the goal was executed in.  The heading of this column also has a number in
-braces which is the total number of passing test cases.
+braces which is the total number of passing test cases.  In the example above
+we can see that 3 passing tests were run.

> > + at item @samp{Suspicion}:
> > +A number between 0 and 1 which gives an indication of how lightly a
> s/lightly/likely/
> 

Fixed.

> > +particular goal is to be buggy.  The is calculated as
> > +Suspicion = F / (P + F) where F is the number of times the goal
> > +was executed in the failing test run and P is the number of times the goal
> > +was executed in passing test runs.
> > + at end itemize
> > + at sp 1
> > +The name of the file containing the failing slice can be specified with the
> > + at samp{-f} or @samp{--fail-trace-count} option or with a seperate
> s/seperate/separate/
> 

Fixed.

> > + at samp{set fail_trace_count @var{filename}} command.
> > + at sp 1
> > +The name of a file containing a list of the files containing the passing
> > +slices can be given with the @samp{-p} or @samp{--pass-trace-counts} option.
> > +Alternatively a seperate @samp{set pass_trace_counts @var{filename}} command
> s/seperate/separate/
> 

Fixed.

> > @@ -2357,7 +2406,7 @@
> >              flat_format, raw_pretty_format, verbose_format, pretty_format,
> >              words[1], words[2]))
> >      {
> > -        MR_trace_usage("parameter", "set");
> > +        MR_trace_usage("misc", "set");
> >      }
> >
> >      return KEEP_INTERACTING;
> > @@ -5830,6 +5879,100 @@
> >      return KEEP_INTERACTING;
> >  }
> >
> > +static MR_Next
> > +MR_trace_cmd_dice(char **words, int word_count, MR_Trace_Cmd_Info *cmd,
> > +    MR_Event_Info *event_info, MR_Event_Details *event_details,
> > +    MR_Code **jumpaddr)
> > +{
> > +    char    *pass_trace_counts_file;
> > +    char    *fail_trace_count_file;
> > +    char    *sort_str = (char*)malloc(MR_MAX_DICE_SORT_STR_SIZE + 1);
> > +    char    *out_file = NULL;
> > +    int     n = 50;
> 
> `n' is not a meaningful variable name.  I suggest `number_of_lines'
> or something like that.  If you're going to have that magic number
> there I suggest at least a comment about what it is.  Better still,
> make it a symbolic constant.
> 

Okay, have used your suggestion and added a symbolic constant.

Ian.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------