On 5/27/2015 3:58 PM, Randell Jesup wrote:
Thanks Randell, these are good points. I'll address a few of your comments
that have not already been covered in the rest of the conversation.
This is used extensively in WebRTC and related media bits to enable
*huge* amounts of debugs (like every-frame debugs for audio or video or
per-network-packet debugs, which will swamp a system normally), and since
people are used to enabling "debug" on random modules (or all:5), having
verbose debugs in the "normal" :5 setting will cause pain.
Here lies half the problem, that number does not mean what we were led to
think it means. Using :5 would include PR_LOG_DEBUG + 1 [1].
The above will also be surprising since it will work "differently" than
other modules, making the same sorts of debugs appear at different
levels. This would be expecially confusing to people not frequently
working in the module or when external users are asked to turn on
debugging.
This assumes log levels have been used consistently across modules, I can
assure you that is not the case :) I hope that we can get to a more
consistent state of course!
Sure - but having "debug" logs at DEBUG in module A, and INFO in module
B (with "verbose-you-only-want-them-if-you-want-insane-data" being at
DEBUG in B) will cause confusion.
+1 !!
It means "turn on logging for X"
requires knowledge of which of two patterns X follows. It also
means all:4 (or all:debug) will cause suprising (and useless) results.
And when coding, it'll be easy to use the "wrong" pattern when switching
between modules. I see serious pain in a two-model system. And we have
real *need* for logging at a makes-the-browser-almost-unusable volume to
track down certain sorts of things.
Even splitting say mediamanager:5 into mediamanager:4 (or :debug) and
mediamanager_verbose:4 (or :debug) will have the same problem for all:.
And it will make getting verbose logging more painful for no real reason.
I don't think it will be any more confusing when telling the external user
what level to turn on (it's already rather confusing). Do we need super
spammy? Turn on debug. Do we need just the basics? Turn on info.
Then there's an oddball: webrtc.org "Trace" logging (a separate
subsystem with low-overhead buffered-IO circular-log maxed at 10MB),
which requires a 16-bit mask. Currently this is exposed as
webrtc_trace:65535 (for example), with a separate env var telling it
where to put the logfile (or 'nspr' to revector the logs through NSPR
logging, which *really* will cause problems with realtime code but is
handy at times). For this oddball, we could do other things like move
it to a separate env var (which is annoying to people using it, but not
horribly).
I think it's probably best to keep this a separate env rather than trying to
shoehorn it in.
Understandable - but I've been trying to move in the opposite direction;
avoiding N different env vars (and also, if I can avoid that, I have
a better chance of leveraging on-the-fly log level changes without
having to reinvent the wheel).
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
