Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Module implementing modified comment-style debugging.

by Socrates (Acolyte)
on Apr 30, 2008 at 17:43 UTC ( #683742=perlquestion: print w/replies, xml ) Need Help??
Socrates has asked for the wisdom of the Perl Monks concerning the following question:

I develop a large, mostly-cgi user interface for network appliances. Hence, large portions of my debugging are done passively via warns, traces, croaks and such in a virtualized environment.

The other day, a coworker and I were having a discussion and were thinking it be nice to be able to have a module which implemented a special kind of debugging syntax that would normally be interpreted as regular comments if the module was not included.

For instance:

some_function_call($var); #$# warn Dumper($var);
Or a block-level approach:
#$#DEBUG some_function_call(); another_function_call(); #$#END
I suppose, then, this is more of a two-part question on the capabilities of modules.
  1. is it possible to write a module that can keep lines starting with an certain string ("#$#" in this case) from being treated as comments like other lines beginning with "#"?
  2. could a module enable verbose tracing and execution, but only of certain specially-tagged blocks of code?
And a further supplemental question:
  • Is this even a good approach to debugging an application in this kind of environment?

Replies are listed 'Best First'.
Re: Module implementing modified comment-style debugging.
by Corion (Pope) on Apr 30, 2008 at 17:54 UTC

    See Smart::Comments - the technique applied is a "source filter", which is fraught with other problems but likely the best you can get with Perl 5.

      I'm assuming that by "fraught with other problems" you're referring to the "looks smarter than it really is" aspect mentioned on the Smart::Comments CPAN page? What other sorts of problems might arise?

        Source filters are generally problematic because they have to implement a parser for (parts of) Perl in Perl and usually do a bad job of this. Most of the time they work and when they fail it will take you a long time to track down the cause, unless you already know to look for tell-tale signs like the line use Switch;.

        If you're lucky, the filter implements a very limited language, like Querylet does and possibly Smart::Comments does as well.

Re: Module implementing modified comment-style debugging.
by stiller (Friar) on Apr 30, 2008 at 18:03 UTC
    Smart::Comments might meet your needs as stated more closely, but have a look at Log::Log4perl, it's very nice. Among other things, you can change logging level for individual parts of you system, without having to restart the system.
      I'd also go for Log::Log4perl. As you can see, leaving log statements in production code with logging disabled makes close to no impact on overall performance (it's actually faster in this benchmark :). Using the init_and_watch option, you can tune the log levels while the program is running (as noted by stiller). That is a property I value very much when arriving at a customer site and the system's symptoms are hard to interpret. Simply increase the log level for individual parts of the system, and see how it actually runs.
      $ /usr/bin/perl Rate fib_no_log fib_log_1 fib_no_log 997050/s -- -3% fib_log_1 1025993/s 3% --
      No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]
Re: Module implementing modified comment-style debugging.
by cdarke (Prior) on Apr 30, 2008 at 18:31 UTC
Re: Module implementing modified comment-style debugging.
by apl (Monsignor) on Apr 30, 2008 at 19:56 UTC
    I'm a dinosaur. In lieu of your
    some_function_call($var); #$# warn Dumper($var); #$#DEBUG some_function_call(); another_function_call(); #$#END
    I'd use:
    my $DEBUG = 0; some_function_call($var); Dumper($var) if $DEBUG > 0; if ( $DEBUG >= 5 ) { some_function_call(); another_function_call(); }
    I normally include $DEBUG in my Getopt, so I can determine the level of debugging at run-time.
Re: Module implementing modified comment-style debugging.
by oko1 (Deacon) on Apr 30, 2008 at 19:08 UTC

    Occasionally, when I have a Heisenbug in a script that resists walk-throughs with 'perl -d', I'll do something like this:

    ### At the top of the script my $debug = 1; # Set to '0' to disable debugging outp +ut sub debug { warn "DEBUG ($_[0]): <<<$_[1]>>>" if $debug; } [...] ### Some troublesome variable or value debug('$foobar', $foobar);

    For really stubborn bugs, I open a log file and write it to the log via 'Data::Dumper'. For that class of bug, I haven't yet found one that can beat that particular treatment.

    Human history becomes more and more a race between education and catastrophe. -- HG Wells
Re: Module implementing modified comment-style debugging.
by CardinalNumber (Prior) on Apr 30, 2008 at 17:56 UTC
Re: Module implementing modified comment-style debugging.
by jethro (Monsignor) on Apr 30, 2008 at 20:38 UTC
    Comment on the supplemental question:

    If you are debugging a cgi script, why not use something in the url to set your debug level.

    For example, if your normal call is

    then you set debug level to 1 with
    With a suitable apache configuration and an init routine to get the number out of the URL and a debug routine like oko1 or apl proposed you could avoid editing your script to turn debugging on or off.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://683742]
Approved by kyle
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2018-06-24 00:08 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.