Re: [Discuss-gnuradio] test message please ignore
Eamon, please don't do this; there's more than 3000 email addresses on this mailing list. If you have any problems with your subscription, feel free to mail discuss-gnuradio-requ...@gnu.org with "help" in the subject line. A much better way to get to know whether the mailing list works would be by sending a self-introduction email and check the mailing list archives for it an hour later, if you're not sure it reached the list. Best regards, Marcus On Thu, 2019-06-06 at 09:39 -0400, Eamon Heaney wrote: > Another test message, due to my subscription wonkiness. Thank you for > bearing with me. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test message please ignore
Another test message, due to my subscription wonkiness. Thank you for bearing with me. -- Eamon Heaney *Fleet Commander* *President, Model UN at Virginia Tech* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test message please ignore
Been having subscription issues, checking to see if I can mail the list. -- _The information contained in this communication may be subject to legal confidentiality protection or privilege. It is intended solely for use by the intended recipient and others authorized to receive it. If you have received this communication in error, please notify the sender and delete it immediately. You are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. The school accepts no liability whatsoever for any damage, loss, or expense arising from any misuse of this e-mail and/or from the accessing of any files attached to this e-mail._ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
On 04/29/2017 11:18 PM, li...@lazygranch.com wrote: > On opensuse it is python-scipy. Those tests did work at one time, and I > do recall having to load python-scipy. > > zmq is the one I find confusing. You can find references to 0mq, zmq, > and zeromq in documentation. For packages, they stuck wit zmq: > czmq > czmq-devel > libczmq3 > libzmq5 > python-pyzmq > pythin-pyzmq-devel > python3-pyzmq > python3-pyzmq-devel > uwsgi-logzmq > > Sadly, zeromq.org uses the terms zeromq and 0mq, but you import zmq. A > trifecta of confusion. > > Generally I roll my eyes at technical writers, but this is a case where > the neck beards needed some help. > I have libzmq3-dev python-zmq installed on Debian. It's possible there earlier versions than 3 which would work too. In python, you should be able to from gnuradio import zeromq And if I recall correctly, during the cmake configuration, cmake indicates if it's missing. If you installed it and cmake complains about it missing then it's probably because it's not the development version. -- Cinaed > On Sat, 29 Apr 2017 22:45:03 -0700 > Cinaed Simson wrote: > >> On 04/29/2017 06:41 PM, Cinaed Simson wrote: >> >>> The test for polar uses python-scipy which requires scipy. >> >> Actually, I don't think this is true. >> >> In Debian and Ubuntu, just about all the libraries with the python >> hooks are named python-. >> >> On you system it may be called scipy. In fact, that's its proper name. >> >> -- Cinaed >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > . > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
That all worked as stated. Thanks. Apparently I am in a detached head state. ;-) On Sat, 29 Apr 2017 21:33:12 -0700 Ron Economos wrote: > Sure, no problem. Since you're trying to compile the latest and > greatest, I assume you used the command: > > git clone --recursive https://github.com/gnuradio/gnuradio.git > > Now you have not only the latest and greatest, but also every release > since October 2009. > > Just cd into the directory the git clone downloaded into and type: > > git tag > > This will print all the release tags, of which v3.7.11 is one. > > Then the command: > > git checkout v3.7.11 > > will change all the files that have changed since that release back > to the versions that existed for that release. > > You can also checkout in between versions by using the hash > associated with the commit. For example: > > git checkout 082711c > > will go back two commits, and you'll be building > 3.7.12git-99-g082711cc. > > Then you can always get back to where you started by typing: > > git checkout master > > Ron > > On 04/29/2017 08:47 PM, li...@lazygranch.com wrote: > > I'm afraid you are going to have to dumb it down for me. I don't see > > where to enter the path to the git repository. In other words > > > > git checkout v3.7.11 > > > > needs to know the location of the git source. Doing some googling, > > it looks like that is for a situation where the git source is local. > > > > Basically I need the full command line or procedure. > > > > This is the best link I can find on doing a git checkout on a > > remote, and it goes on and on, not really resolving the problem. > > http://stackoverflow.com/questions/1783405/how-to-check-out-a-remote-git-branch > > > > In the meantime, I will compile the newest version without thrift > > installed, which hopefully will skip those modules. > > > > On Sat, 29 Apr 2017 > > 19:01:34 -0700 Ron Economos wrote: > > > >> git checkout v3.7.11 > >> > >> But you're still going to have the same test failures. It's not > >> something new. > >> > >> Ron > >> > >> On 04/29/2017 06:57 PM, li...@lazygranch.com wrote: > >>> How do I go back one rev on github? > >>> > >>> > >>> Original Message > >>> From: Cinaed Simson > >>> Sent: Saturday, April 29, 2017 6:42 PM > >>> To: discuss-gnuradio@gnu.org > >>> Subject: Re: [Discuss-gnuradio] test and build errors on > >>> 3.7.12git-101-g098dc3e0 > >>> > >>> On 04/29/2017 05:52 PM, li...@lazygranch.com wrote: > >>>> I have ZMQ. Here is the cmake finding it: > >>>> > >>>> -- Configuring gr-wxgui support... > >>>> -- Dependency ENABLE_GNURADIO_RUNTIME = ON > >>>> -- Dependency ENABLE_GR_FFT = ON > >>>> -- Dependency ENABLE_GR_FILTER = ON > >>>> -- Dependency ENABLE_GR_ANALOG = ON > >>>> -- Dependency ENABLE_PYTHON = ON > >>>> -- Dependency NUMPY_FOUND = TRUE > >>>> -- Dependency WX_FOUND = TRUE > >>>> -- Enabling gr-wxgui support. > >>>> -- Override with -DENABLE_GR_WXGUI=ON/OFF > >>>> -- Checking for module 'libzmq' > >>>> -- Found libzmq, version 4.1.2 > >>>> -- Found ZEROMQ: /usr/lib64/libzmq.so > >>>> > >>>> I also have scipy, though I don't see it being looked for in the > >>>> cmake. > >>> I'm running a release version - 3.7.11 - you're on 3.7.12 which is > >>> on the bleeding edge so your mileage may vary - it's work in > >>> progress unless I missed the email of its release. > >>> > >>> The test for polar uses python-scipy which requires scipy. > >>> > >>> See > >>> > >>> ./gnuradio-3.7.11/gr-fec/python/fec/polar/channel_construction_awgn.py > >>> > >>> which imports > >>> > >>> from scipy.optimize import fsolve > >>> from scipy.special import erfc > >>> > >>> In general, you need to run the run the qa scripts in the > >>> directories where the tests failed - assuming all the CMake > >>> configure errors or the software not found messages have been > >>> cleared. > >>> > >>> -- Cinaed > >>> > >>>> I missed this one, but I
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
On opensuse it is python-scipy. Those tests did work at one time, and I do recall having to load python-scipy. zmq is the one I find confusing. You can find references to 0mq, zmq, and zeromq in documentation. For packages, they stuck wit zmq: czmq czmq-devel libczmq3 libzmq5 python-pyzmq pythin-pyzmq-devel python3-pyzmq python3-pyzmq-devel uwsgi-logzmq Sadly, zeromq.org uses the terms zeromq and 0mq, but you import zmq. A trifecta of confusion. Generally I roll my eyes at technical writers, but this is a case where the neck beards needed some help. On Sat, 29 Apr 2017 22:45:03 -0700 Cinaed Simson wrote: > On 04/29/2017 06:41 PM, Cinaed Simson wrote: > > > The test for polar uses python-scipy which requires scipy. > > Actually, I don't think this is true. > > In Debian and Ubuntu, just about all the libraries with the python > hooks are named python-. > > On you system it may be called scipy. In fact, that's its proper name. > > -- Cinaed > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
On 04/29/2017 06:41 PM, Cinaed Simson wrote: > The test for polar uses python-scipy which requires scipy. Actually, I don't think this is true. In Debian and Ubuntu, just about all the libraries with the python hooks are named python-. On you system it may be called scipy. In fact, that's its proper name. -- Cinaed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
Sure, no problem. Since you're trying to compile the latest and greatest, I assume you used the command: git clone --recursive https://github.com/gnuradio/gnuradio.git Now you have not only the latest and greatest, but also every release since October 2009. Just cd into the directory the git clone downloaded into and type: git tag This will print all the release tags, of which v3.7.11 is one. Then the command: git checkout v3.7.11 will change all the files that have changed since that release back to the versions that existed for that release. You can also checkout in between versions by using the hash associated with the commit. For example: git checkout 082711c will go back two commits, and you'll be building 3.7.12git-99-g082711cc. Then you can always get back to where you started by typing: git checkout master Ron On 04/29/2017 08:47 PM, li...@lazygranch.com wrote: I'm afraid you are going to have to dumb it down for me. I don't see where to enter the path to the git repository. In other words git checkout v3.7.11 needs to know the location of the git source. Doing some googling, it looks like that is for a situation where the git source is local. Basically I need the full command line or procedure. This is the best link I can find on doing a git checkout on a remote, and it goes on and on, not really resolving the problem. http://stackoverflow.com/questions/1783405/how-to-check-out-a-remote-git-branch In the meantime, I will compile the newest version without thrift installed, which hopefully will skip those modules. On Sat, 29 Apr 2017 19:01:34 -0700 Ron Economos wrote: git checkout v3.7.11 But you're still going to have the same test failures. It's not something new. Ron On 04/29/2017 06:57 PM, li...@lazygranch.com wrote: How do I go back one rev on github? Original Message From: Cinaed Simson Sent: Saturday, April 29, 2017 6:42 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0 On 04/29/2017 05:52 PM, li...@lazygranch.com wrote: I have ZMQ. Here is the cmake finding it: -- Configuring gr-wxgui support... -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Dependency ENABLE_PYTHON = ON -- Dependency NUMPY_FOUND = TRUE -- Dependency WX_FOUND = TRUE -- Enabling gr-wxgui support. -- Override with -DENABLE_GR_WXGUI=ON/OFF -- Checking for module 'libzmq' -- Found libzmq, version 4.1.2 -- Found ZEROMQ: /usr/lib64/libzmq.so I also have scipy, though I don't see it being looked for in the cmake. I'm running a release version - 3.7.11 - you're on 3.7.12 which is on the bleeding edge so your mileage may vary - it's work in progress unless I missed the email of its release. The test for polar uses python-scipy which requires scipy. See ./gnuradio-3.7.11/gr-fec/python/fec/polar/channel_construction_awgn.py which imports from scipy.optimize import fsolve from scipy.special import erfc In general, you need to run the run the qa scripts in the directories where the tests failed - assuming all the CMake configure errors or the software not found messages have been cleared. -- Cinaed I missed this one, but I also have libcodec2. -- Configuring gr-vocoder support... -- Dependency Boost_FOUND = 1 -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_BLOCKS = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Enabling gr-vocoder support. -- Override with -DENABLE_GR_VOCODER=ON/OFF -- Found libgsm: /usr/include/gsm, /usr/lib64/libgsm.so -- System libcodec2 not found. -- Checking for module 'libusb-1.0' -- Found libusb-1.0, version 1.0.20 -- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so On Sat, 29 Apr 2017 12:05:30 -0700 Ron Economos wrote: For the polar encoder/decoder and zeromq tests, you need the following dependencies. I'm not sure about the other failures. python-scipy python-zmq Ron On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: Opensuse 42.2 uname -a Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux --- Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git Entire cmake output at: https://pastebin.com/Gqa32538 -- Errors in the doxygen build: https://pastebin.com/2KVp6v9X 95% tests passed, 11 tests failed out of 220 Total Test time (real) = 3850.12 sec The following tests FAILED: 18 - qa_cpp_py_binding (Failed) 22 - qa_ctrlport_probes (Failed) 51 - qa_cpp_py_binding_set (Failed) 84 - qa_python_message_passing (Failed) 89 - qa_polar_encoder_systematic (Failed) 92 - qa_polar_encoder (Failed) 94 - qa_polar_decoder_sc (Failed) 95 - qa_pola
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
I'm afraid you are going to have to dumb it down for me. I don't see where to enter the path to the git repository. In other words git checkout v3.7.11 needs to know the location of the git source. Doing some googling, it looks like that is for a situation where the git source is local. Basically I need the full command line or procedure. This is the best link I can find on doing a git checkout on a remote, and it goes on and on, not really resolving the problem. http://stackoverflow.com/questions/1783405/how-to-check-out-a-remote-git-branch In the meantime, I will compile the newest version without thrift installed, which hopefully will skip those modules. On Sat, 29 Apr 2017 19:01:34 -0700 Ron Economos wrote: > git checkout v3.7.11 > > But you're still going to have the same test failures. It's not > something new. > > Ron > > On 04/29/2017 06:57 PM, li...@lazygranch.com wrote: > > How do I go back one rev on github? > > > > > >Original Message > > From: Cinaed Simson > > Sent: Saturday, April 29, 2017 6:42 PM > > To: discuss-gnuradio@gnu.org > > Subject: Re: [Discuss-gnuradio] test and build errors on > > 3.7.12git-101-g098dc3e0 > > > > On 04/29/2017 05:52 PM, li...@lazygranch.com wrote: > >> I have ZMQ. Here is the cmake finding it: > >> > >> -- Configuring gr-wxgui support... > >> -- Dependency ENABLE_GNURADIO_RUNTIME = ON > >> -- Dependency ENABLE_GR_FFT = ON > >> -- Dependency ENABLE_GR_FILTER = ON > >> -- Dependency ENABLE_GR_ANALOG = ON > >> -- Dependency ENABLE_PYTHON = ON > >> -- Dependency NUMPY_FOUND = TRUE > >> -- Dependency WX_FOUND = TRUE > >> -- Enabling gr-wxgui support. > >> -- Override with -DENABLE_GR_WXGUI=ON/OFF > >> -- Checking for module 'libzmq' > >> -- Found libzmq, version 4.1.2 > >> -- Found ZEROMQ: /usr/lib64/libzmq.so > >> > >> I also have scipy, though I don't see it being looked for in the > >> cmake. > > I'm running a release version - 3.7.11 - you're on 3.7.12 which is > > on the bleeding edge so your mileage may vary - it's work in > > progress unless I missed the email of its release. > > > > The test for polar uses python-scipy which requires scipy. > > > > See > > > > ./gnuradio-3.7.11/gr-fec/python/fec/polar/channel_construction_awgn.py > > > > which imports > > > > from scipy.optimize import fsolve > > from scipy.special import erfc > > > > In general, you need to run the run the qa scripts in the > > directories where the tests failed - assuming all the CMake > > configure errors or the software not found messages have been > > cleared. > > > > -- Cinaed > > > >> I missed this one, but I also have libcodec2. > >> > >> -- Configuring gr-vocoder support... > >> -- Dependency Boost_FOUND = 1 > >> -- Dependency ENABLE_GNURADIO_RUNTIME = ON > >> -- Dependency ENABLE_GR_FFT = ON > >> -- Dependency ENABLE_GR_BLOCKS = ON > >> -- Dependency ENABLE_GR_FILTER = ON > >> -- Dependency ENABLE_GR_ANALOG = ON > >> -- Enabling gr-vocoder support. > >> -- Override with -DENABLE_GR_VOCODER=ON/OFF > >> -- Found libgsm: /usr/include/gsm, /usr/lib64/libgsm.so > >> -- System libcodec2 not found. > >> -- Checking for module 'libusb-1.0' > >> -- Found libusb-1.0, version 1.0.20 > >> -- Found > >> libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so > >> > >> > >> > >> > >> On Sat, 29 Apr 2017 12:05:30 -0700 > >> Ron Economos wrote: > >> > >>> For the polar encoder/decoder and zeromq tests, you need the > >>> following dependencies. I'm not sure about the other failures. > >>> > >>> python-scipy > >>> > >>> python-zmq > >>> > >>> Ron > >>> > >>> On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: > >>>> Opensuse 42.2 > >>>> uname -a > >>>> Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 > >>>> UTC 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux > >>>> --- > >>>> Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git > >>>> Entire cmake output at: > >>>> https://pastebin.com/Gqa32538 > >>>> -- > >>>> Errors in the doxygen build: > >>>> https://p
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
I've never bothered with thrift. Even after using GNU Radio for 3+ years, I've never used gr-ctrlport either. 3.7.11 is the latest release. But there's probably nothing particularly wrong with 3.7.12git-101-g098dc3e0. I would continue trying to work out the issues with that first. In fact, there have been some recent commits to solve some intermittent test errors. Ron On 04/29/2017 07:07 PM, li...@lazygranch.com wrote: I suppose I could uninstall thrift since that looks really hosed on my system. That would get rid of some errors. Is there a recommended rev? Original Message From: Ron Economos Sent: Saturday, April 29, 2017 7:03 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0 git checkout v3.7.11 But you're still going to have the same test failures. It's not something new. Ron On 04/29/2017 06:57 PM, li...@lazygranch.com wrote: How do I go back one rev on github? Original Message From: Cinaed Simson Sent: Saturday, April 29, 2017 6:42 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0 On 04/29/2017 05:52 PM, li...@lazygranch.com wrote: I have ZMQ. Here is the cmake finding it: -- Configuring gr-wxgui support... -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Dependency ENABLE_PYTHON = ON -- Dependency NUMPY_FOUND = TRUE -- Dependency WX_FOUND = TRUE -- Enabling gr-wxgui support. -- Override with -DENABLE_GR_WXGUI=ON/OFF -- Checking for module 'libzmq' -- Found libzmq, version 4.1.2 -- Found ZEROMQ: /usr/lib64/libzmq.so I also have scipy, though I don't see it being looked for in the cmake. I'm running a release version - 3.7.11 - you're on 3.7.12 which is on the bleeding edge so your mileage may vary - it's work in progress unless I missed the email of its release. The test for polar uses python-scipy which requires scipy. See ./gnuradio-3.7.11/gr-fec/python/fec/polar/channel_construction_awgn.py which imports from scipy.optimize import fsolve from scipy.special import erfc In general, you need to run the run the qa scripts in the directories where the tests failed - assuming all the CMake configure errors or the software not found messages have been cleared. -- Cinaed I missed this one, but I also have libcodec2. -- Configuring gr-vocoder support... -- Dependency Boost_FOUND = 1 -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_BLOCKS = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Enabling gr-vocoder support. -- Override with -DENABLE_GR_VOCODER=ON/OFF -- Found libgsm: /usr/include/gsm, /usr/lib64/libgsm.so -- System libcodec2 not found. -- Checking for module 'libusb-1.0' -- Found libusb-1.0, version 1.0.20 -- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so On Sat, 29 Apr 2017 12:05:30 -0700 Ron Economos wrote: For the polar encoder/decoder and zeromq tests, you need the following dependencies. I'm not sure about the other failures. python-scipy python-zmq Ron On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: Opensuse 42.2 uname -a Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux --- Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git Entire cmake output at: https://pastebin.com/Gqa32538 -- Errors in the doxygen build: https://pastebin.com/2KVp6v9X 95% tests passed, 11 tests failed out of 220 Total Test time (real) = 3850.12 sec The following tests FAILED: 18 - qa_cpp_py_binding (Failed) 22 - qa_ctrlport_probes (Failed) 51 - qa_cpp_py_binding_set (Failed) 84 - qa_python_message_passing (Failed) 89 - qa_polar_encoder_systematic (Failed) 92 - qa_polar_encoder (Failed) 94 - qa_polar_decoder_sc (Failed) 95 - qa_polar_decoder_sc_list (Failed) 98 - qa_polar_decoder_sc_systematic (Failed) 218 - qa_zeromq_sub (Failed) 219 - qa_zeromq_pub (Failed) Errors while running CTest Makefile:72: recipe for target 'test' failed make: *** [test] Error 8 For the complete make test: https://pastebin.com/JwHqDGrc ctest -V -R ctrlport_probes UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl Test project /usr/local/src/gnuradio_latest/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 22 Start 22: qa_ctrlport_probes 22: Test command: /usr/bin/sh "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_ct
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
I suppose I could uninstall thrift since that looks really hosed on my system. That would get rid of some errors. Is there a recommended rev? Original Message From: Ron Economos Sent: Saturday, April 29, 2017 7:03 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0 git checkout v3.7.11 But you're still going to have the same test failures. It's not something new. Ron On 04/29/2017 06:57 PM, li...@lazygranch.com wrote: > How do I go back one rev on github? > > > Original Message > From: Cinaed Simson > Sent: Saturday, April 29, 2017 6:42 PM > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] test and build errors on > 3.7.12git-101-g098dc3e0 > > On 04/29/2017 05:52 PM, li...@lazygranch.com wrote: >> I have ZMQ. Here is the cmake finding it: >> >> -- Configuring gr-wxgui support... >> -- Dependency ENABLE_GNURADIO_RUNTIME = ON >> -- Dependency ENABLE_GR_FFT = ON >> -- Dependency ENABLE_GR_FILTER = ON >> -- Dependency ENABLE_GR_ANALOG = ON >> -- Dependency ENABLE_PYTHON = ON >> -- Dependency NUMPY_FOUND = TRUE >> -- Dependency WX_FOUND = TRUE >> -- Enabling gr-wxgui support. >> -- Override with -DENABLE_GR_WXGUI=ON/OFF >> -- Checking for module 'libzmq' >> -- Found libzmq, version 4.1.2 >> -- Found ZEROMQ: /usr/lib64/libzmq.so >> >> I also have scipy, though I don't see it being looked for in the cmake. > I'm running a release version - 3.7.11 - you're on 3.7.12 which is on > the bleeding edge so your mileage may vary - it's work in progress > unless I missed the email of its release. > > The test for polar uses python-scipy which requires scipy. > > See > > ./gnuradio-3.7.11/gr-fec/python/fec/polar/channel_construction_awgn.py > > which imports > > from scipy.optimize import fsolve > from scipy.special import erfc > > In general, you need to run the run the qa scripts in the directories > where the tests failed - assuming all the CMake configure errors or the > software not found messages have been cleared. > > -- Cinaed > >> I missed this one, but I also have libcodec2. >> >> -- Configuring gr-vocoder support... >> -- Dependency Boost_FOUND = 1 >> -- Dependency ENABLE_GNURADIO_RUNTIME = ON >> -- Dependency ENABLE_GR_FFT = ON >> -- Dependency ENABLE_GR_BLOCKS = ON >> -- Dependency ENABLE_GR_FILTER = ON >> -- Dependency ENABLE_GR_ANALOG = ON >> -- Enabling gr-vocoder support. >> -- Override with -DENABLE_GR_VOCODER=ON/OFF >> -- Found libgsm: /usr/include/gsm, /usr/lib64/libgsm.so >> -- System libcodec2 not found. >> -- Checking for module 'libusb-1.0' >> -- Found libusb-1.0, version 1.0.20 >> -- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so >> >> >> >> >> On Sat, 29 Apr 2017 12:05:30 -0700 >> Ron Economos wrote: >> >>> For the polar encoder/decoder and zeromq tests, you need the >>> following dependencies. I'm not sure about the other failures. >>> >>> python-scipy >>> >>> python-zmq >>> >>> Ron >>> >>> On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: >>>> Opensuse 42.2 >>>> uname -a >>>> Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC >>>> 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux >>>> --- >>>> Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git >>>> Entire cmake output at: >>>> https://pastebin.com/Gqa32538 >>>> -- >>>> Errors in the doxygen build: >>>> https://pastebin.com/2KVp6v9X >>>> >>>> >>>> 95% tests passed, 11 tests failed out of 220 >>>> >>>> Total Test time (real) = 3850.12 sec >>>> >>>> The following tests FAILED: >>>> 18 - qa_cpp_py_binding (Failed) >>>> 22 - qa_ctrlport_probes (Failed) >>>> 51 - qa_cpp_py_binding_set (Failed) >>>> 84 - qa_python_message_passing (Failed) >>>> 89 - qa_polar_encoder_systematic (Failed) >>>> 92 - qa_polar_encoder (Failed) >>>> 94 - qa_polar_decoder_sc (Failed) >>>> 95 - qa_polar_decoder_sc_list (Failed) >>>> 98 - qa_polar_decoder_sc_systematic (Failed) >>>> 218 - qa_zeromq_sub (Failed) >>>> 219 - qa_zeromq_pub (Failed) >>>> Errors while running CTest >>>> Makefile:72: recipe for target '
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
git checkout v3.7.11 But you're still going to have the same test failures. It's not something new. Ron On 04/29/2017 06:57 PM, li...@lazygranch.com wrote: How do I go back one rev on github? Original Message From: Cinaed Simson Sent: Saturday, April 29, 2017 6:42 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0 On 04/29/2017 05:52 PM, li...@lazygranch.com wrote: I have ZMQ. Here is the cmake finding it: -- Configuring gr-wxgui support... -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Dependency ENABLE_PYTHON = ON -- Dependency NUMPY_FOUND = TRUE -- Dependency WX_FOUND = TRUE -- Enabling gr-wxgui support. -- Override with -DENABLE_GR_WXGUI=ON/OFF -- Checking for module 'libzmq' -- Found libzmq, version 4.1.2 -- Found ZEROMQ: /usr/lib64/libzmq.so I also have scipy, though I don't see it being looked for in the cmake. I'm running a release version - 3.7.11 - you're on 3.7.12 which is on the bleeding edge so your mileage may vary - it's work in progress unless I missed the email of its release. The test for polar uses python-scipy which requires scipy. See ./gnuradio-3.7.11/gr-fec/python/fec/polar/channel_construction_awgn.py which imports from scipy.optimize import fsolve from scipy.special import erfc In general, you need to run the run the qa scripts in the directories where the tests failed - assuming all the CMake configure errors or the software not found messages have been cleared. -- Cinaed I missed this one, but I also have libcodec2. -- Configuring gr-vocoder support... -- Dependency Boost_FOUND = 1 -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_BLOCKS = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Enabling gr-vocoder support. -- Override with -DENABLE_GR_VOCODER=ON/OFF -- Found libgsm: /usr/include/gsm, /usr/lib64/libgsm.so -- System libcodec2 not found. -- Checking for module 'libusb-1.0' -- Found libusb-1.0, version 1.0.20 -- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so On Sat, 29 Apr 2017 12:05:30 -0700 Ron Economos wrote: For the polar encoder/decoder and zeromq tests, you need the following dependencies. I'm not sure about the other failures. python-scipy python-zmq Ron On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: Opensuse 42.2 uname -a Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux --- Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git Entire cmake output at: https://pastebin.com/Gqa32538 -- Errors in the doxygen build: https://pastebin.com/2KVp6v9X 95% tests passed, 11 tests failed out of 220 Total Test time (real) = 3850.12 sec The following tests FAILED: 18 - qa_cpp_py_binding (Failed) 22 - qa_ctrlport_probes (Failed) 51 - qa_cpp_py_binding_set (Failed) 84 - qa_python_message_passing (Failed) 89 - qa_polar_encoder_systematic (Failed) 92 - qa_polar_encoder (Failed) 94 - qa_polar_decoder_sc (Failed) 95 - qa_polar_decoder_sc_list (Failed) 98 - qa_polar_decoder_sc_systematic (Failed) 218 - qa_zeromq_sub (Failed) 219 - qa_zeromq_pub (Failed) Errors while running CTest Makefile:72: recipe for target 'test' failed make: *** [test] Error 8 For the complete make test: https://pastebin.com/JwHqDGrc ctest -V -R ctrlport_probes UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl Test project /usr/local/src/gnuradio_latest/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 22 Start 22: qa_ctrlport_probes 22: Test command: /usr/bin/sh "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_ctrlport_probes_test.sh" 22: Test timeout computed to be: 9.99988e+06 22: gr::log :INFO: controlport - Apache Thrift: -h linux-0u81 -p 42407 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored ^C^C ctest -V -R cpp_py U
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
How do I go back one rev on github? Original Message From: Cinaed Simson Sent: Saturday, April 29, 2017 6:42 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0 On 04/29/2017 05:52 PM, li...@lazygranch.com wrote: > I have ZMQ. Here is the cmake finding it: > > -- Configuring gr-wxgui support... > -- Dependency ENABLE_GNURADIO_RUNTIME = ON > -- Dependency ENABLE_GR_FFT = ON > -- Dependency ENABLE_GR_FILTER = ON > -- Dependency ENABLE_GR_ANALOG = ON > -- Dependency ENABLE_PYTHON = ON > -- Dependency NUMPY_FOUND = TRUE > -- Dependency WX_FOUND = TRUE > -- Enabling gr-wxgui support. > -- Override with -DENABLE_GR_WXGUI=ON/OFF > -- Checking for module 'libzmq' > -- Found libzmq, version 4.1.2 > -- Found ZEROMQ: /usr/lib64/libzmq.so > > I also have scipy, though I don't see it being looked for in the cmake. I'm running a release version - 3.7.11 - you're on 3.7.12 which is on the bleeding edge so your mileage may vary - it's work in progress unless I missed the email of its release. The test for polar uses python-scipy which requires scipy. See ./gnuradio-3.7.11/gr-fec/python/fec/polar/channel_construction_awgn.py which imports from scipy.optimize import fsolve from scipy.special import erfc In general, you need to run the run the qa scripts in the directories where the tests failed - assuming all the CMake configure errors or the software not found messages have been cleared. -- Cinaed > > I missed this one, but I also have libcodec2. > > -- Configuring gr-vocoder support... > -- Dependency Boost_FOUND = 1 > -- Dependency ENABLE_GNURADIO_RUNTIME = ON > -- Dependency ENABLE_GR_FFT = ON > -- Dependency ENABLE_GR_BLOCKS = ON > -- Dependency ENABLE_GR_FILTER = ON > -- Dependency ENABLE_GR_ANALOG = ON > -- Enabling gr-vocoder support. > -- Override with -DENABLE_GR_VOCODER=ON/OFF > -- Found libgsm: /usr/include/gsm, /usr/lib64/libgsm.so > -- System libcodec2 not found. > -- Checking for module 'libusb-1.0' > -- Found libusb-1.0, version 1.0.20 > -- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so > > > > > On Sat, 29 Apr 2017 12:05:30 -0700 > Ron Economos wrote: > >> For the polar encoder/decoder and zeromq tests, you need the >> following dependencies. I'm not sure about the other failures. >> >> python-scipy >> >> python-zmq >> >> Ron >> >> On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: >>> Opensuse 42.2 >>> uname -a >>> Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC >>> 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux >>> --- >>> Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git >>> Entire cmake output at: >>> https://pastebin.com/Gqa32538 >>> -- >>> Errors in the doxygen build: >>> https://pastebin.com/2KVp6v9X >>> >>> >>> 95% tests passed, 11 tests failed out of 220 >>> >>> Total Test time (real) = 3850.12 sec >>> >>> The following tests FAILED: >>> 18 - qa_cpp_py_binding (Failed) >>> 22 - qa_ctrlport_probes (Failed) >>> 51 - qa_cpp_py_binding_set (Failed) >>> 84 - qa_python_message_passing (Failed) >>> 89 - qa_polar_encoder_systematic (Failed) >>> 92 - qa_polar_encoder (Failed) >>> 94 - qa_polar_decoder_sc (Failed) >>> 95 - qa_polar_decoder_sc_list (Failed) >>> 98 - qa_polar_decoder_sc_systematic (Failed) >>> 218 - qa_zeromq_sub (Failed) >>> 219 - qa_zeromq_pub (Failed) >>> Errors while running CTest >>> Makefile:72: recipe for target 'test' failed >>> make: *** [test] Error 8 >>> >>> For the complete make test: >>> https://pastebin.com/JwHqDGrc >>> >>> >>> ctest -V -R ctrlport_probes >>> UpdateCTestConfiguration >>> from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl >>> UpdateCTestConfiguration >>> from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl >>> Test project /usr/local/src/gnuradio_latest/gnuradio/build >>> Constructing a list of tests >>> Done constructing a list of tests >>> Checking test dependency graph... >>> Checking test dependency graph end >>> test 22 >>> Start 22: qa_ctrlport_probes >>> >>> 22: Test command: /usr/bin/sh >>> "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/py
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
On 04/29/2017 05:52 PM, li...@lazygranch.com wrote: > I have ZMQ. Here is the cmake finding it: > > -- Configuring gr-wxgui support... > -- Dependency ENABLE_GNURADIO_RUNTIME = ON > -- Dependency ENABLE_GR_FFT = ON > -- Dependency ENABLE_GR_FILTER = ON > -- Dependency ENABLE_GR_ANALOG = ON > -- Dependency ENABLE_PYTHON = ON > -- Dependency NUMPY_FOUND = TRUE > -- Dependency WX_FOUND = TRUE > -- Enabling gr-wxgui support. > -- Override with -DENABLE_GR_WXGUI=ON/OFF > -- Checking for module 'libzmq' > -- Found libzmq, version 4.1.2 > -- Found ZEROMQ: /usr/lib64/libzmq.so > > I also have scipy, though I don't see it being looked for in the cmake. I'm running a release version - 3.7.11 - you're on 3.7.12 which is on the bleeding edge so your mileage may vary - it's work in progress unless I missed the email of its release. The test for polar uses python-scipy which requires scipy. See ./gnuradio-3.7.11/gr-fec/python/fec/polar/channel_construction_awgn.py which imports from scipy.optimize import fsolve from scipy.special import erfc In general, you need to run the run the qa scripts in the directories where the tests failed - assuming all the CMake configure errors or the software not found messages have been cleared. -- Cinaed > > I missed this one, but I also have libcodec2. > > -- Configuring gr-vocoder support... > -- Dependency Boost_FOUND = 1 > -- Dependency ENABLE_GNURADIO_RUNTIME = ON > -- Dependency ENABLE_GR_FFT = ON > -- Dependency ENABLE_GR_BLOCKS = ON > -- Dependency ENABLE_GR_FILTER = ON > -- Dependency ENABLE_GR_ANALOG = ON > -- Enabling gr-vocoder support. > -- Override with -DENABLE_GR_VOCODER=ON/OFF > -- Found libgsm: /usr/include/gsm, /usr/lib64/libgsm.so > -- System libcodec2 not found. > -- Checking for module 'libusb-1.0' > -- Found libusb-1.0, version 1.0.20 > -- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so > > > > > On Sat, 29 Apr 2017 12:05:30 -0700 > Ron Economos wrote: > >> For the polar encoder/decoder and zeromq tests, you need the >> following dependencies. I'm not sure about the other failures. >> >> python-scipy >> >> python-zmq >> >> Ron >> >> On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: >>> Opensuse 42.2 >>> uname -a >>> Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC >>> 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux >>> --- >>> Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git >>> Entire cmake output at: >>> https://pastebin.com/Gqa32538 >>> -- >>> Errors in the doxygen build: >>> https://pastebin.com/2KVp6v9X >>> >>> >>> 95% tests passed, 11 tests failed out of 220 >>> >>> Total Test time (real) = 3850.12 sec >>> >>> The following tests FAILED: >>> 18 - qa_cpp_py_binding (Failed) >>> 22 - qa_ctrlport_probes (Failed) >>> 51 - qa_cpp_py_binding_set (Failed) >>> 84 - qa_python_message_passing (Failed) >>> 89 - qa_polar_encoder_systematic (Failed) >>> 92 - qa_polar_encoder (Failed) >>> 94 - qa_polar_decoder_sc (Failed) >>> 95 - qa_polar_decoder_sc_list (Failed) >>> 98 - qa_polar_decoder_sc_systematic (Failed) >>> 218 - qa_zeromq_sub (Failed) >>> 219 - qa_zeromq_pub (Failed) >>> Errors while running CTest >>> Makefile:72: recipe for target 'test' failed >>> make: *** [test] Error 8 >>> >>> For the complete make test: >>> https://pastebin.com/JwHqDGrc >>> >>> >>> ctest -V -R ctrlport_probes >>> UpdateCTestConfiguration >>> from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl >>> UpdateCTestConfiguration >>> from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl >>> Test project /usr/local/src/gnuradio_latest/gnuradio/build >>> Constructing a list of tests >>> Done constructing a list of tests >>> Checking test dependency graph... >>> Checking test dependency graph end >>> test 22 >>> Start 22: qa_ctrlport_probes >>> >>> 22: Test command: /usr/bin/sh >>> "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_ctrlport_probes_test.sh" >>> 22: Test timeout computed to be: 9.99988e+06 >>> 22: gr::log :INFO: controlport - Apache Thrift: -h linux-0u81 -p >>> 42407 22: Could not connect to ControlPort endpoint at >>> linux-0u81:42407. 22: >>> 22: Exception socket.error: (32, 'Broken pipe') in >> ThriftRadioClient.__del__ of >>> >> at >>> 0x7f046ca06200>> ignored >>> 22: Could not connect to ControlPort endpoint at linux-0u81:42407. >>> 22: >>> 22: Exception socket.error: (32, 'Broken pipe') in >> ThriftRadioClient.__del__ of >>> >> at >>> 0x7f046ca117e8>> ignored >>> 22: Could not connect to ControlPort endpoint at linux-0u81:42407. >>> 22: >>> 22: Exception socket.error: (32, 'Broken pipe') in >> ThriftRadioClient.__del__ of >>> >> at >>> 0x7f046ca11b48>> ignored >>> 22:
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
There are additional dependencies in the test that aren't checked for in the cmake. python-scipy and python-zmq are the ones that I know about. You can find the why the tests failed in the file: install_dir/build/Testing/Temporary/LastTest.log Ron On 04/29/2017 05:52 PM, li...@lazygranch.com wrote: I have ZMQ. Here is the cmake finding it: -- Configuring gr-wxgui support... -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Dependency ENABLE_PYTHON = ON -- Dependency NUMPY_FOUND = TRUE -- Dependency WX_FOUND = TRUE -- Enabling gr-wxgui support. -- Override with -DENABLE_GR_WXGUI=ON/OFF -- Checking for module 'libzmq' -- Found libzmq, version 4.1.2 -- Found ZEROMQ: /usr/lib64/libzmq.so I also have scipy, though I don't see it being looked for in the cmake. I missed this one, but I also have libcodec2. -- Configuring gr-vocoder support... -- Dependency Boost_FOUND = 1 -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_BLOCKS = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Enabling gr-vocoder support. -- Override with -DENABLE_GR_VOCODER=ON/OFF -- Found libgsm: /usr/include/gsm, /usr/lib64/libgsm.so -- System libcodec2 not found. -- Checking for module 'libusb-1.0' -- Found libusb-1.0, version 1.0.20 -- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so On Sat, 29 Apr 2017 12:05:30 -0700 Ron Economos wrote: For the polar encoder/decoder and zeromq tests, you need the following dependencies. I'm not sure about the other failures. python-scipy python-zmq Ron On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: Opensuse 42.2 uname -a Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux --- Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git Entire cmake output at: https://pastebin.com/Gqa32538 -- Errors in the doxygen build: https://pastebin.com/2KVp6v9X 95% tests passed, 11 tests failed out of 220 Total Test time (real) = 3850.12 sec The following tests FAILED: 18 - qa_cpp_py_binding (Failed) 22 - qa_ctrlport_probes (Failed) 51 - qa_cpp_py_binding_set (Failed) 84 - qa_python_message_passing (Failed) 89 - qa_polar_encoder_systematic (Failed) 92 - qa_polar_encoder (Failed) 94 - qa_polar_decoder_sc (Failed) 95 - qa_polar_decoder_sc_list (Failed) 98 - qa_polar_decoder_sc_systematic (Failed) 218 - qa_zeromq_sub (Failed) 219 - qa_zeromq_pub (Failed) Errors while running CTest Makefile:72: recipe for target 'test' failed make: *** [test] Error 8 For the complete make test: https://pastebin.com/JwHqDGrc ctest -V -R ctrlport_probes UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl Test project /usr/local/src/gnuradio_latest/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 22 Start 22: qa_ctrlport_probes 22: Test command: /usr/bin/sh "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_ctrlport_probes_test.sh" 22: Test timeout computed to be: 9.99988e+06 22: gr::log :INFO: controlport - Apache Thrift: -h linux-0u81 -p 42407 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored ^C^C ctest -V -R cpp_py UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl Test project /usr/local/src/gnuradio_latest/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 18 Start 18: qa_cpp_py_binding 18: Test command: /usr/bin/sh "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_cpp_py_binding_test.sh" 18: Test timeout computed to be: 9.99988e+06 18: gr::log :INFO: controlport - Apache Thrift: -h linux-0u81 -p 41848 18: Could not connect to Co
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
I have ZMQ. Here is the cmake finding it: -- Configuring gr-wxgui support... -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Dependency ENABLE_PYTHON = ON -- Dependency NUMPY_FOUND = TRUE -- Dependency WX_FOUND = TRUE -- Enabling gr-wxgui support. -- Override with -DENABLE_GR_WXGUI=ON/OFF -- Checking for module 'libzmq' -- Found libzmq, version 4.1.2 -- Found ZEROMQ: /usr/lib64/libzmq.so I also have scipy, though I don't see it being looked for in the cmake. I missed this one, but I also have libcodec2. -- Configuring gr-vocoder support... -- Dependency Boost_FOUND = 1 -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_BLOCKS = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency ENABLE_GR_ANALOG = ON -- Enabling gr-vocoder support. -- Override with -DENABLE_GR_VOCODER=ON/OFF -- Found libgsm: /usr/include/gsm, /usr/lib64/libgsm.so -- System libcodec2 not found. -- Checking for module 'libusb-1.0' -- Found libusb-1.0, version 1.0.20 -- Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so On Sat, 29 Apr 2017 12:05:30 -0700 Ron Economos wrote: > For the polar encoder/decoder and zeromq tests, you need the > following dependencies. I'm not sure about the other failures. > > python-scipy > > python-zmq > > Ron > > On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: > > Opensuse 42.2 > > uname -a > > Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC > > 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux > > --- > > Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git > > Entire cmake output at: > > https://pastebin.com/Gqa32538 > > -- > > Errors in the doxygen build: > > https://pastebin.com/2KVp6v9X > > > > > > 95% tests passed, 11 tests failed out of 220 > > > > Total Test time (real) = 3850.12 sec > > > > The following tests FAILED: > > 18 - qa_cpp_py_binding (Failed) > > 22 - qa_ctrlport_probes (Failed) > > 51 - qa_cpp_py_binding_set (Failed) > > 84 - qa_python_message_passing (Failed) > > 89 - qa_polar_encoder_systematic (Failed) > > 92 - qa_polar_encoder (Failed) > > 94 - qa_polar_decoder_sc (Failed) > > 95 - qa_polar_decoder_sc_list (Failed) > > 98 - qa_polar_decoder_sc_systematic (Failed) > > 218 - qa_zeromq_sub (Failed) > > 219 - qa_zeromq_pub (Failed) > > Errors while running CTest > > Makefile:72: recipe for target 'test' failed > > make: *** [test] Error 8 > > > > For the complete make test: > > https://pastebin.com/JwHqDGrc > > > > > > ctest -V -R ctrlport_probes > > UpdateCTestConfiguration > > from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl > > UpdateCTestConfiguration > > from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl > > Test project /usr/local/src/gnuradio_latest/gnuradio/build > > Constructing a list of tests > > Done constructing a list of tests > > Checking test dependency graph... > > Checking test dependency graph end > > test 22 > > Start 22: qa_ctrlport_probes > > > > 22: Test command: /usr/bin/sh > > "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_ctrlport_probes_test.sh" > > 22: Test timeout computed to be: 9.99988e+06 > > 22: gr::log :INFO: controlport - Apache Thrift: -h linux-0u81 -p > > 42407 22: Could not connect to ControlPort endpoint at > > linux-0u81:42407. 22: > > 22: Exception socket.error: (32, 'Broken pipe') in > ThriftRadioClient.__del__ of > > > at > > 0x7f046ca06200>> ignored > > 22: Could not connect to ControlPort endpoint at linux-0u81:42407. > > 22: > > 22: Exception socket.error: (32, 'Broken pipe') in > ThriftRadioClient.__del__ of > > > at > > 0x7f046ca117e8>> ignored > > 22: Could not connect to ControlPort endpoint at linux-0u81:42407. > > 22: > > 22: Exception socket.error: (32, 'Broken pipe') in > ThriftRadioClient.__del__ of > > > at > > 0x7f046ca11b48>> ignored > > 22: Could not connect to ControlPort endpoint at linux-0u81:42407. > > 22: > > 22: Exception socket.error: (32, 'Broken pipe') in > ThriftRadioClient.__del__ of > > > at > > 0x7f046ca11e60>> ignored > > ^C^C > > > > ctest -V -R cpp_py > > UpdateCTestConfiguration > > from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl > > UpdateCTestConfiguration > > from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl > > Test project /usr/local/src/gnuradio_latest/gnuradio/build > > Constructing a list of tests > > Done constructing a list of tests > > Checking test dependency graph... > > Checking test dependency graph end > > test 18 > > Start 18: qa_cpp_py_binding
Re: [Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
For the polar encoder/decoder and zeromq tests, you need the following dependencies. I'm not sure about the other failures. python-scipy python-zmq Ron On 04/29/2017 11:31 AM, li...@lazygranch.com wrote: Opensuse 42.2 uname -a Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux --- Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git Entire cmake output at: https://pastebin.com/Gqa32538 -- Errors in the doxygen build: https://pastebin.com/2KVp6v9X 95% tests passed, 11 tests failed out of 220 Total Test time (real) = 3850.12 sec The following tests FAILED: 18 - qa_cpp_py_binding (Failed) 22 - qa_ctrlport_probes (Failed) 51 - qa_cpp_py_binding_set (Failed) 84 - qa_python_message_passing (Failed) 89 - qa_polar_encoder_systematic (Failed) 92 - qa_polar_encoder (Failed) 94 - qa_polar_decoder_sc (Failed) 95 - qa_polar_decoder_sc_list (Failed) 98 - qa_polar_decoder_sc_systematic (Failed) 218 - qa_zeromq_sub (Failed) 219 - qa_zeromq_pub (Failed) Errors while running CTest Makefile:72: recipe for target 'test' failed make: *** [test] Error 8 For the complete make test: https://pastebin.com/JwHqDGrc ctest -V -R ctrlport_probes UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl Test project /usr/local/src/gnuradio_latest/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 22 Start 22: qa_ctrlport_probes 22: Test command: /usr/bin/sh "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_ctrlport_probes_test.sh" 22: Test timeout computed to be: 9.99988e+06 22: gr::log :INFO: controlport - Apache Thrift: -h linux-0u81 -p 42407 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored ^C^C ctest -V -R cpp_py UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl Test project /usr/local/src/gnuradio_latest/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 18 Start 18: qa_cpp_py_binding 18: Test command: /usr/bin/sh "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_cpp_py_binding_test.sh" 18: Test timeout computed to be: 9.99988e+06 18: gr::log :INFO: controlport - Apache Thrift: -h linux-0u81 -p 41848 18: Could not connect to ControlPort endpoint at linux-0u81:41848. 18: 18: Exception socket.error: (32, 'Broken pipe') in > ignored ^C^C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test and build errors on 3.7.12git-101-g098dc3e0
Opensuse 42.2 uname -a Linux linux-0u81 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC 2017 (39c8557) x86_64 x86_64 x86_64 GNU/Linux --- Building for version: 3.7.12git-101-g098dc3e0 / 3.7.12git Entire cmake output at: https://pastebin.com/Gqa32538 -- Errors in the doxygen build: https://pastebin.com/2KVp6v9X 95% tests passed, 11 tests failed out of 220 Total Test time (real) = 3850.12 sec The following tests FAILED: 18 - qa_cpp_py_binding (Failed) 22 - qa_ctrlport_probes (Failed) 51 - qa_cpp_py_binding_set (Failed) 84 - qa_python_message_passing (Failed) 89 - qa_polar_encoder_systematic (Failed) 92 - qa_polar_encoder (Failed) 94 - qa_polar_decoder_sc (Failed) 95 - qa_polar_decoder_sc_list (Failed) 98 - qa_polar_decoder_sc_systematic (Failed) 218 - qa_zeromq_sub (Failed) 219 - qa_zeromq_pub (Failed) Errors while running CTest Makefile:72: recipe for target 'test' failed make: *** [test] Error 8 For the complete make test: https://pastebin.com/JwHqDGrc ctest -V -R ctrlport_probes UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl Test project /usr/local/src/gnuradio_latest/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 22 Start 22: qa_ctrlport_probes 22: Test command: /usr/bin/sh "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_ctrlport_probes_test.sh" 22: Test timeout computed to be: 9.99988e+06 22: gr::log :INFO: controlport - Apache Thrift: -h linux-0u81 -p 42407 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored 22: Could not connect to ControlPort endpoint at linux-0u81:42407. 22: 22: Exception socket.error: (32, 'Broken pipe') in > ignored ^C^C ctest -V -R cpp_py UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/usr/local/src/gnuradio_latest/gnuradio/build/DartConfiguration.tcl Test project /usr/local/src/gnuradio_latest/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 18 Start 18: qa_cpp_py_binding 18: Test command: /usr/bin/sh "/usr/local/src/gnuradio_latest/gnuradio/build/gr-blocks/python/blocks/qa_cpp_py_binding_test.sh" 18: Test timeout computed to be: 9.99988e+06 18: gr::log :INFO: controlport - Apache Thrift: -h linux-0u81 -p 41848 18: Could not connect to ControlPort endpoint at linux-0u81:41848. 18: 18: Exception socket.error: (32, 'Broken pipe') in > ignored ^C^C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test
It looks like this was a gnu.org mail server problem. And it appears as though at least most of the messages were just delayed in getting out and not actually lost. Tom On Thu, Apr 24, 2014 at 11:25 PM, Robert Ghilduta wrote: > Yea there's definitely something weird happening, the previous message I > received was at 6:05 PM PST. And I got this one at 8:23 PM PST. > > Rob > On Apr 24, 2014 8:22 PM, "Tom Rondeau" wrote: > >> Testing mail server. Seems server wide problem. >> >> Tom >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test
Yea there's definitely something weird happening, the previous message I received was at 6:05 PM PST. And I got this one at 8:23 PM PST. Rob On Apr 24, 2014 8:22 PM, "Tom Rondeau" wrote: > Testing mail server. Seems server wide problem. > > Tom > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test
Testing mail server. Seems server wide problem. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test Branch for OSX Audio Sink Changes
I've created a branch for folks to try out with changes to the gr-audio-osx
code, the sink only for now. Hopefully this branch addresses GR issue #623 <
http://gnuradio.org/redmine/issues/623 > for the sink (I'm working on the
source separately; it's more involved not just for this bug but overall).
< https://github.com/michaelld/gnuradio/tree/fix_gr_audio_osx_sink >
My commit (7571ef40) entry reads as follows:
{{{
Fix OSX Audio Sink:
+ remove extra instantiation arguments;
+ search for and use the device name, if found;
+ if the device name is not found, print out a list of known device names and
use the default audio output device;
+ dynamically handle the number of output channels, depending on graph topology;
+ various whitespace and comment changes;
+ various CamelCase to lower_case changes;
+ WIP: when using the default output device, set up a listener, which will
(eventually) tear down and bring back up audio output to match the new output
device.
}}}
On my Mac, I have just 1 audio output device: "Built-in Output". I can select
this device when running a audio sink (e.g., dial_tone.py -O "Built-in
Output"), but that's sort of silly since there's just 1 device from which to do
selection. I've ordered a couple rtl-sdr hardware devices which should provide
another option, but until they get here there's not much more I can do to test
out this branch. The audio output works just as before, with whatever sample
rate I throw at it. I have not tried start / stop, but they should now work
correctly too & I will test this sooner or later.
I'm hoping other OSX users can help me out here, by building and installing
this branch and testing the audio output capabilities.
I'll now move on to working on the audio source, and post another email like
this once it's done.
Thanks! - MLD
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test correlate and sync block
On Mon, Dec 16, 2013 at 11:21 AM, bob wole wrote: > I installed a fresh verison of gnuradio 3.7.2.1 and was testing some of the > new features including the "correlate and sync"- A must from burst modems. I > am using the "test_corr_and_sync.grc" example. Constellation and rest of the > output looks fine. However, when I plot the "phase" output of "polyphase > clock sync" its look like during burst time phase does not get lock. Phase > output just keep on changing, please see the attached picture of phase > output. Well, real performance test should include a packet encoder and > decoder etc to evaluate BER. But before trying that I thought I should try > the example that comes with gnuradio, is the phase outputlooks ok? > > -- > Bob Yeah, that actually looks fine to me. It definitely wiggles around a few states of phase due to the step size response to the error function. You can possibly turn down the loop bandwidth of this block to see it reduced even farther. With the initial hint of from the correlate_and_sync block, it might still converge fast enough to be useful. And don't get confused by those spikes. That's just wrapping from filter 0 to filter 31 and back; those are only different by 2pi/32 radians. Then again, I could be wrong and someone might be able to provide a patch that helps this converge even more. What I have done with this instead of a full-on packet encoder/decoder (which I agree would be useful) is just plot the received bits and appropriately-delayed input bits against each other (or subtracting one stream from another) to see that they match. With real hardware in the loop, the delays change and I wasn't doing anything so clever as correlating to find the offset; I would just tune the delay by hand. The intent was not to get a real BER but to make sure that it wasn't completely misbehaving. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test correlate and sync block
I installed a fresh verison of gnuradio 3.7.2.1 and was testing some of the new features including the "correlate and sync"- A must from burst modems. I am using the "test_corr_and_sync.grc" example. Constellation and rest of the output looks fine. However, when I plot the "phase" output of "polyphase clock sync" its look like during burst time phase does not get lock. Phase output just keep on changing, please see the attached picture of phase output. Well, real performance test should include a packet encoder and decoder etc to evaluate BER. But before trying that I thought I should try the example that comes with gnuradio, is the phase outputlooks ok? -- Bob <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test Results on gnuradio-3.6.5 & exe extensions
On Mon, Jun 3, 2013 at 2:51 AM, Josh Blum wrote: > > > 200: import scipy > > 200: ImportError: No module named scipy > > 1/1 Test #200: qa_ofdm_txrx .***Failed0.42 sec > > > > Wouldnt worry about it. I wonder if scipy is an intentional dependency > for the QA test though? > This has been fixed--it was a stray import line. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test Results on gnuradio-3.6.5 & exe extensions
> 200: import scipy > 200: ImportError: No module named scipy > 1/1 Test #200: qa_ofdm_txrx .***Failed0.42 sec > Wouldnt worry about it. I wonder if scipy is an intentional dependency for the QA test though? > 0% tests passed, 1 tests failed out of 1 > > Total Test time (real) = 0.49 sec > > The following tests FAILED: > 200 - qa_ofdm_txrx (Failed) > Errors while running CTest > UNQUOTE > > Regarding exe extensions, i am seeing them only with python examples in > gr_xxx folders(such as graudio, gr-digital etc.) and not with other binary > executables in other folders. Window showing the files even display colour > icons. They are marked program and when i try open them with click, it > tires to open with archive manager and fails to open. > > Here is the line that makes that extension. At least on some windows installs, the default behaviour is to open with the python interpreter: http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/GrPython.cmake#n207 -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test Results on gnuradio-3.6.5 & exe extensions
Test Results: QUOTE vsrks@vsrks-HP-Compaq-nx6115-EX728PA-ACJ:~/gnuradio$ ctest -V -R udp_source UpdateCTestConfiguration from :/home/vsrks/gnuradio/DartConfiguration.tcl UpdateCTestConfiguration from :/home/vsrks/gnuradio/DartConfiguration.tcl Test project /home/vsrks/gnuradio Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 127 Start 127: qa_udp_source_sink 127: Test command: /bin/sh "/home/vsrks/gnuradio/gr-blocks/python/qa_udp_source_sink_test.sh" 127: Test timeout computed to be: 9.99988e+06 127: ... 127: -- 127: Ran 3 tests in 2.022s 127: 127: OK 1/1 Test #127: qa_udp_source_sink ... Passed9.26 sec The following tests passed: qa_udp_source_sink 100% tests passed, 0 tests failed out of 1 Total Test time (real) = 10.70 sec vsrks@vsrks-HP-Compaq-nx6115-EX728PA-ACJ:~/gnuradio$ ctest -V -R ofdm_txrx UpdateCTestConfiguration from :/home/vsrks/gnuradio/DartConfiguration.tcl UpdateCTestConfiguration from :/home/vsrks/gnuradio/DartConfiguration.tcl Test project /home/vsrks/gnuradio Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 200 Start 200: qa_ofdm_txrx 200: Test command: /bin/sh "/home/vsrks/gnuradio/gr-digital/python/qa_ofdm_txrx_test.sh" 200: Test timeout computed to be: 9.99988e+06 200: Traceback (most recent call last): 200: File "/home/vsrks/gnuradio-3.6.5/gr-digital/python/qa_ofdm_txrx.py", line 24, in 200: import scipy 200: ImportError: No module named scipy 1/1 Test #200: qa_ofdm_txrx .***Failed0.42 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.49 sec The following tests FAILED: 200 - qa_ofdm_txrx (Failed) Errors while running CTest UNQUOTE Regarding exe extensions, i am seeing them only with python examples in gr_xxx folders(such as graudio, gr-digital etc.) and not with other binary executables in other folders. Window showing the files even display colour icons. They are marked program and when i try open them with click, it tires to open with archive manager and fails to open. -- vsrk sarma ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test Results on gnuradio-3.6.5 & exe extensions
On Sun, Jun 02, 2013 at 11:52:51AM +0530, vsrk sarma wrote: > I just built and installed gnuradio-3.6.5 on HP-Compaq nx-5115 with Ubuntu > 13.04. > > Following two tests failed out of 239: qa_udp_source_sink and qa_ofdm_txtrx Can you please send the output of $ ctest -V -R udp_source and $ ctest -V -R ofdm_txrx > Errors while running Ctest: Error 8 > > Are test failures because as I have no hardware connected? No. > I set -DCMAKE_INSTALL_PREFIX=$HOME/gnuradio Make sure you're PATHs are all correct if you do that. > Another strange observation is that all .py files in various examples folders > have exe extensions,( e.g. dial_tone.py.exe). Is there an abnormality? I'm not entirely sure if you're being serious, but just in case: That's normal. I doubt that any binary on your system has such an extension, given you're on Ubuntu. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpzgUWAzjKao.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test Results on gnuradio-3.6.5 & exe extensions
I just built and installed gnuradio-3.6.5 on HP-Compaq nx-5115 with Ubuntu 13.04. Following two tests failed out of 239: qa_udp_source_sink and qa_ofdm_txtrx Errors while running Ctest: Error 8 Are test failures because as I have no hardware connected? I set -DCMAKE_INSTALL_PREFIX=$HOME/gnuradio Another strange observation is that all .py files in various examples folders have exe extensions,( e.g. dial_tone.py.exe). Is there an abnormality? -- vsrk sarma ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test runs twice
On Tue, Feb 26, 2013 at 7:17 AM, Nemanja Savic wrote: > Hi GNURADIOers, > > I wanted to tell you that test for my block runs twice. > Namely, I designed block based on tagged_file_sink, which is able to store > some > additional samples before true tag. > I designed also test, but when I run it, it simply executes twice. > > at the bottom of my qa file you can find this: > > self.tb.run () > print "\nAfter run!\n" > result_data = (0, 1, 1, 0, 0, 1, 1) > expected_result = (0, 1, 1, 0, 0, 1, 1) > self.assertEqual (expected_result, result_data, 6) > > and I am able to see in terminal twice "After run", and there are also two > files produced by the block itself. > > I discovered that at very end of my qa file, there is: > > if __name__ == '__main__': > gr_unittest.run(qa_file_sink_history, "qa_file_sink_history.xml") > > but in some older test one can find this: > > if __name__ == '__main__': > gr_unittest.main () > > When change first one with the second one, test executes once as it should > be. > Can anybody explain me this behaviour? > > Best > > -- > Nemanja Savić It has to do with how we run the test in the gr_unittest.py suite. Specifically, if you give it an XML file to save the results, it has to run the test twice: once to output to the XML file and once to output to the screen for feedback. If you don't provide the XML file to output to, it will only run the test once. Their is actually a FIXME in the gr_unittest.py file about this. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test runs twice
Hi GNURADIOers, I wanted to tell you that test for my block runs twice. Namely, I designed block based on tagged_file_sink, which is able to store some additional samples before true tag. I designed also test, but when I run it, it simply executes twice. at the bottom of my qa file you can find this: self.tb.run () print "\nAfter run!\n" result_data = (0, 1, 1, 0, 0, 1, 1) expected_result = (0, 1, 1, 0, 0, 1, 1) self.assertEqual (expected_result, result_data, 6) and I am able to see in terminal twice "After run", and there are also two files produced by the block itself. I discovered that at very end of my qa file, there is: if __name__ == '__main__': gr_unittest.run(qa_file_sink_history, "qa_file_sink_history.xml") but in some older test one can find this: if __name__ == '__main__': gr_unittest.main () When change first one with the second one, test executes once as it should be. Can anybody explain me this behaviour? Best -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test
Pong! Cheers, Ben On Thu, Oct 27, 2011 at 4:07 PM, Tom Rondeau wrote: > Ping... > > Tom > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test
Ping... Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test-bed application: how to control GUI app and gr_vector_source
On 11/11/2010 03:46 PM, Tom Rondeau wrote:
On Wed, Nov 10, 2010 at 12:52 PM, Andis Dembovskis
wrote:
Hello, dear GNU-Radio community,
Some last weeks I am coping with how to run and reconfigure gr.top_block on
the fly, didn't manage, so I thought, maybe someone out there could give me
some hint.
I am writing an application which is expected to send different test signal
through USRP2 - to test some other embedded receivers. So I need to
reconfigure top_block an different parameters on the fly.
I can do the nonGUI case, its OK. I just use wait() to identify when vector
with test data is empty, to generate a new one and restart the flowgraph.
But I can't wrap around how to involve the wxPython GUI - after starting
MainLoop() I've no control any more on the top_block.
What is needed:
1) during software run, change gr.vector_source data (get some notification,
when its empty, then fill with new test-case-data, start again)
2) on each test-case, be able to adjust frequency, and gain of USRP2
3) give some graphical output of signal, for example, FFT.
Q1)Is there some callback, when vector is empty (I didn't find one) or
flowgraph is stopped due finished-data-stream? Or at least parameter? (the
gr_vector_source.detail().done() just rises an error)
Q2)Is there some callback from MainLoop() which "usually" is used?
Q3)does it in general make sense to reconfigure and readjust flowgraph
"fluently" or it is recommended some sleep time inbetween. Like, maybe, the
gain of USRP2 just impossible to switch from 0 to 35 within 1ms. Or
notification done() can be issued between data samples are really sent out
by USRP, thus changing frequency at that time would be wrong.
I also tried to start the grc_wxgui.top_block_gui in new thread and after
run() tried to adjust parameters, without efforts. Also MainLoop() in
different thread, no luck.
Here down some very basic sample - if somebody can give hint to attach Scope
to it, I would appreciate it a lot.
Best regards from Bremen,
diehortusxana
==
#!/usr/bin/env python
from gnuradio import audio
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from optparse import OptionParser
import time
import math
class my_basic_tb(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.samp_rate = samp_rate = 32000
self.audio_sink_0 = audio.sink(48000, "", True)
self.gr_vector_source_x_0 = gr.vector_source_f(gen_freq(41,1), False, 1)
self.connect((self.gr_vector_source_x_0, 0), (self.audio_sink_0, 0))
def gen_freq(freq,len_s):
nv = []
for i in range(1,48000*len_s):
if math.fmod(i,freq) == 0:
nv.append(1)
else:
nv.append(0)
return nv
if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tb = my_basic_tb()
tb.start()
tb.wait()
print("done_part_1")
tb.lock()
tb.disconnect(tb.gr_vector_source_x_0)
tb.gr_vector_source_x_0 = gr.vector_source_f(gen_freq(11,1), False, 1)
tb.connect((tb.gr_vector_source_x_0, 0), (tb.audio_sink_0, 0))
tb.unlock()
tb.start()
print("reconfigured")
tb.wait()
print("Done")
===
Instead of disconnecting the source, rebuilding it, and reconnecting
it, try to use the rewind() function on the source.
Also, yes, you'll want to put in some pause time when you update the
frequency/gain of the USRP.
Tom
Hello everybody, I found solution to the problem stated above, so I
share it with everybody - so people like me, searching to make
testing-purpose applications, could find the answer here.
There are 2 main points to care about:
1) the top_block was wrapped in grc_wxgui.top_block_gui [to get wx GUI]
and that again in Thread [to be able call Run() and have return of execution
2) the vector and Scope are reconnected [the just "rewind() + unlock() +
start()" doesn't start the flowgraph with new values. If scope isn't
reattached, it doesn't update its GUI (just freezes for a while and
shows end-state)
And thanks to Tom for the notes. I put some pause now inside :)
If someone knows another way how the same target could be achieved in
better way, please post here.
Enjoy :)
=
#!/usr/bin/env python
from gnuradio import audio
from gnuradio import gr
import time
import math
from gnuradio.wxgui import scopesink2
from grc_gnuradio import wxgui as grc_wxgui
from threading import Thread
class my_basic_tb_gui(grc_wxgui.top_block_gui):
def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title="my_basic_tb_gui")
self.samp_rate = samp_rate = 32000
self.audio_sink_0 = audio.sink(48000, "", True)
self.gr_vector_source_x_0 = gr.vector_source_f(gen_freq(41,2),
False, 1)
self.wxgui_scopesink2_0 = scopesink2.scope_sink_f(
self.GetWin(),
title="Scope Plot",
sample_rate=samp_rate,
v_s
Re: [Discuss-gnuradio] Test-bed application: how to control GUI app and gr_vector_source
On Wed, Nov 10, 2010 at 12:52 PM, Andis Dembovskis
wrote:
> Hello, dear GNU-Radio community,
> Some last weeks I am coping with how to run and reconfigure gr.top_block on
> the fly, didn't manage, so I thought, maybe someone out there could give me
> some hint.
>
> I am writing an application which is expected to send different test signal
> through USRP2 - to test some other embedded receivers. So I need to
> reconfigure top_block an different parameters on the fly.
> I can do the nonGUI case, its OK. I just use wait() to identify when vector
> with test data is empty, to generate a new one and restart the flowgraph.
> But I can't wrap around how to involve the wxPython GUI - after starting
> MainLoop() I've no control any more on the top_block.
> What is needed:
> 1) during software run, change gr.vector_source data (get some notification,
> when its empty, then fill with new test-case-data, start again)
> 2) on each test-case, be able to adjust frequency, and gain of USRP2
> 3) give some graphical output of signal, for example, FFT.
>
> Q1)Is there some callback, when vector is empty (I didn't find one) or
> flowgraph is stopped due finished-data-stream? Or at least parameter? (the
> gr_vector_source.detail().done() just rises an error)
> Q2)Is there some callback from MainLoop() which "usually" is used?
> Q3)does it in general make sense to reconfigure and readjust flowgraph
> "fluently" or it is recommended some sleep time inbetween. Like, maybe, the
> gain of USRP2 just impossible to switch from 0 to 35 within 1ms. Or
> notification done() can be issued between data samples are really sent out
> by USRP, thus changing frequency at that time would be wrong.
>
> I also tried to start the grc_wxgui.top_block_gui in new thread and after
> run() tried to adjust parameters, without efforts. Also MainLoop() in
> different thread, no luck.
>
> Here down some very basic sample - if somebody can give hint to attach Scope
> to it, I would appreciate it a lot.
>
> Best regards from Bremen,
> diehortusxana
>
> ==
> #!/usr/bin/env python
>
> from gnuradio import audio
> from gnuradio import eng_notation
> from gnuradio import gr
> from gnuradio.eng_option import eng_option
> from gnuradio.gr import firdes
> from optparse import OptionParser
> import time
> import math
>
> class my_basic_tb(gr.top_block):
> def __init__(self):
> gr.top_block.__init__(self)
> self.samp_rate = samp_rate = 32000
> self.audio_sink_0 = audio.sink(48000, "", True)
> self.gr_vector_source_x_0 = gr.vector_source_f(gen_freq(41,1), False, 1)
> self.connect((self.gr_vector_source_x_0, 0), (self.audio_sink_0, 0))
>
> def gen_freq(freq,len_s):
> nv = []
> for i in range(1,48000*len_s):
> if math.fmod(i,freq) == 0:
> nv.append(1)
> else:
> nv.append(0)
> return nv
>
>
> if __name__ == '__main__':
> parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
> (options, args) = parser.parse_args()
>
> tb = my_basic_tb()
> tb.start()
> tb.wait()
> print("done_part_1")
> tb.lock()
> tb.disconnect(tb.gr_vector_source_x_0)
> tb.gr_vector_source_x_0 = gr.vector_source_f(gen_freq(11,1), False, 1)
> tb.connect((tb.gr_vector_source_x_0, 0), (tb.audio_sink_0, 0))
> tb.unlock()
> tb.start()
> print("reconfigured")
> tb.wait()
>
> print("Done")
> ===
Instead of disconnecting the source, rebuilding it, and reconnecting
it, try to use the rewind() function on the source.
Also, yes, you'll want to put in some pause time when you update the
frequency/gain of the USRP.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test-bed application: how to control GUI app and gr_vector_source
Hello, dear GNU-Radio community,
Some last weeks I am coping with how to run and reconfigure gr.top_block
on the fly, didn't manage, so I thought, maybe someone out there could
give me some hint.
I am writing an application which is expected to send different test
signal through USRP2 - to test some other embedded receivers. So I need
to reconfigure top_block an different parameters on the fly.
I can do the nonGUI case, its OK. I just use wait() to identify when
vector with test data is empty, to generate a new one and restart the
flowgraph.
But I can't wrap around how to involve the wxPython GUI - after starting
MainLoop() I've no control any more on the top_block.
What is needed:
1) during software run, change gr.vector_source data (get some
notification, when its empty, then fill with new test-case-data, start
again)
2) on each test-case, be able to adjust frequency, and gain of USRP2
3) give some graphical output of signal, for example, FFT.
Q1)Is there some callback, when vector is empty (I didn't find one) or
flowgraph is stopped due finished-data-stream? Or at least parameter?
(the gr_vector_source.detail().done() just rises an error)
Q2)Is there some callback from MainLoop() which "usually" is used?
Q3)does it in general make sense to reconfigure and readjust flowgraph
"fluently" or it is recommended some sleep time inbetween. Like, maybe,
the gain of USRP2 just impossible to switch from 0 to 35 within 1ms. Or
notification done() can be issued between data samples are really sent
out by USRP, thus changing frequency at that time would be wrong.
I also tried to start the grc_wxgui.top_block_gui in new thread and
after run() tried to adjust parameters, without efforts. Also MainLoop()
in different thread, no luck.
Here down some very basic sample - if somebody can give hint to attach
Scope to it, I would appreciate it a lot.
Best regards from Bremen,
diehortusxana
==
#!/usr/bin/env python
from gnuradio import audio
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from optparse import OptionParser
import time
import math
class my_basic_tb(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.samp_rate = samp_rate = 32000
self.audio_sink_0 = audio.sink(48000, "", True)
self.gr_vector_source_x_0 = gr.vector_source_f(gen_freq(41,1),
False, 1)
self.connect((self.gr_vector_source_x_0, 0), (self.audio_sink_0, 0))
def gen_freq(freq,len_s):
nv = []
for i in range(1,48000*len_s):
if math.fmod(i,freq) == 0:
nv.append(1)
else:
nv.append(0)
return nv
if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tb = my_basic_tb()
tb.start()
tb.wait()
print("done_part_1")
tb.lock()
tb.disconnect(tb.gr_vector_source_x_0)
tb.gr_vector_source_x_0 = gr.vector_source_f(gen_freq(11,1), False, 1)
tb.connect((tb.gr_vector_source_x_0, 0), (tb.audio_sink_0, 0))
tb.unlock()
tb.start()
print("reconfigured")
tb.wait()
print("Done")
===
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test
___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test tarballs for 3.3git
On Fri, Jan 22, 2010 at 13:52, Don Ward wrote: > Apart from one or two minor issues, this tarball works fine under Cygwin > 1.7.1 with gcc 3.4.4 Thanks for testing. > but with gcc 4.3.4 make check fails with > > ~/gnuradio-3.3git-594-g02616cf8/gnuradio-core/src/tests> ./test_all.exe > Testing gr_vmcircbuf_createfilemapping_factory... > ... gr_vmcircbuf_createfilemapping_factory: OK > Testing gr_vmcircbuf_sysv_shm_factory... > terminate called after throwing an instance of 'gr_signal' > Aborted (core dumped) > > It appears that a signal is being caught and a gr_signal is being thrown but > not caught. > > This is probably a Cygwin-specific problem with exception handling in gcc > 4.3.4, but if anyone else has seen problems like this and has any insight as > to the cause, I would like to hear about it. The code itself has a try/catch block wrapped around the QA tests, with handlers for anticipated exceptions and a default uncaught exception handler. The fact that exception gr_signal is being thrown is probably correct, but that fact that execution blows out the top of the try/catch block instead of being caught is definitely not correct. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test tarballs for 3.3git
Johnathan Corgan wrote: Test tarball distribution files have been created for the current 3.3git release under development: http://gnuradio.org/releases/gnuradio/gnuradio-3.3git-594-g02616cf8.tar.gz Apart from one or two minor issues, this tarball works fine under Cygwin 1.7.1 with gcc 3.4.4, but with gcc 4.3.4 make check fails with ~/gnuradio-3.3git-594-g02616cf8/gnuradio-core/src/tests> ./test_all.exe Testing gr_vmcircbuf_createfilemapping_factory... ... gr_vmcircbuf_createfilemapping_factory: OK Testing gr_vmcircbuf_sysv_shm_factory... terminate called after throwing an instance of 'gr_signal' Aborted (core dumped) It appears that a signal is being caught and a gr_signal is being thrown but not caught. This is probably a Cygwin-specific problem with exception handling in gcc 4.3.4, but if anyone else has seen problems like this and has any insight as to the cause, I would like to hear about it. Thanks, -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test tarballs for 3.3git
Il 19/01/2010 19:10, Johnathan Corgan ha scritto: On Tue, Jan 19, 2010 at 05:57, Arturo Rinaldi wrote: will these new *.deb binaries be good for updating on ubuntu 9.04 too ? or are they for ubuntu 9.10 specific only? Right now they will be for Ubuntu 9.10. Unfortunately, 9.04 and 9.10 do not ship with a common version of Boost, so I would have to build a separate set of .debs for 9.04. I may do that if I get the time. Johnathan thank you very much. it would be appreciated (i think) not only by myself ;) Bye, Arturo ;) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test tarballs for 3.3git
On Tue, Jan 19, 2010 at 05:57, Arturo Rinaldi wrote: > will these new *.deb binaries be good for updating on ubuntu 9.04 too ? or > are they for ubuntu 9.10 specific only? Right now they will be for Ubuntu 9.10. Unfortunately, 9.04 and 9.10 do not ship with a common version of Boost, so I would have to build a separate set of .debs for 9.04. I may do that if I get the time. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test tarballs for 3.3git
Il 17/01/2010 19:32, Johnathan Corgan ha scritto: Test tarball distribution files have been created for the current 3.3git release under development: http://gnuradio.org/releases/gnuradio/gnuradio-3.3git-594-g02616cf8.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3git-594-g02616cf8.tar.gz These distribution files should compile and install using the same configure, make, make install process as the current 3.2.2 release files do. The purpose of providing these is to test the distribution tarball creation process, which can fail in ways that wouldn't affect building from a repository checkout. The full set of features for 3.3 release is not in them, nor are there release notes. However, the resulting build should be identical to what you would get if you were to build from our current git master. A word on naming--pre-release tarballs will have 3.3git, followed by the number of revisions since the last tag in the repository, followed by the shortened git commit id they are based on. In this case, we put in a 3.3git tag in the repo when we did the conversion from Subversion, so there have been 594 commits along the master branch since then. (This naming is derived from the output of 'git describe'). For USRP2 users, the associated image files for the firmware and FPGA, respectively, are: http://gnuradio.org/releases/usrp2-bin/trunk/txrx_edk10.1_3.3git-594-g02616cf8.bin http://gnuradio.org/releases/usrp2-bin/trunk/u2_rev3_ise10.1sp3_3.3git-594-g02616cf8.bin Remember, this is not a stable release, but a snapshot of our current development for 3.3. If this turns out to be useful (as measured by feedback on the list or the wiki), we may automate this. Finally, pending further testing, binary packages for Ubuntu 9.10 for this version will be created; those tracking 'unstable' in their package manager will get these automatically when they are ready. Thank you, Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio will these new *.deb binaries be good for updating on ubuntu 9.04 too ? or are they for ubuntu 9.10 specific only? thx in advance for the answer Bye ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test tarballs for 3.3git
Test tarball distribution files have been created for the current 3.3git release under development: http://gnuradio.org/releases/gnuradio/gnuradio-3.3git-594-g02616cf8.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3git-594-g02616cf8.tar.gz These distribution files should compile and install using the same configure, make, make install process as the current 3.2.2 release files do. The purpose of providing these is to test the distribution tarball creation process, which can fail in ways that wouldn't affect building from a repository checkout. The full set of features for 3.3 release is not in them, nor are there release notes. However, the resulting build should be identical to what you would get if you were to build from our current git master. A word on naming--pre-release tarballs will have 3.3git, followed by the number of revisions since the last tag in the repository, followed by the shortened git commit id they are based on. In this case, we put in a 3.3git tag in the repo when we did the conversion from Subversion, so there have been 594 commits along the master branch since then. (This naming is derived from the output of 'git describe'). For USRP2 users, the associated image files for the firmware and FPGA, respectively, are: http://gnuradio.org/releases/usrp2-bin/trunk/txrx_edk10.1_3.3git-594-g02616cf8.bin http://gnuradio.org/releases/usrp2-bin/trunk/u2_rev3_ise10.1sp3_3.3git-594-g02616cf8.bin Remember, this is not a stable release, but a snapshot of our current development for 3.3. If this turns out to be useful (as measured by feedback on the list or the wiki), we may automate this. Finally, pending further testing, binary packages for Ubuntu 9.10 for this version will be created; those tracking 'unstable' in their package manager will get these automatically when they are ready. Thank you, Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test that GNU Radio works with the USRP after Installation
Hi, I am new in GNU RAdio. After the GNU Radio installation on my Ubuntu 8.04, when I try to test that GNU Radio works with the USRP I obtain the following: w...@wsn-desktop:~/Escritorio/gnuradio$ ls -lR /dev/bus/usb | grep usrp crw-rw 1 root usrp 189, 642 2009-01-19 19:32 003 w...@wsn-desktop:~/Escritorio/gnuradio$ cd gnuradio-examples/python/usrp w...@wsn-desktop:~/Escritorio/gnuradio/gnuradio-examples/python/usrp$ * ./usrp_benchmark_usb.py* Traceback (most recent call last): File "./usrp_benchmark_usb.py", line 30, in from gnuradio import gr File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py", line 43, in from gnuradio_swig_python import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py", line 23, in from gnuradio_swig_py_runtime import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 6, in import _gnuradio_swig_py_runtime ImportError: libgnuradio-core.so.0: cannot open shared object file: No such file or directory w...@wsn-desktop:~/Escritorio/gnuradio/gnuradio-examples/python/usrp$ cd usrp/host/apps bash: cd: usrp/host/apps: No existe el fichero ó directorio Besides, Before that, when I installed GNU Radio I obtained the following: *The following components were skipped either because you asked not * *to build them or they didn't pass configuration checks: * * * *gcell * *gr-gcell * *gr-audio-jack * *gr-audio-osx * *gr-audio-portaudio * *gr-audio-windows * *gr-comedi * * * *These components will not be built. * Is it correct? Could anyone help me, please? Thanks in advance. José Carlos* * ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test my confirmation
I have joined the mailing list by another email and ask some questions, but I neither received my own email for maillist, nor received reply from others, so I just test this email. Sorry to bother others. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test with message_source
Dan, thanks for the info you provided; it was ver helpful! I think I got the basic understanding of the message_source/sink. I wrote my first toy code based on this: The Tx queues 100 packets and the Rx waits until it receives everything (broken into different number of packets) The Rx does not know when transmission ended but I can check the total # of bytes received and it coincides with that transmitted. I hope I have not missed something big here. I wanted to ask if there is a natural way for the code to exit this kind of loop; so far I am doing it manually with contr-C Thanks Achilleas === #!/usr/bin/env python from gnuradio import gr class my_graph(gr.flow_graph): def __init__(self,rx_queue): gr.flow_graph.__init__(self) Qtx=20 src = gr.message_source(gr.sizeof_char,Qtx) self.tx_queue = src.msgq() dst = gr.message_sink(gr.sizeof_char,rx_queue,False) self.connect (src, dst) if __name__ == '__main__': payload = 'abcdefghijklmnopqrst' Qrx=5 rx_queue = gr.msg_queue(Qrx) fg=my_graph(rx_queue) print 'Starting the graph' fg.start() i=1 j=1 imax=100# max number of packets to Tx tot=0 # counts number of received bytes tx_done = False while True: # process Tx side if not tx_done: msg=gr.message_from_string(payload) fg.tx_queue.insert_tail(msg) print 'Just queued the ',i,' th packet' i+=1 if i>imax: tx_done = True print 'Nothing to do at the Tx' print 'Sending the EOF message' eof_msg=gr.message(1) fg.tx_queue.insert_tail(eof_msg) #process Rx side while not rx_queue.empty_p(): rmsg = rx_queue.delete_head() tot+=rmsg.length() print 'I got mail: ',j,rmsg.type(), rmsg.length(), rmsg.arg1(), rmsg.arg2(), tot j+=1 == ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test with message_source
Anastasopoulos Achilleas wrote: What I don't know how to do is to enqueue a message every time I press a button. Can someone point to the right direction as to how this event driven behavior is implemented. Look in the gnuradio-examples/python/digital/tunnel.py and subfiles. transmit_path.py has a send_pkt function which calls the send_pkt function in pkt.py (in the gnuradio python libraries directory), which converts a string into the proper format and enqueues it into a message queue. When you're done with the queue, and you want to close up, call the send_pkt function with eof = True (enqueues gr.message(1)), which tells the queue that no more input is coming and enables the fg to stop. -Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test with message_source
Hi, I am trying to understand how the message source works and how I can use it from within my python code. So I wrote a simple script with a message source and a null sink. I wanted the following behavior: every time I press a button on my keybord to send a constant message in the queue and verify that the queue size has increased. Here is the piece of code that I have so far... What I don't know how to do is to enqueue a message every time I press a button. Can someone point to the right direction as to how this event driven behavior is implemented. Thanks Achilleas == from gnuradio import gr from gnuradio import audio from gnuradio.eng_option import eng_option from optparse import OptionParser class my_graph(gr.flow_graph): def __init__(self): gr.flow_graph.__init__(self) packet = 'abcdefghijklmnopqrstuwxy' #multiple of gr.sizeof_float msg=gr.message_from_string(packet) src0 = gr.message_source(gr.sizeof_float,10) dst = gr.null_sink (gr.sizeof_float) self.connect (src0, dst) # Now I want every time I press a button to run the following code, # so that I add the same msg in the message queue src0.msgq().insert_tail(msg) print src0.msgq().count() if __name__ == '__main__': try: my_graph().run() except KeyboardInterrupt: pass == ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
This has been fixed in r3697 on the SVN trunk and r3698 in the release-3.0 branch, which will eventually make it into a new 3.0rc2 tarball. Thanks. I just ran 'make distcheck' on a pretty-recent NetBSD system with up-to-date svn and ran into only a few problems (the first two of which aren't new, but I'm listing them to be helpful to anyone else trying this): 1) One needs to give LDFLAGS and CPPFLAGS in the environment; the values from original configure aren't propagated to the configure run as part of distcheck. 2) The test of gr_vmcircbuf_mmap_tmpfile_factory uses vast amount of space in /tmp. My /tmp is on mfs and 64 MB, so it fails. 3) One of the test leaves shm turds, apparently 3 from running make check. Surely this must be gr_vmcircbuf_sysv_shm_factory, but I saw no easy way to run this test separately. 4) Running with TMP=/home/tmp, gr_vmcircbuf_mmap_tmpfile seems to be ok, but then seems to free things incorrectly. I can try a RC tarball when there's a new one. gmake check-TESTS gmake[1]: Entering directory `/home/gdt/ADROIT-public/gnuradio/gnuradio-3.0svn/_build/gnuradio-core/src/tests' test_all in free(): warning: modified (chunk-) pointer. .Testing gr_vmcircbuf_createfilemapping_factory... gr_vmcircbuf_createfilemapping: createfilemapping is not available ... gr_vmcircbuf_createfilemapping_factory: Doesn't work Testing gr_vmcircbuf_sysv_shm_factory... gr_vmcircbuf_sysv_shm: shmget (2): Cannot allocate memory gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument gr_vmcircbuf_sysv_shm: shmget (1): Cannot allocate memory ... gr_vmcircbuf_sysv_shm_factory: Doesn't work Testing gr_vmcircbuf_mmap_shm_open_factory... gr_vmcircbuf_mmap_shm_open: mmap or shm_open is not available ... gr_vmcircbuf_mmap_shm_open_factory: Doesn't work Testing gr_vmcircbuf_mmap_tmpfile_factory... ... gr_vmcircbuf_mmap_tmpfile_factory: OK test_all in free(): warning: junk pointer, too low to make sense. test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: modified (chunk-) pointer. test_all in free(): warning: page is already free. test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: page is already free. test_all in free(): warning: page is already free. [many such lines removed] test_all in free(): warning: page is already free. test_all in free(): warning: page is already free. test_all in free(): warning: page is already free. test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. .test_all in free(): warning: junk pointer, too low to make sense. Memory fault (core dumped) FAIL: test_all === 1 of 1 tests failed === gmake[1]: *** [check-TESTS] Error 1 gmake[1]: Leaving directory `/home/gdt/ADROIT-public/gnuradio/gnuradio-3.0svn/_build/gnuradio-core/src/tests' gmake: *** [check-am] Error 2 > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
gr-video-sdl requires library sdl, not found.
The configure script will say this for any reason the SDL test
fails, so
it should probably say 'not found or failed compilation test' or
something like that to be more accurate.
Not sure if it helps, but here's the relevant output from config.log.
configure:33616: checking for sdl-config
configure:33634: found /opt/local/bin/sdl-config
configure:33647: result: /opt/local/bin/sdl-config
configure:33656: checking for SDL - version >= 1.2.0
configure:33751: gcc -o conftest -g -O2 -Wall -I/opt/local/include/
SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE -L/opt/local/lib conftest.c -L/
opt/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa >&5
configure:33754: $? = 0
configure:33760: ./conftest
kCGErrorRangeCheck : Window Server communications from outside of
session allowed for root and console user only
INIT_Processeses(), could not establish the default connection to the
WindowServer../configure: line 1: 3313 Abort trap ./
conftest$ac_exeext
configure:33763: $? = 134
configure: program exited with status 134
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "gnuradio"
| #define VERSION "3.0rc1"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define HAVE_PYTHON_H 1
| #define OMNITHREAD_POSIX 1
| #define HAVE_GETTIMEOFDAY 1
| #define HAVE_NANOSLEEP 1
| #define HAVE_SYS_IPC_H 1
| #define HAVE_SYS_SHM_H 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_WAIT_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_TIME_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_MMAN_H 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_RESOURCE_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_SCHED_H 1
| #define TIME_WITH_SYS_TIME 1
| #define WORDS_BIGENDIAN 1
| #define HAVE_ALLOCA_H 1
| #define HAVE_ALLOCA 1
| #define PROTOTYPES 1
| #define __PROTOTYPES 1
| #define HAVE_VPRINTF 1
| #define HAVE_MMAP 1
| #define HAVE_SELECT 1
| #define HAVE_SOCKET 1
| #define HAVE_STRCSPN 1
| #define HAVE_STRERROR 1
| #define HAVE_STRSPN 1
| #define HAVE_GETPAGESIZE 1
| #define HAVE_SYSCONF 1
| #define HAVE_SNPRINTF 1
| #define HAVE_GETTIMEOFDAY 1
| #define HAVE_NANOSLEEP 1
| #define HAVE_MODF 1
| #define HAVE_SQRT 1
| #define HAVE_SINF 1
| #define HAVE_COSF 1
| #define HAVE_TRUNC 1
| #define HAVE_SHM_OPEN 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_GETOPT 1
| #define HAVE_USLEEP 1
| #define HAVE_GETTIMEOFDAY 1
| #define HAVE_NANOSLEEP 1
| #define HAVE_RAND 1
| #define HAVE_SRAND 1
| #define HAVE_RANDOM 1
| #define HAVE_SRANDOM 1
| #define HAVE_SLEEP 1
| #define HAVE_SIGACTION 1
| #define HAVE_STRUCT_TIMEZONE 1
| #define HAVE_STRUCT_TIMESPEC 1
| #define HAVE_SSIZE_T 1
| #define HAVE_GETOPT 1
| #define HAVE_USLEEP 1
| #define HAVE_GETTIMEOFDAY 1
| #define HAVE_FCNTL_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DECL_GETENV 1
| #define HAVE_MKSTEMP 1
| #define WORDS_BIGENDIAN 1
| #define HAVE_GETRUSAGE 1
| #define HAVE_SIGACTION 1
| #define HAVE_SNPRINTF 1
| #define HAVE_USB_H 1
| #define HAVE_AUDIOUNIT_AUDIOUNIT_H 1
| #define HAVE_AUDIOTOOLBOX_AUDIOTOOLBOX_H 1
| /* end confdefs.h. */
|
| #include
| #include
| #include
| #include "SDL.h"
|
| char*
| my_strdup (char *str)
| {
| char *new_str;
|
| if (str)
| {
| new_str = (char *)malloc ((strlen (str) + 1) * sizeof(char));
| strcpy (new_str, str);
| }
| else
| new_str = NULL;
|
| return new_str;
| }
|
| int main (int argc, char *argv[])
| {
| int major, minor, micro;
| char *tmp_version;
|
| /* This hangs on some systems (?)
| system ("touch conf.sdltest");
| */
| { FILE *fp = fopen("conf.sdltest", "a"); if ( fp ) fclose(fp); }
|
| /* HP/UX 9 ([EMAIL PROTECTED]) writes to sscanf strings */
| tmp_version = my_strdup("1.2.0");
| if (sscanf(tmp_version, "%d.%d.%d", &major, &minor, µ) != 3) {
| printf("%s, bad version string\n", "1.2.0");
| exit(1);
|}
|
|if ((1 > major) ||
| ((1 == major) && (2 > minor)) ||
| ((1 == major) && (2 == minor) && (11 >= micro)))
| {
| return 0;
| }
| else
| {
| printf("\n*** 'sdl-config --version' returned %d.%d.%d, but
the minimum version\n", 1, 2, 11);
| printf("*** of SDL required is %d.%d.%d. If sdl-config is
correct, then it is\n", major, minor, micro);
| printf("*** best to upgrade to the required version.\n");
| printf("*** If sdl-config was wrong, set the environment
variable SDL_CONFIG\n");
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
Johnathan Corgan wrote: > Can you send me your ./configure file? I seem to recall this came up in > a different place in the past and we fixed it. Um, never mind. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
Michael Dickens wrote:
> This is for 3.0rc1, trying to compile under OSX 10.4.7 and 10.4.8 on
> both PPC and Intel Macs. Everything basically configures (except see
> below), makes ("make" and "make -j3"), installs, and distchecks. I will
> try actually running (3.0rc2) tomorrow on a known-working OSX PPC (dual
> G5). - MLD
Thanks.
> checking for machine dependent speedups... generic
> ../configure: line 28595: test: =: unary operator expected
Can you send me your ./configure file? I seem to recall this came up in
a different place in the past and we fixed it.
> gr-video-sdl requires library sdl, not found.
The configure script will say this for any reason the SDL test fails, so
it should probably say 'not found or failed compilation test' or
something like that to be more accurate.
Johnathan Corgan, AE6HO
[EMAIL PROTECTED]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
This is for 3.0rc1, trying to compile under OSX 10.4.7 and 10.4.8 on
both PPC and Intel Macs. Everything basically configures (except see
below), makes ("make" and "make -j3"), installs, and distchecks. I
will try actually running (3.0rc2) tomorrow on a known-working OSX
PPC (dual G5). - MLD
In configure:
(1) The "machine dependent speedups" looks like it has a testing bug;
this doesn't break things, but it does output a warning:
checking for machine dependent speedups... generic
../configure: line 28595: test: =: unary operator expected
checking for cppunit-config... /opt/local/bin/cppunit-config
(2) Checking for sdl doesn't work on any of these Macs ---when done
via a remote login---; it requires an X11 display, which no matter
how hard I try I can't get to work reliably even using "ssh -X" etc;
it does work when done by the current "console" user on any X11 xterm.
checking for sdl-config... /opt/local/bin/sdl-config
checking for SDL - version >= 1.2.0... no
*** Could not run SDL test program, checking why...
*** The test program compiled, but did not run. This usually means
*** that the run-time linker is not finding SDL or finding the wrong
*** version of SDL. If it is not finding SDL, you'll need to set your
*** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to
point
*** to the installed location Also, make sure you have run ldconfig
if that
*** is required on your system
***
*** If you have an old version installed, it is best to remove it,
although
*** you may also be able to get things to work by modifying
LD_LIBRARY_PATH
gr-video-sdl requires library sdl, not found.
% sdl-config --version
1.2.11
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
Greg Troxel wrote: > The problem is that fusb_ra_wb.h isn't listed in noinst_HEADERS. I > suppose make distcheck would catch this in svn if run on recent-enough > NetBSD. I'll run that tomorrow. This has been fixed in r3697 on the SVN trunk and r3698 in the release-3.0 branch, which will eventually make it into a new 3.0rc2 tarball. Johnathan Corgan, AE6HO [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
On Tue, Oct 03, 2006 at 03:59:47PM -0400, Greg Troxel wrote: > > The problem is that fusb_ra_wb.h isn't listed in noinst_HEADERS. I > suppose make distcheck would catch this in svn if run on recent-enough > NetBSD. I'll run that tomorrow. > > Greg Troxel <[EMAIL PROTECTED]> Could also have been caught using the check-tarball-h-files script contained in dtools/bin. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
On Tue, Oct 03, 2006 at 12:47:05PM -0400, Tom Rondeau wrote: > I haven't tried the tarball, but checking the latest trunk from SVN worked > fine. I've only played with the digital modulation portions so far, but no > problem with the install or operation of anything I've used after a make > distclean. > > Tom Thanks. However, we're *really* looking for feedback on the tarball. If we don't hear any, we'll assume that everything is OK, which it might not be ;) Please let us know now, *before* we make the official 3.0 release. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
The problem is that fusb_ra_wb.h isn't listed in noinst_HEADERS. I suppose make distcheck would catch this in svn if run on recent-enough NetBSD. I'll run that tomorrow. -- Greg Troxel <[EMAIL PROTECTED]> pgpi0LhZeghE5.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
3.0rc1 fails on NetBSD due to missing fusb_ra_wb.h: Hmm, I'll try it myself. But a fresh checkout of svn head has the file. Does your working area look like this? fnord gdt 7 ~/ADROIT-public/gnuradio/usrp/host/lib > l total 320 -rw-r--r-- 1 gdt ir 3370 Oct 3 15:36 Makefile.am -rw-r--r-- 1 gdt ir 2539 Oct 3 15:36 README_OSX -rw-r--r-- 1 gdt ir 6269 Oct 3 15:36 ad9862.h -rwxr-xr-x 1 gdt ir 1448 Oct 3 15:36 check_data.py -rw-r--r-- 1 gdt ir 8988 Oct 3 15:36 circular_buffer.h -rw-r--r-- 1 gdt ir 7611 Oct 3 15:36 circular_linked_list.h -rw-r--r-- 1 gdt ir 5834 Oct 3 15:36 darwin_libusb.h -rwxr-xr-x 1 gdt ir 1060 Oct 3 15:36 dump_data.py -rw-r--r-- 1 gdt ir 3251 Oct 3 15:36 dxc-io-assignments.gnumeric -rw-r--r-- 1 gdt ir 1673 Oct 3 15:36 fusb.cc -rw-r--r-- 1 gdt ir 3275 Oct 3 15:36 fusb.h -rw-r--r-- 1 gdt ir 14100 Oct 3 15:36 fusb_darwin.cc -rw-r--r-- 1 gdt ir 5685 Oct 3 15:36 fusb_darwin.h -rw-r--r-- 1 gdt ir 2544 Oct 3 15:36 fusb_generic.cc -rw-r--r-- 1 gdt ir 2276 Oct 3 15:36 fusb_generic.h -rw-r--r-- 1 gdt ir 16461 Oct 3 15:36 fusb_linux.cc -rw-r--r-- 1 gdt ir 3456 Oct 3 15:36 fusb_linux.h -rw-r--r-- 1 gdt ir 6594 Oct 3 15:36 fusb_ra_wb.cc -rw-r--r-- 1 gdt ir 2279 Oct 3 15:36 fusb_ra_wb.h -rw-r--r-- 1 gdt ir 1262 Oct 3 15:36 fusb_sysconfig_darwin.cc -rw-r--r-- 1 gdt ir 1264 Oct 3 15:36 fusb_sysconfig_generic.cc -rw-r--r-- 1 gdt ir 1259 Oct 3 15:36 fusb_sysconfig_linux.cc -rw-r--r-- 1 gdt ir 1481 Oct 3 15:36 fusb_sysconfig_ra_wb.cc -rw-r--r-- 1 gdt ir 1280 Oct 3 15:36 fusb_sysconfig_win32.cc -rw-r--r-- 1 gdt ir 6087 Oct 3 15:36 fusb_win32.cc -rw-r--r-- 1 gdt ir 2380 Oct 3 15:36 fusb_win32.h -rwxr-xr-x 1 gdt ir 1165 Oct 3 15:36 gen-ratios -rwxr-xr-x 1 gdt ir 3833 Oct 3 15:36 gen_usrp_dbid.py -rw-r--r-- 1 gdt ir 14001 Oct 3 15:36 md5.c -rw-r--r-- 1 gdt ir 4701 Oct 3 15:36 md5.h -rw-r--r-- 1 gdt ir 6311 Oct 3 15:36 mld_threads.h -rw-r--r-- 1 gdt ir 1648 Oct 3 15:36 rate_to_regval.h -rw-r--r-- 1 gdt ir914 Oct 3 15:36 std_paths.h.in -rw-r--r-- 1 gdt ir 31014 Oct 3 15:36 usrp_basic.cc -rw-r--r-- 1 gdt ir 24323 Oct 3 15:36 usrp_basic.h -rw-r--r-- 1 gdt ir 1729 Oct 3 15:36 usrp_bytesex.h -rw-r--r-- 1 gdt ir 1009 Oct 3 15:36 usrp_config.cc -rw-r--r-- 1 gdt ir 2011 Oct 3 15:36 usrp_config.h -rw-r--r-- 1 gdt ir 1886 Oct 3 15:36 usrp_dbid.dat -rw-r--r-- 1 gdt ir 3842 Oct 3 15:36 usrp_local_sighandler.cc -rw-r--r-- 1 gdt ir 1648 Oct 3 15:36 usrp_local_sighandler.h -rw-r--r-- 1 gdt ir 32213 Oct 3 15:36 usrp_prims.cc -rw-r--r-- 1 gdt ir 9647 Oct 3 15:36 usrp_prims.h -rw-r--r-- 1 gdt ir 1101 Oct 3 15:36 usrp_slots.h -rw-r--r-- 1 gdt ir 19970 Oct 3 15:36 usrp_standard.cc -rw-r--r-- 1 gdt ir 10825 Oct 3 15:36 usrp_standard.h -- Greg Troxel <[EMAIL PROTECTED]> pgplCNx8r5DYK.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
G'day, 3.0rc1 fails on NetBSD due to missing fusb_ra_wb.h: gmake[5]: Entering directory `/tmp/gnuradio-3.0rc1/usrp/host/lib' if /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../usrp/host/lib -I../../../usrp/firmware/include -I/usr/pkg/include -I/usr/pkg/include -Wall -Woverloaded-virtual -pthread -MT fusb_ra_wb.lo -MD -MP -MF ".deps/fusb_ra_wb.Tpo" -c -o fusb_ra_wb.lo fusb_ra_wb.cc; \ then mv -f ".deps/fusb_ra_wb.Tpo" ".deps/fusb_ra_wb.Plo"; else rm -f ".deps/fusb_ra_wb.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../usrp/host/lib -I../../../usrp/firmware/include -I/usr/pkg/include -I/usr/pkg/include -Wall -Woverloaded-virtual -pthread -MT fusb_ra_wb.lo -MD -MP -MF .deps/fusb_ra_wb.Tpo -c fusb_ra_wb.cc -fPIC -DPIC -o .libs/fusb_ra_wb.o fusb_ra_wb.cc:27:24: error: fusb_ra_wb.h: No such file or directory fusb_ra_wb.cc:78: error: 'fusb_devhandle_ra_wb' has not been declared fusb_ra_wb.cc:78: error: ISO C++ forbids declaration of 'fusb_devhandle_ra_wb' with no type [...] The patches that optimizes data bandwidth on USB interface hasn't made it into the trunk :( cheerio Berndt On Wednesday 04 October 2006 02:05, Johnathan Corgan wrote: > This is just a reminder to the group that we have GNU Radio release > 3.0rc1 available for testing: > > http://gnuradio.org/releases/gnuradio/gnuradio-3.0rc1.tar.gz > > There have been no reported problems so far, but it would also be > helpful to get more "works for me" reports as well. You can send a note > to me or to the list. > > Once the tarball is unpacked, the only difference in build instructions > between the tarball and building from SVN is that one does not need to > run 'bootstrap' first. > > The release tarball does not include all the components that are > available via SVN, as some are considered experimental, incomplete, or > destined for a future 'contrib' tarball. You can still obtain these via > SVN. > > Johnathan Corgan, AE6HO > [EMAIL PROTECTED] > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
I haven't tried the tarball, but checking the latest trunk from SVN worked fine. I've only played with the digital modulation portions so far, but no problem with the install or operation of anything I've used after a make distclean. Tom > -Original Message- > From: [EMAIL PROTECTED] [mailto:discuss- > [EMAIL PROTECTED] On Behalf Of Johnathan Corgan > Sent: Tuesday, October 03, 2006 12:36 PM > To: gnuradio mailing list > Subject: [Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball > > This is just a reminder to the group that we have GNU Radio release > 3.0rc1 available for testing: > > http://gnuradio.org/releases/gnuradio/gnuradio-3.0rc1.tar.gz > > There have been no reported problems so far, but it would also be > helpful to get more "works for me" reports as well. You can send a note > to me or to the list. > > Once the tarball is unpacked, the only difference in build instructions > between the tarball and building from SVN is that one does not need to > run 'bootstrap' first. > > The release tarball does not include all the components that are > available via SVN, as some are considered experimental, incomplete, or > destined for a future 'contrib' tarball. You can still obtain these via > SVN. > > Johnathan Corgan, AE6HO > [EMAIL PROTECTED] > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test reports needed for release 3.0rc1 tarball
This is just a reminder to the group that we have GNU Radio release 3.0rc1 available for testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.0rc1.tar.gz There have been no reported problems so far, but it would also be helpful to get more "works for me" reports as well. You can send a note to me or to the list. Once the tarball is unpacked, the only difference in build instructions between the tarball and building from SVN is that one does not need to run 'bootstrap' first. The release tarball does not include all the components that are available via SVN, as some are considered experimental, incomplete, or destined for a future 'contrib' tarball. You can still obtain these via SVN. Johnathan Corgan, AE6HO [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test: Ignore
Since your are reading this: I'm not sure why gnu.org lists are still listed in several RBL databases. I'm subscribed to many mailing lists but gnuradio is the only one giving me grieve. This situation exists for a long time now and I'm surprised that the responsible list maintainers seemingly don't care and get this sorted out for once and all! Personally, I couldn't sleep until this problem was fixed for once and all if this was my domain being blacklisted. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test: Please Ignore
G'day, we kicked Spamcrap off our mailserver. This is a test to see if mail from gnu.org gets through. It is hoped that other ISP will do the same in order to force them to change their stupid policy or out of business. cheerio Berndt pgpjBBRrcKoBj.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test: ignore
pgplqK9nu2MbJ.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test
Test. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] test equipment
On Thu, Oct 27, 2005 at 06:00:21PM -0400, cswiger wrote: > Thanks to Eric for making it so we can change DDC frequency w/o > disturbing their phase, I can now measure the magnitude AND > phase response of a network over a wide range, transmission > and/or reflection (like an antenna). Smith charts can't be > too far behind. > > http://webpages.charter.net/cswiger/phase/vna_10.html > > --Chuck Very nice, Chuck! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test equipment
Thanks to Eric for making it so we can change DDC frequency w/o disturbing their phase, I can now measure the magnitude AND phase response of a network over a wide range, transmission and/or reflection (like an antenna). Smith charts can't be too far behind. http://webpages.charter.net/cswiger/phase/vna_10.html --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
