The DEBUG constant?

Discussion in 'Perl Misc' started by kj, Aug 10, 2006.

  1. kj

    kj Guest

    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.
    kj, Aug 10, 2006
    #1
    1. Advertising

  2. kj

    Paul Lalli Guest

    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
    Paul Lalli, Aug 10, 2006
    #2
    1. Advertising

  3. kj

    -berlin.de Guest

    Paul Lalli <> 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
    -berlin.de, Aug 10, 2006
    #3
  4. kj

    kj Guest

    In <> -berlin.de writes:

    >Paul Lalli <> 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.
    kj, Aug 11, 2006
    #4
  5. On 21 Aug 2006 02:16:04 -0700, "ska" <-brs.de> wrote:

    >-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!
    Brian Greenfield, Aug 21, 2006
    #5
  6. kj

    Dr.Ruud Guest

    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."
    Dr.Ruud, Aug 21, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christopher M. Lusardi
    Replies:
    1
    Views:
    4,072
  2. Martin Magnusson
    Replies:
    2
    Views:
    490
    John Harrison
    Oct 8, 2004
  3. Tor Erik Soenvisen
    Replies:
    14
    Views:
    543
    Tim Roberts
    Nov 23, 2006
  4. Replies:
    4
    Views:
    331
    Keith Thompson
    Dec 14, 2006
  5. Replies:
    13
    Views:
    12,892
    Kai-Uwe Bux
    Jan 22, 2007
Loading...

Share This Page