I can reproduce the issue and also confirm your work-around. I pushed a
fix to the grcwg repo. See if that works for you guys.
Sebastian
On 01/31/2014 12:53 AM, Achilleas Anastasopoulos wrote:
> SUCCESS!!
>
> after renaming the output message pad as zzz_something, the right order
> is restored!
SUCCESS!!
after renaming the output message pad as zzz_something, the right order is
restored!
I will make sure to file a bug ticket on this, but for now I am set.
thanks
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, Now I can reproduce your problem.
But I do get (in contrast to your error message because of connecting
a block to itself):
Traceback (most recent call last):
File "/home/marcus/top_block.py", line 74, in
tb = top_block()
File "/home/marcu
Marcus,
the error is still there even if you don't have direct connections between
in/out pads.
See attached
Achilleas
test_msg_hier.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Achilleas,
you're right, grc omits one of the pad sinks; that is kind of a bug,
but I don't know if the terminology really fits; as it seems, gnuradio
does not like you to have input and output pads directly connected.
I don't know if this is only
Please see attached simple hier block with 4 complex outputs
and 1 async message output.
Everything compiles but the application does not run giving python error:
Using Volk machine: sse4_1_64_orc
Traceback (most recent call last):
File "./test_msg.py", line 67, in
tb = test_msg()
File "