>> One of my OOT blocks is a function that takes in shorts and outputs shorts
>> (a 1-to-2 interpolator).
>> I have a simple flowgraph created in GRC: File Source -> My block -> File
>> sync .
>> GRC is happy until I run the flowgraph, and I get this:
>> Executing: "<....> /top_block.py"
>> Traceback (most recent call last):
>> File "<....> /top_block.py", line 54, in <module>
>> tb = top_block()
>> File "<....> /top_block.py", line 39, in __init__
>> self.connect((self.my_block_s_to_s_0, 0), (self.blocks_file_sink_0, 0))
>> File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
>> line 130, in connect
>> self._connect(points[i-1], points[i])
>> File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
>> line 141, in _connect
>> self._tb.primitive_connect(src_block.to_basic_block(), src_port,
>> AttributeError: 'function' object has no attribute 'to_basic_block'
I have found the error (or at least I am closer): The Python code that GRC
generates is slightly different between v3.6.4.2 and v3.7.0 for the same test
flowgraph. Namely, the newer version omits an empty set of parens, thusly:
>From v3.6.4.2 :
##################################################
# Blocks
##################################################
self.my_oot_my_block_0 = my_oot.my_block()
>From v3.7.0 :
##################################################
# Blocks
##################################################
self.my_oot_my_block_0 = my_oot.my_block
My block has no parameters (thus the empty parens).
If I manually edit the v3.7.0 generated py code to add the missing parens, it
all works fine as with v3.6.4.2.
Question: Is this a v3.7.0 bug, or some subtle coding error in my OOT module?
As far as I can tell, I converted it according to the 3.6 -> 3.7 recipe.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
