Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcrdcf.UUCP
Path: utzoo!utcs!lsuc!pesnta!hplabs!sdcrdcf!darrelj
From: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Newsgroups: net.works
Subject: Re: Returning to Batch Processing
Message-ID: <1771@sdcrdcf.UUCP>
Date: Wed, 20-Feb-85 14:52:52 EST
Article-I.D.: sdcrdcf.1771
Posted: Wed Feb 20 14:52:52 1985
Date-Received: Sat, 23-Feb-85 00:42:47 EST
References: <633@topaz.ARPA> <376@terak.UUCP>
Reply-To: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Organization: System Development Corp. R+D, Santa Monica
Lines: 64
Summary: 

The way to find multiple bugs in one run in an interactive environment is to
go even farther into an integrated interactive environment.  A premeire
example is Interlisp (especially Interlisp-D on a workstation, but was just
as doable in Interlisp 10).  The way that Interlisp acheives this (there are
probably other ways) is that all tools run in a single environment (primary
tools: editors, debuggers, incremental compiler, compatible interpreter, a
history list for commands [including results and how to UNDO many commands],
and an object inspector).
A typical scenario in testing new (pieces of) programs is 
*   write code,
*   possibly compile all or part (the trade off is speed of execution versus
granularity of debugging; Interlisp can only break at the entry to a
function, so errors inside a compiled function back up to the entry point;
some other Lisp workstations can break in the middle of compiled code, but
this requires integrating a decompiler or disassembler into the debugger and
require the programmer to know both the language and the detailed machine
model used by the compiler--these are both legitimate design decisions)
*   Invoke a test case (or run a loop against a file of test cases, etc)
*   Something goes wrong, often causing an error  (if not, set breakpoints
to create an artificial error, and use history to run again).  These errors
may be "fundamental" like arithmetic on a character string, or programmer
checks (e.g. (if "malformed state test" then (SHOULDNT "Bad input to FOO"))).
As a result of the error, you are (normally) dropped into the debugger (it's
always there), where you can examine the entire state of the system, edit
and recompile pieces of the code.  Because the debugger is a first class
component of the system, you can make multiple retries of the faulty
function without losing your place, "force" the right answer out of the
debugger as the return from any function on the stack.  If the logical error
is "close enough" to the system detected error, you can often repair any
damage, fix code and resume (not restart) execution as though there had
never been an error, the system goes on and breaks on the next (unrelated)
error.  I have occasionally repaired more than half a dozen errors in a
"single" run of a test case in a series of such diversions into the debugger.


The key features in making such debugging possible are:
  1)  A way to move from tool to tool (even csh job control would be
adequate)
  2)  A debugger which permits fairly radical repairs to the runtime state,
including flushing portions of the stack
  3)  The ability to dynamically link revised code fragments into the test
system
Beyond that, it's mostly a matter of making the tools easy enough to use
(e.g. a debugger which requires making all repairs in terms of absolute
octal addresses and data would hardly be usable above the assembler level,
and barely usable even at that level).  As an example of convenience in
integration, the Interlisp D environment can get you into the editor on a
particular function by pointing to the function on the stack with your mouse
(you don't even have to remember which file contains it).  The large display
and mouse make for an easier to use method of "job control" than csh because
most jobs correspond to logical windows on the screen, and you switch by
pointing at them.  While this doesn't really change what you can do with
your tools, it can make it enough easier to use them that result tends to be
a qualitative change (like model T and rutted dirt roads vs contemporary
cars and the Interstate freeway syst).
-- 
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
                                                            !sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA