Loglevels question

[Gabriela Gibson]

What are we going to use certain log level for, and when/why?

I have cut down the 'classic' list to these:

Name Order Purpose
---------------------------------------------------------------
LOG_ERR
LOG_WARN
LOG_NOTICE
LOG_DEBUG
LOG_INFO

I can add more and it's easy to add custom levels on the fly, but
my main question is, can we standardise the meaning of the names
and the purpose. For example, WARN, NOTICE and INFO look pretty
similar to me -- do we need them all? And when would we use
them?

Then there is also the question of the order, because whilst it's
possible to switch on a specific level (or, even cherry pick
levels with a bit of extra code), being able to say 'any log
levels below and including foo' is useful.

So I put that list, just to see what order and purpose you think
those levels should have. If you do not see what you'd like, add
it to the list :)

thanks,

G

[jan i]

On Thursday, September 10, 2015, Gabriela Gibson <gabriel...@gmail.com> wrote:

What are we going to use certain log level for, and when/why?

I have cut down the 'classic' list to these:

Name        Order       Purpose
---------------------------------------------------------------
LOG_ERR
LOG_WARN
LOG_NOTICE
LOG_DEBUG
LOG_INFO

i am all for romving LOG_WARN and LOG_NOTICE, It is too detailed in my opinion.

rgds

jan i 

I can add more and it's easy to add custom levels on the fly, but
my main question is, can we standardise the meaning of the names
and the purpose.  For example, WARN, NOTICE and INFO look pretty
similar to me -- do we need them all? And when would we use
them?

Then there is also the question of the order, because whilst it's
possible to switch on a specific level (or, even cherry pick
levels with a bit of extra code), being able to say 'any log
levels below and including foo' is useful.

So I put that list, just to see what order and purpose you think
those levels should have.  If you do not see what you'd like, add
it to the list :)

thanks,

G

--
You received this message because you are subscribed to the Google Groups "CorinthiaTeam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to corinthiatea...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from My iPad, sorry for any misspellings.

[Ian C]

Hi G,

I would drop the NOTICE. To me NOTICE and INFO are much the same.
We could have a VERVOSE or TRACE level.

Then when to use each should be pretty obvious, and similar to a
compiler's output.
ERROR - it ain;t gonna work
WARN - it should be okay but should have...
INFO - keeping the user etc up to date with what is going on
VERBOSE - even more info about what is going on.
And DEBUG for devlopment/tracing.

I also like the way gcc adds colour to the different levels.

And switching levels on and off, generally it is only the VERBOSE and
DEBUG levels that would be optional on systems I have seen.
But I have also seen those that skip the the others and only tell when
things go wrong.

> --
> You received this message because you are subscribed to the Google Groups "CorinthiaTeam" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to corinthiatea...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

Cheers,

Ian C

[Gabriela Gibson]

On Saturday, September 12, 2015 at 5:15:24 AM UTC+1, Ian C wrote:
> Hi G,
>
> I would drop the NOTICE. To me NOTICE and INFO are much the same.
> We could have a VERVOSE or TRACE level.
>
> Then when to use each should be pretty obvious, and similar to a
> compiler's output.
> ERROR - it ain;t gonna work
> WARN - it should be okay but should have...
> INFO - keeping the user etc up to date with what is going on
> VERBOSE - even more info about what is going on.
> And DEBUG for devlopment/tracing.
>
> I also like the way gcc adds colour to the different levels.
>
> And switching levels on and off, generally it is only the VERBOSE and
> DEBUG levels that would be optional on systems I have seen.
> But I have also seen those that skip the the others and only tell when
> things go wrong.
>
> On Fri, Sep 11, 2015 at 3:18 AM, Gabriela Gibson
> <gabriel...@gmail.com> wrote:
> > What are we going to use certain log level for, and when/why?

(snip)

> --
> Cheers,
>
> Ian C

Hi,

I have to admit I've never actually used a logger, until I wrote one
and tested it. *blush*

Mostly I used printf I typed out dutifully, then commented out and
eventually deleted, just to retype them. Several times over. (gah)

Hence, my desire to have something that allows me to selectively
create customised debug statements (say, per function) so that I write
once, and then just switch off, until I inevitably find that I need
them again.

Also, I have to ask/verify some things with y'all, just so I can
document this properly to make sure that everyone is on the same plane
:-)

LOG_ERR: Is this meant for production code? With the idea that ERR
seems to be a pretty serious case and probably something that
only happens when the moon is green.

LOG_INFO: Is this used to leave little communiques about the code,
say, if I made a less than optimal algo that works but could
do better, or if there is a TODO issue that affects the code
path later on?

LOG_TRACE: Is this a 'I was here' thingy as we know it from gdb's
stack trace, just less work? (if so, this would be very
nice to have a turn off/on switch[1])

LOG_DEBUG: I imagine to this to be incredibly noisy in a big
application. How do you use this so that it's not
ending up in a wall of text of everything?

LOG_WARN: Jan didn't think it's needed, Ian has said it's for 'near
misses', so Ian, could I ask you in what situation you would
prefer to use this instead of LOG_ERR, or, perhaps,
LOG_INFO?

LOG_VERBOSE: Ian mentioned this. He said 'even more info what is
going on'. Ian, do you have a use case so I can
understand how, where and why this is useful?

On another note, (to continue the LOG_ERR theme) the only other
error system I worked with was svn's rather comprehensive error
reporting system. Would that kind of thing be something for us
to consider for production code (so we can for example process
bug reports much easier), besides the dev centred logger?

G

Ps.: Sorry to be so overly picky and uh, logger obsessed(and, wordy!).

But I think that in code (for a change) words have meaning, and I
think that the above is important to have agreement on, because in the
end, it saves much time. Plus I'm curious as to what this all means
and how people are going to make this work for them, so I can 'reduce
to essence'.

[1] Ian about his Lenses branch: "It still needs some (quite a bit)
cleaning, to get rid of some warnings, and trace messages. "

See, that's what I'm talking about. N% of those messages will need
to be retyped at some point and with my little geegaw, they could just
be turned off with one command, and forgotten until they are needed
once more. Because they all start with LOG_, you could even have a
convention that they start with LOG_C_ and then teach emacs and vi to
blank those lines if you don't want to see them in the display.

I may be wrong, but currently I really think that this idea will save
a lot of programmer time in the end.

[Peter Kelly]

On 12 Sep 2015, at 12:38 am, jan i <ja...@apache.org> wrote:

On Thursday, September 10, 2015, Gabriela Gibson <gabriel...@gmail.com> wrote:

What are we going to use certain log level for, and when/why?

I have cut down the 'classic' list to these:

Name        Order       Purpose
---------------------------------------------------------------
LOG_ERR
LOG_WARN
LOG_NOTICE
LOG_DEBUG
LOG_INFO

i am all for romving LOG_WARN and LOG_NOTICE, It is too detailed in my opinion.

rgds

jan i 

I can add more and it's easy to add custom levels on the fly, but
my main question is, can we standardise the meaning of the names
and the purpose.  For example, WARN, NOTICE and INFO look pretty
similar to me -- do we need them all? And when would we use
them?

I think probably what’s more likely to be useful apart from 3-4 levels is the ability to specify individual modules. So we could have log messages that live in some of the support functions like the zip code, others in the XML parser, and others still in different modules. If we have an additional parameter to the log function which allows you to specify the module, then we could subsequently add an environment variable or command-line option that lets you indicate which modules you do or don’t want to see messages from.

For example, if you’re working on the ODF filter and not touching the XML parser or zip module, then you’d disable messages from the latter two, unless of course you run into a problem which you suspect might lie in one of these other modules.

--
Dr. Peter M. Kelly
kell...@gmail.com

http://www.kellypmk.net/

PGP key: http://www.kellypmk.net/pgp-key

(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

[Peter Kelly]

On 15 Sep 2015, at 5:53 am, Gabriela Gibson <gabriel...@gmail.com> wrote:

Also, I have to ask/verify some things with y'all, just so I can
document this properly to make sure that everyone is on the same plane
:-)

LOG_ERR: Is this meant for production code? With the idea that ERR
        seems to be a pretty serious case and probably something that
        only happens when the moon is green.

Under normal circumstances, I don’t think any of the log messages would be enabled for production code. All of the logging is likely to be of use for us as developers only.

There may be cases however where we want to report errors or warnings to the user. Actually we already report some errors, via the DFError parameters that are passed around. But some things are just skipped if they’re found to be incorrect, and the user is none the wiser.

Thinking in the context of an interactive end-user application (e.g. the desktop editor), it would be useful to collect these log messages into an object or array, so that they can subsequently be displayed to the user in a dialog box, as opposed to simply being written to standard output/error or a specified file. This would imply an in-memory structure to store the messages. Such a structure could be created prior to a conversion operation and populated with any warnings or errors (or higher levels, if desired for debugging purposes). Then the application could display a dialog box saying “Could not open foo.docx; this file appears to be corrupt. See below for detailed information.”, perhaps combined with a button to submit a bug report to us.

You mentioned you’d never used a logger before - I suggest we approach this from the point of view of “what would we use this for?” and design based on that. The logging of warnings and errors during conversion for presentation to the user in an error dialog is one; debugging during conversion is another; logging to a file when used on a web server is perhaps a third. But it should be use-case driven; once we know what we want out of it, this will make the decisions about how to structure it a lot easier to make.

Probably the most important use case at this point in time is debugging - i.e. we should think about what sort of information we want reported for our own testing purposes, and how it should be presented and filtered.