Re: a though to help with debugging ns

[Lloyd Wood <eep1lw@surrey.ac.uk>]

On Thu, 20 Jan 2000, Mark Allman wrote:
[..]
> Finally, it hit me...  What I needed was a variable in the TCP class
> that I could turn on if I wanted the debugging.  And, so that is
> what I did...
> 
> So, I added a variable to the protected section of the TcpAgent
> class...
> 
>     int tcp_debug_;
[..]
> I suggested the above to Sally, who thought it was a nice idea.
> However, while this took about 2 minutes to implement the above,
> what I am suggesting is that ns include these debugging variables
> all over the place (I have subsequently added a sink_debug_ to the
> TCP sink class).  

Great idea, but... Okay, extremely stupid implementation question
and nitpick here.

Since the variables are class variables and have local scope, why not
just be clear and consistent and call them *all* debug_ ?

Agent/TCP set debug_ true

has got to be different from

Agent/TCPSink set debug_ true

and at the OTcl level:
set tcp666 [new Agent/TCP/Vegas/UpperDorking]
[..]
set debugging_my_bloody_tcp_instance_again [$tcp666 set debug_ true]
[..]
if { debugging_my_bloody_tcp_instance_again } {
  puts "this time for sure!"
  [..]
}

seems straightforward enough, even to me.

The thought of scouring the ns code to find out what the specific
debug variable you're supposed to be using around your printf
statements is called, or getting it wrong and misinterpreting the
output as a result, really doesn't appeal. (Reminds me of the
occasional legacy problem resulting from not checking that the Tcl
variable is bound to a C++ variable of the same name and CaSe_, in
fact...)

Can't inheritance take care of it, so we can have globally available
debug_ functionality via a consistently-named instance variable? Just
define and bind debug_ false in Agent and the other base classes and
let everything inherit from those, and a lot should be done.

L.

I mean, all this overhyped object-oriented twaddle I keep hearing
about has to be good for _something_.


> For what it's worth, I encourage the VINT team to add tons of such
> variables.  Maybe not all in one pass, but as you work on various
> classes keep this in the back of your mind.  I am guessing that
> would be a big help in debugging rare problems that only seem to
> crop up in large simulations.
> 
> allman
> 
> 
> ---
> http://roland.grc.nasa.gov/~mallman/

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>