🚀 go-pugleaf

In article <4055@n-kulcs.cs.kuleuven.ac.be>, bimbart@hera.cs.kuleuven.ac.be (Bart Demoen) writes:
> In article <6403@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au
> (Richard A. O'Keefe) writes:
> 
> > What exactly is it you don't like about the 4-port debugger?
> 
> it is the slower way to debug
> also, trying to debug a program you didn't write yourself, is more painful with
> the 4-port debugger, as compared to a source oriented debugger
> I am not saying that the 4-port debugger is completely useless, but perhaps
> nearly so

There is an utterly false distinction being drawn here between the
four-port debugger and a source debugger.  What makes a four-port debugger
a four-port debugger is WHERE IT CAN STOP, where you can set breakpoints.
What makes a debugger a source debugger is WHAT IT CAN DISPLAY.
The two questions are completely independent.  For example, the Prolog
system you can get from Edinburgh (was "NIP", now "Edinburgh Prolog")
is a 4-port source debugger.  Similarly, the debugger that came with
IF/Prolog right from the beginning was a 4-port source debugger.

> forget about 5-port debugging in ProLog by BIM as well: it is still there,
> but once you use the source oriented debugging tool (which looks very much
> like dbxtool) you will not want to use the port debugger any more

So does the NIP debugger look a lot like dbxtool.  That has *NOTHING* to
do with whether it is a four-port debugger or not.  It would be fair, for
example, to describe dbxtool as a 2-port source debugger for C.

-- 
I agree with Jim Giles about many of the deficiencies of present UNIX.