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

[Mark Brown]

On 29-Aug-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 27-Aug-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > I therefore propose a new trace level, tentatively called "interface"
> ...
> > This solves two problems. The first is the maintenance problem with the
> > expected outputs, since I don't think any debugger test cases call higher
> > order library functions.
> 
> If they don't, then that is clearly an omission in our test suite,
> since this is an important case to test.

Okay.

> 
> > The second is the fact that declarative debugging
> > doesn't work with trace level shallow. The problem is that a shallow traced
> > procedure can call a decl traced procedure in another module, and if it does
> > so, the declarative debugger doesn't know whether the decl traced procedure
> > is a negative context or not.
> 
> Uh, could you remind me again why the declarative debugger needs to know
> whether such calls are in negative contexts or not?

It boils down to a limitation of our current understanding of annotated
traces, the data structures underlying our implementation of the debugging
tree.  The full details can be found in the paper in papers/decl_debug.

The way that we understand annotated traces to be correct is that we break
the structure down into smaller and smaller components, and we ultimately
demonstrate these to be in one-one correspondence with nodes in a debugging
tree.  These components have been carefully chosen to meet certain criteria,
including:
	- the final components faithfully represent the debugging tree;
	- the structure can be built and analysed efficiently.

One of these steps is that we break the events pertaining to the body
of a procedure into "strata".  These are sets of events which come from
goals that have been negated by the same set of constructs.  The algorithm
that constructs the annotated trace depends on knowing where the boundaries
of strata are -- that is, it needs to know when we enter or leave a negated
context.  This is basically the reason that cond and nege events were added
to the trace.

I'm currently working on a modification to annotated traces that may
solve this problem for the case of a shallow traced procedure that calls
a deep traced procedure.  I haven't tested it out yet, but it is a simple
change and that part shouldn't take long.  The difficult part, assuming
it passes any tests I throw at it, is to convince myself that the change
is actually correct.  I'll post more on this later.

(So now I have two approaches I'm looking into: this one and the other
one that involved generating extra hidden events.)

> (**) Actually, even this is not quite correct.  If there is a bug, it
> might be in the Mercury implementation, or in the C compiler, or in the
> OS, or the hardware...

... or the universe.  Probably best we don't think about that.

:-)

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