[Ns-developers] logging

[Gustavo Carneiro]

On 10/04/2008, Tom Henderson <tomh at tomh.org> wrote:
>
> >-----Original Message-----
> >From: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr]
> >Sent: Thursday, April 10, 2008 07:51 AM
> >To: 'ns-developers'
> >Subject: Re: [Ns-developers] [ns3] logging
> >
> >
> >On Wed, 2008-04-09 at 17:16 -0700, Mathieu Lacage wrote:
> >> hi,
> >>
> >> Today is not the first time I try to use unsuccessfully NS_LOG_PARAMS:
> I
> >> just seem unable to figure out what its input is expected to be (the
> >> fact that it is undocumented speaks volume) so, I looked at the code
> >> today and I am even more confused by what its behavior is supposed to
> >> be.
> >>
> >> I personally would have expected something like this:
> >>
> >> NS_LOG_PARAMS ("name0" << value0 << "name1" << value1 ...);
> >>
> >> to print something like this:
> >>
> >> Component:FunctionName (name0=value0, name1=value1)
> >
> >Actually, to be really specific, what I expected is that we would have a
> >macro named NS_LOG_FUNCTION used like this:
> >
> >NS_LOG_FUNCTION ("name0"<<value0<<name1<<value1);
> >
> >or, if you don't care about the args,
> >
> >NS_LOG_FUNCTION ();
> >
> >which would be able to understand the log bits FUNCTION and PARAMS and
> >would generate only the function name if ((flags & (FUNCTION | PARAMS))
> >== FUNCTION) and both the function name and parameters if flags &
> >PARAMS. I suspect very strongly that this is close to what craig
> >originally proposed and implemented with the log levels having an
> >ordering relationship. Although they don't have this ordering
> >relationship anymore, we could trivially make NS_LOG_FUNCTION do the
> >above and get the same feature set.
> >
> >The above would allow you to avoid duplicating the NS_LOG_FUNCTION +
> >NS_LOG_PARAMS macro calls which are used everywhere in tandem to leave
> >just one NS_LOG_FUNCTION.
> >
> >result:
> >  functionality: no loss
> >  lines of code: great decrease
> >
> >If this is felt the way to go, I have a small perl script to do the
> >conversion.
>
>
> See the (closed) bug 79 discussion for some history of how we got to where
> we are today.  What you suggest seems like a good idea to me.
>
> I have another feature request, while we are on the topic, which is that
> it would be nice to have the logging output display simulation timestamp as
> well.  I don't feel strongly about whether it is always on or optionally
> enabled, but as a user of the log output, I have found it difficult to
> associate log output with events for which I know the timestamp.


On that subject, on my wish list would be NS-3 logging improvements in that
direction.  I would like to see more context information associated with
each log message.  A time stamp is one such context information, but there
are others equally important, such as the name and/or number of the node, or
netdevice.  Just like tracing has a "context", it would be really nice if
all logging had a similar context.  Oh, and one more thing this is painfully
obviously missing from logging messages is the logging domain.

Another front for logging improvement would be an XML output option.
Coupled with some PyGtk GUI love it would allow the developer to show/hide
log domains with the click of a button, insert <XXX seconds passed> markers,
for easier grouping, horizontal scrolling so that there is no line wrapping
to screw up logging events alignment, etc...

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert