Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > The DEBUG constant?

Reply
Thread Tools

The DEBUG constant?

 
 
kj
Guest
Posts: n/a
 
      08-10-2006



In perl documentation, I often run into references to a "DEBUG
constant", or some such. E.g., in the documentation for Carp::Assert
one sees code like this:

assert(EXPR) if DEBUG;

Is there in fact a special DEBUG constant in Perl, or does code
like the example above simply imply that elsewhere in the current
package one has a line like

use constant DEBUG => 0;

?

The above definition of DEBUG through the constant pragma is
straighforward enough but, as far as I can tell, it has the major
disadvantage of requiring the editing of the code to toggle its
value (as opposed to being easily settable from the command-line,
or perhaps from a config file), since all too often programmers
like me will forget to re-edit the code to ensure that DEBUG is
false in production code. Is this assessment correct?

Thanks!

kj
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
 
Reply With Quote
 
 
 
 
Paul Lalli
Guest
Posts: n/a
 
      08-10-2006
kj wrote:
> In perl documentation, I often run into references to a "DEBUG
> constant", or some such. E.g., in the documentation for Carp::Assert
> one sees code like this:
>
> assert(EXPR) if DEBUG;
>
> Is there in fact a special DEBUG constant in Perl, or does code
> like the example above simply imply that elsewhere in the current
> package one has a line like
>
> use constant DEBUG => 0;
>
> ?


That is my take on it, yes.

> The above definition of DEBUG through the constant pragma is
> straighforward enough but, as far as I can tell, it has the major
> disadvantage of requiring the editing of the code to toggle its
> value (as opposed to being easily settable from the command-line,
> or perhaps from a config file), since all too often programmers
> like me will forget to re-edit the code to ensure that DEBUG is
> false in production code. Is this assessment correct?


Yes.

I tend to use Getopt::Long when I want to enable or disable debug
statements....

use Getopt::Long;
GetOptions('debug' => \my $DEBUG);

assert($foo eq $bar) if $DEBUG;

__END__

And then on the command line...

../assertions.pl --debug
or even just
../assertions.pl -d

Paul Lalli

 
Reply With Quote
 
 
 
 
anno4000@radom.zrz.tu-berlin.de
Guest
Posts: n/a
 
      08-10-2006
Paul Lalli <(E-Mail Removed)> wrote in comp.lang.perl.misc:
> kj wrote:
> > In perl documentation, I often run into references to a "DEBUG
> > constant", or some such. E.g., in the documentation for Carp::Assert
> > one sees code like this:
> >
> > assert(EXPR) if DEBUG;
> >
> > Is there in fact a special DEBUG constant in Perl, or does code
> > like the example above simply imply that elsewhere in the current
> > package one has a line like
> >
> > use constant DEBUG => 0;
> >
> > ?

>
> That is my take on it, yes.
>
> > The above definition of DEBUG through the constant pragma is
> > straighforward enough but, as far as I can tell, it has the major
> > disadvantage of requiring the editing of the code to toggle its
> > value (as opposed to being easily settable from the command-line,
> > or perhaps from a config file), since all too often programmers
> > like me will forget to re-edit the code to ensure that DEBUG is
> > false in production code. Is this assessment correct?

>
> Yes.


To the OP: You can add unconditional debugging output to remind yourself
to switch off debugging, for instance (untested)

END { warn "Debugging active" if DEBUG }

There may be a form of assertion that can be used instead of warn().

Perl will go out of its way to execute an END block, so you'll
always see the final warning while debugging is on. An uncaught
exception is the only way to bypass END. There is little danger
of accidentally releasing software in that state.

> I tend to use Getopt::Long when I want to enable or disable debug
> statements....
>
> use Getopt::Long;
> GetOptions('debug' => \my $DEBUG);
>
> assert($foo eq $bar) if $DEBUG;
>
> __END__
>
> And then on the command line...
>
> ./assertions.pl --debug
> or even just
> ./assertions.pl -d


One point about the the approach using constants is that a statement
qualified by "if DEBUG" will not even be compiled when debugging
is off. Thus code with "DEBUG => 0" will be the same as if no
assertions were present at all.

Anno
 
Reply With Quote
 
kj
Guest
Posts: n/a
 
      08-11-2006
In <(E-Mail Removed)> http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de writes:

>Paul Lalli <(E-Mail Removed)> wrote in comp.lang.perl.misc:
>> kj wrote:
>> > In perl documentation, I often run into references to a "DEBUG
>> > constant", or some such. E.g., in the documentation for Carp::Assert
>> > one sees code like this:
>> >
>> > assert(EXPR) if DEBUG;
>> >
>> > Is there in fact a special DEBUG constant in Perl, or does code
>> > like the example above simply imply that elsewhere in the current
>> > package one has a line like
>> >
>> > use constant DEBUG => 0;
>> >
>> > ?

>>
>> That is my take on it, yes.
>>
>> > The above definition of DEBUG through the constant pragma is
>> > straighforward enough but, as far as I can tell, it has the major
>> > disadvantage of requiring the editing of the code to toggle its
>> > value (as opposed to being easily settable from the command-line,
>> > or perhaps from a config file), since all too often programmers
>> > like me will forget to re-edit the code to ensure that DEBUG is
>> > false in production code. Is this assessment correct?

>>
>> Yes.


>To the OP: You can add unconditional debugging output to remind yourself
>to switch off debugging, for instance (untested)


> END { warn "Debugging active" if DEBUG }


>There may be a form of assertion that can be used instead of warn().


>Perl will go out of its way to execute an END block, so you'll
>always see the final warning while debugging is on. An uncaught
>exception is the only way to bypass END. There is little danger
>of accidentally releasing software in that state.


>> I tend to use Getopt::Long when I want to enable or disable debug
>> statements....
>>
>> use Getopt::Long;
>> GetOptions('debug' => \my $DEBUG);
>>
>> assert($foo eq $bar) if $DEBUG;
>>
>> __END__
>>
>> And then on the command line...
>>
>> ./assertions.pl --debug
>> or even just
>> ./assertions.pl -d


>One point about the the approach using constants is that a statement
>qualified by "if DEBUG" will not even be compiled when debugging
>is off. Thus code with "DEBUG => 0" will be the same as if no
>assertions were present at all.


This is a generic enough functionality that I wish Perl had a
builtin mechanism for it, e.g. a standard global variable (requiring
no package qualification) that the compiler would understand as an
explicit cue from the programmer to optimize code away. This is
one area in which the conflict between "strict" and unqualified
names becomes annoying...

Maybe one can use the code

{ package DE; use constant BUG => 1 }

assert( tongue_in_cheek() ) if DE::BUG;

....

kj

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
 
Reply With Quote
 
Brian Greenfield
Guest
Posts: n/a
 
      08-21-2006
On 21 Aug 2006 02:16:04 -0700, "ska" <(E-Mail Removed)-brs.de> wrote:

>(E-Mail Removed)-berlin.de wrote:
>
>> One point about the the approach using constants is that a statement
>> qualified by "if DEBUG" will not even be compiled when debugging
>> is off. Thus code with "DEBUG => 0" will be the same as if no
>> assertions were present at all.

>
>I always wondered:
>
>Can you, for instance, write
>
>assert( condition );
>
>in the code, but let have perl ignore the statement, or let have perl
>_not_ evaluate the arguments, unless a $debug (non-constant) is true?


not quite. Consider x.pl:

#!/usr/bin/perl

use constant DEBUG => 0;

assert( 1 == 0 );

sub assert { die "bad thing happened" if DEBUG && ! $_[0] }

and then deparse it:

~/scripts$ perl -MO=Deparse x.pl # letter O, not digit
use constant ('DEBUG', 0);
assert(!1);
sub assert {
0;
}

you can see the sub call is still compiled, but the contents of the
sub aren't

>With a preprocessor one could write, e.g.:
>
>#define assert(a) if(debug) _assert(a)
>
>Is something like this possible in plain perl, too?


No, but I wish it was!
 
Reply With Quote
 
Dr.Ruud
Guest
Posts: n/a
 
      08-21-2006
ska schreef:

> Can you, for instance, write
> assert( condition );
> in the code, but let have perl ignore the statement, or let have perl
> _not_ evaluate the arguments, unless a $debug (non-constant) is true?


You can "use Sub::Assert", but the statement is not fullly ignored when
assertions are turned of.

See also "use constant", after which you could write "assert ... if
DEBUG" to let the assert-line get optimized away.

There is also Carp::Assert. And Perl 5.9.

http://search.cpan.org/search?m=module&q=assert&n=50

`perldoc constant`

--
Affijn, Ruud

"Gewoon is een tijger."


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
netvmini.sys still not working on Windows 7 even after driver signing disabled ?! (Windows debug mode necessary for debug drivers ???) Skybuck Flying Windows 64bit 3 08-09-2009 05:54 AM
debug="false" in web.config and <%@ debug="true" ...%> in aspx file => true or false? André ASP .Net 3 08-28-2006 12:02 PM
Config Mgr Debug/Release and Web.config Compilation debug=true RonL ASP .Net 0 04-08-2006 03:50 PM
Debug (DLL MFC) -> Debug (Static MFC) ringos75 C++ 0 04-14-2005 01:50 PM
[Howto] Compiling debug Python extensions for non-debug Python Mike C. Fletcher Python 3 10-12-2003 09:37 PM



Advertisments