[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-17 9:12:51
[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.

Well, I consider them "often-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.
?? If you die you bring with you all you've hacked in the past ?
Gosh, let's hope Torben doesn't die !

> > 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. 
So we would have to use kdebug (to do the area number checking,
which is the "guard expression" here), on top of nana... Hmm.

> 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.
Not sure how that would live together with kdoc. We already have
documentation generated from the sources (though from the header,
not the implementation).

I received off list the following comment about nana, which I find of
interest.

> -----Original Message-----
> From: jbb [mailto:jbb@ihug.co.nz]
> Sent: Wednesday, December 15, 1999 5:56 PM
> To: David Faure
> Subject: RE: "RFC" : New kdebug/Nana
> 
> 
> Hi David,
> 
> Nana's an interesting and novel approach to asserts. Wish I had thought of
it.
> :-) But, just reading the documents, I'd say it has some issues. Here's
some
> comments, in no particular order. I've only read the nana documents so I
hope
> these comments are accurate.
> 
> - It's gdb specific.
>     although (as the author says) support for other debuggers could be
added
> 
> - Currently, front end debuggers (like kdbg) wouldn't work with this
approach
>      But they could be made to...
> 
> - Nana is more efficient than asserts.
>     Hmmm. Is this _really_ an issue?
> 
> - ENSURE would be nice. But this shouldn't be difficult to implement. I
did a
>     similar thing for indenting/unindenting trace messages. (i.e doing
something
>     on entry/exiting a method)
> 
> - Macro name's are very cryptic. DS, L, I etc.
> 
> - You have a choice between code in program (standard assert like) or
debugger
>     asserts. But these macro are different for the style you want. (eg
>     I=inline assert, DI=gdb assert) Ouch.
> 
> - gdb style requires preprocessing the source.
> 
> - dlopen'ed files could be a problem for debugger asserts.
> 
> - getting users to give decent error reports is hard. If you went with
debugger
>     asserts I think it'll make the job impossible.
> 
> I do like the idea of debugger asserts though. Perhaps just a preprocessor
> working off the normal asserts, tt asserts and kdebug would be sufficient?
> 
> In terms of using debuggers with asserts, the standard assert macro is a
pain as
> it leaves the stack at the call to the function that contained an assert,
so
> you cannot examine that functions variables. QT's ASSERT, 
> however, will leave the stack at the assert that was triggered.
> 
> Of all the issues, my two main objection's to nana are
> .. the macro names being so cryptic, and different between 
> debugger asserts and inline asserts :(
> .. using debugger asserts will cause many more user reporting problems.
> 
> -- 
> Regards,
> 
> jbb
> http://homepages.ihug.co.nz/~jbb
> 


And :

> If you use dbg asserts then you need to compile your code with _debug on_.
That
> seems to (partially) negate two points.
> 
> "Avoid the two executables problem (one with asserts in and another 
> without any)."
> 
> and 
>  
> "Time and space efficient. 
> 
> For example the GNU `assert.h' implementation uses 53 bytes for 
> `assert(i>=0)' on a i386. The nana version using the i386 `stp' 
> instruction on assert fail uses 10 bytes. If your willing to 
> accept the time penalty this can be reduced to 0 or 1 byte by 
> using debugger based assertions. "
> 
> But damn it, I still like this idea :-/

-------

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