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

[Zoltan Somogyi]

On 28-Aug-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
> Is it not possible to filter the output of the tests to get rid of any
> variation?

It is possible, but (a) the details would have to be ugly, and (b) unlike
my proposal, it doesn't address the other problem, the problem of the
declarative debugger not knowing the context of a call.

> 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.

I don't think my proposal designs around anything. I think it is a desirable
thing in its own right. That's the point.

> 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.

No. It could also mean that the trust in the module was misplaced.

> 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.

We could generate only interface events and context events (i.e the events
around if-then-else conditions and negated goals) for procedures in category 1.
That would reduce the number of events to the bare minimum. However, it would
also complicate the declarative debugger (see your own point below).

> 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.

My concern with this design is that it could slow down the processing of
non-hiddenm events, since it would introduce an extra test that rarely
succeeds. However, we should be able to arrange for this extra test to be
executed only when we are about to enter the expensive part of event
processing. The test could look at a new field in MR_Label_Layout.
There is some slack there (using 16 bits to store a port, which needs
less than 8), so we could do this without increasing executable size.

Based on this, I have two updated proposals for the handling of procedures
in category 1.

Proposal 1: They should generate public interface events and hidden
internal events, and should not turn off MR_trace_enabled, thus allowing
the calls they make to be traced.

Proposal 2: They should generate public interface events and hidden
internal events. They should turn off MR_trace_enabled, but restore it
just around higher order (and method) calls in which the higher order value
is an input argument (or, harder to implement, derived from an input argument).

> 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.

My proposal should require only minimal changes, to wit, mentioning misplaced
trust when reporting a wrong or missing answer bug for an interface traced
procedure. Modifying the front end to handle getting some but not all internal
events from a procedure would be significantly more complex.

> > 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?

Yes.

Shallow tracing is actually quite complicated to document. For example, the
user guide says:

	A procedure compiled with trace level @samp{shallow}
	will generate interface events
	if it is called from a procedure compiled with trace level @samp{deep},
	but it will never generate any internal events,
	and it will not generate any interface events either
	if it is called from a procedure compiled with trace level
	@samp{shallow}.
	If it is called from a procedure compiled with trace level @samp{none},
	the way it will behave is dictated by whether
	its nearest ancestor whose trace level is not @samp{none}
	has trace level @samp{deep} or @samp{shallow}.

The corresponding documentation for trace level interface would be much
simpler: for an interface traced procedure, you get only interface events,
and you never get any events from within their computation.

Zoltan.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------