[m-dev.] spypoints in external debugger

[Fergus Henderson]

On 28-Sep-1999, Gregory Daniel Denehy <gdenehy at cs.monash.edu.au> wrote:
> 
> On Tue, 28 Sep 1999, Erwan Jahier wrote:
> 
> > | My question relates to how this should be
> > | implemented.  I envisage that after the external debugger sends
> > | 'spypoint_matched_print' it could be placed into a 'waiting' state, where
> > | the external process could request the additional data as required, and
> > | will resume execution only when it receives a continue request of some
> > | kind.  I would be grateful for any comments/ideas on this.
> > 
> > Well, it is exactly the way it is currently working. Once you have done a
> > "forward move", the debugger is in a waiting state: it is waiting for an other
> > 'forward_move' request or a 'current_*' that will retrieve informations that can
> > (for example) be printed.
> 
> This is true if the forward move request has been matched, however, if a
> spypoint has been reached the execution will have been stopped before
> reaching the requested event (and the request is forgotten).  What I'm
> proposing is for the request to be remembered while waiting and to
> continue searching for the same requested event after the external process
> is finished retrieving its data.  It may very well be easier/better to
> leave it the way it is, and make the external process (the graphical
> debugger) remember what it was asking for, and then ask for it again if it
> received a spypoint 'print' response.

Yes, I think that sounds better.  It's better to keep the interface as
simple as possible.  All other things being equal, the fewer different
"modes" (in the "vi" moded editor sense) that an interface has, the better.
Or equivalently, to say the same thing in different words, the fewer
different states the server (in this case the debuggee) can be in, the better.

The exceptions would be if this would be too inefficient, or if
simplifying the interface would unduly complicate the clients.
But neither of those is the case here.  In this case, the external
debugger can easily remember what it was asking for and ask for it
again, so keeping the interface simpler here does not complicate the
client much at all.  Regarding efficiency, the cost of an extra request
or two being sent down the socket is negligable, given that it only
happens when you encounter a breakpoint.

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------