[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUe-dev] Creating a system for debug-levels
From: |
Jason Cater |
Subject: |
Re: [GNUe-dev] Creating a system for debug-levels |
Date: |
Thu, 10 Feb 2005 18:29:10 -0600 |
User-agent: |
KMail/1.7.2 |
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