mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-17 14:57:03 +00:00
a77588f6d2
Estimated hours taken: 8
Branches: main
Add two new capabilities to the debugger.
The first capability is the idea of "held variables", variables that the
debugger holds onto even when execution has left the event they came from.
You can hold onto a variable via the mdb command "hold varname heldvarname".
You can suffix the name of the existing variable with a term path, in which
case the new held variable will refer only to the specified part of the term.
Later mdb commands can refer to the held variable by prefixing its name with
a dollar sign. For example, after "hold HeadVar__1^2 x", "$x" will refer to
the term that was the second argument of HeadVar__1 at the program point
at which the "hold" command was executed.
The second capability is the ability to compute the diff of two terms and
express those diffs as the term paths of the function symbols at which the two
terms differ, instead of the line numbers you get by using save_to_file and the
usual Unix diff command. The mdb command is "diff var1 var2". We limit the
number of term paths of difference sites that we display at any one time;
the mdb diff command has options to control this.
NEWS:
Mention the new capabilities.
doc/user_guide.texi:
Document the new mdb commands "hold" and "diff", the new mdb command
"held_vars" which simply lists the names of all the held variables
(just as "vars" lists the names of all the nonheld variables currently
accessible), and the concept of held variables.
doc/mdb_categories:
Update this file for the new mdb commands and concepts.
browser/browse_diff.m:
This new module implements the diff operation on terms.
browser/mdb.m:
Add the new module to the list of submodules of the mdb package.
browser/*.m:
Minor cleanups, such as importing only one module per line; there
are no algorithmic changes.
trace/mercury_trace_hold_vars.[ch]:
This new module implements the database of held variables.
trace/Mmakefile:
Mention the new module.
trace/mercury_trace_internal.c:
Implement the three new mdb commands.
trace/mercury_trace_vars.[ch]:
Modify the functions that recognize variable specifications or
process them to work with held variables as well as variables from
the current environment. This required some reorganization of the
internals of this module.
Provide some a utility function, MR_trace_parse_lookup_var_path,
for converting a string representing the specification of a term
(a variable and possibly some path within it) to the type and value
of that term. Make the utility function this is based upon,
MR_lookup_unambiguous_var_spec, replace the previous but less capable
MR_convert_var_spec_to_type_value.
trace/mercury_trace_spy.c:
Conform to the change in mercury_trace_vars.c.
trace/mercury_trace_util.c:
Make a utility function more robust.
trace/mercury_trace_alias.c:
Minor cleanups.
tests/debugger/queens.{inp,exp*}:
Update this test case to test the debugger's new capabilities.
tests/debugger/completion.{inp,exp*}:
Update this test case to expect the new mdb commands, and avoid the
ambiguity between "help" and "held_vars".
80 lines
2.6 KiB
Mathematica
80 lines
2.6 KiB
Mathematica
%---------------------------------------------------------------------------%
|
|
% Copyright (C) 2004-2005 The University of Melbourne.
|
|
% This file may only be copied under the terms of the GNU Library General
|
|
% Public License - see the file COPYING.LIB in the Mercury distribution.
|
|
%---------------------------------------------------------------------------%
|
|
|
|
% This module defines a type to represent both natural and synthetic terms
|
|
% for use by the browser.
|
|
|
|
:- module mdb.browser_term.
|
|
|
|
:- interface.
|
|
|
|
:- import_module bool.
|
|
:- import_module list.
|
|
:- import_module std_util.
|
|
|
|
:- type browser_term
|
|
---> plain_term(
|
|
univ % We are browsing a plain term.
|
|
)
|
|
; synthetic_term(
|
|
string, % We are browsing a synthetic term,
|
|
% such as a predicate name applied to
|
|
% a list of arguments. The string says
|
|
% what we should print as the functor.
|
|
list(univ), % The arguments.
|
|
maybe(univ) % If yes, the synthetic term represents
|
|
% a function call, and the argument
|
|
% inside the yes() is the return value.
|
|
).
|
|
|
|
% This predicate converts a term represented as univ to a browser term.
|
|
|
|
:- func univ_to_browser_term(univ) = browser_term.
|
|
|
|
% This predicate converts a plain term from the representation used
|
|
% in the trace directory to a browser term.
|
|
|
|
:- func plain_term_to_browser_term(T) = browser_term.
|
|
|
|
% This predicate converts a synthetic term from the representation used
|
|
% in the trace directory (as a list of arguments, the last of which
|
|
% represents the return value for function calls) to the representation
|
|
% used in the browser directory, in which a function call's return
|
|
% value is stored separately from the other arguments.
|
|
%
|
|
% The reason why the trace directory does not use the latter
|
|
% representation is that it would require C code to construct values
|
|
% of type maybe(T).
|
|
|
|
:- func synthetic_term_to_browser_term(string, list(univ), bool)
|
|
= browser_term.
|
|
|
|
:- implementation.
|
|
|
|
:- pragma export(plain_term_to_browser_term(in) = out,
|
|
"ML_BROWSE_plain_term_to_browser_term").
|
|
:- pragma export(univ_to_browser_term(in) = out,
|
|
"ML_BROWSE_univ_to_browser_term").
|
|
:- pragma export(synthetic_term_to_browser_term(in, in, in) = out,
|
|
"ML_BROWSE_synthetic_term_to_browser_term").
|
|
|
|
univ_to_browser_term(Univ) = BrowserTerm :-
|
|
BrowserTerm = plain_term(Univ).
|
|
|
|
plain_term_to_browser_term(Term) = BrowserTerm :-
|
|
BrowserTerm = plain_term(univ(Term)).
|
|
|
|
synthetic_term_to_browser_term(FunctorString, Args, IsFunc) = BrowserTerm :-
|
|
(
|
|
IsFunc = no,
|
|
BrowserTerm = synthetic_term(FunctorString, Args, no)
|
|
;
|
|
IsFunc = yes,
|
|
list__split_last_det(Args, FuncArgs, Return),
|
|
BrowserTerm = synthetic_term(FunctorString, FuncArgs,
|
|
yes(Return))
|
|
).
|