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

List:       kde-core-devel
Subject:    Re: "RFC" : New kdebug/Nana
From:       Phil Maker <pjm () gnu ! org>
Date:       1999-12-16 7:41:33
[Download RAW message or body]

On Wed, Dec 15, 1999 at 09:24:25AM -0000, David Faure wrote:
> > 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.

The Debugger based checking/logging is indeed a bit strange,
I think rms said like something like "thats clever, uhm..."
The big win is that it doesn't cost your space/time in the
the executable for seldom used log messages.

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

Its small, and I'd suggest you keep a copy in your own build tree
so if I die tomorrow no one will pick on me in heaven.

> 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.

Yep, so DBC should handle most of that plus perhaps some
safety invariants.

> 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".

It does sort-of, each logging/checking statement is only executed if
a guard expression is true and you can redefine this yourself. 

There are a couple of other things in Nana that might be of interest
as well:

	o Shortform generation - takes your code and spits out the
	  interfaces in HTML with REQUIRE/ENSURE calls but without
	  the implementation. So you end up with something like:

		char* left_hand_side(int n, const char *s) {
		   REQUIRE(n < strlen(s));
		   ...; 
		   ENSURE(strlen(result) == n);
	        }
	  So if you go to the trouble of documenting interfaces
	  this lets you publish the interface with looking at the
	  implementation.

	o Various tracing/timing operations.

			Thanks

-- 
Phil Maker, Quoll Systems, <pjm@gnu.org>,     "Never run; once you start 
16 Bougainvillia St, Nightcliff, Darwin        running you stop thinking, 
+61 8 89854 939	work/home number.	       now remember that!" 
0409-691-399 mobile phone.		         -- Jock Lewes.
<http://www.quoll.com.au>		

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