|Subject:||Re: [Discuss-gnuradio] possible bug in tag->srcid processing|
|Date:||Thu, 2 Oct 2014 12:05:40 -0400|
On 10/01/2014 10:47 AM, Tom Rondeau wrote:
On Thu, Sep 25, 2014 at 11:17 PM, Jeff Long <address@hidden
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 : h = pmt.to_pmt('hello')
In : type(h)
In : pmt.is_symbol(h)
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: <block tag_debug (3)>]:
pmt_symbol_to_string: wrong_type : #f
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.
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?
|[Prev in Thread]||Current Thread||[Next in Thread]|