Module implementing modified comment-style debugging.

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);
[download]

Or a block-level approach:

#$#DEBUG
some_function_call();
another_function_call();
#$#END
[download]

I suppose, then, this is more of a two-part question on the capabilities of modules.

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 "#"?
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?

Comment on Module implementing modified comment-style debugging. Select or Download Code

Replies are listed 'Best First'.
Re: Module implementing modified comment-style debugging. by Corion (Patriarch) 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.	[reply]
Re^2: Module implementing modified comment-style debugging. by Socrates (Acolyte) on Apr 30, 2008 at 18:19 UTC
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?	[reply]
Re^3: Module implementing modified comment-style debugging. by Corion (Patriarch) on Apr 30, 2008 at 18:24 UTC
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.	[reply] [d/l]
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.	[reply]
Re^2: Module implementing modified comment-style debugging. by andreas1234567 (Vicar) on May 01, 2008 at 05:58 UTC
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. Read more... (2 kB) `$ /usr/bin/perl l4p_bench.pl Rate fib_no_log fib_log_1 fib_no_log 997050/s -- -3% fib_log_1 1025993/s 3% --` [download] -- No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]	[reply] [d/l] [select]
Re: Module implementing modified comment-style debugging. by cdarke (Prior) on Apr 30, 2008 at 18:31 UTC
Carp::Assert is another possibility	[reply]
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` [download] I'd use: `my $DEBUG = 0; some_function_call($var); Dumper($var) if $DEBUG > 0; if ( $DEBUG >= 5 ) { some_function_call(); another_function_call(); }` [download] I normally include $DEBUG in my Getopt, so I can determine the level of debugging at run-time.	[reply] [d/l] [select]
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);` [download] 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	[reply] [d/l]
Re: Module implementing modified comment-style debugging. by SankoR (Prior) on Apr 30, 2008 at 17:56 UTC
Sounds very similar to Smart::Comments.	[reply]
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 `http://website/path/bla.html` [download] then you set debug level to 1 with `http://website/path/bla.html?d=1` [download] or `http://website/1/path/bla.html` [download] or `http://website/path/bla.html1` [download] 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.	[reply] [d/l] [select]