Re: [Discuss-gnuradio] Ctrl-port port lottery...

[Alexandru Csete]

On Fri, Feb 1, 2013 at 4:37 AM, Tom Rondeau <address@hidden> wrote:
> On Thu, Jan 31, 2013 at 11:22 AM, Alexandru Csete <address@hidden> wrote:
>>
>> Greetings,
>>
>> I started to play with the gr-ctrl-port examples today and I noticed
>> that every time I execute pfb_sync_test or pfb_sync_test-qt grc
>> scripts they use a different port number. Is that intentional?
>
> This is the default behavior, yes. On my list of things to do is more
> strongly integrate a config file concept with ControlPort, of which setting
> the port  will be one of the parameters. I'm sure you're asking because
> constantly having to know which port you've randomly set up is kind of
> annoying. But really, it's the right behavior if you don't have anything
> else specifically telling it for your machine. Definitely on the short list
> of things to do.

Hi Tom,

Thanks for the reply. Indeed, I was asking because I had to restart
the client with the new port number every time. If it will be possible
to specify the port number later it'll be great, but there is no hurry
from my side.


>> I also noticed that the gr-ctrl-port stuff got installed without
>> problems, despite that I didn't have python-zeroc-ice package
>> installed so a check seems to be missing in the cmake files.
>
> That's only partially problematic, but thanks for pointing it out. There are
> a few things that we don't check for that are used, actually. Specifically,
> these we don't check for all possible Python packages when they are only
> used in example files.
>
> Having said that, here's my thoughts. We shouldn't stop the installation of
> ControlPort if the Python ICE package is not found. You don't need it to run
> GNU Radio apps with ControlPort and you can develop clients in many other
> languages. On the other hand, since gr-ctrlport-monitor uses Python's ICE
> package and we run slice2py, we need to check for this and not run slice2py
> or install gr-ctrlport-monitor if the Python package is not there.

I see your point and I agree; a missing python package should not
prevent the C++ part to be installed.

Alex