[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 #9 from Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com>  2009-02-18 12:06:52 EDT ---
(In reply to comment #8)
> (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 ?

Right.  This makes sense to me.

In NS-3, tracing is like a regular expression.  We should have an API that
returns all "regexp matches", sort of speak.  For each match, an object that
represents the match could include some properties, like config path for the
match, type of match (attribute or traced callback), and callback type in case
of traced callback matches.

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

Right.  Except that it's not std::typeid, more like:

  const std::type_info & GetTypeInfo (void) const;

(you cannot copy type_info objects, you always have to pass around const
references).

The std::type_info reference would be obtained via (e.g.) typeid(Callback<void,
Ptr<const Packet> >).


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