Conditional Interpretation?

earcam has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Conditional Interpretation? by ikegami (Patriarch) on Feb 01, 2006 at 03:13 UTC
Two ways. 1. You can tell Perl to use the C preprocessor with the command line option -P. Be sure to read the limitations of the switch, as documented in perlrun. 2. Use constant folding to remove the checks at runtime. In the following, notice how the debug code is removed when (and only when) a constant expression is used in the `if`: `>perl -MO=Deparse -e "$DEBUG = 0; print(qq{debug\n}) if $DEBUG; print( +qq{end\n})" $DEBUG = 0; print "debug\n" if $DEBUG; print "end\n"; -e syntax OK >perl -MO=Deparse -e "use constant DEBUG => 0; print(qq{debug\n}) if D +EBUG; print(qq{end\n})" use constant ('DEBUG', 0); '???'; print "end\n"; -e syntax OK` [download]	[reply] [d/l] [select]
Re: Conditional Interpretation? by ptum (Priest) on Feb 01, 2006 at 03:00 UTC
Re: Conditionally including modules	[reply]
Re: Conditional Interpretation? by gryphon (Abbot) on Feb 01, 2006 at 03:06 UTC
Greetings earcam, One of the things we did was to use a constant (or a bitwise and set of constants) inside a right-side if conditional for whether we had debug statements work. The compiler optimizes away the entire line at run-time if the constant conditional is false. `do_something() if ($CONSTANT); do_something_else() if ($CONSTANT & $ANOTHER_CONSTANT);` [download] Is this what you're looking for? gryphon Whitepages.com Development Manager (WDDC) code('Perl') \|\| die;	[reply] [d/l]
Re^2: Conditional Interpretation? by ikegami (Patriarch) on Feb 01, 2006 at 03:14 UTC
Constants don't have leading dollar signs. `do_something() if (CONSTANT); do_something_else() if (CONSTANT & ANOTHER_CONSTANT);` [download] If there's a dollar sign, it's not a constant, and Perl won't optimize it away.	[reply] [d/l]
Re: Conditional Interpretation? by blazar (Canon) on Feb 01, 2006 at 11:53 UTC
In addition to the other suggestions that have already been given to you, it is worth mentioning that you would better provide a per-module conditional debugging facility. You may want to activate it like `use My::Module DEBUG => 1;` [download] or more easily from the implementation POV: `use My::Module; # ... $My::Module::DEBUG = 1;` [download] If you're concerned that for every debugging info there will be a condition to be checked, for the most critical cases you may write two versions of a sub: one for regular use and one for debugging and call them dereferencing a coderef to the appropriate one assigned to a variable, or perhaps, if you really need to, you may mangle the symbol table. But please do that only if you know what you're doing	[reply] [d/l] [select]
Re: Conditional Interpretation? by glasswalk3r (Friar) on Feb 01, 2006 at 13:50 UTC
Maybe this is not exactly what you're looking for, but if you want to add logging to the OO modules depending on a value, them you should check the Log4Perl module. Alceu Rodrigues de Freitas Junior --------------------------------- "You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill	[reply]
Re: Conditional Interpretation? by salva (Canon) on Feb 01, 2006 at 14:54 UTC
you are looking for assertions, unfortunatelly they only work on the unstable versions of perl. assertions::compat is also available but it requires you to test constants explicitelly as ... `dbg and expensive_test();` [download] Another similar module is ctflags (that stands for "compile time flags"), it is overly complex with too many options... but for what you need: In some place, at the beggining of your script, include this code to set flags from an environment variable: `use ctflags::parse ns => "myapp:debug", env=>'MYAPPDEBUG';` [download] then in every module where you want to conditionally execute something add: `use ctflags prefix=>'dbg_', 'myapp:debug:*'; dbg_a and print "a flag is on\n"; dbg_b and print "b flag is on\n"; dbg_c and print "c flag is on\n";` [download] Finally, if you call your script as `$ MYAPPDEBUG=ac perl myapp.pl` [download] it will output `a flag is on c flag is on` [download]	[reply] [d/l] [select]
Re: Conditional Interpretation? by earcam (Initiate) on Feb 01, 2006 at 23:40 UTC
Thanks for all suggestions, I will investigate these further and report back. To clarify my problem here's an example `sub someMethod { my $this = isa( ref $_[0], 'Package::Path::Module' ) ? shift : die( +'Package::Path::Module::someMethod called with uninstantiated object. +'); # ... }` [download] Replaced with something like: `sub someMethod { =PERL_INCLUDE my $this = isa( ref $_[0], 'Package::Path::Module' ) ? shift : die( +'Package::Path::Module::someMethod called with uninstantiated object. +'); =PERL_INCLUDE # ... }` [download] With the shebang in calling script stating something like: #!/usr/bin/perl -Wall -POD_PERL_INCLUDE to include the POD section. The instantiation check exists in every object/instance method (with a similar check for class-only methods) - with a massive number of subroutine calls, this really hits performance across all the code. ( I know there's quicker ways of checking correct instantiation, but it's still a check that becomes unnecessary for production code ) There are many other checks that could also be excluded. Our logging already works using sub refs to a dummy subroutine to avoid endless if($obj->{'DEBUG'}){ ... } calls so no gains to be made there. I think we may have exhausted the majority of optimisation tricks - avoiding these kind of checks shaves off approximately 1/4 of the total run time. I found this (via "man perlbot") 1 Do not attempt to verify the type of $self. That'll break if the class is inherited, when the type of $self is valid but its pack- age isn't what you expect. See rule 5. 2 If an object-oriented (OO) or indirect-object (IO) syntax was used, then the object is probably the correct type and there's no need to become paranoid about it. Perl isn't a paranoid language anyway. If people subvert the OO or IO syntax then they probably know what they're doing and you should let them do it. See rule 1. Though object orientated, we've avoided inheritance, but I still disagree with the above because not checking how a method is called has already caused hours of scratched heads and bug hunting - so we do need these checks at dev level, but only at dev... Thanks for all comments. cheers, Caspar	[reply] [d/l] [select]