[m-dev.] for review: expand implicit trees in the debugger

[Mark Anthony BROWN]

I'll go ahead and commit this one.

Cheers,
Mark.

Mark Anthony BROWN writes:
> Hi,
> 
> This is for review by anyone.
> 
> Cheers,
> Mark.
> 
> Estimated hours taken: 40
> 
> Implement the expanding of implicit subtrees in the declarative debugger.
> When the maximum depth is reached by the front end, it now returns to
> the back end a request for the missing subtree.  If the back end receives
> such a request, it restarts declarative debugging with a different
> topmost call and a deeper depth bound.
> 
> The EDT instance needs to know when to request expansion, so CALL nodes
> need a flag to indicate whether they were at the maximum depth.  The
> front end needs to be able to point out the bug and/or subtree to the
> back end, so CALL, EXIT and FAIL nodes need to record the event number.
> 
> browser/declarative_execution.m:
> 	- Store the event number in CALL, EXIT and FAIL nodes.
> 	- Store a bool in CALL nodes which indicates whether the event
> 	  was at the maximum depth or not.
> 
> browser/declarative_debugger.m:
> 	- Store the event number of the buggy event in the reported bug,
> 	  and pass this event number to the back end so it can go back
> 	  to that event.
> 	- Add a case for expanding an implicit tree to the
> 	  diagnoser_response type, and handle this response properly.
> 	- Export procedures to C that allow acces to the diagnoser_response
> 	  type.
> 	- Accommodate the changes to the trace_node type.
> 
> browser/declarative_analyser.m:
> 	- Store the list of previous prime suspects in the analyser state.
> 	  That way they don't have to be specially dealt with when
> 	  restarting analysis with an expanded subtree.
> 	- When starting analysis, assume the top node is wrong; this
> 	  is not an unreasonable assumption, and the strategy works better
> 	  for the case when a subtree is expanded.
> 
> browser/declarative_user.m:
> 	- Accommodate changes to the reported bug.
> 
> trace/mercury_trace_declarative.c:
> 	- Change the depth step size to a reasonable number, now that
> 	  it works.  This also has the effect of testing the change,
> 	  since some test cases go deeper than the new limit.
> 	- Filter events outside the topmost call.  Rather than keep
> 	  track of the minimum depth, we record the topmost call sequence
> 	  number and use a global to keep track of whether we have entered
> 	  or left this procedure.
> 	- Factor out code in the existing mechanism for starting
> 	  declarative debugging, so that it can be used to re-start
> 	  debugging as well.
> 	- Accommodate the changes to the trace_node type.
> 	- Output error messages if declarative debugging fails to start
> 	  properly.
> 	- Handle the reponse from the diagnoser, by jumping to the buggy
> 	  event (if a bug is found) or re-executing to expand a subtree
> 	  (if one is requested).
> 	- Add a new checkpoint for events which are filtered out of
> 	  the annotated trace.
> 
> trace/mercury_trace_internal.c:
> 	- Don't report error messages when declarative debugging fails
> 	  to start.  Errors are now reported by the declarative debugger
> 	  before returning.
> 
> tests/debugger/declarative/*.inp:
> tests/debugger/declarative/*.exp:
> tests/debugger/declarative/*.exp2:
> 	- Update to reflect the removed questions.
> 
> tests/debugger/declarative/Mmakefile:
> tests/debugger/declarative/filter.m:
> tests/debugger/declarative/filter.inp:
> tests/debugger/declarative/filter.exp:
> 	- New test case to cover the code which filters events which
> 	  are outside the topmost call.
> 
> ? tests/debugger/declarative/filter.exp2
> ? tests/debugger/declarative/filter.inp
> ? tests/debugger/declarative/filter.m
> ? tests/debugger/declarative/filter.exp

-- 
Mark Brown, PhD student            )O+  |  "Another of Fortran's breakthroughs
(m.brown at cs.mu.oz.au)                   |  was the GOTO statement, which was...
Dept. of Computer Science and Software  |  uniquely simple and understandable"
Engineering, University of Melbourne    |              -- IEEE, 1994
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------