timborn@ihlpg.UUCP (08/11/87)
My fondness for Forth has waned in recent months due to the (apparent)
lack of debugging tools available. I guess I'm spoiled by my UNIX
environment, with tracers & symbolic debuggers and all. When I run
into trouble with Forth on my micro, it seems I have to exsert a great
amount of effort tracing words to find the problem.
I appeal to those of you who have so much more experience in this area
than I: what are the "tricks of the trade"? The day to day debugging
tools & techniques that you obviously take for granted that make your
life so much more productive (in Forth) than mine?
I venture to guess that there are others who follow this group who are
reasonably intelligent folks who just haven't caught on to thinking
in Forth. I open myself up to your collective wisdom - I dare you to
show me that Forth can be used without going bald from banging ones head
against the walls.
"Ah so, Grasshopper. You have much to learn".
Tim Born
...ihnp4!ihlpg!timborn
{insert standard disclaimer here}billk@crash.CTS.COM (Bill Kelly) (08/12/87)
In message 3623@ihlpg.ATT.COM timborn@ihlpg.ATT.COM (Tim Born) writes: >My fondness for Forth has waned in recent months due to the (apparent) >lack of debugging tools available. I guess I'm spoiled by my UNIX >environment, with tracers & symbolic debuggers and all. When I run >into trouble with Forth on my micro, it seems I have to exsert [sic] a great >amount of effort tracing words to find the problem. One of the things I've always liked about Forth is that it is (at least to me) it's own symbolic debugger. All of the names of your words, arrays, constants, and variables exist in Forth after compiling them and are just waiting for you to try them out interactively. I have never come across a debugger that let me experiment with and debug code as easily as Forth does. Some things I have seen happen with programmers who are new to Forth are: 1. There seems to be a tendency (sp?) to use more variables than are really necessary. 2. (This is the one that really makes debugging a pain!) There also seems to be a tendency to write very large Forth words. While the first "problem" isn't really that big of a deal, and will probably go away in time (it did with me), the second is the one that is likely to make one go "bald from banging ones head against the wall." :-) Debugging Forth words becomes EVER SO MUCH EASIER if each word is made to be small and simple. These words should be EASILY testable by themselves, interactively. You should be able to pass the word its required parameters, press return, and imediately be able to determine whether or not it functioned correctly. In fact, I make each word so small (just a few lines long) that it becomes obvious just by a quick glance at the code, after performing the little interactive test, what the problem with the word is. Sometimes, however, even with these small words, a quick test and glance at the code isn't sufficient. Occasionally some really obscure problems come up that often stare you in the face without you being able to see what's wrong. No problem. (Honestly, after a bit of practice it really becomes easy!) The small word that is being troublesome is, itself, also made up of many other small and easy to debug words. Here's what I like to do in the case of a really obscure bug in one of my small words: Instead of testing out the word (I'll call it "TT") with some sample inputs like this: 65 34 TT ok . 45137 ok And getting some strange result (in this case, the number "45137") which I haven't the slightest idea why I got, I prefer to test out these obnoxious little "problem-words" like this: I look at the definition of the word "TT". Now, I take the sample inputs again (the 65 and the 34), and instead of just executing "TT", I type in the definition of TT a word at a time, examining the stack after each word. By doing this, you are able to determine exactly where in the word "TT" that the problem is occuring. Many times the problem will not be in "TT" but in one of the words that make up the definition of "TT". Since you have now determined which word in "TT" started giving you trouble, you can examine the definition of THIS word, following the same steps you followed when debugging "TT". Sooner or later, and usually very quickly, the problem and its solution become apparent. Even if it sounds like I'm going "too far" with my small, simple words, I encourage you to try it. At first, you may want to make words smaller than you feel is really necessary. Once you get into the hang of debugging Forth this way, you will eventually settle on some way of writing Forth that works best for you. Anyway, this is why I feel that Forth is a symbolic debugger in itself. I am able to develop and test and debug Forth code much faster than I can in any other language. That's why I like Forth so much! :-) Happy debugging to all, Bill Kelly -- -- Bill Kelly {hplabs!hp-sdd, ihnp4, sdcsvax}!crash!billk "You can't get there from here."
drw@cullvax.UUCP (Dale Worley) (08/12/87)
I once implemented FIG-Forth on the PDP-11 (translating from their 6502 or whatever distributed (paper!) version, and put in simple debugging facilities. These included breakpointing and single-stepping (the tricky part is stepping over a complex colon-word). Breakpointing isn't too hard, you just have a BREAKPOINT word that you write over the breakpointed colon-word reference, just as in assembler debugging. Single stepping is harder, because you have to modify the NEXT (?) routine to watch to see if it's supposed to interrupt after executing the colon-word. Anyway, once you've hit a breakpoint, you go back to the standard input-eval loop, which lets you screw around with things and then resume execution. I might still have the code floating around, if anyone's interested. Dale -- Dale Worley Cullinet Software ARPA: cullvax!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw OS/2: Yesterday's software tomorrow Nuclear war? There goes my career!
jv@unh.UNH.EDU (Jaime Viehweg) (08/12/87)
I have a verion of F83 (for CP/M and 8080) that has a word called 'debug'
that I just assumed that everyone had it (silly me!). You just say
'debug whatever-word-is-not-working-right' and it will show you the stack
and what it is about to execute allowing you to stop or go on. I have found
this utility invaluable more than once.
You might want to see if your system has this word.
Jaime [having fun as an intern at UNH while writing a compiler compiler!]
Viehwegkeithe@tekgvs.TEK.COM (Keith Ericson) (08/18/87)
In article <3623@ihlpg.ATT.COM> timborn@ihlpg.ATT.COM (Tim Born) writes: >My fondness for Forth has waned in recent months due to the (apparent) >lack of debugging tools available... > >I appeal to those of you who have so much more experience in this area >than I: what are the "tricks of the trade"? I haven't had a chance to study it yet, but the most recent edition of FORTH DIMENSIONS (Volune IX, Number 2) has an article, with source, of a test environment which allows one to decide, at compile time, whether or not debugging code should be compiled into the definitions. It appears similar to the #ifdef DEBUG technique. keith
rvk@houdi.UUCP (R.KLINE) (08/19/87)
In article <2574@tekgvs.TEK.COM>, keithe@tekgvs.TEK.COM (Keith Ericson) writes: > > I haven't had a chance to study it yet, but the most recent edition of > FORTH DIMENSIONS (Volune IX, Number 2) has an article, with source, of a > > keith
mj@myrias.UUCP (Michal Jaegermann) (08/21/87)
I agree with all comments made here about Forth being its own
symbolic debugger, writing small words with meanigful names and so on.
Still one problem remains, exemplified by a novice tendency to use
to many variables in a code. One - good - reason for that is that
one cna be easily lost in a "stack jungle" created quite easily,
even if your words are small and simply. And you need some experience
and practice to discard all this "stack noise" (ROT, DUP, OVER,
SWAP.....) when reading a code. One proposition was to execute
"problem" words by typing components one by one. I am just too lazy for
that, so in one of my Forth systems I included a tracing facility into
a screen editor which I wrote (I was unhappy with the original editor).
A certain key combinations caused an an execution of word (or two words -
if needed) and display a stack contents at the bottom of a scree.
A great debugging, teaching, learning ans demonstration tool. And very
easy to implement in Forth, since all needed componenets are already
in place - by the language design. Details may vary a little bit, due
to implementations peculiarities, but basically you have to grab
a string of characters from screen and move cursor past it
(ENCLOSE willdo the job and provide information needed) change it to
an address (this is a job of FIND) and pass it to inner interpreter
to execute it (it was designed to do exactly that). That's all and
some extra bells and whistles can be easily added.
Michal Jaegermann
Myrias Research Corporation
Edmonton, Alberta, CANADA
....ihnp4!alberta!myrias!mj