Re: [log4perl-devel] Log::Log4perl::AutoCategorize

[Jim C. <jc...@di...>]

Mike Schilli wrote:

>On Fri, 30 May 2003, Jim Cromie wrote:
>
>  
>
>>Yeah, the optimizer part took some time to Grok.
>>I hope that the code and the comments will take you thru the hard parts,
>>let me know if otherwize.
>>    
>>
>
>Jim, nice work! Here's a couple of item I stumbled across, in the order
>I encountered them:
>
:-D

thx Mike & Kevin.  Yours are the 1st other set of eyeballs on it.

     Did you get a chance to run 'make test' ?
     On what platform(s) ?
     Did it just work ?
     Did you run perftests/timeit.sh ? (can you send me results ?)

>* You might want to explain what 'static method style' is.
>  
>
heh - static method is what I called it for lack of a better description.

'static method' is equivalent (at an approximate level)  to 'class method';

ie:       Class->method()   # what Ive called static (probably needs 
better name)
vs:       $obj->method()    # std instance method
vs:      Class::Method()     # Fully Qualified, class method.

I dont think there is a preferred name for this construct, would welcome 
corrections or
pod-citations, or even opinions as to what best conveys that the best.


>* You write: "Log::Log4perl provides easy_init(), which achieves some
>  simplification of categories, but you are still faced with creating
>  them once" -- but this function doesn't really do anything for categories.
>  The stealth logger feature included via 'use Log::Log4perl qw(:easy);'
>  is probably what you're referring to -- although you don't have to
>  'create' categories, it just uses the class names.
>  
>
heh - I guess I should write a use-case of it, following the specific 
example in perftest/t2.pl.
Then with a few tips, I could re-write it for a fair comparison wrt 
style, performance, etc..

>* As mentioned before, I like the coverage feature a lot. What's the
>  "unseen log", though, and how does it work?
>  
>

When function name munging is done (at use/check time), each munged name 
is recorded
as a key in an %unseen hash.   As each function-name is 1st seen by 
AUTOLOAD,
and vivified into a subroutine, the name is deleted from %unseen.    
What remains at
end-time are munged function names that were never called, so were never 
seen by AUTOLOAD.

>* Looks like in
>        # for example, debug Frob.pm, but only info on Frob::nicate()
>        log4perl.category.Frob = DEBUG
>        log4perl.category.Frob.nicate.debug = INFO
>  -- there's no appender, would be informative to see what the recommended
>  way of defining them is (and think of messages "bubbling up" :).
>  
>
hmm.  I left out any appender precisely to focus on how successive 
layers of categories would
filter the items - most debug from Frob:: would logged, but not from 
nicate(), cuz of the
more specific config-item.  And so on.    Ill try to clarify it, and 
re-test the phrasing on you all.

>* I didn't understand what you meant by this: "Its probably a bit
>  confusing at 1st to have debug=INFO, but this is intentional; it tells
>  you the logging level thats coded (so you dont have to go back to the
>  source everytime), and therefore what is done if the config-line is
>  commented out."
>  
>
self-fullfilling prophesy on the confusion, eh ?

The category that AUTOLOAD constructs includes the logging-level as 
extracted from the function,
(ex: info from Logger->info_00013).   Because its part of the category, 
it ends up in the coverage logs,
and can be cut-pasted into the config-file, where it serves to convey 
both; 'this is what it does now',
and 'this is what it does by default'. 

The 'does now' part is debug=INFO (ie this debug message is suppressed, 
cuz INFO is higher than debug)
The 'default' part is as follows : the code contains a debug call at 
package X, method Y, line Z, and if you
were to comment out this config-line, it would bubble up, and be dealt 
with according to other
config items. 

>* Question: If a module author decides to ship his module with
>  Log::Log4perl::AutoCategorize, will it work if the main program
>  (1) doesn't use it?
>  (2) uses plain Log::Log4perl?
>  
>

REALLY good question, cuz its really important to coexist, and I hadnt 
thought to test for it.

For 1, Id expect it would just pick up the default config.
For 2, I suspect that Imight load right over existing config, which 
would be bad.

which brings me to a set of Qs;

1 .Are you currently considering an include mechanism so that
    a config could be broken down into chunks that control the app's 
subsystems ?

2. Would the include scheme work for overrides & subclasses ?
    Id like it to be possible to specify both an initfile => $file, and 
initstr => q{blah ..},
    and have the initfile specify the general logging behavior (for say 
a set of related utilities)
    with specific overrides given for utility-A, B, etc.

3.  wrt init_and_watch(), I need a notification when a new config is 
loaded and parsed.
    (its probably there already - I havent looked yet)   I need to 
undefine munged-functions
    where the config has changed, so AUTOLOAD is called again for each 
item, and can rewrite
    the corresponding a-sub according to the new config.
   
    Id prefer not to undefine all subs, but this means that the 
notification would have to include
     a list of categories that were changed ( added/deleted/altered - 
tho I dont need to know which)

4. th down, punt.
    The issue boils down to;  what happens if Log::Log4perl->init() is 
called 2x. 
    In your (2) scenario it seems quite likely to happen, but could also 
happen while using
    just Log::Log4perl, wo my wrapper. 

    I currently rely on the over-load; I load my default-config at 
use-time, unless either initfile or
    initstr is given.  Since my default-load happens at use time, if the 
application calls init() itself,
    it will most likely override my config.

>* As for shipping it with Log::Log4perl ... you're depending on optimizer.pm
>  which depends on 5.7.2 -- and Log::Log4perl works with 5.005_03. I
>  think you're gonna be better off shipping it as a separate module to
>  CPAN, this way you're free in what modules you depend on and don't
>  have to support odd configurations (perl 5.005_03, Windows). We'll
>  certainly provide a plug for Log::Log4perl::AutoCategorize within the
>  Log::Log4perl docs.
>  
>
:-D

heh, from the outset I had a very different interface, (ie 
Logger->debug()), and dependencies
on new modules, so I had the separate dist as a mind-set.  I never even 
got around to thinking
about versions support.

Ill start a thread on modules-*@perl.org now..

If you had an opportunity to change the package-name (you do), would you  ?

Log::Log4perl::AutoCat      (shorter, but ultimately not as descriptive)
Log::Log4perl::AutoCover   (emphasize coverage features)
any other possibilities ??


-- Mike

>Mike Schilli
>log...@pe...
>http://perlmeister.com
>http://log4perl.sourceforge.net
>
>  
>
-jimc