> Robert,
> 
>> There's no definition of "context" --- the first example uses the
>> string 'czar' and I don't know how that's associated with a logger. If
>> it needs to be created explicitly from a config file I think we have a
>> problem.
> 
> 	A context is just a way of creating a relative logger name that
> is pushed/popped (with RAII now).  "czar" is just the addition to the
> logger name path (i.e. default_path = default_path + ".czar").  This new
> name can be used in the config file, but it is not created from the
> config file.

So is the logger created for me?

>> The performance of formatted output looks worrying.
> 
> 	Bill is working on this for boost::format.  Do you find the snprintf timings to be inadequate, too?

I thought that they were OK, but I don't see that on the new page.

>> We probably need to support boost::format too.
> 
> 	So your desire is to either speed up boost::format to be as fast as snprintf, or support both, right?

Yes.  If printf is fast enough we can live with it for most things, but I think we need the non-POD formatting as (maybe slower) option.

>>> 	Having enough debug levels.  I'd like to have at least 3 and
>>> 	maybe 5 different debug levels, and preferably control them by a
>>> 	numerical parameter not a logger name (protolog.debug(3, ...)
>>> 	rather than protolog.debug3(...)) to enable changing the level
>>> 	of groups of debug commands. Yes, you can do this with  mylog =
>>> 	{3: protolog.debug3);  mylog[3](...) but that's more work.
>> 
>> You provides only 2 by default, trace and debug (+ info + warn + error
>> + fatal).  That's not enough.  There's some python to support other
>> levels, but it's not standardized.
> 
> 	The point is that you should think about your multiple levels
> differently -- as multiple loggers rather than multiple levels.  Bill's
> sample code just shows the isomorphism between the two, but I don't
> think it's recommended that you actually use it.

I'd like a complete example of what is really being proposed (see below).  Please.

>>> 	I think we need to be able to change logging levels from an
>>> 	interactive python prompt.
>>> 
>>> 	This is probably supported, but with debug("afw.image", 1, ...)
>>> 	debug("afw.image.fitsio", 2, ...) Can I enable afw debug logging
>>> 	at level 1 (which applies to afw.image and afw.image.fitsio),
>>> 	then switch afw.image to 2 (which also applies to
>>> 	afw.image.fitsio), and then change afw.image.fitsio to yet
>>> 	another log level?
>> 
>> Can you provide a complete example to illustrate this?
> 
> setLevel("afw.image", 1)
> setLevel("afw.image", 2)
> setLevel("afw.image.fitsio", 3)

That's not complete.  How many loggers are involved?  How were they created?  I'm sorry, but clear complete examples are very helpful.

> 
>> My impression is that the levels are handled per-logger, and thus per context (== logger?? See comment on contexts above).  Is that right?
> 
> 	No, there's also inheritance in the tree (if Bill got this right).

> 
>> If so, before I can control the debugging level for a given package I
>> need to create a logger, and that requires an xml/log4j file which
>> users will *not* want to do.
> 
> 	No, you create a logger in the code.  The XML/log4j file controls how that logger logs.
> 
> -- 
> Kian-Tat Lim, LSST Data Management, [log in to unmask]

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1