[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: kdebug
From:       Johannes Sixt <Johannes.Sixt () telecom ! at>
Date:       1997-12-28 10:15:52
[Download RAW message or body]

On Fri, 26 Dec 1997, "Jacek Konieczny" wrote:
>I looked into kdebug, and I have found out it is really interesting feature.
>But when I had tried to use it before evry info/debug message went to message 
>box, wich was rather annoying.
>I have found out now, why it was this way - it is configurable, but everything 
>goes to message box by default. I don't uderstand this. If it there to help 
>developers it is enough to send logs to files.
>I need some debug output now, but I don't want everybody who uses alpha KDE to 
>configure kdebug or close all windows which would appear.
>So I have written my own debug routine. So did others (I sow such function in 
>khtmlw).
>The kdebug is great idea, but INFO and DEBUG output should default to stderr. 
>Only ERROR and FATAL messages should be displayed in windows. I would surely 
>use this feature then.
>-- 
>         ,
>    Jajcus
>           email: jajcus@polbox.com , jajcus@zeus.polsl.gliwice.pl

I think that kdebug could be an extremely helpful debugging feature. But it
would need a major overhaul for the following reasons:

* It tries to be way too fancy. As a developer I need: Either all debugging
output in one place, or no debugging output at all. (I never need debugging
output in a message box).

* For the application developer it's much too troublesome to get a line of
output. The KASSERT macro even requires an extra description argument!

* It's a bit misconcepted: What's the difference between a KDEBUG_FATAL and a
KASSERT?

I'm planning to simplify this and make it cooperate with kgdb (the debugger
GUI) in order to make these facilities powerful debugging means. With
simplifications I mean: Write
    TRACE1("foo=%d",foo);
to get a line of debugging output and
    ASSERT(foo > 0);
to state an assertion (no extra description needed, it's only meaningful for
the developer anyway). If the assertion fails, you fall into the debugger (if
the app is running under the debugger). If the program is compiled with
-DNDEBUG, you get none of these (that's how it works currently).

Opinions?

-- Hannes

[prev in list] [next in list] [prev in thread] [next in thread]