|
From: | Tom Rondeau |
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
<mailto:address@hidden>> wrote:
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
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
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
[Prev in Thread] | Current Thread | [Next in Thread] |