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.
Estimated hours taken: 1
Branches: main
browser/collect_lib.m:
browser/declarative_debugger.m:
browser/declarative_execution.m:
browser/dl.m:
browser/interactive_query.m:
browser/io_action.m:
browser/mdb.m:
browser/name_mangle.m:
browser/util.m:
Add Mercury versions of code which has been defined only as
foreign procs so as to allow this directory to compile for
the non-C backends.
The Mercury versions just call private_builtin__sorry.
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.
Estimated hours taken: 1
Branches: main
Add the command 'pd' to the declarative debugger. This command returns
to the procedural debugger at the event corresponding to the current
question; it is notionally the inverse of the 'dd' command in the
procedural debugger.
browser/declarative_user.m:
Handle the new command, and add a new alternative to the
user_response type.
browser/declarative_oracle.m:
Handle the new user response, and add a new alternative to the
oracle_response type.
browser/declarative_debugger.m:
Handle the new oracle response, and add a new alternative to the
diagnoser_response type.
Export some procedures to C so that the back end can interpret the
new diagnoser response.
Update an old comment.
trace/mercury_trace_declarative.c:
Handle the new diagnoser response. Rename the function
MR_decl_handle_bug_found, since it now also handles the case
where a symptom has been found.
Interpret the diagnoser response using something like a switch,
rather than something like an if-then-else. This gives better
error messages if the diagnoser response type is changed.
doc/user_guide.texi:
Document the new command.
tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/pd.exp:
tests/debugger/declarative/pd.inp:
tests/debugger/declarative/pd.m:
Test the new feature.
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.
Estimated hours taken: 16
Branches: main
Make the declarative debugger more flexible with how it interprets
trace event sequences. This makes the declarative debugger "smarter":
it is now able to handle code that makes use of solutions/2 and its
variants, and it is not confused if it misses some events due to shallow
tracing. It does, however, ask more questions than it would with full
tracing; this is unavoidable because it doesn't have the information about
backtracking that it would normally use to prune questions away. (Later
we will be able to get the information we need by using "hidden" events.)
This version should (almost, see the XXX) be able to handle any of the
proposals that have recently been made on mercury-developers mailing list
regarding "interface" tracing. The requirements on trace event sequences
are:
1) if there are any events from a certain class (e.g. interface events,
negation events, disj events) then we require all events of that
class;
2) if there are any disj events, we require all negation events
and if-then-else events.
XXX At the moment, there is another requirement:
3) the depth limiting part of the code that constructs annotated
traces requires that the depths of consecutive events differ
by no greater than one.
This limitation shouldn't be difficult to remove, but that will come in
a later change.
browser/declarative_debugger.m:
Document the assuptions the front end makes about trace sequences.
Instead of detecting the start of a contour or stratum by looking
for a particular type of event, get the caller to pass in the
identity of the event at the start.
If a fail event is encountered when stepping left on a contour,
this indicates that some internal events were not seen. Treat
the entire failed call (as well as any later conjuncts) as being
in a negated context; that is, call missing_answer_children on
this section of the tree, with the start of the "context" being
the event before the call event corresponding to the fail we
encountered.
Similarly, if a neg_fail event is encountered when stepping left
on a contour don't assume that it must have been backtracked over.
That assumption is currently valid, but may not be in future
depending on what we decide to do with hidden events.
tests/debugger/declarative/Mmakefile:
Enable the tests 'solutions' and 'shallow'.
tests/debugger/declarative/untraced_subgoal.exp:
tests/debugger/declarative/untraced_subgoal.inp:
Update the input and output of this test to allow for the extra
questions.
tests/debugger/declarative/untraced_subgoal.m:
Improve some comments.
tests/debugger/declarative/shallow.exp:
tests/debugger/declarative/shallow.inp:
Provide correct input and expected output for this test.
tests/debugger/declarative/shallow_2.m:
Fix some incorrect comments.
tests/debugger/declarative/solutions.exp:
tests/debugger/declarative/solutions.inp:
tests/debugger/declarative/solutions.exp2:
tests/debugger/declarative/solutions.inp2:
New files. Provide input and expected output for this test. We
need an alternative input file for debug grades because these
produce interface events for the library predicate solutions/2,
hence extra questions are generated.
Estimated hours taken: 12
Branches: main
Until now, programmers could add `tabled_for_io' annotations to foreign_procs
that do I/O, which asks the compiler to make those foreign_procs idempotent,
i.e. ensures that they are performed at most once even in the presence of a
retry operation in the debugger. This change adds a compiler option,
--trace-table-io-require, which generates an error if a foreign_proc that does
I/O does not have this annotation. Specifying this option thus ensures
that all I/O done by the program is idempotent.
In the future, we may want to have this option turned on in all debugging
grades. Until we decide about, the new option is not yet documented.
compiler/options.m:
Add the new option --trace-table-io-require.
compiler/handle_options.m:
Make --trace-table-io-require imply --trace-table-io.
compiler/table_gen.m:
If --trace-table-io-require is enabled, require all I/O primitives
to have the tabled_for_io annotation.
compiler/mercury_compile.m:
Pass I/O states to table_gen.m, since it can now generate error
messages.
trace/mercury_trace_util.h:
trace/mercury_trace_vars.c:
When calling Mercury code from the trace directory, disable I/O
tabling, since any I/O actions executed by Mercury code in the browser
directory (or by library code called from there) should not be tabled,
not being part of the user program.
Due to the depth of nesting, make mercury_trace_vars.c use four-space
indentation.
browser/collect_lib.m:
browser/declarative_debugger.m:
browser/declarative_execution.m:
browser/dl.m:
browser/io_action.m:
browser/mdb.m:
browser/name_mangle.m:
browser/util.m:
compiler/gcc.m:
compiler/mercury_compile.m:
compiler/passes_aux.m:
compiler/process_util.m:
compiler/stack_layout.m:
library/io.m:
library/time.m:
tests/debugger/declarative/tabled_read_decl.m:
Add a whole lot of tabled_for_io annotations, to enable the compiler to
bootstrap with --trace-table-io-require enabled.
In many cases, this required turning old-style pragma c_code into
pragma foreign_proc. While doing that, I standardized the layouts
of pragma foreign_procs.
browser/util.m:
Turn an impure semidet predicate into a pure det predicate with I/O
states, to allow it to be tabled. Make it return a Mercury bool
to indicate success or failure.
library/bool.m:
Add functions that allow C code to get their hands on the constants
`yes' and `no', for communication with Mercury code.
library/table_builtin.m:
Add debugging code to the main primitive of I/O tabling. This is
controlled both by the macro for retry debugging and a boolean global.
library/mercury_trace_base.[ch]:
Add the boolean global variable to switch the new debugging code in
table_builtin.m on and off.
library/mercury_trace_internal.c:
When starting I/O tabling with retry debug enabled, turn on the switch.
tests/debugger/queens.exp3:
New expected output file that applies when the library is compiled with
--trace-table-io-require.
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.
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.
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.
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.
Estimated hours taken: 2
Branches: main
Add two pieces of information that will be needed to an upcoming change
to the representation of procedure bodies in the declarative debugger.
The first piece is the full list of head vars. This is needed now because the
debugger no longer ignores variables of type type_info, and thus the Nth
headvar is no longer guaranteed to be variable number N. The second piece
is a cut/no_cut indicator in `some' goals. This is needed to allow us to
reconstruct goal paths exactly as we traverse goal representations.
browser/program_representation.m:
Make the two data structure changes described above.
browser/*.m:
Trivial changes to conform to the new data structures.
compiler/prog_rep.m:
Create the updated data procedure representation.
compiler/*.m:
Record and transmit the information needed by the updated procedure
representation.
runtime/mercury_stack_layout.h:
Update the documentation of the relevant field in proc_layouts.
Estimated hours taken: 2
Branches: main
browser/*.m:
Make the debugger use the committed choice versions of the
deconstruction predicates, and propagate the committed choice
environment up the call chain as far as necessary.
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.
Estimated hours taken: 5
Fix a bug in term dependencies in the declarative debugger. The code
is not currently used, but is required for a change that I am working
on at the moment. This will be committed on the main branch only.
browser/declarative_debugger.m:
Make sure the list of atomic goal representations is built in
mode-correct order.
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.
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.
Estimated hours taken: 8
Implement declarative debugging of code that throws exceptions.
This aborts if used on code that handles exceptions. There is no point
dealing with this yet, since the oracle won't handle the higher order
argument to try/2.
browser/declarative_debugger.m:
Add "unexpected exception" questions and "unhandled exception" bugs,
and generate these from EXCP events. Handle the exception case
in various switches.
Add a predicate unexpected_exception_children/4, analogous to
{wrong,missing}_answer_children/4.
browser/declarative_execution.m:
Add excp/5 nodes to the event trace, and export a C function to
construct them. Handle these nodes in various switches.
Allow contours to extend beyond NEGE events, if the status is
`undecided'. Such events have no matching NEGS or NEGF event,
so they do not mark the boundary of a separate context.
browser/declarative_oracle.m:
Store information about which exceptions should/shouldn't be thrown
from various calls, and use this information to answer questions
where possible.
browser/declarative_user.m:
Handle the new questions and bugs.
trace/mercury_trace_declarative.c:
Add a function to deal with EXCP events.
trace/mercury_trace_internal.c:
Allow declarative debugging to be started from EXCP events.
tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/throw.m:
tests/debugger/declarative/throw.inp:
tests/debugger/declarative/throw.exp:
tests/debugger/declarative/throw.exp2:
A test case for this feature.
tests/debugger/declarative/queens.exp:
Update the output from this test.
Estimated hours taken: 8
Fix a bug in the handling of implicit subtrees: the debugger was not
always skipping gaps in the contours properly. The fix is to find an
earlier contour when a dead end is reached (at FAIL, REDO and NEGF events).
The bug was in step_left_in_contour/2, but the same bug appeared in
wrong_answer_children/4 which was doing essentially the same work.
To avoid problems like this in future, the latter has been rewritten
in terms of the former. Similarly, missing_answer_children/4 has been
rewritten in terms of a new function step_in_stratum/2.
browser/declarative_debugger.m:
Rewrite {wrong,missing}_answer_children in terms of the
step functions.
browser/declarative_execution.m:
Export the step functions for use in the mercury_edt instance;
this means that they must be polymorphic (the previous monomorphic
versions are now called *_store). step_left_in_contour/2
is the same as before except that it also handles REDO nodes,
and the clauses are grouped together logically (for readibility).
step_in_stratum/2 is a new function.
tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/untraced_subgoal.m:
tests/debugger/declarative/untraced_subgoal_sub.m:
tests/debugger/declarative/untraced_subgoal.inp:
tests/debugger/declarative/untraced_subgoal.exp:
A test case for this change. This test is only effective if
there are no events from the sub-module, so it is disabled in
debug grades.
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.
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.
Estimated hours taken: 15
Fix the user interface of the declarative debugger so that it
produces more readable output; the representation of atoms
is updated so that it can handle non-ground arguments.
Ensure that all DD output goes through the correct stream, so that
the debugger works properly under emacs.
browser/declarative_debugger.m:
Call a procedure in the oracle to handle bug confirmation
(including printing out the bug), rather than handle
it directly.
browser/declarative_execution.m:
Update the trace_atom type so that it can handle both ground
and free arguments. Export to C some procedures for
constructing trace atoms.
browser/declarative_oracle.m:
Export a procedure which handles bug confirmation. This calls
the declarative_user module to do the interaction, and interprets
the result.
browser/declarative_user.m:
Export a procedure to handle bug confirmation by the user.
Update to handle the changes to trace_atom.
trace/mercury_trace_declarative.c:
Construct trace_atoms by calling the new Mercury procedures
exported from browser/declarative_execution.m.
trace/mercury_trace_declarative.h:
Remove the macro that had been used to construct old style atoms.
trace/mercury_trace_vars.{c,h}:
Export a procedure to calculate the argument position of a
head variable.
tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/args.{m,inp,exp,exp2}:
New test case to test mixing bound and free arguments.
tests/debugger/declarative/*.inp:
tests/debugger/declarative/*.exp:
tests/debugger/declarative/*.exp2:
Update test cases to reflect new output, and the extra question
asked for bug confirmation.
Estimated hours taken: 25 (plus ? by zs)
Bring the implementation up to date with the algorithm that is
described in the paper (papers/decl_debug). Add some debugging
infrastructure to the back end, which was used to debug this
change.
browser/declarative_execution.m:
- Store the call sequence number in call nodes.
- Store the previous redo (if there is one) in fail nodes.
- Use a functor specifically for switches.
- Use a pointer to the first disj event, instead of a pointer
to the event before it.
- Export two new predicates for dereferencing disj node ids.
- Export (to C) a procedure for accessing the call sequence number,
and a procedure for getting to the first disj event.
- Split the scan_backwards function into two: step_left_in_context
and find_prev_contour.
browser/declarative_debugger.m:
trace/mercury_trace_declarative.c:
- Use the updated data structure.
runtime/mercury_conf_param.h:
- Add the configuration parameter MR_USE_DECL_STACK_SLOT, which
makes the declarative debugger use stack slots reserved by
the compiler to cache the location of the call node.
trace/mercury_trace_declarative.h:
trace/mercury_trace_declarative.c:
- Use stack slot only if MR_USE_DECL_STACK_SLOT is defined.
- If not using stack slot, use the new algorithm to search
for a matching call or exit event.
- Avoid using a global by passing the previous node to
MR_trace_decl_* and returning the new node.
- Rename MR_trace_call_node_answer to
MR_trace_call_node_last_interface.
- Update comments.
browser/declarative_execution.m:
trace/mercury_trace_declarative.c:
- Added debugging output for various events of interest
in the back end. It is activated when MR_DEBUG_DD_BACK_END
is set.
tests/debugger/declarative/aadebug.m:
tests/debugger/declarative/aadebug.inp:
tests/debugger/declarative/aadebug.exp:
tests/debugger/declarative/aadebug.exp2:
- Update this test to match the example in the paper.
tests/debugger/declarative/propositional.inp:
tests/debugger/declarative/propositional.exp:
tests/debugger/declarative/propositional.exp2:
- Update this test case so it gives a similar result in
debugging grades to non-debugging grades.
tests/debugger/declarative/app.exp2:
tests/debugger/declarative/if_then_else.exp2:
- Update test case results.
tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/backtrack.m:
tests/debugger/declarative/backtrack.inp:
tests/debugger/declarative/backtrack.exp:
- New test case.
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.
Author: dougl
Estimated hours taken: 25 (mostly hand checking the test results)
Fix a bug in the front end which was causing some questions
to be missed. Reorganize the expected test results, as suggested
after the last commit.
browser/declarative_debugger.m:
Fix a bug in missing answer children/4.
tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/aadebug.m:
tests/debugger/declarative/aadebug.inp:
tests/debugger/declarative/aadebug.exp:
New test case.
tests/debugger/declarative/family.m:
tests/debugger/declarative/higher_order.m:
tests/debugger/declarative/ite_2.m:
tests/debugger/declarative/solutions.m:
New test cases for unimplemented features. These tests are
not yet enabled.
tests/debugger/declarative/*.exp:
tests/debugger/declarative/*.exp2:
Swap the .exp files for the .exp2 files. This is to be
consistent with the other test directories, where the .exp files
contain normal output and the .exp2 files contain output in
debug grades.
tests/debugger/declarative/*.inp:
tests/debugger/declarative/*.exp:
tests/debugger/declarative/*.exp2:
Use `register --quiet' to make the output of the test cases
more predictable.
tests/debugger/declarative/gcf.exp2:
tests/debugger/declarative/neg_conj.exp2:
tests/debugger/declarative/negation.exp2:
tests/debugger/declarative/oracle_db.exp2:
tests/debugger/declarative/queens.exp2:
tests/debugger/declarative/small.exp2:
Remove these expected results, since using `register --quiet'
makes them the same as the .exp versions.
Estimated hours taken: 5
Fix the output of the declarative debugger so that it prints out
something that resembles a bug. Re-enable all the test cases,
and add some new ones. Add an `.exp2' file for each case, so
that tests work in debug grades as well as non-debug grades.
browser/declarative_debugger.m:
Output a text representation of the bug. The output is
rather unpretty, but allows us to check that the bug was
found correctly.
tests/debugger/declarative/Mmakefile:
Enable the new test cases. Re-enable the old ones.
tests/debugger/declarative/app.exp:
tests/debugger/declarative/gcf.exp:
tests/debugger/declarative/if_then_else.exp:
tests/debugger/declarative/oracle_db.exp:
tests/debugger/declarative/propositional.exp:
tests/debugger/declarative/queens.exp:
Update old test case results.
tests/debugger/declarative/app.exp2:
tests/debugger/declarative/gcf.exp2:
tests/debugger/declarative/if_then_else.exp2:
tests/debugger/declarative/oracle_db.exp2:
tests/debugger/declarative/propositional.exp2:
tests/debugger/declarative/queens.exp2:
Alternative results for old test cases.
tests/debugger/declarative/big.{m,inp,exp,exp2}:
tests/debugger/declarative/lpe_example.{m,inp,exp,exp2}:
tests/debugger/declarative/neg_conj.{m,inp,exp,exp2}:
tests/debugger/declarative/negation.{exp,exp2,inp}:
tests/debugger/declarative/small.{m,inp,exp,exp2}:
New test cases.
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.
Estimated hours taken: 160
Implement a new data structure for declarative debugging. The
major differences between this and the old implementation are:
- The data structure is implemented in Mercury. The definition
of the type, and procedures for constructing values of that
type, have been moved from trace/mercury_trace_declarative.{c,h}
to browser/declarative_execution.m (which is a new module).
- The front end no longer needs to call the back end via an
indirect pointer---the front end does not call the back end at
all.
- The data structure is not specifically for wrong answer
analysis, it is intended to be used for any sort of analysis.
- The data structure represents execution at a lower level---the
new front end defines a more abstract view in terms of this
data structure.
Implement a test harness for debugging the front end code. This allows
the front end to run as a stand-alone program, which can then be
debugged using `mdb'.
The code in the front end does not currently handle the new structure
very nicely. This is because that code is about to undergo some major
structural changes, so there is little point cleaning it up now.
Consequently:
- Some of the code in the front end is incorrect (eg. the
user interface does not print missing answer nodes
properly).
- The tests have not been reinstated.
These things will be fixed in subsequent changes.
Likewise the compiler still reserves two stack slots, even though
only one is required. After this change the algorithm should be able
to get away with using no stack slots, so modifications to the compiler
will be postponed until then.
browser/declarative_execution.m:
New module. Implement the execution_tree typeclass, which
represents the execution of a Mercury program. Implement
two instances of this typeclass, one for normal use and one for
testing purposes.
browser/declarative_test.m:
New module. A test harness that can be compiled as a
stand-alone program, enabling the front end to be debugged.
trace/mercury_trace_declarative.c:
trace/mercury_trace_declarative.h:
- Remove the definition of the old data structure.
- Add some macros which enable the new Mercury data structure
to be destructively updated by C code.
- Change the interface to this module so that it reflects more
general diagnosis, not just wrong answer analysis.
- Implement the new algorithm.
- Call an alternative front end if in test mode.
- Update comments.
trace/mercury_trace_internal.h:
Add a new mode for debugging the declarative debugger.
trace/mercury_trace_internal.c:
Change the command from `dd_wrong' to `dd', since it is not
specifically for wrong answer analysis. Add a new command
`dd_dd' which calls the alternative front end used for testing.
runtime/mercury_init.h:
runtime/mercury_wrapper.c:
runtime/mercury_wrapper.h:
util/mkinit.c:
Remove any reference to `MR_edt_root_node', since it is no
longer used.
browser/declarative_debugger.m:
- Add a case for missing answer nodes to `edt_node'.
- Change the `evaluation_tree' typeclass into `mercury_edt'
typeclass. This is to make it more distinct from the new
`execution_tree' typeclass, which is a lower level concept.
- New interface to the diagnoser: types `diagnoser_response'
and `diagnoser_state', and procedure `diagnosis'.
- Define an instance of `mercury_edt' from an instance of
`execution_tree'.
- Updates to the analyser to get it to compile---further changes
will be forthcoming.
browser/declarative_user.m:
- Updates to the user interface to get it to compile---further
changes will be forthcoming.
browser/browser_library.m:
Import the new module (declarative_execution.m).
browser/debugger_interface.m:
browser/util.m:
Move the definitions of trace_port_type and goal_path_string
to browser/util.m, since they are now used by more than just
the external debugger.
browser/Mmakefile:
Add the test harness as a `depend' target.
browser/browse_test.m:
Use the correct interface to the browser.
Estimated hours taken: 55
This change adds a more sophisticated oracle to the declarative
debugger. The oracle now tries to remember previous answers and uses
them if available, and only asks the user if there is no other
information.
browser/declarative_oracle.m:
- Add the type "oracle_assumption", which identifies an
internal assumption of the oracle.
- Add the type "oracle_answer", which the oracle returns to the
caller. This holds either the truth value, or a reason why
the truth value cannot be given yet.
- Implement a knowledge base to store the previous answers.
This data structure is designed to be able to store arbitrary
assertions, although at this stage only one kind of assertion
is used.
- Where possible, use the KB to answer questions, instead of
asking the user.
- Update comments.
browser/declarative_debugger.m:
- Use the new interface to the oracle. Handle "don't know"
answers in a simple way: either save the question and ask it
later or return without finding any bug.
- Move the debugger_command type to this module.
- Move the UI stuff to a new module.
browser/declarative_user.m:
New module to handle interaction between the debugger/oracle
and the user.
tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/oracle_db.{m,inp,exp}
Add a test case for the new feature.
Estimated hours taken: 12
Clean up the declarative debugger.
browser/declarative_debugger.m:
browser/declarative_oracle.m:
- Add a new type, oracle_data, to store the oracle database.
- Thread an oracle database through a single call to the
front end.
- Replace `unknown' with a less overloaded name in
some type definitions.
trace/mercury_trace_declarative.c:
trace/mercury_trace_declarative.h:
browser/declarative_debugger.m:
- Improve documentation.
browser/declarative_debugger.m:
- Export new type, edt_truth.
- Improve the interface to the oracle.
- Add a new typeclass, evaluation_tree, and update the
previous interface to reflect this.
- Make declarative_bug a polymorphic type, and change the
constructor for buggy nodes from `wrong' to `e_bug'.
Estimated hours taken: 2
Add the option `--enable-decl-debug' to configure, which enables
declarative debugging support in the internal debugger.
configure.in:
Add the option to configure.
browser/declarative_debugger.m:
runtime/mercury_wrapper.c:
Avoid using MR_address_of_edt_root_node unless configured
for declarative debugging.
runtime/mercury_conf.h.in:
runtime/mercury_conf_param.h:
Move the configuration macro to mercury_conf.h.in.
trace/mercury_trace_declarative.c:
Define MR_edt_root_node only if configured for declarative
debugging, thereby undoing a previous change.
Estimated hours taken: 3
Fix a bug causing the debugger tests to get link errors.
browser/declarative_debugger.m:
Call MR_edt_root_node indirectly via MR_address_of_edt_root_node.
runtime/mercury_wrapper.{c,h}:
Add a global function pointer, MR_address_of_edt_root_node.
util/mkinit.c:
Make sure MR_address_of_edt_root_node is initialized.
trace/mercury_trace_declarative.c:
Define MR_edt_root_node even if the declarative debugger is not
used.
Estimated hours taken: 80
Add a front end to the declarative debugger, written in Mercury. Modify
the back end to call this whenever an EDT is built. Also, various
bug fixes and improvements.
browser/declarative_debugger.m:
New module. This is a first implementation of the front end of
the declarative debugger. It uses a simple top-down algorithm
to search the EDT for a buggy node. The results are printed
in a simple format to the output stream. It is called from the
back end, in trace/mercury_trace_declarative.c.
browser/declarative_oracle.m:
New module. This is a first implementation of an oracle for the
declarative debugger. It simply passes all queries directly
on to the user.
browser/browser_library.m:
Import the new modules.
trace/mercury_trace_declarative.c:
- Various fixes/improvements of comments.
- Fix bugs where `int' is used instead of `Unsigned'.
- Pass the event_info structure to MR_trace_decl_update_path,
rather than passing various components of it.
- Use the copy of MR_trace_event_number in the event_info structure
rather than referring to the global variable directly.
- Remove the EDT printing functions, as they have been superseded by
the new front end. Call the new front end instead of these old
functions.
- Provide an interface to the EDT nodes that is imported by the
front end.
- Ensure that, after diagnosis, we end up at the same event we
started at.
- Fix a bug where it was assumed all procedures had at least one
argument.
- Ensure that the user is notified if the dd_wrong operation cannot
be started due to MR_trace_retry failing.
trace/mercury_trace_declarative.h:
- Move a #include to the correct place.
- Declare the interface to the EDT nodes.
trace/mercury_trace_internal.c:
Fix a bug introduced earlier.
runtime/mercury_conf_param.h:
Add a new configuration macro, MR_DEBUG_DD_BACK_END. When defined
this causes information about the declarative debugger back end
to be printed out during operation.
