Forum: GNU Radio Error messages when running gr_filter_design for gnuradio 4.7 on MacPorts

Hi, all,

I updated MacPorts to 2.1.3 just now and installed gnuradio-next by the
following command:

$ sudo port install gnuradio-next +full configure.compiler=llvm-gcc-4.2

When I tried to run gr_filter_design, it gave me this error message:
$ gr_filter_design
Please install PyQwt5 to run this script (http://pyqwt.sourceforge.net/)

To execute it, I deactivate qwt forcefully by
$ sudo port -f deactivate qwt

And then install PyQwt5 by:

$ sudo port py27-pyqwt

Then running gr_filter_design works perfectly! Good!

Should gnuradio-next depends on PyQwt5 instead of qwt package?

--
Albert Chun-Chieh Huang(黃俊傑)
Blog: Random Notes, http://alberthuang314.blogspot.com/

On Mon, Feb 4, 2013 at 10:15 AM, Albert Chun-Chieh Huang <
alberthuang314@gmail.com> wrote:

>
>
> --
> Albert Chun-Chieh Huang(黃俊傑)
> Blog: Random Notes, http://alberthuang314.blogspot.com/


Albert,

No, you still need QWT for gr-qtgui. We also don't want to add PyQWT as 
a
dependency since you don't require it to install anything. You need it 
for
runtime on a few apps and examples, but as you saw, we catch that import
error and provide a slightly nicer error message about what's going on. 
I
don't like the idea of adding runtime dependencies to the compile time 
list
of requirements. Having said that, we could check for runtime 
dependencies
and not install apps that fail, but this wouldn't stop compilation. I
haven't done that, yet, because it's a bit of a management nightmare to
keep all of that tied together. I think the runtime error message about 
the
missing Python component is sufficient.

Tom

Hi Albert - On my end as the maintainer of the gnuradio* ports in 
MacPorts, I'll add a runtime dependency on py*-pyqwt for gr-utils. 
It'll be a little tricky since I have to get the variants to match up 
(the variant for pyqwt and which version of qwt is installed), but it 
can be done.

Tom - Do you know if the 2 gr-utils which depend on pyqwt 
(gr_filter_design and gr_plot_qt) will work with qwt5 and qwt6?  RIght 
now they try to import PyQwt5, but maybe the import test could be 
changed to try for PyQwt6 first then if that fails PyQwt5?  I've set up 
the gnuradio* ports to not care which version of qwt is installed (5 or 
6; via depending on "path:lib/libqwt.dylib:qwt" which looks for the 
library first and if that is not found then port reverts the dependency 
to qwt which is version 5.1.2) -- so, requiring qwt version 5 in these 
scripts seems to counter my settings.  Hence, my question. - MLD

On Mon, Feb 4, 2013 at 11:06 AM, Michael Dickens <mlk@alum.mit.edu> 
wrote:

> Hi Albert - On my end as the maintainer of the gnuradio* ports in
> MacPorts, I'll add a runtime dependency on py*-pyqwt for gr-utils.  It'll
> be a little tricky since I have to get the variants to match up (the
> variant for pyqwt and which version of qwt is installed), but it can be
> done.
>

Thanks!


> Tom - Do you know if the 2 gr-utils which depend on pyqwt
> (gr_filter_design and gr_plot_qt) will work with qwt5 and qwt6?  RIght now
> they try to import PyQwt5, but maybe the import test could be changed to
> try for PyQwt6 first then if that fails PyQwt5?  I've set up the gnuradio*
> ports to not care which version of qwt is installed (5 or 6; via depending
> on "path:lib/libqwt.dylib:qwt" which looks for the library first and if
> that is not found then port reverts the dependency to qwt which is version
> 5.1.2) -- so, requiring qwt version 5 in these scripts seems to counter my
> settings.  Hence, my question. - MLD


So this is a bit tricky right now. PyQwt on supports version 5. They 
have
stated that they do not plan to support Qwt6 in it's current for. I 
think
they were talking about doing a full redo of their software. I don't 
really
know what this means yet for long-term capabilities or stability.

On the other hand, PyQwt5 works in all cases I've tested against Qwt6.
Qwt6, though, is much nicer and has some significant performance 
benefits.
So if possible, use Qwt6 with PyQwt5.

Tom

Tom Rondeau <tom@trondeau.com> writes:

>> When I tried to run gr_filter_design, it gave me this error message:
>> Then running gr_filter_design works perfectly! Good!
> No, you still need QWT for gr-qtgui. We also don't want to add PyQWT as a
> Tom
Hi, Tom,

Thanks for your reply. In the beginning, I thought gnuradio will also
work well with qwt 5.2.1 that comes with py27-pyqwt package. But I
tested it with QtGUI in gnuradio-companion, and it failed.

Now I get it. QtGUI in gnuradio-companion depends on QWT 5.1.2 and
gr_filter_design depends on PyQwt 5.2. So I try to install PyQwt 5.2 on
MacOSX without MacPorts. Now both gr_filter_design and QtGUI work fine
on my Mac.

GNU Radio 3.7 is really a huge jump for this project! Thank you all very
much!


--
Albert Chun-Chieh Huang(黃俊傑)
Blog: Random Notes, http://alberthuang314.blogspot.com/

Michael Dickens <mlk@alum.mit.edu> writes:

> Hi Albert - On my end as the maintainer of the gnuradio* ports in
> MacPorts, I'll add a runtime dependency on py*-pyqwt for gr-utils.
> It'll be a little tricky since I have to get the variants to match up
> (the variant for pyqwt and which version of qwt is installed), but it
> can be done.

That will be even better! Thanks! I tried to install PyQwt5 manually,
and both gr_filter_design and QtGUI work well right now.

If both QtGUI and gr_filter_design can depend on PyQwt5, which depends
on Qwt 5.2.1, that will solve this issue. But I'm not sure if QtGUI
works with Qwt 5.2.1.

>
> Tom - Do you know if the 2 gr-utils which depend on pyqwt (gr_filter_design and 
gr_plot_qt) will work with qwt5 and qwt6?  RIght now they try to import PyQwt5, 
but maybe the import test could be changed to try for PyQwt6 first then if that 
fails PyQwt5?  I've set up the gnuradio* ports to not care which version of qwt is 
installed (5 or 6; via depending on "path:lib/libqwt.dylib:qwt" which looks for 
the library first and if that is not found then port reverts the dependency to qwt 
which is version 5.1.2) -- so, requiring qwt version 5 in these scripts seems to 
counter my settings.  Hence, my question. - MLD

--
Albert Chun-Chieh Huang(黃俊傑)
Blog: Random Notes, http://alberthuang314.blogspot.com/

On Tue, Feb 5, 2013 at 2:47 AM, Albert Chun-Chieh Huang <
alberthuang314@gmail.com> wrote:

> >> $ sudo port install gnuradio-next +full configure.compiler=llvm-gcc-4.2
> >>
> >
> dependencies
> Thanks for your reply. In the beginning, I thought gnuradio will also
>
>
> --
> Albert Chun-Chieh Huang(T)
> Blog: Random Notes, http://alberthuang314.blogspot.com/
>

I consistently run using Qwt 5.2 (actually version 5.2.2) on some of my
machines. I normally try to run Qwt6, but I test against both. On my OSX
machine, I only run Qwt6, though, so I'm not sure if there's some issue
with 5.2.1/2 on that platform.

Tom

I just checked in a change in r102664 < 
https://trac.macports.org/changeset/102664 >, which adds in the runtime 
dependency.  I tried a couple ways to do "active variants" but I don't 
grok them yet so I went ahead and checked this in along with bumping 
devel and next to the latest from GIT.  If OSX users are up for it, go 
ahead and experiment with the various QWT versions and see if/how they 
work.  Let me know if you do, and if you come to any conclusions. - MLD

On Feb 4, 2013, at 11:37 AM, Tom Rondeau <tom@trondeau.com> wrote:
> On the other hand, PyQwt5 works in all cases I've tested against Qwt6. Qwt6, 
though, is much nicer and has some significant performance benefits. So if 
possible, use Qwt6 with PyQwt5.

Hi Tom - I'm wondering if you can clarify what you've written.

Last night I checked into MacPorts a big overhaul of the Qwt series, so 
we have qwt (5.1), qwt52 (5.2.3), qwt60 (replaces qwt-60; 6.0.2), and 
qwt-devel (6.1.rc3).

This morning I tried compiling PyQwt (5.2.0) using qwt52 and qwt60; the 
former works just fine but the latter fails because the API has changed 
(e.g., removal of qwt_array).

I tried installing "py27-pyqwt +qwt60" but that failed (again due to the 
API changes).  So while I -could- install "py27-pyqwt +qwt52" then force 
install qwt60 (over qwt52), the PyQwt python library will not be 
loadable because it's is linked to "libqwt.5.dylib" and not 
"libqwt.dylib".  I could hack the library requirement to be just 
"libqwt.dylib", but that seems a bit "extreme" and unwise for general 
use (e.g., in MacPorts).

Maybe I'm missing something?  Thanks for explaining. - MLD

On Mon, Feb 11, 2013 at 9:31 AM, Michael Dickens <mlk@alum.mit.edu> 
wrote:

>
>
> Maybe I'm missing something?  Thanks for explaining. - MLD


Most people should be fine sticking with Qwt 5.2. I noticed the 
performance
problem with the new time raster plots that I introduced to the 'next'
branch last week. Using Qwt 5.2, it is pretty much unusable while with 
Qwt
6, everything works fine. Profiling the code showed a couple of specific
library calls that were taking all of the heat under Qwt 5.2. So this is 
an
internal thing (unless I've completely screwed something up) that they
fixed in the new version.

On the other hand, it seems like the APIs are largely compatible from
PyQwt's standpoint. There are some notable changes between the two
versions, but I haven't run into this as a problem using PyQwt5 with 
Qwt6.

Can you send me the line where you received the error for the API 
problem
you mentioned above? I just recently compiled using both Qwt5 and Qwt6 
to
test if both versions were handled properly, and everything looked good 
on
my end. But there's always a chance something slipped by. We can fix 
those
problems, though.

Tom