Possible bug in tag->srcid processing


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

It looks like you’re doing it right. The example
gr-blocks/examples/vector_source_with_tags.grc does the same thing, and
also fails to report srcid correctly.

Walked through the process in Python and it works fine.

In [57]: h = pmt.to_pmt(‘hello’)

In [58]: type(h)
Out[58]: pmt.pmt_swig.swig_int_ptr

In [59]: pmt.is_symbol(h)
Out[59]: True

So, probably not a swig problem. Somehow, the ‘symbolness’ of srcid is
getting lost before it gets to the tag debug block.

Removed the is_symbol() check in tag debug, and got this:

thread[thread-per-block[2]: <block tag_debug (3)>]:
pmt_symbol_to_string: wrong_type : #f

Gave up.

  • Jeff

On Thu, Sep 25, 2014 at 11:17 PM, Jeff L. [email protected] wrote:

In [59]: pmt.is_symbol(h)
Gave up.

  • Jeff

Hey guys,

Can one of you open an issue on the issue tracker? It’d really help if
you
can throw up a simple test case, too.

Thanks!

Tom

On 10/01/2014 10:47 AM, Tom R. wrote:

Can one of you open an issue on the issue tracker? It’d really help if
you can throw up a simple test case, too.

Thanks!

Tom

Turns out that the vector_source does not use the srcid parameter, and
the default srcid for a tag is PMT_F, so everything is working
correctly, just not as expected. The user-supplied srcid is ignored.

It would seem like a good idea to fill in this field. The question is
with what? The srcid supplied with each tag? The actual srcid of the
vector_source, ignoring the supplied value?

  • Jeff

On Wed, Oct 1, 2014 at 7:55 PM, Jeff L. [email protected] wrote:

Hey guys,
default srcid for a tag is PMT_F, so everything is working correctly, just
not as expected. The user-supplied srcid is ignored.

It would seem like a good idea to fill in this field. The question is with
what? The srcid supplied with each tag? The actual srcid of the
vector_source, ignoring the supplied value?

  • Jeff

Ok, gotcha. Thanks.

First, fixing the vector source to respect a set srcid in the input tag
is
easy. I’ll definitely patch that. I can’t change the PMT_F as the
default
for the srcid, though. It’s been documented that way since we first
created
the tags:

http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a8b7cc51b9d289124d6843bb392f564fc

So while it might not be intuitive, it’s documented to have this
behavior.

I’m also going to make it so that you can use only three items when
calling
python_to_tag, so you can leave out the optional srcid. Again, will
default
to PMT_F.

Tom