Re: [log4perl-devel] requesting feedback on Log::Abstract
Mike Schilli wrote: > > While you're at it, here's my pipe dream: I want something like Dtrace, > where the logging framework zeroes out the opcodes that are currently > inactive, and the interpreter rushes through them at light speed with > practically no overhead. > > -- Mike > This sounds like what I did with Log4perl::AutoCategorize, ( which is unsupportable - due to breakage of B::Generate ) FWIW, it hacked the optree to cause an AUTOLOAD fn to instantiate a different sub for every call-point. that new sub could be customized for to the way the config applied to that call-point, thus inlining all the config decisions. Assuming B::Generate comes back to life (there is hope yet), it will be practical to truly no-op the call. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ log4perl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] requesting feedback on Log::Abstract
>> The problem I have with the DEBUG etc keywords is that they promote
>> inefficient behavior. e.g.
>>
>> DEBUG "Current arguments: " . Dumper([EMAIL PROTECTED]);
>>
>> will take the performance hit for Dumper() even when debug logging
>> isn't turned on.
>
> Sure, although I don't see how
>
> $log->debug("Current arguments: " . Dumper([EMAIL PROTECTED]));
>
> is any different.
It isn't different, by itself, but it translates naturally into
$log->debug("Current arguments: " . Dumper([EMAIL PROTECTED])) if
$log->is_debug;
whereas if you start off in easy mode, you don't have any way to get
at the logger (as far as I can tell).
> By the way, in Log4perl you can pass a subroutine ref
> to the method, which eliminates the problem:
>
> DEBUG sub { "Current arguments: " . Dumper([EMAIL PROTECTED]) };
>
Right, I forgot about the subroutine syntax. I do think that is a
little harder for novices, and a little more expensive, than the
conditional (especially when the conditional is against a simple
scalar).
To be honest I have other problems with porting the DEBUG etc
keywords into a generic, universally acceptable API. The all-caps is
not in line with Perl standards, and it interferes with
Carp::Assert's DEBUG. It also introduces a second, less-powerful API
that isn't trivial to convert to the primary API when you need more
features. IMHO it is better to just provide users with an easy way to
create the default logger, and then maintain a single powerful OO
API. My two cents.
Jon
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
log4perl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
Re: [log4perl-devel] requesting feedback on Log::Abstract
On Mon, 10 Sep 2007, Jonathan Swartz wrote:
> It isn't different, by itself, but it translates naturally into
>
> $log->debug("Current arguments: " . Dumper([EMAIL PROTECTED])) if
> $log->is_debug;
>
> whereas if you start off in easy mode, you don't have any way to get
> at the logger (as far as I can tell).
get_logger() without arguments defaults to the current package:
DEBUG "Current arguments: " . Dumper([EMAIL PROTECTED]) if
get_logger()->is_debug;
But I agree that that's a stretch. We could export IS_DEBUG(), but it
hasn't come up yet, so I assume people don't stumble over it often.
> > By the way, in Log4perl you can pass a subroutine ref to the method,
> > which eliminates the problem:
> >
> > DEBUG sub { "Current arguments: " . Dumper([EMAIL PROTECTED]) };
> >
>
> Right, I forgot about the subroutine syntax. I do think that is a
> little harder for novices, and a little more expensive, than the
> conditional (especially when the conditional is against a simple
> scalar).
Interesting. Have you benchmarked it?
> To be honest I have other problems with porting the DEBUG etc
> keywords into a generic, universally acceptable API.
> The all-caps is not in line with Perl standards,
Clearly, you could argue either way. I like it :).
> and it interferes with
> Carp::Assert's DEBUG.
Clearly, an API like this will clash with one module or another.
>It also introduces a second, less-powerful API that isn't trivial to
>convert to the primary API when you need more features. IMHO it is
>better to just provide users with an easy way to create the default
>logger, and then maintain a single powerful OO API. My two cents.
I disagree. Easy things should be easy, hard things possible. Sounds
familiar? :)
-- Mike
Mike Schilli
[EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
log4perl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
