> 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
|