My team has been trying (and failing!) for years to get a Verbose level
added to NSPR logging.
In the (non-WebRTC) media playback code, we now use the PR_LOG_DEBUG+1
hack. Like WebRTC, we have spammy, and super spammy logging modes.
Because of threading, often logging is the only or easiest
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
Yes, thanks. Eric's message was scrolled out of my view when I wrote my
responses. I'm happy to hear that.
cpearce.
On 5/29/2015 1:42 PM, Nicholas Nethercote wrote:
On Thu, May 28, 2015 at 4:21 PM, Chris Pearce cpea...@mozilla.com wrote:
My team has been trying (and failing!) for years to
On Thu, May 28, 2015 at 4:21 PM, Chris Pearce cpea...@mozilla.com wrote:
My team has been trying (and failing!) for years to get a Verbose level
added to NSPR logging.
Just yesterday Eric wrote (in the message immediately before this one
in the thread) the following:
After some back and forth
As I said earlier, I agree with Jesup. If people insist on not adding above
debug,
at least please allow individual modules to use a number that is DEBUG+1 on
their own this is relevant for a lot of the media stuff which actually has
its own logging
and just shims to PR_LOG anyway).
-Ekr
On
On Sat, May 23, 2015 at 4:46 AM, Randell Jesup rjesup.n...@jesup.org wrote:
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
Thanks Adam, these are good points.
On Friday, May 22, 2015 at 2:08:33 PM UTC-7, Adam Roach wrote:
On 5/22/15 15:51, Eric Rahm wrote:
I agree, we shouldn't make it harder to turn on logging. The easy
solution is just to add a separate logger for verbose messages (if we
choose not to add
On Friday, May 22, 2015 at 12:06:05 PM UTC-7, David Rajchenbach-Teller wrote:
On 22/05/15 04:06, Eric Rahm wrote:
After a rather thorough examination of usages of each I have come up with a
set that I believe would fit our needs:
enum class LogLevel {
Disabled = 0, // Logging is
On Fri, May 22, 2015 at 3:36 PM, Eric Rahm er...@mozilla.com wrote:
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
Hi,
I still want a same level as PR_LOG_ALWAYS.
In nsTextStore which is an implementation of ITextStoreACP of TSF uses
PR_LOG_ALWAYS only logs the module behavior. I.e., we can use to check
specific IME behavior with this level. I don't like to call this as
error. And also I wrote some
On Fri, May 22, 2015 at 4:11 PM, Eric Rescorla e...@rtfm.com wrote:
I think it's generally valuable to have a trace level for all
networking-type things.
Having some separate mechanism seems like the more complicated thing.
+1 - I actually wasn't aware of this debug+1 mechanism and now
On 5/22/15 4:50 AM, Ted Mielczarek wrote:
On Thu, May 21, 2015, at 10:06 PM, Eric Rahm wrote:
enum class LogLevel {
Disabled = 0, // Logging is disabled for this module
Error,
Warning,
Info,
Debug,
};
Just for comparison with other popular logging libraries:
Thanks Adam, these are good points.
On Friday, May 22, 2015 at 2:08:33 PM UTC-7, Adam Roach wrote:
On 5/22/15 15:51, Eric Rahm wrote:
I agree, we shouldn't make it harder to turn on logging. The easy solution
is just to add a separate logger for verbose messages (if we choose not to
add
On Fri, May 22, 2015 at 04:08:21PM -0500, Adam Roach wrote:
On 5/22/15 15:51, Eric Rahm wrote:
I agree, we shouldn't make it harder to turn on logging. The easy
solution is just to add a separate logger for verbose messages (if we
choose not to add Verbose/Trace).
I don't know why we
On Fri, May 22, 2015 at 11:46 AM, Randell Jesup rjesup.n...@jesup.org
wrote:
As part of the effort to improve logging in gecko we'd like to introduce
a new set of unified log levels.
*PR_LOG_DEBUG + 1 aka log level 5*
Various bits of code invented a log level that was less important than
On Fri, May 22, 2015 at 12:22 PM, Bobby Holley bobbyhol...@gmail.com
wrote:
On Fri, May 22, 2015 at 12:11 PM, Gregory Szorc g...@mozilla.com wrote:
Better than a log level is an event type (possibly enumerated). When
people
are looking at log output, they want to see specific events. While
+1 - I actually wasn't aware of this debug+1 mechanism and now that I am I
would like to make use of it.
Please, please, please don't do this until we work this out (once we switch to
enum class this will not be an option).
requiring special builds is much much less satisfying, especially
On 5/22/15 15:51, Eric Rahm wrote:
I agree, we shouldn't make it harder to turn on logging. The easy solution is
just to add a separate logger for verbose messages (if we choose not to add
Verbose/Trace).
I don't know why we wouldn't just add a more verbose log level (Verbose,
Trace... I
On Sat, May 23, 2015 at 5:11 AM, Gregory Szorc g...@mozilla.com wrote:
Better than a log level is an event type (possibly enumerated).
I suspect that's right.
Having said that, Eric is trying to clean up an existing system which
is large and messy. Just fixing up the log levels is challenging
Thank you for the feedback, you make some good points.
On Friday, May 22, 2015 at 1:31:14 AM UTC-7, masayuki nakano wrote:
Hi,
I still want a same level as PR_LOG_ALWAYS.
Would switching this to the new level 'Info' suffice? The main difference is
that by enabling the Info level you will
On Sat, May 23, 2015 at 4:46 AM, Randell Jesup rjesup.n...@jesup.org wrote:
Various bits of code invented a log level that was less important than
debug (I would call this verbose). This was not specified in NSPR logging,
but just kind of worked. With the addition of |Info| we can transition code
On Fri, May 22, 2015 at 1:02 PM, Nicholas Nethercote n.netherc...@gmail.com
wrote:
On Sat, May 23, 2015 at 4:46 AM, Randell Jesup rjesup.n...@jesup.org
wrote:
Various bits of code invented a log level that was less important than
debug (I would call this verbose). This was not specified in
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
On Thu, May 21, 2015, at 10:06 PM, Eric Rahm wrote:
enum class LogLevel {
Disabled = 0, // Logging is disabled for this module
Error,
Warning,
Info,
Debug,
};
Just for comparison with other popular logging libraries:
On 2015-05-22 7:50 AM, Ted Mielczarek wrote:
On Thu, May 21, 2015, at 10:06 PM, Eric Rahm wrote:
enum class LogLevel {
Disabled = 0, // Logging is disabled for this module
Error,
Warning,
Info,
Debug,
};
Just for comparison with other popular logging libraries:
As part of the effort to improve logging in gecko we'd like to introduce a new
set of unified log levels.
*PR_LOG_DEBUG + 1 aka log level 5*
Various bits of code invented a log level that was less important than
debug (I would call this verbose). This was not specified in NSPR logging,
but just
On 22/05/15 04:06, Eric Rahm wrote:
After a rather thorough examination of usages of each I have come up with a
set that I believe would fit our needs:
enum class LogLevel {
Disabled = 0, // Logging is disabled for this module
Error,
Warning,
Info,
Debug,
};
I'll vote to
On Thu, May 21, 2015 at 7:06 PM, Eric Rahm er...@mozilla.com wrote:
As part of the effort to improve logging in gecko we'd like to introduce a
new set of unified log levels.
Currently we use NSPR logging which defines the following log levels:
typedef enum PRLogModuleLevel {
On Fri, May 22, 2015 at 12:11 PM, Gregory Szorc g...@mozilla.com wrote:
Better than a log level is an event type (possibly enumerated). When people
are looking at log output, they want to see specific events. While
filtering by the logger is a good way to limit/expand logging, I find that
As part of the effort to improve logging in gecko we'd like to introduce a new
set of unified log levels.
Currently we use NSPR logging which defines the following log levels:
typedef enum PRLogModuleLevel {
PR_LOG_NONE = 0,/* nothing */
PR_LOG_ALWAYS = 1,
30 matches
Mail list logo
