# Possible bug in tag-\>srcid processing **URL:** \ **Category:** GNU Radio\ **Created:** [September 26, 2014, 2:52am UTC](https://www.ruby-forum.com/t/possible-bug-in-tag-srcid-processing/232221 "2014-09-26T02:52:06Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [September 26, 2014, 2:52am UTC](https://www.ruby-forum.com/t/possible-bug-in-tag-srcid-processing/232221/1 "2014-09-26T02:52:06Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![jared](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/848f3c/32.png) [@jared](https://www.ruby-forum.com/u/jared)\ **Post date:** [September 26, 2014, 5:19am UTC](https://www.ruby-forum.com/t/possible-bug-in-tag-srcid-processing/232221/2 "2014-09-26T05:19:14Z")
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]: \]: pmt\_symbol\_to\_string: wrong\_type : #f Gave up. - Jeff ---
**Author:** ![jared](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/848f3c/32.png) [@jared](https://www.ruby-forum.com/u/jared)\ **Post date:** [October 1, 2014, 4:49pm UTC](https://www.ruby-forum.com/t/possible-bug-in-tag-srcid-processing/232221/3 "2014-10-01T16:49:32Z")
On Thu, Sep 25, 2014 at 11:17 PM, Jeff L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![jared](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/848f3c/32.png) [@jared](https://www.ruby-forum.com/u/jared)\ **Post date:** [October 2, 2014, 1:56am UTC](https://www.ruby-forum.com/t/possible-bug-in-tag-srcid-processing/232221/4 "2014-10-02T01:56:46Z")
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 ---
**Author:** ![jared](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/848f3c/32.png) [@jared](https://www.ruby-forum.com/u/jared)\ **Post date:** [October 2, 2014, 6:07pm UTC](https://www.ruby-forum.com/t/possible-bug-in-tag-srcid-processing/232221/5 "2014-10-02T18:07:29Z")
On Wed, Oct 1, 2014 at 7:55 PM, Jeff L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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: > **[GNU Radio Manual and C++ API Reference: gr::block Class Reference](https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html)** 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