Bug #103902 for Debug-Show: Runtime switching

Thu Apr 23 03:38:18 2015 EDAVIS [...] cpan.org - Ticket created

Subject:

Runtime switching

I understand that a major selling point of Debug::Show is that when turned off, it is turned off at compile time, so has little run time overhead. Nonetheless it can often be useful to turn on debug printing at run time. Is there scope for adding a mode where printing is controlled by a global variable? use Debug::Show qw(debug=conditional); $Debug::Show::On = 1; debug('hello'); # prints $Debug::Show::On = 0; debug('goodbye'); # runs, but does not print That would also allow things like { local $Debug::Show::On = 1; # do some stuff with printing turned on } $Debug::Show::On = 1 if $opt_trace; Later, the programmer would be able to change debug=conditional to debug=hide to have all the calls compiled out. But debug=conditional is a useful setting for non-performance-critical code where you want flexibility to start producing debug output (perhaps even in an already-running process).

Thu Apr 23 06:33:11 2015 zefram [...] fysh.org - Correspondence added

Subject:	Re: [rt.cpan.org #103902] Runtime switching
Date:	Thu, 23 Apr 2015 11:32:25 +0100
To:	EDAVIS via RT <bug-Debug-Show [...] rt.cpan.org>
From:	Zefram <zefram [...] fysh.org>

EDAVIS via RT wrote: Show quoted text

>Nonetheless it can often be useful to turn on debug printing at run time. >Is there scope for adding a mode where printing is controlled by a >global variable?

Maybe, but it doesn't seem awfully appealing to me. You can achieve much of the effect already with a $SIG{__WARN__} handler: $SIG{__WARN__} = sub { warn($_[0]) if $_[0] !~ /\A### / || $Debug_Show_On; }; If I were to make D:S runtime-configurable, I'd probably offer a global hook of this general form, rather than just the choice between warning and not: $Debug::Show::Output = sub { warn($_[0]) }; # default $Debug::Show::Output = sub { }; $Debug::Show::Output = sub { $AppLogger->log($_[0], "debug") }; Show quoted text

>But debug=conditional is a useful setting for non-performance-critical >code where you want flexibility to start producing debug output (perhaps >even in an already-running process).

In the case where you want the debug tracing always compiled in, D:S is the wrong tool. -zefram

Thu Apr 23 06:33:11 2015 The RT System itself - Status changed from 'new' to 'open'

Fri Apr 24 09:39:54 2015 EDAVIS [...] cpan.org - Correspondence added

Localizing the subroutine is certainly more flexible than localizing an on/off flag. Usually a large codebase will have a mixture of requirements. There is some code where performance is important, where trace statements should be compiled out for best speed (even though this requires a restart to turn them on). Error handling and 'why on earth is this happening' code will often want to crank up the verbosity level if it ever runs. And there will be a larger body of code which is not part of the hot path, so the few percent slowdown of running some do-nothing trace statements is not important, but where it is useful to switch on tracing at run time. It would be easier to have similar syntax for trace statements in all three, rather than having to use two different modules for compiled-out and run-time-switchable trace. After all, code moves quite fluidly between the three categories; today's heavily logged experimental code may become tomorrow's well-tested, performance-critical section and vice versa. Better to flip between the kinds of trace with a single flag at the top of the source file rather than with a global search and replace from one trace primitive to another.