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

[Martin Luelf]

On 04.03.2016 18:05, Tom Rondeau wrote:
On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf > 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 ?


Thanks,
Tom



I created a new bug #907 that can be viewed at 
http://gnuradio.org/redmine/issues/907


Thanks for your support.
Martin


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Martin Luelf]

On 07.03.2016 14:23, Tom Rondeau wrote:
On Sun, Mar 6, 2016 at 6:08 AM, Martin Lülf > wrote:


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



I have activated your account.



Hi Tom,

thanks for the activation, I can now log in. However I can't find a 
button or link to create a new bug/issue. According to the wiki there 
should be an entry "New Issue" appearing in the navigation, but I can't 
find it anywhere. Do I need to have additional rights to open tickets?


Martin


Now, if someone can get rid of spammers, we wouldn't need to do this...

Tom

On 03/04/16 18:05, Tom Rondeau wrote:

On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf mailto:m...@mluelf.de>
>> 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 
?

Thanks,
Tom





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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 mailto:m...@mluelf.de>> 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 ?

Thanks,
Tom



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Tom Rondeau]

On Wed, Mar 2, 2016 at 4:28 AM, Martin Luelf  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?

Thanks,
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Martin Luelf]

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

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio