[Ns-bugs] [Bug 127] Add trace callback type information for Python bindings

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=127





--- Comment #8 from Mathieu Lacage <mathieu.lacage at sophia.inria.fr>  2009-01-11 04:01:06 EDT ---
(In reply to comment #7)

> I am kind of reluctant to work on the NS-3 side of this because last time I
> provided a patch it was left to bitrot and is now completely obsolete.  I don't

The reason for that is that the whole tracing system was reworked at that time.
It seems unlikely that this is going to happen in the near future again so, if
you can come up with a patch, I don't see any reason not to merge it asap.

The last time this issue came up, the patch to the core ns-3 code was fairly
minimal and mainly involved getting a typeid string from the CallbackBase base
class. The main issue seemed to be to write code in the python binding to make
use of that. I suspect that what you had in mind was something along the lines
of:

1) take the user-provided path, use it to find all matching trace sources
2) for each matching trace source, obtain the typeid, and find a matching
autogenerated C++ trace sink, instanciate that trace sink, connect it to the
trace source, and make it call python with the right arguments.

So, it seems that the main challenge is generating all the possible C++ trace
sinks, right ?

Anyway, if the above description of what needs to be done is correct, a more
robust API would be to not export a typeid string but to export a typeid
directly. i.e., CallbackBase would get a std::typeid GetTypeId (void) const;
method and you would store in your binding code a table of pairs of
std::typeid+callback constructor instead of dealing with a typeid string.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.