[Ns-developers] [ns3] logging

[Tom Henderson]

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

Tom