[Ns-developers] NS-3: state of ns-3-pybindgen
gjcarneiro at gmail.com
Wed Jan 2 03:31:12 PST 2008
On 02/01/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
> hi gustavo,
> On Tue, 2008-01-01 at 21:23 +0000, Gustavo Carneiro wrote:
> > Still some important things are missing, namely:
> > 1- Parameters default values (but should not be very difficult to
> > implement this);
> > 2- Templated classes in general; -> needed for protocol
> implementation (
> > e.g. Header classes)
> > 3- Callback<...> in particular; -> needed for working with sockets
> > tracing (simple scripting needs this)
> > 4- Simulator::Schedule* methods; -> needed for scripting
> > I'd be glad to hear some feedback on the general direction I'm heading.
> Could you point me to a sample python program I can look at to get a
> feel for the API ?
The "feel" for the API has not really changed since the time where I posted
the last time. The main difference is in terms of coverage. While before I
only wrapped the minimum API required to run the simple-p2p.py example, now
most of the NS-3 API is being wrapped, although as I said some few but
crucial functions are not yet being wrapped.
There's the good old
Now there's also
I'm sure many other examples are easily portable; it's just tedious work.
Also, in case anyone is curious, the generated source file looks like this:
As I'm sure you know, the 'ns.' prefix from everywhere could easily
disappear from the python code, by doing a 'from ns3 import *', but that is
considered bad Python programming style so I refrain from doing it.
> As a side note, is there any reason why Simulator::Schedule is not using
> > Callback's as parameters? Because it would be easier to wrap only
> > Callback<> and not Simulator::Schedule as well...
> Yes, there is a reason: the argument to Schedule is a fully bound
> functor while a callback is a fully unbound functor. i.e., an EventImpl
> is expected to store internally the set of values to give back to the
> target function. However, binding this part of the API should be really
> easy: it is a matter of implementing a PythonEventImpl subclass of the
> EventImpl base class which implements the Expire method to call back
> into a python class instance which stores the arguments to the target
> function and imvokes the target python function directly. Of course,
> this depends on making the proper Schedule (Ptr<EventImpl> ) methods
Yes, sounds like a good idea. I'll work on it next.
Thanks for the feedback.
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
More information about the Ns-developers