# Message port names **URL:** \ **Category:** GNU Radio\ **Created:** [February 24, 2014, 8:47pm UTC](https://www.ruby-forum.com/t/message-port-names/239394 "2014-02-24T20:47:38Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [February 24, 2014, 8:47pm UTC](https://www.ruby-forum.com/t/message-port-names/239394/1 "2014-02-24T20:47:38Z")
Quick question: can a message port name be any valid PMT type? Or does it have to be a string converted to a symbol? Thanks, Sean ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [February 27, 2014, 8:46pm UTC](https://www.ruby-forum.com/t/message-port-names/239394/2 "2014-02-27T20:46:36Z")
On Mon, Feb 24, 2014 at 2:46 PM, Nowlan, Sean [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Quick question: can a message port name be any valid PMT type? Or does it > have to be a string converted to a symbol? > > Thanks, > > Sean Hey Sean, I /think/ so. I’d have to double check, but at some point it’s likely to go through a symbol\_to\_string conversion. Can you think of a need for a port name to be something other than a symbol/string? Maybe an enumeration or something? Tom ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [February 28, 2014, 1:40am UTC](https://www.ruby-forum.com/t/message-port-names/239394/3 "2014-02-28T01:40:46Z")
> * * * > > From: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [removed\_email\_address@domain.invalid] on behalf of Tom R. > [removed\_email\_address@domain.invalid] > Sent: Thursday, February 27, 2014 2:45 PM > To: Nowlan, Sean > Cc: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > Subject: Re: [Discuss-gnuradio] message port names > On Mon, Feb 24, 2014 at 2:46 PM, Nowlan, Sean > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > Quick question: can a message port name be any valid PMT type? Or does it > > have to be a string converted to a symbol? > > > > Thanks, > > > > Sean > Hey Sean, > I /think/ so. I’d have to double check, but at some point it’s likely > to go through a symbol\_to\_string conversion. > Can you think of a need for a port name to be something other than a > symbol/string? Maybe an enumeration or something? > Tom In a certain block I’m registering N ports, where N is a constructor argument to the block. I was hoping I could call them pmt::from\_long(0) through pmt::from\_long(N-1), but that didn’t work. I ended up creating string names “out0” through “outK” (where K = N-1) and then used pmt::string\_to\_symbol. Thanks, Sean ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [February 28, 2014, 4:01pm UTC](https://www.ruby-forum.com/t/message-port-names/239394/4 "2014-02-28T16:01:45Z")
Hi Sean, Tom and Martin, basic\_block enforces using a symbol in its message\_port\_register\_in method, so that’s where you’d have to start changing things. But to add my 0b0010\* ct to this: - using strings as port names keeps consistency - using strings is the “proper” way to ensure all tools (esp. the companion) display port names alike and are able to save/generate a flowgraph into/from a text file format - stepping away from pmt\_symbol as port name type opens up the gate for people doing stuff like assigning numeric values of different types (that could lead to a nice monte carlo QA for pmt::eqv; corner cases like pmt::eqv(pmt\_uint64(x),pmt\_int(x))==false will lead to problems) - I guess the whole point of pmt\_symbol is it being unique and provide guaranteed identification\*\* - comparatively very little overhead with the outK method, your workaround seems feasible (also: you could consider keeping your own port name std::vector\ and use that for later reference; if you just need a (strangely sorted) list of your ports, it’s basic\_block::msg\_queue) - hashing overhead negligible for short strings and it speeds up the std::map operations when adding/using message ports (hashing will probably even pay during runtime) +Ok, I admit it’s strange to use PMTs if you’d actually wanted to use strings (and have the type safety) Greetings, Marcus - valid for gcc 4.3+, clang and C++14 😉 \*\* Tom: why is there a d\_next member in pmt\_symbol? ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [February 28, 2014, 9:38pm UTC](https://www.ruby-forum.com/t/message-port-names/239394/5 "2014-02-28T21:38:57Z")
> Hi Sean, Tom and Martin, > basic\_block enforces using a symbol in its message\_port\_register\_in method, so > that’s where you’d have to start changing things. > But to add my 0b0010\* ct to this: > - using strings as port names keeps consistency > - using strings is the “proper” way to ensure all tools (esp. the companion) > display port names alike and are able to save/generate a flowgraph into/from a > text file format > - stepping away from pmt\_symbol as port name type opens up the gate for people > doing stuff like assigning numeric values of different types (that could lead to a > nice monte carlo QA for pmt::eqv; corner cases like > pmt::eqv(pmt\_uint64(x),pmt\_int(x))==false will lead to problems) > - I guess the whole point of pmt\_symbol is it being unique and provide > guaranteed identification\*\* > > - comparatively very little overhead with the outK method, your workaround seems > feasible (also: you could consider keeping your own port name std::vector\ > and use that for later reference; if you just need a (strangely sorted) list of > your ports, it’s basic\_block::msg\_queue) > - hashing overhead negligible for short strings and it speeds up the std::map > operations when adding/using message ports (hashing will probably even pay during > runtime) > +Ok, I admit it’s strange to use PMTs if you’d actually wanted to use strings > (and have the type safety) > Greetings, > Marcus I don’t see a need to change how it’s currently being done, i.e., using string\_to\_symbol. I had just asked the question because I was curious, and I think the outK “workaround” is useful because it corresponds with how GRC automates naming with . > > > In a certain block I’m registering N ports, where N is a constructor * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > **[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)** ---
**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\ **Post date:** [February 28, 2014, 9:20am UTC](https://www.ruby-forum.com/t/message-port-names/239394/6 "2014-02-28T09:20:55Z")
On 02/28/2014 01:39 AM, Nowlan, Sean wrote: > In a certain block I’m registering N ports, where N is a constructor > argument to the block. I was hoping I could call them > pmt::from\_long(0) through pmt::from\_long(N-1), but that didn’t work. > I ended up creating string names “out0” through “outK” (where K = > N-1) and then used pmt::string\_to\_symbol. I doubt anyone implemented that to limit names, it was more likely that we didn’t think of this use case. If you see this is a small, non-invasive change that would allow other PMTs to be port names, that would be interesting to see. M