The Debugging Process

(c) Lee Bradley 2010 

+-----------------------------------------------------------------------+
+  Note: This used to be a .txt file but is now a .html file. Please    +
+  visit http://primepuzzle.com/tc/the-debugging-process.html instead!  +
+-----------------------------------------------------------------------+
I was motivated to write this as I finished "perfecting" my solution to the Foxtrot exercise. It took me the better part of the entire day (yes, *day*) to get it right and I thought it would be useful to anyone trying to tackle similar problems if I spelled out some of the things I do during a typical debugging period.

Some of the things you will read here apply to *any* problem-solving effort. Some are specific to tiny-c.

One of the things I do when things aren't working is to put display statements in my code. For example 

pn v(0);sak
This prints the number in v(0) and then waits for the user to strike any key. I finally found the error I was comitting. I had declared v(0) to be a character array with 1 element. I should have declared it to be an integer array. This was causing my totalling logic to fail because character variables can only go up to 255.

I comment out these debugging lines (and add others) until I've made needed repairs and then I delete them all.

My 1st draft of foxtrot.tc was done w/ pencil and paper. I thought about the problem a fair amount before I did any writing. I then went to my computer and, using my very jumbled "pseudocode," typed it in.

I always use my favorite text editor to build my programs. I seldom use tiny-c's shell for this purpose. Notepad or similar or a full-featured editor (like Boxer) are way easier and more powerful than the shell.

When I get to the stage of actually trying to run my program, I usually get some error message and I'm back to a tc> prompt. I have tiny-c error codes handy (usually by bringing them up in a browser session (http://primepuzzle.com/tc/tiny-c error codes.html)).

To make changes I discover I need (undeclared variables, missing brackets etc.) I make the changes w/ my external editor and then type the following at my tc> prompt: 

tc>.1                    (go to line 1)
tc>.d 999                (delete all lines)
tc>.r foxtrot.tc         (read in the newly changed program code)
tc>.foxtrot "6-10-10"    (run it)
This debugging cycle may last for quite some time!

Another handy tool is to use tiny-c's "immediate mode." For example, if you're not sure of the syntax / semantics of a particular instruction, just try something like 

tc>.[int i;for (i=5;i<15;++i) [pn i]]
The above has nothing wrong w/ it but you might type something that gives you an error and will have to play w/ it till you get it right.

I use immediate mode to test a function I've defined which is in some loaded program. 

tc>.[int t(30);split(t,"2009/11/29 50 2009/12/11 100 "," ");ps t(3)]
would display 100. (See foxtrot.tc for how split works.)

If you are new to this language (or to anything you are learning) it is always very helpful to have its reference material nearby. The online tiny-c docs are invaluable. I am often consulting them because I can't remember the way some things work. http://primepuzzle.com/tc is a front-end to the detailed documentation. It has a link to tiny-c's basic constructs, system library, error messages etc. The system library contains the basic building blocks of this language and the more familiar you are w/ them the better. Consult the sample programs; find how they use the functions index, atoi, readfile etc. Copy code from them and then modify it to your needs.