Re: [GNUe-dev] Creating a system for debug-levels

[Jason Cater]

Reinhard, 

I like the idea of this. However, when I first started doing stuff in Common 
with --debug-level, I tried to keep all level 1 messages related to how the 
program was run and the user's environment. 

So, if a user is having issues, we could get them to send us the output of 
--debug-level=1 and we could get the basics of his system (i.e., Python 
version #, underlying operating system, parameters passed via command-line, 
etc.)

I would like to see some number reserved for this. 

-- Jason 


On Thursday 10 February 2005 08:28 am, Reinhard Mueller wrote:
> Am Donnerstag, den 10.02.2005, 14:10 +0100 schrieb Johannes Vetter:
> > it's ok for me, except your level 3. shouldn't this (sql-commands) go
> > into a common level too ? for example a function in forms (level 4)
> > generates some sql-command on the backend (level 3).
>
> The idea behind this is that it's a common wish to *only* see the SQL
> commands, and nothing else. We usually use postgres' own logfile if we
> want that, but other databases do't have such a file (or it needs some
> manual configuration).
>
> > depreciation warnings:
> > using level 1 for this is ok, but what about a function like
> > "gDepreciate (message)" ? if we would use 'gDebug ()' to print
> > depreciations they would not be seen on stdout. using an explicit
> > function for this could handle both, dumping to a given debug-level as
> > well as printing to stdout/stderr or something similair.
>
> Thinking about the curses interface, I would not like *anything* to be
> printed to stdout and/or stderr.
>
> We could at some point consider optionally logging to syslog:
> level 1 = warning
> level 2 = notice
> level 3 = info
> level 4-9 = debug
>
> Thanks,
> Reinhard