Shareware Overload/ShartewareOverload.cdr/progm/funkybox.zip/DEBUG.DOC

Text File | 1983-04-01 | 12KB | 221 lines

***************************
     BLOOPERS AND BUGS
***************************

PEOPLE SYSTEMS, LTD.
Copyright 1983 (c) L. A. Warner, P.E.

Even a musical genius practises and plays compositions, written
by others, for a long time before he sets out to play a concert
of his own creations. Similiarly, a programmer should keyboard-in,
and debug other people's programs long before he decides to give
a recital of his own composing. There is much to be gained by
copying in a program from a magazine or book and then debugging it
or adapting it for the idiosyncrasies of his particular PC.
Finding and fixing the bloopers is not all that difficult. Try it.

prgm : 20 READ X$, Z$        you typed:  20 REED X4, Z$

DEBUGGING KEYED-IN PROGRAMS FROM A MAGAZINE
At the time, debugging another's program may seem very difficult,
but as the work progresses, and experience is gained, debugging and
adapting a program becomes quite easy, even though the programming
may seem foreign or a little too advanced to understand. Of course,
debugging your own programs ensures a better understanding and also
a commitment to make them work well. Most of this
article will be concerned with debugging your own programming
efforts, so let us touch lightly on keyed-in debugging and
adaptation before we plunge into the bottomless pit called DB.

prgm: 15 READ X$,B: DATA JONES,24 you typed:15 READ X,B$: DATA @$,JONES

SOME DB TIME SAVERS
Some of the time savers are: print-out the listing and place it
side by side with the original and with two 3x5 cards cross-check
it line by line, marking the errors. Using a copy stand and good
lighting with a line marker will expedite the keyboarding. There
are good references like "The BASIC Handbook" by David Lien and
"The Conversion Handbook" by D. A. Brain not to mention Appendix D
in the IBM BASIC manual, that will save time in translation of
certain language specifics.

Technical publishers discovered that proof readers who didn't speak
the language they were checking were often very careful in their
galley corrections. Perhaps your family can spot typos that
you can't find?

Whats wrong? 25 PRINT "The number is, Z : GOTO 35    (end ")

DEBUGGING YOUR OWN PROGRAMS
This is a short tutorial on the process of debugging a program
and is not intended to teach how to use the DOS program called
DEBUG, which is quite self explanatory although its usage could be
better explained with some examples and demonstrations. It is a tool
worth getting familiar with and we discuss some of its uses in Vol.2
to unlock protected files and recover EDLIN files when the disk
is full.

For definition, debugging is the process of successive improvements
made to enable a program to do what it is intended to do, under most
conditions. Debugging should start right at the beginning of coding
so that errors of most types can be eliminated, rather than
trapped and handled. Generally, error trapping is omitted until
the program is well developed, because error routines can present
serious impediments to program development and it is better to find
and correct an error instead of being satisfied by handling it.

DEBUGGING VS. ERROR HANDLING
In contrast to debugging, ERROR trapping and handling applies to the
run-time keyboard and peripheral errors that would cause a well
debugged program to shut down, losing all work not already saved.
ERROR trapping is covered in another article in the series.

25 READ T,U,V : DATA 3,6       (not enough data)

Error handling installed prematurely can cast a smokescreen over
efforts to debug. However, sometimes ERR and ERL, error message and
error line can be used to debug a very involved program and save
data from being lost because of a crash. During the development of a
complex program, all error messages should be noted and line numbers
logged so that the decision to trap errors can be based on the
programmer's experience in that part of the program.

STUDY THE ERROR MESSAGES IN BASIC AND DOS
The error messages in Appendix A : BASIC manual are extensive and worth
studying on their own terms. It's much easier to learn from them
when you don't have to solve a problem, than it is to read them, one
at a time after the program has shut down and you know you have a mess
to straighten out. By the way, the second edition of IBM BASIC Manual
has an extended section on error messages in Appendix A. Moving
in the right direction, IBM indicates how to correct the error now.

AFTER THE CRASH
Now what do you do? That's the question. Record the error message and
line number. Look it up for detail and study it.  Sometimes there are
many possibilities to consider. Then LIST the lines before the ERL and
see if you can detect the problem. There is another route to take
and that is in direct mode enter the print-out of variables, one by
one and see if there are any surprises. Entering  ?X,K$   provides the
value of X and K$ on the next line following the command.

Whats wrong?  10R5 PRINT "LINE NUMBER BAD"

TRON -- TROFF TRACE
One of the most useful tools, especially if you have a printer and a
quick trigger finger is TRON, which prints the line numbers as the
program proceeds towards the crash. You can stop the action using
Ctrl-NumLock and print out the screen for study purposes. TROFF turns
the trace off again.

MULTIPLE STATEMENT LINES
When you have narrowed the program area down to where you
suspect the error is caused, it may be beneficial to rewrite those
lines especially if they contain multiple statements. Bad single
statement lines can be identified by the error message ERL. Sometimes
a line may show on the screen correctly but have a bug in it's bits.
Retyping a suspect line sometimes helps. Look-up in the manual
the correct spelling and check it letter for letter for any BASIC
statements or commands. ( Don't be fooled by CRSLIN or CSRLIN :
which is it ?)

PRINT, STOP AND CONT
In loops and other segments with inter-woven operations, it is often
beneficial to install PRINT commands that will show on the screen or
printer important variables or data that might be clogging the chute.
They can be REMed out temporarily when the trouble is passed. Some
crashes take with it all survivors and don't leave a record on the
screen. Exercise your right to know by installing a STOP just before
the scene of the accident. But don't leave, you can solve it if you
have the patience. The bigger the bug -- the easier they are to find,
sometimes. STOP and CONT can be used to hold the screen for inpection.

Whats wrong? 105 PRUNT " My name is Dhuh, I cannt speel."

We sometimes forget that DOS  allows us to print-out an LLIST for
say lines 100-120 (LLIST 100-120) without waiting for the entire LIST
to be printed. An up-to-the-instant printout can be very useful in DB.
Printing the line   340 PRINT "PROGRAM IS AT LINE 340" may be handy
in detecting the progress of the program. Placing an apostrophe in
front of the PRINT will convert it to a REM until you use or delete it.

HAND TRACING
When you have tired of eye-ball tracing those fuzzy little green
characters on the screen, then try taking your print-out to a quiet
place and hand trace it. Oddly enough, a pencil is usually needed but
nobody calls it a pencil trace job. By the way do you have a light
hood over your CRT ? It saves eye fatigue, and a corrugated box is
certainly  a low initial cost investment. Tape it to the CRT with
a strong piece of duct tape or other. If you want to get fancy, paint
it black with your kids tempora paints, but standard box-tan works
well. It may be useful to hand calculate and compare results also.

LOOP-DE-LOOPS
Probably one of the greatest sources of gray hair, time delays,
crashes and many other CPU maladies is the FOR NEXT loop we all love
so dearly. Please be advised a bad loop may not issue an error message,
instead the CPU may politely ignore it. Unless STEP-1 or some
negative value is used  the loop FOR A = X TO Y where X=7 and Y=-4
will be ignored. Because, "... the initial value of the loop is
more than the final value. "

PARTIAL RUNS IN LONG PROGRAMS
One of the troublesome problems in a complex program being debugged
is sitting through the repeated sections to get to the problem area.
Doing a RUN 200 will start the show on line 200 but the variables and
arrays will not be there. Although it is not listed as a command
by IBM, but a statement,  GOTO line   can be used in direct mode to
debug areas of a program without destroying the variables and arrays.
If you have ever sat through many unnecessary replays of your pro-
grams, unwillingly committing them to memory, you will enjoy using
GOTO line  . It beats putting extra variable definitions into the
program sections to   RUN line  .

What's wrong?  105 FOR DELAY = 1 TO 10000 : GOTO 65

RETURN TO GROUND ZERO
Since all good programmers faithfully keep back-up copies of all
their work as they progress forward through the stormy night, it is
a simple matter to create a useful system to protect the next to
the last version of your program. One that worked, before you added
the XY4AS-?!@W%$#@* blankety-blank lines to make it better.

By using two drives and alternating from one to the other each time
you save a newer edition you can be assured of having one available
that was free of the latest bugs that you built into it. Its also a
very good procedure to save any change that might hang up and
all memory could be lost in a cold restart. Thus an LLIST of the two
programs, one from each drive will produce hard copies for comparison.

A FUNNY THING HAPPENED ON THE WAY TO THE FORUM
Its often necessary to sit back and laugh at yourself once in a while.
Have you ever made a correction to a line and then carefully run the
program again to check it to find, lo and behold, someone, maybe a
grinch, changed it back again? No, you aren't imagining things, you
did correct the line, really you did. BUT, you didn't enter it while
you were on the same line and probably moved off with the cursor
arrows to work on another line. Be thankful that it didn't tie all
the lines together like my word processor does when you don't enter
each line promptly, before you leave it.

SOME TYPICAL DEBUG BLOOPERS
If everyone made a list of their own bloopers it would include
the full BASIC vocabulary certainly and variations of every syntax
imaginable. Of course for the organized programmers there are
classifications of bloopers, although most roses, by any other
name, are still roses. They can be either Syntax Errors which the
IBM-PC wont stand for in a program, unless they occur because of
a Run-time Error or keyboard input. Another classification is the
Logic Errors which mean your intentions are good but the CPU can't
fulfill your desires because it doesn't understand them. No crash
but meaningless results.

Some of the Syntax errors are: No closing quote needed if it would
be the last character on the line. But 20 PRINT " HELLO : GOTO 60
won't work. A variable must begin with a letter. An array of over 11
items or multidimensional must be dimensioned before using. Erasing
a non-existant array. Misspelled Commands, Statements, Functions.
The CPU doesn't care if you misspell text ( inside quotes ). And so
the list goes on. I'd like to have a nickel for every blooper.