hi everyone,

we've had a couple of challenging hws, so you'll be happy to know the next
two are relatively straightforward (and have no programming component).

hw5 & hw6 are about debugging and testing respectively.  the two 
are closely related, and so i've made them due concurrently, two weeks from
now.

POP has extensive comments on debugging, so i'll just point
out the ones i think are especially important.

 -  LEARN TO USE A DEBUGGER!  

    at the very least, you should be able to set break-points (conditionally), 
    step through code, print the values of variables, and move up and down the 
    call stack.
      surprisingly, even though your program may execute millions (or billions)
    of instructions, before it exhibits problems, it's usually not too hard
    to actually execute it in a debugger to get to the point where it crashes.

    very often, if you just look at a printout of the code, it'll do what you
    think it does - running a program in the debugger shows you what the 
    program actually does.
 
 - use tools to help you identify problems:

   o compilers have warning flags (gcc uses -Wall) which identify things which
     syntactically correct, but are signs of potential problems: unused 
     variables, functions not returning values, use of = in a conditional 
     check in C/C++, etc.  always compile with these flags on, and be sure
     you've understood why warnings are generated.  (they are not always a sign
     of problems, e.g., you may not use a variable you're assigning to if
     you're just using it to test a function, but be sure to understand 
     the warning.)

  o tricky memory problems (segfaults, leaks, data getting corrupted) are best 
    debugged by using tools specifically targetting these.  on unix, you can
    use dmalloc (www.dmalloc.com) which is basically a library which replaces
    malloc and free - you link against the dmalloc library, and your calls to
    malloc and free are implemented by the versions in the dmalloc library;
    these versions do things like keep track of where memory is allocated,
    whether unallocated memory is being read/written to, etc.  i like 
    purify (http://www-306.ibm.com/software/awdtools/purify/features/index.html#win) which works on both windows and unix.  (incidentally, purified executables
   run 2-5x slower.)

 - don't make the same mistake twice: if you fix a bug somewhere, ask yourself
   where else you made the same mistake.

TESTING: POPs remarks on testing are fairly comprehensive.  you may find the 
concept of extreme programming quite interesting 
(http://www.extremeprogramming.org/) one key idea here is that test is 
as important as actual implememtation, and every class/function/package should 
code a set of test routines FIRST!

it's actually not that difficult to write test routines FIRST.  they 
don't have to be comprehensive right from the start, but if you put them off 
till the day they are "complete", chances are you'll never put them there 
in the first place.

GRADING:  i hope to be done with the first 3 HWs tomorrow, and plan to US mail
your solutions back to you with comments.  

pls mail me where you'd like me to mail you the HWs, with the text POP USMAIL 
in the subject line.

the goal of this class is for you to make a sincere attempt at reading the book.
i recognize that you have different backgrounds, particularly programming-wise,
and i'll make allowances for that.  in particular, if you turn in all HWs, and
it's clear that you really tried, you'll get an A.

ALTERNATIVE HW:  if you already know something, or there's something you are
more interested in learning, feel free to suggest substitute HWs (e.g., a 
major perl programming assignment) - chances are i'll allow the substitution.

cheers,
adnan


   



cheers,
adnan