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

List:       kde-core-devel
Subject:    RE: "RFC" : New kdebug/Nana
From:       David Faure <David.Faure () cramersystems ! com>
Date:       1999-12-15 9:24:25
[Download RAW message or body]

> On Tue, Dec 14, 1999 at 04:35:10PM -0000, David Faure wrote:
> > > > If anybody knows more about what nana could bring to us, please
speak
> > up.
> 
> Ah yes blame me (the author).... 

Ah, thanks for speaking up.

> -1. I'm speaking from 0 to 0.01% knowledge of KDE, however
>     I have a bit of experience in programming and testing.
>     Note that some/most/all of the points may already be
>     done by your current system.

Well we all have 0% experience with nana here, so let's add our experiences
:-)

> 0. What on earth could nana do for KDE 
> 	
> 	o The debugger based invariant checking/logging
> 	  where checking/logging operations only cost space/time 
> 	  when running under GDB might be useful. 
> 	  This could perhaps cut down on your executable sizes
> 	  and run time costs and encourage people to instrument
> 	  their code a bit better. 
This bit looks strange to me - I run stuff in gdb very seldom, and
prefer the checks/logs to happen also in normal execution mode.
But I saw this is supported as well, of course.
 
> 	o The Quantifier support (forall, exists, ...) is quite 
>           nice if you do lots of data manipulation. For example
>  	  you might to assert as a safety property that only 
> 	  one window thinks it has the focus at any one time. 
>  	  This looks like:
> 
> 	  /* Exists 1 window that has the focus */
> 	  assert(E1(window_ptr p = first,
> 	            p != NULL,
> 	 	    p = p->next, 
> 		    p->has_focus())); 
> 
> 	  Support is also provided for STL iterators.
> 
> 	o The pre/post condition (eiffel Design by Contract) stuff
> 	  is nice if you like that sort of thing. To state what 
> 	  everyone probably knows we do something like:
> 
> 		int average(int a[], int n) {
> 		  REQUIRE(a != NULL && /* we need some data to average */
>                          n >= 1); /* if n isn't >= 1 blame the caller */
> 		  ...; / some code to do it */
> 		  ENSURE(something else....); 
> 		}
> 	
> 	   By splitting your asserts into the REQUIRE/ENSURE classes
> 	   you make sure that:
> 
> 		* Errors are picked up on function entry/exit
> 		* And more importantly the 2nd phase of debuggering,
> 		  finding the error becomes easier since:
> 
> 			REQUIRE fails blame the caller
> 			ENSURE fails blame this function
> 
> 
> 	   Using DBC does make programming a lot easier since
> 	   forces people to document the why (assumptions) of
> 	   the code.			

All this looks very good, indeed.

Although linking to yet another library doesn't really make me
enthousiast...
But I suppose that it's relatively small.


> 1. So where do we go from here?
> 
> 	I'm happy to answer questions and provide a bit of
> 	assistance between doing everything else. However we probably
> 	need to analyse the following:
> 
> 	o What errors are occurring in KDE and how are they 
> 	  fixed. In particular is error location a 
> 	  problem, e.g. do you get errors occuring which are
> 	  only detected 5 minutes afterwards (which makes them
> 	  hard to find :-). 
We might have some of those, but very seldom I would say, at least to
my knowledge. I guess most of the problems are about tracing what's
being called and with what parameters, as well as parameter checking.

> 	o What the space/time constraints for KDE and do your 
> 	  current logging/checking mechanisms use up a significant
> 	  amount of space/time (> say 10%). Is it worth having a 
> 	  complicated mechanism to enable/disable these things?

Yes. The major point in my proposal for a new kdebug was : being able
to easily disable debug output from a class or library used by a program.
Say you're working on kedit, you don't want all the debug output
that the core libraries might have in it, mostly useful for the library
developers. So currently, the debug output has to be commented out
from the libs, and uncommented when looking for a bug.

This being said : the problem I see with using only nana is that it doesn't
have support for that : for what we called in kdebug "debug areas".
With kdebug you can (already, but it would be easier after the changes I
suggested)
disable a specific area, this disabling the debug output from a bunch of
statements
at the same time.

So one solution is to keep kdebug, possibly with my changes, and use nana
for all the assertions and design-by-contract stuff, but those two things
look very independent to me.

kdebug is for
* debugging with tracing - with support for debug areas
* showing warnings and errors (*)

nana is for
* assertions, including complex ones
* contract-by-design

So ... those are two different issues and two different decisions, as far as
I can see.

I am of course very much in favor of the new kdebug, and I think I am also
in favour of using nana, though I should give it a try first, when I find
some time for that. If anybody is willing to give it a try, please do.

> 2. Anyway I better get to work and earn some money, drop by
>    when are in Darwin or East Timor.
:)

Note : (*) If we use nana, warnings and errors might disappear from kdebug
though.
They are not warnings and errors aimed at the user (those use/should use
KMessageBox),
they are often the result of a check, which would be turned into a nana
check.

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems

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