Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!oberon!nunki.usc.edu!sal4.usc.edu!raulmill
From: raulmill@sal4.usc.edu (Raul Miller)
Newsgroups: comp.lang.apl
Subject: Re: debuggers
Summary: debugging vs. apl style
Keywords: apl, workspace, symbols, program design, debugging
Message-ID: <1671@nunki.usc.edu>
Date: 18 Oct 88 03:57:13 GMT
Expires: 1 Jan 89 08:00:00 GMT
References: <109@infbssys.infbs> <49700004@uicsrd.csrd.uiuc.edu>
Sender: news@nunki.usc.edu
Reply-To: raulmill@oberon.usc.edu (Raul Miller)
Followup-To: comp.lang.apl
Distribution: na
Organization: University of Southern California, Los Angeles, CA
Lines: 53

In article <49700004@uicsrd.csrd.uiuc.edu> jaxon@uicsrd.csrd.uiuc.edu writes:
>    If you want hints about how to tackle writing a debuggable program...
>       1) Write components that check their arguments, environment &
>          results.  Write the checks as separate lines that halt the
>          program when the check fails.  You can filter them out once
>          its time to cut a production version.
>
>       2) Don't optimize anything until most of the design bugs have been
>          found and fixed.
>
>       3) Write up a test program that unit tests components;
>          Write a test script that integration tests the whole system; 
>          Rerun the tests frequently while you're fixing bugs.  
>

More generally:  Always include comments describing any variables
used to communicate between a function or defined code sequence and
the rest of the world.  Rarely comment on the code itself.

        Next write the code that goes with the comments.  When you
debug, you want to make sure that what is going in and out of the
function matches the comments.  quadTRACE and such are useful here
for isolating problems within a function.

        A general troubleshooting technique you should be familiar
with is isolating cause and effect.  This can be done by starting
at the beginning of a flow and tracing it through to where it 
deviates from the ideal.  This can also be done by forcing data
in at some point and making sure that it is handled properly from
that point on.

        One of the most important debugging/analysis 'techniques'
anywhere is knowing how things should be when they are working
right.  This allows you to recognize where they are wrong.  In
APL, this can generally be achieved by commenting variables
(commenting the workspace can help too...).

        Finally, if you are dealing with big workspaces or sets
of workspace, you'll need to have some tools to show the hierarchy
between the different modules.  Some of these can be generated
automatically (for example, showing the graph structure of which
functions call which functions in a workspace).  Others will have
to be generated by the originator of the programming (for example,
the purpose of a directory or workspace).

        Essentially, what I am trying to say is debugging a
program you understand is trivial.  The trick is understanding
it.  I hope you find the above useful.



Raul Miller
USENET:             raulmill@oberon.usc.edu