proposed command set for the internal trace based debugger

[Mireille Ducasse]

>> When the debugger (as opposed to the program being debugged) is interacting
>> with the user, the debugger prints a prompt and reads in a line of text,
>> which it will interpret as its next command.

It is usually a good idea to separate the I/O of the traced program
from the debugging I/O. in a separate window. Otherwise the two fows
are mixed up and the user is confused.

				- o -

As for the discussion wrt breakpoints and spypoints, as well as the
discussion wrt different variants (print level...). What you really
want is Opium, this is exactly because of non-ending discussions about
what this and that command should do, that I designed a customizable
debugger with simple basic breakpoints (possibly at every event) +
Prolog to decide exactly what should be done.

There is NO WAY that you can decide a priori for all possible users
what the best commands can be.

For the forward movements I haven't seen anything that couldn't be
done VERY EASILY with the Opium mechanism.  As Opium is due soon I
would suggest that you stay with what you have now and rely on the
forthcoming Opium to provide the full functionality.

Note that we can nevertheless make use of any hard-coded breakpoint
mechanism. IE we will support all the ones that you will provide with
your tracer. 

				- o -

A side remark : I have the feeling that I haven't spent enough effort
explaining the usefulness of Opium. If some people are coming to
Manchester we should arrange for a through demo.

				- o -

>> redo
>> 	Restarts execution at the call port of the call corresponding to the
>> 	current event. Reports an error if the current event refers to a call
>> 	port.

This is NOT covered by Opium, and indeed VERY useful. 


>> 	The command will report an error unless the values of all the input
>> 	arguments are available at the current port. (The compiler will keep
>>	the values of the input arguments of traced predicates as long as
>>	possible, but it cannot keep them beyond the point where they are
>>	destructively updated.)

In Opium we could keep some information, or at least provide the user
with the possibility to specify which predicates are of interest, so
that Opium keeps the argument values. This wouldn't slow down the
traced execution. 

This doesn't change your spec. Just to tell that we could complement
the functionality.


				- o -


>>	For implementation reasons XXX, the command may also fail if the
>>	current event represents an execution point inside a commit
>>	in the code of a predicate that uses the deterministic stack.
>>	(This limitation can be fixed by letting the program continue
>>	*forward* execution until it reaches a port on the relevant predicate
>>	that is outside the commit, and then performing a redo. This
>>	may require a noticeable amount of time, and although IO states
>>	cannot be updated inside commits, may result in the execution of
>>	user-written C code that nevertheless performs I/O and/or has other
>>	side-effects.)


This is exactly the kind of things that are straitforward to implement
in Opium.

	:- current_goal(G), f_get( goal = G), 
	   current_port(P), is_outside_commit(P), redo.

I think that you should leave this to us.


				- o -


>>	At the moment this command prints the entire value of every variable,
>>	even if this is very big. Later it will merely invoke a configurable
>>	dynamic term browser, which will eventually have its own sublanguage.

We are working on this. Remember we have FULL Prolog as a language, it
is very powerful to build a term browser.

What we need is basic primitives to retrieve the values "bits by bits". 

Erwan will provide a requirement list soon.


				- o -


>> stack
>>	Prints the names of the ancestors of the call specified by the
>>	current event. If two or more ancestor calls are for the same
>>	predicate, the predicate name will be printed once with the
>>	appropriate multiplicity annotation.

We would need a basic primitive that doesn't abstract away anything
and that reaturns the anscetors in a list (ie that doesn't print
anything).


>>	This command will report an error if there is no stack trace
>>	information available about any ancestor.

Is there a way to know when this will occur ?


				- o -

>> up [<num>]
>>	Sets the current environment to the stack frame of the <num>'th
>>	level ancestor of the current environment (the immediate caller
>>	is the first-level ancestor).

>> down [<num>]

Is it true that there are more frames that You CANNOT expect than that
you can expect with this mechanism ?

My feeling is that this type of command is more useful for the system
developper than for the casual programmer.

I'd be glad to have feedback from users


				- o -

>> quit
>> 	Quits the debugger and aborts the execution of the program.

You also need a command that quits the debugger NOT aborting the
traced program. (Very useful, indeed).

>> 	Asks confirmation first, which is given by any answer starting
>> 	with "y" or EOF.

I had NEVER felt the need for such a confirmation with Opium. OK, with
an interpreted environment it is very easy to re-execute a program,
but is it that different in Mercury ?


>>	EOF on the debugger's input is considered a quit command.

I do not like this kind of practice even if they are common.