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 wrote:
My team has been trying (and failing!) for years to get a Verbose level
ad
On Thu, May 28, 2015 at 4:21 PM, Chris Pearce 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 in this thread,
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-fram
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 wa
After some back and forth in this thread, IRC, and in bugzilla I've been
convinced that adding a Verbose level will make this transition smoother.
The new enum will look something like:
enum class LogLevel {
Disabled = 0, // Logging is disabled for this module
Error,
Warning,
Info,
Deb
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 We
>On Sat, May 23, 2015 at 4:46 AM, Randell Jesup 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
>> people are used t
>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
>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
On Fri, May 22, 2015 at 3:36 PM, Eric Rahm 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 module
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, // Logg
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-netw
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 w
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
>
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:
http://loggi
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 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 don
> +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, especiall
On Fri, May 22, 2015 at 4:11 PM, Eric Rescorla 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 that I am I
On Fri, May 22, 2015 at 1:02 PM, Nicholas Nethercote wrote:
> On Sat, May 23, 2015 at 4:46 AM, Randell Jesup
> 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
On Sat, May 23, 2015 at 5:11 AM, Gregory Szorc 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
enough, as seen
On Sat, May 23, 2015 at 4:46 AM, Randell Jesup 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
>>that was us
On Fri, May 22, 2015 at 11:46 AM, Randell Jesup
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
> >debug (I w
On Fri, May 22, 2015 at 12:22 PM, Bobby Holley
wrote:
> On Fri, May 22, 2015 at 12:11 PM, Gregory Szorc 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
On Fri, May 22, 2015 at 12:11 PM, Gregory Szorc 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
> this approach is
On Thu, May 21, 2015 at 7:06 PM, Eric Rahm 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 {
> PR_LOG_NONE = 0,
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 vo
>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,
>bu
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:
http://logging.ap
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:
http://logging.apache.org/log4j/2.x/manual/customlogle
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 docu
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, /*
32 matches
Mail list logo
