mercurylang/mercury
1
0
Fork 0
mirror of https://github.com/Mercury-Language/mercury.git synced 2025-12-20 00:15:27 +00:00
Code Issues Projects Releases Wiki Activity
11,634 Commits 24 Branches 141 Tags
c0f66e00d4afac120fd6a037cf37ec653f99fe3f
Commit Graph

15 Commits

Author SHA1 Message Date
Zoltan Somogyi
ecdc285bc7 Split the existing browser library into two libraries, by making the 
Estimated hours taken: 10
Branches: main

Split the existing browser library into two libraries, by making the
program_representation module into its own library. This is useful because
the compiler refers to program_representation.m, whose code thus needs to be
linked into compiler executables even if the compiler isn't compiled with
debugging enabled. By creating a new library for this module, we avoid any
chance of the linker dragging in the rest of the modules in the browser
library. (This is a problem with an upcoming diff.).

The name of the new library is "mdbcomp", because the intention is that it
contain code that is shared between the debugger and the compiler. This means
mostly the definitions of data structures that the compiler generates for the
debugger, and the predicates that operate on them.

Mmake.common.in:
	Allow MDB_COMP_ as a prefix for symbol names in the browser directory.

Mmake.workspace:
	Add a make variable holding for the name of the new library, and
	add the name to the relevant lists of libraries.

	Avoid duplicating the lists of filenames that need to be updated
	when adding new libraries or changing their names.

Mmakefile:
	Use make variables to refer to library names.

browser/mdbcomp.m:
browser/mer_mdbcomp.m:
	Add these files as the top modules of the new library.

browser/program_representation.m:
	Make program_representation.m a submodule of mdbcomp, not mdb.

browser/program_representation.m:
browser/browser_info.m:
	Move a predicate from program_representation.m to browser_info.m
	to avoid the mdbcomp library depend on the browser library, since
	this would negate the point of the exercise.

browser/mdb.m:
	Delete program_representation.m from the list of submodules.

browser/Mmakefile:
	Update this file to handle the new module.

browser/Mercury.options:
	Mention the new module.

browser/*.m:
	Update the lists of imported modules. Import only one browser module
	per line.

compiler/notes/overall_design.html:
	Document the new library.

compiler/compile_target_code.m:
	Add the mdbcomp library to the list of libraries we need to link with.

compiler/prog_rep.m:
trace/mercury_trace_internal.c:
	Import program_representation.m by its new name.

scripts/c2init.in:
	Centralize knowledge about which files need to be updated when the list
	of libraries changes here.

scripts/c2init.in:
scripts/ml.in:
tools/binary:
tools/binary_step:
tools/bootcheck:
tools/linear:
tools/lml:
	Update the list of libraries programs are linked with.
 2003-10-27 06:00:50 +00:00
Mark Brown
c9563335ef Allow users of the declarative debugger to revise answers that they 
Estimated hours taken: 60
Branches: main

Allow users of the declarative debugger to revise answers that they
have given previously.  We do this by modifying the user interface
to allow a default answer to be shown as part of the question; the
default answer will always be some answer the user has given previously,
which they can choose to either change or accept as is.  Initially no
questions will be candidates for revision, but if the user ever rejects
a diagnosis, some or all of the questions leading directly to the bug in
question will be asked again.

Add an empty command to the user_command type, for when the user just
presses return.  If there is a default answer, the empty command is
interpreted as that answer.  If there is no default answer, the empty
command is interpreted as the skip command, which allows the user to
cycle through all the available questions by repeatedly pressing return.

browser/declarative_debugger.m:
	Define the type decl_evidence which represents the evidence
	collected against a particular suspect.

	Pass the evidence to the oracle as required.

	Ensure the analyser is updated after the user rejects a diagnosis.

browser/declarative_analyser.m:
	Collect the evidence against the prime suspect as the answers are
	processed, and include this evidence when the analyser response
	is a bug.

	Export the predicate revise_analysis/4 which updates the
	analyser state after the user has rejected a diagnosis.

	Pass the IO action map to prime_suspect_get_evidence so that
	edt_root_question can be called.

browser/declarative_oracle.m:
	When the user rejects a bug, retract from the oracle's knowledge
	base any of the evidence which implicated that bug.  Rather than
	throw this information away, we assert it in a secondary knowledge
	base which is consulted when we want to know if there should be
	a default answer provided to the user.

	Update the oracle_state to reflect the above change, and remove
	all the get_* and set_* predicates for the oracle state.  That
	functionality is provided by labelled fields, so maintaining the
	get_* and set_* predicates is no longer worth the trouble.

	Add the predicate retract_oracle_kb/3 to remove information from
	a knowledge base.

	Use the correct (equivalence) type for exceptions.

browser/declarative_user.m:
	Add the type user_question, which may be a plain decl_question or
	may be a decl_question with a default answer.  Use this type in
	query_user* instead of decl_question.

	Write the command handling switch as a separate predicate.  This
	makes it easier for one command to emulate others (e.g. the empty
	command).

	If the question has a default answer, print it as part of the
	prompt.

	Parse the empty command.

doc/user_guide.texi:
	Update the documentation to reflect the changes.

library/list.m:
	Add a cc_multi version of list__map.

tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/empty_command.exp:
tests/debugger/declarative/empty_command.inp:
tests/debugger/declarative/empty_command.m:
tests/debugger/declarative/revise.exp:
tests/debugger/declarative/revise.inp:
tests/debugger/declarative/revise.m:
tests/debugger/declarative/revise_2.exp:
tests/debugger/declarative/revise_2.inp:
tests/debugger/declarative/revise_2.m:
	Test cases for the new features.
 2003-02-03 05:19:32 +00:00
Mark Brown
f302f534fd Move the code that defines an instance of mercury_edt/2 from 
Estimated hours taken: 1
Branches: main

Move the code that defines an instance of mercury_edt/2 from
browser/declarative_debugger.m into a module of its own.  This section
of code is large and reasonably self-contained, so it makes sense for it
to have its own module.  Moreover, declarative_debugger.m contains the
main declarative debugging definitions and the upper levels of code for
the front end, and the mercury_edt/2 instance doesn't fit into either of
these categories.

Add an exception handler to the front end, so that if declarative debugging
fails for whatever reason, the debugging session can at least continue using
the procedural debugger.  Rather than calling error in the front end, throw
exceptions that are of a type specific to the front end (so we know which
errors are ours and which aren't).

browser/declarative_debugger.m:
	Add a new type, diagnoser_exception/0.  Handle these exceptions
	but rethrow any other kind.

browser/declarative_debugger.m:
browser/declarative_tree.m:
	Move the mercury_edt/2 instance to the new module.

browser/mdb.m:
	Add the new module to the mdb library.

browser/declarative_*.m:
	Call throw/1 instead of error/1.

tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/catch.exp:
tests/debugger/declarative/catch.inp:
tests/debugger/declarative/catch.m:
	A test case for debugging code that catches exceptions.  This sort
	of code is still not supported by the front end, but at least we
	now give a decent error message and allow debugging to resume.
 2002-09-13 04:17:47 +00:00
Zoltan Somogyi
985b13ed3f Make I/O actions known to the declarative debugger. 
Estimated hours taken: 48
Branches: main

Make I/O actions known to the declarative debugger. The debugger doesn't do
anything with them yet beyond asking about their correctness.

browser/io_action.m:
	New module for representing I/O actions, and for constructing the map
	from I/O action numbers to the actions themselves.

browser/mdb.m:
	Include the new module.

browser/declarative_analysis.m:
	Make the map from I/O action numbers to the actions themselves part
	of the analyzer state, since conversions from annotated trace nodes
	to EDT nodes may now require this information. This information is
	stored in the analyzer state because only the analyser needs this
	information (when converting annotated trace nodes to EDT tree nodes).
	It is not stored in the trace node store because its lifetime is
	different: its contents does not change during a tree deepening
	operation.

browser/declarative_execution.m:
	Store the current value of the I/O action counter with each call and
	exit node. The list of I/O actions associated with the atom of the exit
	node is given by the I/O actions whose counters lie between these two
	values (initial inclusive, final exclusive).

browser/declarative_debugger.m:
browser/declarative_oracle.m:
	Distinguish atoms associated with exit nodes from atoms associated with
	call nodes, since the former, but not the latter, now have a list of
	I/O actions associated with them.

browser/declarative_user.m:
	Add mechanisms for printing and browsing the I/O actions associated
	with EDT nodes and bugs.

runtime/mercury_trace_base.[ch]:
	Move the code for finding an I/O action here from the file
	mercury_trace_declarative.c, for use by browser/io_action.m.

runtime/mercury_layout_util.[ch]:
	Move a utility function here from mercury_trace_declarative.c,
	for use by the code moved to mercury_trace_base.c.

trace/mercury_trace_declarative.c:
	When invoking the front end, pass to it the boundaries of the required
	I/O action map. Cache these boundaries, so we can tell the front end
	when reinvocation of the back end by the front end (to materialize
	previously virtual parts of the annotated trace) does not require
	the reconstruction of the I/O action map.

trace/mercury_trace_vars.[ch]:
	Separate out the code for finding an I/O action from the code for
	browsing it, for use in mercury_trace_declarative.c.

	Note places where the implementation does not live up to the
	documentation.

trace/mercury_trace.[ch]:
	Add a parameter to MR_trace_retry that allows retries to cross I/O
	actions without asking the user if this is OK.

trace/mercury_trace_internal.c:
trace/mercury_trace_external.c:
	Pass MR_FALSE as this new parameter to MR_trace_retry.

tests/debugger/declarative/tabled_read_decl.{m,inp,exp}:
	A slightly modified copy of the tests/debugger/tabled_read_decl test
	case, to check the declarative debugger's handling of goals with I/O
	actions.

tests/debugger/declarative/Mmakefile:
	Enable the new test case.
 2002-05-15 11:24:21 +00:00
Mark Brown
14ceb68776 Change the definitions of decl_question and decl_answer in the declarative 
Estimated hours taken: 24
Branches: main

Change the definitions of decl_question and decl_answer in the declarative
debugger.  Each question now contains a reference to the EDT node that
generated the question, and each answer contains the reference from the
question it applies to.  Previously, the answers referred to the questions
themselves.

This change means that the analyser no longer needs to unify questions
to determine what to do with an answer.  The reason we need to avoid
this is that questions may contain higher order terms, and these will
cause a runtime abort if unified.  Also, by using our new approach it is
possible to simplify the analyser in a number of ways.

This is the first part of a larger change to support declarative debugging
of higher order code.  The main task remaining is to avoid using comparison
of questions in the oracle.  But this will require a different approach
than the one taken here, because the oracle is interested in the value of
the question, not just the identity of it.

browser/declarative_*.m:
	Propagate the effect of the changes to decl_question and decl_answer.

	Fix some comments which are out of date, and elaborate on some others
	which don't give enough information.

browser/declarative_analyser.m:
	Remove the definition of the suspect/1 type.  Its main purpose
	was to associate a question with its EDT node, but this is no
	longer required.  Update the places that used suspect(T) to instead
	use either decl_question(T) or just T, as appropriate.

	Separate out the code which calculates the analyser response.  This
	requires adding some fields to the analyser state, but this in turn
	means that the processing of answers can be greatly simplified.
	This should also make implementing more sophisticated search
	strategies possible, which is something we want to do in the
	future.

browser/declarative_debugger.m:
	Make the changes to the two exported types.  Export a function which
	extracts the EDT node from the question.

browser/declarative_oracle.m:
browser/declarative_user.m:
	Add a type parameter to oracle_response and user_response, similarly
	to the change to the other types.

tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/dependency2.exp:
tests/debugger/declarative/dependency2.inp:
tests/debugger/declarative/dependency2.m:
	A test case, which tests for a bug I encountered when developing
	this change.

tests/debugger/declarative/family.exp:
	Because of the change to the way the analyser matches up the answers
	with the EDT, a different but equally valid instance of the same bug
	is chosen in part of this test case.  Update the expected output to
	reflect this.
 2002-04-30 07:08:02 +00:00
Mark Brown
03a8cad379 Document the type variable naming conventions for mercury_edt. 
Estimated hours taken: 0.1
Branches: main

browser/declarative_analyser.m:
	Document the type variable naming conventions for mercury_edt.

browser/declarative_execution.m:
	Document the type variable naming conventions for annotated_trace.

browser/declarative_debugger.m:
	Document the type edt_node/1.
 2002-04-24 17:43:56 +00:00
Zoltan Somogyi
700e5cc1b6 Redesign the way the declarative debugger tracks dependencies, to avoid bugs 
Estimated hours taken: 60
Branches: main

Redesign the way the declarative debugger tracks dependencies, to avoid bugs
and make the code comprehensible. This required tackling an issue we could
ignore before: the typeinfos added to procedure arguments by the compiler.

browsers/declarative_debugger.m:
	Rewrite the dependency algorithm from scratch. It now has three phases:
	materializing the contour leading up to the relevent point in the
	procedure body, using that contour to construct a list of the conjoined
	primitive operations executed up to that point by the procedure body,
	and tracking the source of the marked subterm in this list of
	primitives.

	Add a mechanism to print out the result of the dependency tracking
	algorithm if a flag is set, for testing and debugging.

browsers/declarative_analyser.m:
	Transmit the result of the dependency tracking algorithm to where
	it may be printed out.

browsers/declarative_user.m:
	Update the user interface to make it switchable between viewing atoms
	from the user's perspective (with compiler-generated arguments hidden)
	and the implementor's perspective (with compiler-generated arguments
	visible). The default view is the user view.

browsers/declarative_execution.m:
	Add the immediate parent's goal path to the representation of call
	events; this allows us to place the call in the body of its parent.

	Expand the representation of atom arguments to include their HLDS
	variable numbers, and a boolean that says whether the argument
	is a programmer-visible headvar.

	Use this extra information to add support for indexing lists of
	arguments from either the user view or the implementor view.

	Add field names to several types.

browsers/program_representation.m:
	Add a field to plain calls, giving the name of the module defining
	the called procedure. This is necessary to reliably distinguish
	the builtin unify and compare procedures, calls to which must be
	handled specially because they generate no events. (They don't need to,
	since they are correct by construction.)

	Add mechanisms for converting goal paths from strings to structured
	terms, for use by the dependency tracking code.

	Add tests on atomic goals, for use by the dependency tracking code.

	Add a mechanism to let C code retrieve the types of proc_reps as well
	as goal_reps.

compiler/prog_rep.m:
	Fill in the module name field in plain calls.

trace/mercury_trace_vars.[ch]:
	Add functions to get information about a variable specified by HLDS
	number.

trace/mercury_trace_declarative.c:
	Include typeinfos in the atoms constructed at interface events.
	(The same code will work for typeclassinfos as well, once they
	become deconstructable and hence printable.)

	Fill in the extra slot in call events, and the extra slots in
	representations of atom arguments.

trace/mercury_trace_internal.c:
	Fix a bug in the implementation of the proc_body command: the
	type of the proc_rep slot is proc_rep, not goal_rep.

tests/debugger/declarative/dependency.{m,inp,exp}:
	A new test case to exercise dependency tracking. It cooperates with
	instrumentation code in the browser directory to print out the result
	of each trace_dependency operation.

	The test case also tests the proc_body command.

tests/debugger/declarative/Mmakefile:
	Enable the new test case.
 2002-04-23 08:52:46 +00:00
Mark Brown
d9f96a8c20 Use record syntax for the analyser state. 
Estimated hours taken: 0.25
Branches: main

browser/declarative_analyser.m:
	Use record syntax for the analyser state.
 2001-04-23 17:28:55 +00:00
Mark Brown
75a2a90cbb This is the second part of a change to support term dependency analysis 
Estimated hours taken: 40
Branches: main

This is the second part of a change to support term dependency analysis
in the declarative debugger.  A `mark' command is implemented for the
term browser, which allows a particular subterm to be selected and
returned from the browser.  The declarative debugger interprets this as
a suspicious subterm, and tries to find a child or sibling node from which
this subterm comes.  This is used to determine the next question to be
asked of the oracle.

browser/browse.m:
	Update the browser interface to allow for marked subterms being
	returned from the browser.

	Implement and document the mark command.

	Rewrite run_command as a switch instead of a chain of if-then-elses.
	This forces all unimplemented commands to be explicitly listed,
	and gives better error checking.

browser/browser_info.m:
	Add a maybe_mark field to the browser_info.  It is initially `no',
	but is updated when the mark command is given.

browser/declarative_analyser.m:
	Select which child or sibling node to ask about next by searching
	for the origin of the suspicious subterm.  If the subterm has mode
	`out' we act as if the oracle had answered no, and if the subterm
	has mode `in' we act as if the oracle had answered yes.  In future
	we may not wish to presume this -- we do so now mainly to keep the
	analysis algorithm simpler.

browser/declarative_debugger.m:
	Add a functor for suspicious subterms to the decl_answer type.

browser/declarative_oracle.m:
	Accommodate the changed answer type.  The oracle does not try to
	store information about suspicious subterms in the knowledge base,
	because in principle this could lead to infinite loops (although
	currently this wouldn't be a problem since we don't ever use the
	information to move upward in the tree, so no cycle could be
	formed).

browser/declarative_user.m:
	Accommodate the changed answer type, and interpret marked terms
	from the browser as suspicious subterms.

browser/parse.m:
	Add the new command.

browser/program_representation.m:
	Add a procedure to convert the browser's list(dir) to a term_path.

	Change atomic_goal_rep_is_call/2 so it fails for special predicates,
	which was originally intended.

trace/mercury_trace_browse.c:
	Ignore the extra argument -- marked terms are not currently used in
	the main debugger.

tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/input_term_dep.*:
tests/debugger/declarative/output_term_dep.*:
tests/debugger/declarative/special_term_dep.*:
	New test cases.
 2001-04-23 16:26:38 +00:00
Mark Brown
0b062bc60f This is the first part of a change to support term dependency analysis 
Estimated hours taken: 80

This is the first part of a change to support term dependency analysis
in the declarative debugger.  A method is added to the mercury_edt
typeclass which finds the origin of a selected subterm in an EDT node,
somewhere in the body of the call or in the body of the parent.  The
other parts of the change required before this can be useful are to
modify the search strategy (in browser/declarative_analyser.m) to make
use of the new information, and to modify the user interface to allow
a subterm to be selected.  They will be committed as separate changes.

The typeclass method first traverses one or more contours, matching the
contour events up with goals in a procedure representation.  This matching
process requires a left to right traversal, because we need to know which
disjunct/arm/branch was taken before we can match subgoals, and the
DISJ/SWTCH/THEN/ELSE events which tell us this information occur at the
left edge of the subgoals to which they apply.  But we must always start
from the right hand side of the contour being traversed, so this means
that a right to left traversal is required before the matching can start.

Using the contour matched up with the atomic goals, we track the location
of a subterm by looking at which variables are bound, while scanning right
to left along the contour.  Because this must happen after the matching,
this must be a separate right to left traversal than the earlier one.
Therefore the algorithm implemented here requires two passes over the
contours in order to find the origin of the selected subterm.

browser/declarative_execution.m:
	Add a maybe(goal_rep) to call nodes in the annotated trace.  This
	is `no' if the relevant module was compiled below trace level `rep'.

trace/mercury_trace_declarative.c:
	If the information is available, fill in the goal_rep when
	constructing call nodes.

browser/declarative_analyser.m:
	Add the new method to the mercury_edt typeclass.

browser/declarative_debugger.m:
	Implement the new method.  Update for the changed call nodes.

browser/program_representation.m:
	Add a version of goal_paths to be used by the declarative debugger,
	and a predicate to parse these from goal_path_strings.  Add the
	types arg_pos and term_path to represent a subterm of a call or exit.

browser/program_representation.m:
compiler/prog_rep.m:
	No longer store conjunctions in reverse order in the goal_rep; we now
	store them in the same order as in the HLDS.

	Although we search conjunctions in reverse order, we need to match
	them up with contour events before doing that.  This can only be
	done in the forwards direction, so it turns out that there is no
	advantage in storing them in reverse order.

compiler/hlds_goal.m:
compiler/trace.m:
	Add comments to the existing definitions of goal_path and
	path_step_to_string.
 2001-01-16 15:44:25 +00:00
Mark Brown
9578ff16bb Alter the `dd' command in mdb so that it does not assume that the answer 
Estimated hours taken: 2.5

Alter the `dd' command in mdb so that it does not assume that the answer
to the first question asked is `no'.  The question is somewhat redundant,
since the only sensible answer is `no', but I find that it gives useful
feedback about the symptom that is being diagnosed, and it makes clearer
why the following questions are asked.

browser/declarative_analyser.m:
	Start analysis with a list of suspects which contains only the
	topmost node of the debugging tree.

browser/declarative_debugger.m:
	If the answer to the first question is something other than `no',
	then end the diagnosis and report that no bugs were found.

tests/debugger/declarative/*.{inp,exp,exp2}:
	Update test cases to handle the extra question.
 2000-08-18 10:59:40 +00:00
Mark Brown
1c587d56af Implement the expanding of implicit subtrees in the declarative debugger. 
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.
 2000-05-08 18:17:45 +00:00
Mark Brown
134e188154 Represent bugs directly rather than with edt nodes. 
Estimated hours taken: 10

Represent bugs directly rather than with edt nodes.  This makes the
interface to the analyser more consistent: bugs are now handled
in much the same way as questions.

browser/declarative_analyser.m:
	- In the mercury_edt/2 typeclass, change edt_root/3 to
	  edt_root_question/3 and add the method edt_root_e_bug/3.
	- Add the type prime_suspect/1 which keeps track of the
	  evidence (oracle answers) which implicates a particular
	  edt node.
	- Use the new bug representation.

browser/declarative_debugger.m:
browser/declarative_oracle.m:
	- Move oracle_confirmation to declarative_debugger.m, and
	  rename it decl_confirmation.

browser/declarative_debugger.m:
	- Change decl_bug/1 to decl_bug/0.  Instead of a bug being
	  represented by an edt node, decl_bug now represents
	  directly the different sorts of bugs possible.
	- Add an implementation for the new mercury_edt method.

browser/declarative_oracle.m:
browser/declarative_user.m:
	- Update the confirmation to use the new types.

tests/debugger/declarative/*.{exp,exp2}:
	- Update test results.
 2000-03-01 04:17:27 +00:00
Simon Taylor
9ba3b14098 Make all the modules in the browser library sub-modules of 
Estimated hours taken: 1

Make all the modules in the browser library sub-modules of
module `mdb', to avoid link errors when users use module names
such as `parse'.

browser/Mmakefile:
browser/browser_library.m:
browser/mdb.m:
	Rename browser_library.m to mdb.m.
	Change `:- import_module' declarations to
	`:- include_module' declarations.

browser/Mmakefile:
	Remove the special case rule for `mer_browser.init' --
	it doesn't work when the file names are not the same
	as the module name. Instead, the default rule for `mdb.init'
	is used and the output is copied to `mer_browser.init'.

browser/.cvsignore:
	Rename header files, etc.

browser/*.m:
	Add a `mdb__' prefix to the names of modules in the browser library
	in `:- module' and `:- import_module' declarations.

trace/*.c:
	Rename the header files for the browser library in
	`#include' statements.

tests/hard_coded/Mmakefile:
tests/hard_coded/parse.m:
tests/hard_coded/parse.exp:
	Test case.
 2000-02-04 03:45:53 +00:00
Mark Brown
3e065c040e Implement the new architecture for the front end of the 
Estimated hours taken: 120

Implement the new architecture for the front end of the
declarative debugger.  Disable declarative debugging if conservative
GC is not being used since this change relies on it.  The benefits
of declarative debugging in non-GC grades are not worth the extra
maintenance required to support it, since even small examples require
a large amount of memory.

browser/declarative_analyser.m:
	New module which handles the analysis of EDTs, which was
	previously done in browser/declarative_debugger.m.

browser/declarative_debugger.m:
	- Change the interface according to the new design.
	- Export types of the form decl_*, rather than edt_*.
	- Move the EDT analysis to the new module.
	- Handle the interaction between the analyser and the oracle.
	- Don't interact directly with the user, but go via the oracle.
	- New diagnoser state type.
	- Update the EDT instance to conform to the other changes.

browser/declarative_oracle.m:
	- Replace oracle_answer type with oracle_response.
	- Allow the oracle to work with a queue of questions rather
	  than one at a time.
	- Add new predicates to manipulate the knowledge base.

browser/declarative_user.m:
	- Export the user_state type.
	- Handle some user commands in this module.
	- Handle questions properly (apart from printing atoms).

browser/browser_library.m:
	Add the new module.

trace/mercury_trace_declarative.c:
	- Initialise the front end state just once per session.
	- Make the step size much larger, since implicit subtrees
	  are not fully supported yet.
	- Correct the types in a format specifier.

trace/mercury_trace_declarative.c:
trace/mercury_trace_internal.c:
trace/mercury_trace_internal.h:
	- Disable declarative debugging unless conservative GC is used.
 2000-01-03 02:23:04 +00:00