Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!hubcap!ncrcae!ncr-sd!crash!billk From: billk@crash.CTS.COM (Bill Kelly) Newsgroups: comp.lang.forth Subject: Re: Debugging Aids for Forth Message-ID: <1516@crash.CTS.COM> Date: Wed, 12-Aug-87 04:10:16 EDT Article-I.D.: crash.1516 Posted: Wed Aug 12 04:10:16 1987 Date-Received: Fri, 14-Aug-87 05:36:49 EDT References: <3623@ihlpg.ATT.COM> Reply-To: billk@crash.CTS.COM (Bill Kelly) Organization: Crash TS, El Cajon, CA Lines: 91 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."