Gr-modtool produces incorrect swig.i

GNU Radio
1

I’m using the gr-modtool that is now included with gnuradio to add a
block
to an existing module that was created with an earlier version of
gr-modtool.py. The swig.i file originally looks like:

%include “gnuradio.i”
%include “testmod_swig_doc.i”

{
#include “testmod_testblock.h”
}

GR_SWIG_BLOCK_MAGIC(testmod,testblock);
%include “testmod_testblock.h”

After adding my new block the swig.i looks like:

%include “gnuradio.i”
%include “testmod_swig_doc.i”

{
#include “testmod_testblock.h”
#include “testmod_testblock2.h”
}

GR_SWIG_BLOCK_MAGIC(testmod,testblock);
%include “testmod_testblock.h”

%include “testmod_testblock2.h”
GR_SWIG_BLOCK_MAGIC(testmod, testblock2);

I can build and install the module just fine but when I got to execute a
flowgraph with testblock2 in it I get these errors:

Traceback (most recent call last):
File “/home/user/top_block.py”, line 52, in
tb = top_block()
File “/home/user/top_block.py”, line 34, in init
self.testmod_testblock2_0 = testmod.testblock2()
AttributeError: ‘module’ object has no attribute ‘testblock2’
Error in sys.excepthook:
Traceback (most recent call last):
File “/usr/lib/python2.7/dist-packages/apport_python_hook.py”, line
64,
in apport_excepthook
from apport.fileutils import likely_packaged, get_recent_crashes
File “/usr/lib/python2.7/dist-packages/apport/init.py”, line 4, in

from apport.report import Report
File “/usr/lib/python2.7/dist-packages/apport/report.py”, line 28, in

import problem_report
File “/usr/lib/python2.7/dist-packages/problem_report.py”, line 14, in

import zlib, base64, time, sys, gzip, struct, os
File “/usr/lib/python2.7/gzip.py”, line 10, in
import io
File “/usr/lib/python2.7/io.py”, line 51, in
import _io
TypeError: type ‘_io._IOBase’ participates in gc and is a base type but
has
inappropriate tp_free slot

Original exception was:
Traceback (most recent call last):
File “/home/user/top_block.py”, line 52, in
tb = top_block()
File “/home/user/top_block.py”, line 34, in init
self.testmod_testblock2_0 = testmod.testblock2()
AttributeError: ‘module’ object has no attribute ‘testblock2’

Simply reversing the order of the last two lines (ie.
GR_SWIG_BLOCK_MAGIC
comes BEFORE %include) fixes this and allows it to run correctly. This
isn’t very intuitive from the error and it would be great if gr-modtool
could be updated to correct this.

2

On Wed, Feb 13, 2013 at 4:44 PM, Tom R. [email protected] wrote:

#include “testmod_testblock.h”
%include “testmod_swig_doc.i”
GR_SWIG_BLOCK_MAGIC(testmod, testblock2);
Error in sys.excepthook:
File “/usr/lib/python2.7/dist-packages/problem_report.py”, line 14, in
Traceback (most recent call last):
could be updated to correct this.

It sounds like this is the opposite for the 3.6 way of doing things (which
we normally don’t do this way and instead create a .i file for each block
and handle things that way). But I guess this is why we named it MAGIC…

Tom

Sorry, I should have mentioned I’m using the build-gnuradio script on
Ubuntu for my installation. I believe that is 3.6 API. Does this
mean the modules will need to be updated when moving to a 3.7 install in
the future?

Eric

3

On Wed, Feb 13, 2013 at 4:10 PM, Eric B [email protected] wrote:

{
I can build and install the module just fine but when I got to execute a
File “/usr/lib/python2.7/dist-packages/apport_python_hook.py”, line 64,
import zlib, base64, time, sys, gzip, struct, os
tb = top_block()
File “/home/user/top_block.py”, line 34, in init
self.testmod_testblock2_0 = testmod.testblock2()
AttributeError: ‘module’ object has no attribute ‘testblock2’

Simply reversing the order of the last two lines (ie. GR_SWIG_BLOCK_MAGIC
comes BEFORE %include) fixes this and allows it to run correctly. This
isn’t very intuitive from the error and it would be great if gr-modtool
could be updated to correct this.

Is this for the v3.6 or v3.7 API? I’m assuming this is for 3.6 (based
off
master). And this might finally clear up some confusion we’ve been
having
regarding this.

In the new 3.7, the ordering should absolutely be:

%import <thing’s header>
GR_SWIG_BLOCK_MAGIC2(thing)

It sounds like this is the opposite for the 3.6 way of doing things
(which
we normally don’t do this way and instead create a .i file for each
block
and handle things that way). But I guess this is why we named it
MAGIC…

Tom

4

On Thu, Feb 14, 2013 at 10:57 AM, Eric B [email protected] wrote:

On Wed, Feb 13, 2013 at 4:44 PM, Tom R. [email protected] wrote:

Sorry, I should have mentioned I’m using the build-gnuradio script on
Ubuntu for my installation. I believe that is 3.6 API. Does this
mean the modules will need to be updated when moving to a 3.7 install in
the future?

Eric

Eventually, but the 3.7 code is backwards compatible with 3.6 blocks.
We’ll
keep it that way for a while so there will be time to change things. The
gr-modtool will generate 3.7-compatible blocks, too, so you could use
that
as a starting point and copy-and-paste your code that way.

We will deprecate the 3.6 way of doing things when we release 3.7. We
will
probably remove it entirely (basically, removing GR_SWIG_BLOCK_MAGIC and
tools like that) in 3.8.

Tom

5

On Thu, Feb 14, 2013 at 11:29:20AM -0500, Tom R. wrote:

Eventually, but the 3.7 code is backwards compatible with 3.6 blocks. We’ll
keep it that way for a while so there will be time to change things. The
gr-modtool will generate 3.7-compatible blocks, too, so you could use that as a
starting point and copy-and-paste your code that way.

We will deprecate the 3.6 way of doing things when we release 3.7. We will
probably remove it entirely (basically, removing GR_SWIG_BLOCK_MAGIC and tools
like that) in 3.8.

That said, out-of-tree modules created with gr-modtool are always in
3.7 format, even if you’re running 3.6 (“3.7 format” really is a bit
misleading, as it’s used already in 3.6.3 for some components).
Only if you’ve created that module long ago, when the 3.6 code was still
in modtool, would you have this problem.

In theory, you should point modtool at your module and it should do the
right thing. That swig-thing was simply a bug, as 3.6 and 3.7 use
different orders for %include and GR_SWIG_BLOCK_MAGIC.

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association