Message port names

GNU Radio
1

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

2

On Mon, Feb 24, 2014 at 2:46 PM, Nowlan, Sean
[email protected] 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

3

From: [email protected] [[email protected]] on behalf of Tom R.
[[email protected]]
Sent: Thursday, February 27, 2014 2:45 PM
To: Nowlan, Sean
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] message port names

On Mon, Feb 24, 2014 at 2:46 PM, Nowlan, Sean
[email protected] 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

4

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<pmt_t> 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 :wink:
    ** Tom: why is there a d_next member in pmt_symbol?
5

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<pmt_t>
    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
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

6

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