[m-dev.] debugging grades and I/O tabling

[Mark Brown]

On 27-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 18-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > - Add a new grade component, called something like .decl or .decldebug,
> >   controlled by an option such as --require-decl-tracing. Just as
> >   --require-tracing disallows trace level none, --require-decl-tracing
> >   would disallow trace levels none, shallow and deep, leaving a choice
> >   only between trace levels decl and rep. (Eventually, we could add a version
> >   of shallow tracing that is suitable for declarative debugging, either by
> >   marking the boundaries of negated contexts or by suppressing all events
> >   inside shallow traced procedures.)
> 
> I discovered that in practice, we *need* a version of shallow tracing for
> declarative debugging. If we don't, then in .decldebug grades, the event
> numbers in the outputs of the debugger test cases depend on the exact
> implementation details of the library functions called by those test cases,
> and this is too much of a nuisance for maintenance.

Is it not possible to filter the output of the tests to get rid of any
variation?  For example, filter out any line that contains a trace event.
There would need to be at least one test that didn't do that (this would
be a test that checks that the correct event is reached when the debugger
exits), but we could avoid calling the library in this case.  For other
tests, the event details shouldn't be important.  I think it would be
better to try to deal with the test case maintenance problem within the
tests directory itself, rather than trying to design our way around it
from the debugger.

Regarding the proposal, it is nice to think of the '--trace shallow' option
as saying that the module is trusted to have no bugs in it, and that the only
way a problem may arise from the module is if an inadmissible call is made to
it.  So the user is saying that they don't need to see any events other than
those at entry to and exit from the point at which the module is called.
A proposal such as yours which avoids producing events that are not required
by the declarative debugger is a good idea (I have some comments on the
details, but I'll post those later), but I think it is a problem that the
user is also burdened with events that they don't really need.

I have in mind a scheme to let the declarative debugger have access to more
events than the user does, which would complement a scheme like yours:
introduce "hidden" events which are never shown to the user.  We could modify
the code at the start of MR_trace_real, which tests whether we are in a
shallow traced procedure called from shallow traced code, and instead of
returning immediately we could call a new function named something like
MR_trace_hidden, which does any processing we want but performs no output
and does not increment the call sequence number, etc.  When the declarative
debugger is constructing the debugging tree, this function would call some
(possibly new) function in mercury_trace_declarative to update the tree for
the hidden event.  Of course, the declarative debugging front end would also
need to be updated to handle the change to the debugging tree.

> This trace level is in many ways simpler than trace level shallow, so once
> it is implemented, we may wish to emphasize it instead of shallow tracing.

One way I can see that it is simpler is that it tries to ensure that we never
skip up or down more than one level in the call tree at a time.  For example,
you don't get an event at depth 5 followed by an event at depth 10.  Is there
some other way it is simpler that I have missed?  If not, I still think the
current behaviour of shallow traced procedures is preferable.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------