Re: [Discuss-gnuradio] ControlPort setup_rpc function not called for pure message passing blocks

[Martin Lülf]

Dear Tom,

thanks for your reply.

I created an account on the gnuradio.org platform. A day later the 
account is still disabled, so I assume there is a manual confirmation 
required.

So I kindly ask somebody on the list with the right permissions to 
activate my account "MartinLuelf" with the same Email address as I use 
for this mailing list.

Thank you and have a nice weekend eveybody.
Martin

On 03/04/16 18:05, Tom Rondeau wrote:
> On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf <address@hidden
> <mailto:address@hidden>> wrote:
>
>     Dear mailing list,
>
>     we are trying to create a status overview of our receiver by using
>     the control ports feature. For most of our custom made blocks this
>     works very well and we can see the exported variables.
>
>     But for a few blocks the exported variables do not show up in the
>     control port monitor. After putting tracing lines in these blocks we
>     found out that the setup_rpc function is not called. The only
>     difference we could see between the blocks were the setup_rpc
>     function is called and the ones where it is not is that the latter
>     have no stream in- or output. Instead they only use the message
>     passing API to process data, like the mesage debug block from GNURadio.
>
>     A minimal working example of a block whichs setup_rpc() method is
>     not called can be found at http://pastebin.com/cBFJCnW7 with private
>     and public header files at http://pastebin.com/35WhFqQ0 and
>     http://pastebin.com/zb4jBRAw
>
>     If we run this block and feed messages to it, we get the following
>     output:
>     constructor()
>     ControlPort Monitor running.
>     INFO: Apache Thrift: -h localhost -p 40444
>     monitor::endpoints() = -h localhost -p 40444
>     process frame()
>     process frame()
>     [...]
>     process frame()
>     process frame()
>     running: ['gr-ctrlport-monitor', 'localhost', '40444']
>     process frame()
>     process frame()
>     [...]
>     process frame()
>     process frame()
>
>     We would expect to see an additional line at the beginning saying
>     "setup_rpc()" (see line 71 of the c++ code) and consequently see the
>     variable "testval" in the control port monitor, like it does for our
>     working blocks.
>
>     The above output is generated with GNURadio version
>     3.7.8.1-229-g51c0426a manually compiled from source on an Ubuntu
>     trusty system (64 bit).
>
>     The only difference we could find between the blocks working as
>     expected and the ones that do not, is that they use streaming for
>     data transport, i.e. that their work or general_work function has
>     some actual data processing and their gr::io_signature is not set to
>     (0,0,0).
>
>     I kindly ask for your help to find out why the setup_rpc function is
>     not called for our example block posted above and what we can do to
>     change this.
>
>     Yours sincerely
>     Martin Luelf
>
>
> Martin,
>
> This definitely sounds like a bug for a case that wasn't planned for
> initially. Can you open up a bug report with this information on our
> Issue tracker on gnuradio.org <http://gnuradio.org>?
>
> Thanks,
> Tom