[Ns-developers] debugging ns-3 bindings problems

[Gustavo Carneiro]

2009/5/28 Gustavo Carneiro <gjcarneiro at gmail.com>

>
>
> 2009/5/28 Tom Henderson <tomh at tomh.org>
>
> Gustavo,
>>
>> I'm having the following problem with bindings in ~tomh/ns-3-ip-routing
>> directory and am wondering how you would suggest to debug it or deal with
>> it.
>>
>> Consider the class hierarchy:
>>
>> class A : public Object
>> {
>> public:
>>  static TypeId GetTypeId (void);
>>
>>  virtual void AMethod (void) = 0;
>>
>> };
>> class B : public A
>> {
>> public:
>>  static TypeId GetTypeId (void);
>>
>>  virtual void BMethod (void) = 0;
>> };
>> class BImpl : public B
>> {
>> public:
>>  static TypeId GetTypeId (void);
>>
>>  void AMethod (void);
>>  void BMethod (void);
>> };
>>
>>
>> this generates, after the binding generation process, the following class
>> (among other classes):
>>
>> class PyNs3B__PythonHelper : public ns3::B
>> {
>> public:
>>  ...
>>    virtual void BMethod();
>>
>>    virtual void AMethod();
>>  ...
>> }
>>
>> so, objects of type PyNs3B__PythonHelper can be instantiated even though
>> ns3::B is an abstract base class, and everything builds fine.
>>
>> However, the test case above is analogous to real classes in
>> ns-3-ip-routing, where class A is really class Ipv4RoutingProtocol, and
>> class B is really class Ipv4StaticRouting : public class Ipv4RoutingProtocol
>> (and there is also a corresponding Impl class).
>>
>> In this case, the bindings code is not generating the equivalent
>> PyNs3B__PythonHelper::AMethod(), which in this case is
>> PyNs3Ipv4StaticRouting__PythonHelper::RouteOutput().  What follows is a
>> compilation error such as:
>>
>> debug/bindings/python/ns3module.h: In function ‘ns3::Ptr<T>
>> ns3::CreateObjectPython(PyObject*, const ns3::AttributeList&) [with T =
>> PyNs3Ipv4StaticRouting__PythonHelper]’:
>> debug/bindings/python/ns3_module_node.cc:29253:   instantiated from here
>> debug/bindings/python/ns3module.h:16342: error: cannot allocate an object
>> of abstract type ‘PyNs3Ipv4StaticRouting__PythonHelper’
>> debug/bindings/python/ns3module.h:5647: note:   because the following
>> virtual functions are pure within ‘PyNs3Ipv4StaticRouting__PythonHelper’:
>> debug/ns3/ipv4-routing-protocol.h:66: note:     virtual
>> ns3::Ptr<ns3::Ipv4Route> ns3::Ipv4RoutingProtocol::RouteOutput(const
>> ns3::Ipv4Header&, uint32_t, ns3::Socket::SocketErrno&)
>> ...
>>
>> Nothing in ns3modulegen.log seems to suggest what may be going wrong, and
>> the python bindings seem to properly reflect that these methods are virtual:
>>
>>    cls.add_method('RouteOutput',
>>                   'ns3::Ptr< ns3::Ipv4Route >',
>>                   [param('ns3::Ipv4Header const &', 'header'),
>> param('uint32_t', 'oif'), param('ns3::Socket::SocketErrno &', 'sockerr')],
>>                   is_pure_virtual=True, is_virtual=True)
>>
>>
>> so I was wondering what you might recommend next for debugging a code
>> generation problem like this.
>
>
> True, the method is declared virtual, but is being ignored by pybindgen:
>
>    ../bindings/python/ns3_module_node.py:2852:
> TypeLookupError(['ns3::Socket::SocketErrno &'],)
>
> Why this "ns3::Socket::SocketErrno &" type is being rejected by pybindgen I
> do not know.  Sounds like a bug.  I am looking into it.  Sorry about that...
>

I fixed that bug (missing support for Enumeration& parameter types).

I fixed another bug of not being able to generate a virtual method caused
code to be generated that could not be compiled.

If you update to pybindgen revision 640, things should start working again.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert