Hello,

I have the same problem before. After adding the virtual function in
include directory and other are done.

You need to "make clean" and after that you just make and make install. The
"AttributeError: 'module' object has no attribute" will solve.

I have no idea why the swig won't update when you add new virtual function
in include file if you have done make.

Jeff Guo


2014-08-08 16:19 GMT+08:00 Marcus Müller <[email protected]>:

> Hi Mike,
>
> puh, you're asking us to translate C++ish to plain English. C++'s
> language design isn't too open for such unclean and incomplete concepts
> as the English language ;)
>
> I'll try:
>
> > Make sure the methods in include/modname/blockname.h are declared pure
> virtual so that blockname can remain an abstract class.
>
> Methods of your base class as defined in include/modname/blockname.h
> should *not* be fully fledged callable methods, but only entries in the
> table that lets the compiler know that there must be a subclass actually
> implementing this method.
> In practice, this looks like:
>
> namespace gr{
>     namespace modname{
>     class MODNAME_API blockname : virtual public gr::block {
>         ...
>         public:
>         virtual set_my_herring_count(int herrings) = 0;
>         ...
>     };
>     }
> }
>
> The trick is that this class cannot ever be "complete", because there's
> a method defined, but you don't implement
> blockname::set_my_herring_count(int) in blockname itself. Now, as this
> class is incomplete ("abstract"), this guarantees that SWIG doesn't try
> to directly instantiate blockname, and the only way to get an instance
> of blockname is through the make call.
>
> Greetings,
> Marcus
> On 07.08.2014 23:10, Mike Willis wrote:
> > I still have the problem with the AttributeError: 'module' object has
> > no attribute problem for my OOT module. Really clutching at straws
> > now, hair all gone. Can anyone explain in plain English what the
> > following advice from the WiKi means? I am sure it is 100% clear to
> > whoever wrote it but it means little to me.
> >
> >
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7?version=7
> >
> > Make sure the methods in include/modname/blockname.h are declared pure
> > virtual so that blockname can remain an abstract class.
> >
> > Following that is the advice that If blockname is not abstract, your
> > code may compile but SWIG will interpret the declaration as the
> > concrete class instead of your blockname_impl class. At runtime this
> > will cause an error like ImportError: [...] undefined symbol when the
> > Python interpreter attempts to load your SWIGged object code.
> >
> > Well that's more or less what is happening but it might not be the cause.
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > [email protected]
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to