Re: Qt GUI Chooser initial selection
Yes, on testing it that does work. But surely, as I said, this needs to go into the 3.8 branch of gnuradio so that it is in the next 3.8 release? Chris On Sun, 12 Apr 2020 17:16:24 +0200 Volker Schroer wrote: > I think, it should be possible to take the qtgui_chooser.block.yml file > from the master branch. This sould work, as there is no code affected. > > Volker > > Am 12.04.20 um 14:56 schrieb Chris Vine: > > Ah, OK. This did not find its way into gnuradio-3.8.1.0. Presumably it > > will apply OK to that version however? (If so I suggest it is applied > > to the 3.8 branch also.) > > > > Chris > > > > > > On Sun, 12 Apr 2020 11:48:56 +0200 > > Volker Schroer wrote: > >> Hi ! > >> This was fixed with #2778 > >> > >> See also: > >> > >> https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a > >> > >> > >> -- Volker > >> Am 11.04.20 um 14:45 schrieb Chris Vine: > >>> Hi, > >>> > >>> On porting a gnuradio-companion flow graph from gnuradio-3.7 to > >>> gnuradio-3.8, I noticed that there no longer seems to be a way of > >>> setting the initial (default) selection for the Qt GUI Chooser widget. > >>> The initial selection seems now always to be the first one in the list. > >>> > >>> The widget is therefore no longer suitable for presenting a selection > >>> of numeric values to the user in numerical order where you don't want > >>> the initial default to be the highest (or lowest) value. > >>> > >>> Is there some way around this or some other widget that is now intended > >>> to be used for this purpose? > >>> > >>> Chris > >>> > >>
Re: Looking for insight into gr-iio for plutosdr
Hello again, I believe I have found my solution. At least it fixes the segfault. Adding add_definitions(-DBOOST_CHRONO_HEADER_ONLY) to the CMakeLists.txt file in upgrade-3.8 branch of gr-iio allows me to import iio from python without error. I would like to thank https://gist.github.com/DonOregano for the fix. It is in one of his trees. Chris On Sat, Apr 11, 2020 at 8:41 PM Chris Gorman wrote: > > Hello All, > > I am trying to install gr-iio to build the needed libraries for a > plutosdr. I have a slightly unique situation in that I am running on > a linux from scratch machine and as a result uses shared libraries > when possible. I have followed the instructions on > https://wiki.analog.com/resources/tools-software/linux-software/gnuradio > , except I am using the upgrade-3.8 branch of gr-iio. In order to get > cmake to run, I need to pass -DBUILD_SHARED_LIBS=ON to cmake. This > causes a small problem with the resulting binaries. When I try to > load them I get errors. A simple import of iio in Python causes a > segfault. > > Python 3.7.4 (default, Dec 21 2019, 10:53:28) > [GCC 9.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import iio > Fatal Python error: Segmentation fault > > Current thread 0x7fbf14c7a740 (most recent call first): > File "", line 219 in _call_with_frames_removed > File "", line 1043 in create_module > File "", line 583 in module_from_spec > File "", line 670 in _load_unlocked > File "", line 967 in _find_and_load_unlocked > File "", line 983 in _find_and_load > File "", line 219 in _call_with_frames_removed > File "", line 1035 in _handle_fromlist > File "/opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py", > line 13 in > File "", line 219 in _call_with_frames_removed > File "", line 728 in exec_module > File "", line 677 in _load_unlocked > File "", line 967 in _find_and_load_unlocked > File "", line 983 in _find_and_load > File "/opt/gnuradio/lib/python3.7/dist-packages/iio/__init__.py", > line 36 in > File "", line 219 in _call_with_frames_removed > File "", line 728 in exec_module > File "", line 677 in _load_unlocked > File "", line 967 in _find_and_load_unlocked > File "", line 983 in _find_and_load > File "", line 1 in > Segmentation fault > > When I try to run iio_swig.py from within gdb I get an error > indicating that linking has gone wrong somehow. > > (gdb) run /opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py > Starting program: /usr/bin/python3 > /opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/libthread_db.so.1". > Traceback (most recent call last): > File "/opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py", > line 15, in > import _iio_swig > ImportError: /opt/gnuradio/lib/libgnuradio-iio.so...: undefined > symbol: _ZN5boost6chrono12steady_clock3nowEv > [Inferior 1 (process 10709) exited with code 01 > > _ZN5boost6chrono12setady_clock3nowEv exists in > /usr/lib/libboost_chrono.so , but that library is not used by gr-iio > as far as I can see. (I can't find > _ZN5boost6chrono12setady_clock3nowEv in any of the requested > libraries: date_time; program_options; filesystem; system; regex; > thread; unit_test_framework.) > > I'm attaching my build.log in case the fix can be found by perusing > it. (It hasn't helped me yet.) Any ideas on how to fix my problem > would be appreciated. > > Thanks in advance. > > Chris
Re: Qt GUI Chooser initial selection
I think, it should be possible to take the qtgui_chooser.block.yml file from the master branch. This sould work, as there is no code affected. Volker Am 12.04.20 um 14:56 schrieb Chris Vine: Ah, OK. This did not find its way into gnuradio-3.8.1.0. Presumably it will apply OK to that version however? (If so I suggest it is applied to the 3.8 branch also.) Chris On Sun, 12 Apr 2020 11:48:56 +0200 Volker Schroer wrote: Hi ! This was fixed with #2778 See also: https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a -- Volker Am 11.04.20 um 14:45 schrieb Chris Vine: Hi, On porting a gnuradio-companion flow graph from gnuradio-3.7 to gnuradio-3.8, I noticed that there no longer seems to be a way of setting the initial (default) selection for the Qt GUI Chooser widget. The initial selection seems now always to be the first one in the list. The widget is therefore no longer suitable for presenting a selection of numeric values to the user in numerical order where you don't want the initial default to be the highest (or lowest) value. Is there some way around this or some other widget that is now intended to be used for this purpose? Chris
Re: Qt GUI Chooser initial selection
Ah, OK. This did not find its way into gnuradio-3.8.1.0. Presumably it will apply OK to that version however? (If so I suggest it is applied to the 3.8 branch also.) Chris On Sun, 12 Apr 2020 11:48:56 +0200 Volker Schroer wrote: > Hi ! > This was fixed with #2778 > > See also: > > https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a > > > -- Volker > Am 11.04.20 um 14:45 schrieb Chris Vine: > > Hi, > > > > On porting a gnuradio-companion flow graph from gnuradio-3.7 to > > gnuradio-3.8, I noticed that there no longer seems to be a way of > > setting the initial (default) selection for the Qt GUI Chooser widget. > > The initial selection seems now always to be the first one in the list. > > > > The widget is therefore no longer suitable for presenting a selection > > of numeric values to the user in numerical order where you don't want > > the initial default to be the highest (or lowest) value. > > > > Is there some way around this or some other widget that is now intended > > to be used for this purpose? > > > > Chris > > >
Question on OOT- Modules installation path
Hi, I'm trying to expand the gr-osmosdr oot module using the funcube ( fcd, fcdproplus ) modules. While gr-fcd formerly was a part of gnuradio and disappeard in 3.8, fcdproplus was always a oot module. In gnuradio >=3.8 oot modules provide gnuradio-{oot-name}Config.cmake and some others. Now I came across that using gr_modtool these files will be installed to ${GNURADIO_INSTALL_PREFIX}/lib/cmake/"Module name", while some other oot's like gr-iqbal or gr-osmosdr put these files to ${GNURADIO_INSTALL_PREFIX}/lib/cmake/gnuradio. This path has consequences how to find these modules later. So my question: What is the recommended path for these files. Thanks in advance -- Volker
Re: Qt GUI Chooser initial selection
Hi ! This was fixed with #2778 See also: https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a -- Volker Am 11.04.20 um 14:45 schrieb Chris Vine: Hi, On porting a gnuradio-companion flow graph from gnuradio-3.7 to gnuradio-3.8, I noticed that there no longer seems to be a way of setting the initial (default) selection for the Qt GUI Chooser widget. The initial selection seems now always to be the first one in the list. The widget is therefore no longer suitable for presenting a selection of numeric values to the user in numerical order where you don't want the initial default to be the highest (or lowest) value. Is there some way around this or some other widget that is now intended to be used for this purpose? Chris