On Wed, Oct 1, 2014 at 7:55 PM, Jeff Long <willcode4@gmail.com> wrote:
On 10/01/2014 10:47 AM, Tom Rondeau wrote:
On Thu, Sep 25, 2014 at 11:17 PM, Jeff Long <willcode4@gmail.com
<mailto:willcode4@gmail.com>> 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
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:
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
No comments:
Post a Comment