[Ns-developers] NS-3: state of ns-3-pybindgen

[Gustavo Carneiro]

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
> and
> > 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
http://code.nsnam.org/gjc/ns-3-pybindgen/file/7598937d89d9/examples/simple-p2p.py
Now there's also
http://code.nsnam.org/gjc/ns-3-pybindgen/file/7598937d89d9/examples/udp-echo.py

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:
http://telecom.inescporto.pt/~gjc/ns3module.cc.gz

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


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