Re: [MacPerl] Q: How do YOU generate debugging output?

[Alex Satrapa <packrat@blitzen.canberra.edu.au>]

At 00:08 +1000 on 5/7/97, you wrote:
>... One refinement that I use is to hand the actual output off
>to a function, something like:
>
>  sub debug {
>    my($level,$message) = @_;
>    print STDERR "DEBUG: $message\n" if ($DEBUG >= $level);
>  }
>
>which can then be invoked by something like:
>
>  &debug(2,"Oh no! We lost horribly!");
>
>The advantage[s] of doing it this way:
[reformatted]
  - if you decide that you want to write your debugging output somewhere
    else or customize the output format, you can hack a single function
    rather than changing every single invocation in the entire program.
  - It also makes for relatively clean and intelligible code.
  - The actual amount of debugging information you see is controlled by
    the global $DEBUG variable, and
  - each invocation of 'debug' specifies exactly how urgent the message
    in question is, so you can tailor the output to taste.

I suppose you'd set the $DEBUG based on "command line parameters" in case
you're running under a command-line based OS like Un*x? Vicky Brown asked
that same question about my sample code...

I have yet to look at CPAN to see if anyone else has done this yet... but
one idea I had was to use the standard options libraries or present dialog
boxes, based on the operating system. One way, I suppose, is simply to
replace Getopt::Std and Getopt::Long with routines that do similar things.
Or just have a big conditional "if ($OSNAME="MacOS") { moose } else { ape
};" Then I can have $DEBUG defined as a "default" in the code, with a
command line option to change it.

>... I even leave this
>stuff in 'production code', on the grounds that you never get *all* the
>bugs out, and some day you may be glad of the ability to switch debugging
>back on by editing a single line in a configuration file.

(or allowing for a "command line" option to set the debug level) That was
the way I was heading. Seeing that someone else has travelled this path too
indicates that I'm either just as right as everyone else, or we're all done
for done-diddly-done for!

>...I await with interest to see what the Perl Gods recommend.

I haven't heard any more on the subject. Guess not many people out there
put debugging code in :-(

There's only so much you can learn about your program by running it through
"perl -d". When I was writing Pascal programs at school, my teacher
suggested using colour coding or special symbols to make important lines
stand out. Perhaps I'll adapt my own debug routine to do similar things eg:
put a variety of symbols like ¡, * and * ahead of debugging lines to
indicate trivial through critical errors.

This is getting way to long for a reply... but thanks for your response!

-Alex
"If the code was damned hard to write, it should be damned hard to read, too!"

Windows 95: n. 32 bit extensions and a graphical shell for a 16 bit patch
to an 8 bit operating system originally coded for a 4 bit microprocessor,
written by a 2 bit company.