[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-15 0:16: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).... 

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

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. 

	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.			

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 :-). 
	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?

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


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