[m-rev.] for review: fix three bugs in declarative debugger

[Julien Fischer]

On Mon, 28 Mar 2005, Ian MacLarty wrote:

> For review by anyone.
>
> Estimated hours taken: 30
> Branches: main
>
> Fix three bugs in the declarative debuggger.
>
> The first two are to do with IO tabling in the declarative debugger:
>
> The first bug was exposed when a new explicit supertree was built over a part
> of the program that did IO.  The starting IO action sequence number was not
> being set correctly, causing some IO actions to be omitted from the resulting
> IO action map.  The fix is to set the starting IO action sequence number to
> the IO action sequence number at the CALL event for the topmost node of the new
> explicit supertree.
>
> The second bug was exposed when a retry was done over a part of the program
> whose IO was not tabled.  This caused the building of the IO action map to
> fail.  Specifically the MR_trace_get_action C function would abort with a
> message that the IO action number was out of range.  The fix is to only record
> tabled IO actions in the IO action map and then warn the user if a question is
> asked where some of the IO actions for the atom haven't been tabled.
>
> The third bug causes the declarative debugger to throw an exception when
> an explicit subtree of depth 1 is requested.  This was because MR_edt_depth
> (the global which keeps track of the current depth of the EDT) was not being
> set correctly.
>
> browser/declarative_debugger.m:
> 	Allow the IO actions for a final atom to be tabled or untabled.
>
> browser/declarative_tree.m:
> 	Extract a list of the tabled and untabled IO actions for a question
> 	from the IO action map.
>
> browser/declarative_user.m:
> 	Bring module imports up to date with coding standards.
>
> 	Only allow browsing and printing of tabled IO actions.
>
> 	Print all the tabled IO actions for a question and print a warning if
> 	there are any untabled IO actions for a question.
>
> 	Use "tabled IO actions" instead of "io actions" when displaying how
> 	many tabled IO actions there are for a question.
>
> browser/io_action.m:
> 	Add a type to record if an IO action is tabled or not.
>
> 	Bring module imports up to date with coding standards.
>
> 	Only record tabled IO actions in the IO action map used by the
> 	declarative debugger.
>
> runtime/mercury_trace_base.[ch]:
> 	Make MR_trace_get_action return true or false depending on whether
> 	the requested IO action was tabled or not, so that we can easily
> 	detect this in io_action.m above.
>
> tests/debugger/declarative/io_stream_test.exp2:
> 	Update expected output.
>
> tests/debugger/declarative/tabled_read_decl.{exp,inp,m}:
> 	Add regression tests for all three bugs.
>
> trace/mercury_trace.[ch]:
> 	Allow the message printed by the retry command, when it is about to
> 	retry over untabled IO, to be customised.  This allows the declarative
> 	debugger to print a different message when it needs to do a retry
> 	over untabled IO.  Previously the message seemed unrelated to the
> 	declarative debugging session.
>
> 	Get MR_trace_retry to report if it did an unsafe retry over
> 	untabled IO.
>
> trace/mercury_trace_declarative.c:
> 	Print a friendlier message when attempting to retry over untabled IO.
>
> 	Set the initial IO action sequence number to the IO action sequence
> 	number at the time of the CALL event of the topmost node of the new
> 	explicit supertree.
>
> 	Initialise MR_edt_depth to -1, instead of 0, since it will be
> 	subsequently made 0.
>
> 	When building an explicit supertree, only ask the user once if a
> 	retry can be done over untabled IO.
> 	Because of this rename MR_trace_retry_max to MR_trace_retry_supertree,
> 	since it should now only be used when building a supertree.
>
> 	When checking if we are at the final event for the top of the new
> 	explicit supertree, add the depth_check_adjustment.  This ensures
> 	that the final event has the same depth as the corresponding call
> 	event.
>
> 	Add an argument to MR_decl_diagnosis to tell it whether a new tree
> 	was generated, or to resume a previous session.  Previously the resume
> 	option was implied by a null tree, which made the code less readable.
>
> trace/mercury_trace_external.c:
> trace/mercury_trace_internal.c:
> 	Pass the new extra arguments to MR_trace_retry.
>
> trace/mercury_trace_readline.c:
> 	If a readline prompt spans multiple lines then the display gets messed
> 	up when the user starts typing (not sure if this is a bug in readline
> 	or not).  Fix this by only passing the last line of a prompt to
> 	readline and just fprintf'ing any previous lines.
>
> trace/mercury_trace_vars.c:
> 	Handle the new MR_bool return value of MR_trace_get_action.
>
...

> @@ -980,7 +993,46 @@
>  		is_function(PredOrFunc)),
>  	browse.print_browser_term(BrowserTerm, User ^ outstr, CallerType,
>  		User ^ browser, !IO),
> -	write_io_actions(User, IoActions, !IO).
> +	write_maybe_tabled_io_actions(User, MaybeTabledIoActions, !IO).
> +
> +:- pred write_maybe_tabled_io_actions(user_state::in,
> +	list(maybe_tabled_io_action)::in, io::di, io::uo) is cc_multi.
> +
> +write_maybe_tabled_io_actions(User, MaybeTabledIoActions, !IO) :-
> +	filter_tabled_io_actions(MaybeTabledIoActions, IoActions, AreUntabled),
> +	write_io_actions(User, IoActions, !IO),
> +	(
> +		AreUntabled = yes,
> +		io.write_string(User ^ outstr, "Warning: some IO actions " ++
> +			"for this atom were not tabled.\n", !IO)
> +	;
> +		AreUntabled = no
> +	).
> +
s/were/are/?

> Index: runtime/mercury_trace_base.h
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/runtime/mercury_trace_base.h,v
> retrieving revision 1.45
> diff -u -r1.45 mercury_trace_base.h
> --- runtime/mercury_trace_base.h	24 Mar 2005 01:58:05 -0000	1.45
> +++ runtime/mercury_trace_base.h	26 Mar 2005 05:58:20 -0000
> @@ -404,10 +404,12 @@
>  ** This function is called from the Mercury code in the debugger, in the
>  ** browser directory. It is here, not in the trace directory, because code
>  ** in the browser directory cannot call functions in the trace directory.
> +**
> +** If the io action action_number has not been tabled, then this
s/action action/action/

> +** function will return MR_FALSE, otherwise it will return MR_TRUE.
>  */
>
> -extern	const char
> -		*MR_trace_get_action(int action_number,
> +extern	MR_bool	MR_trace_get_action(int action_number,
>  			MR_ConstString *proc_name_ptr, MR_Word *is_func_ptr,
>  			MR_Word *arg_list_ptr);
>
...

> ===================================================================
> RCS file: /home/mercury1/repository/mercury/trace/mercury_trace_declarative.c,v
> retrieving revision 1.82
> diff -u -r1.82 mercury_trace_declarative.c
> --- trace/mercury_trace_declarative.c	12 Mar 2005 04:46:33 -0000	1.82
> +++ trace/mercury_trace_declarative.c	27 Mar 2005 09:02:13 -0000
> @@ -99,6 +99,17 @@
>  #endif
>
>  /*
> +** The message to display when attempting to retry of an untabled area.
> +*/
> +
> +#define MR_DECL_UNTABLED_IO_RETRY_MESSAGE \
> +	"The declarative debugger needs to perform a retry across\n" \
> +	"an area which is not IO tabled.  This is not always safe.\n" \

s/which is not IO tabled/in which IO is not tabled/.

> +	"To avoid this warning restart mdb and issue a `table_io start'\n" \
> +	"command at an event before the suspect area.\n" \
> +	"Do you wish to proceed with the retry? "
> +
> +/*
>  ** The declarative debugger back end is controlled by the
>  ** settings of the following variables.  They are set in
>  ** MR_trace_start_decl_debug when the back end is started.  They
> @@ -194,6 +205,15 @@
>  static	MR_bool		MR_edt_compiler_flag_warning;
>
>  /*
> +** When building a supertree there will be 2 retries.  The first will
> +** retry to an event before the topmost node of the currently materialized
> +** tree and the second will be a retry from the topmost node to the root
> +** of the new supertree.  This global records whether the user said it
> +** was safe to do the first retry across untabled IO.  If they said this was
> +** okay then there's no point asked them again for the second retry.

s/asked/asking/

The rest looks ok.

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------