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 H.(黃俊傑)
Blog: Random Notes, http://alberthuang314.blogspot.com/
On Mon, Feb 4, 2013 at 10:15 AM, Albert Chun-Chieh H. <
[email protected]> wrote:
–
Albert Chun-Chieh H.(黃俊傑)
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 D. [email protected]
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 R. [email protected] 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 H.(黃俊傑)
Blog: Random Notes, http://alberthuang314.blogspot.com/
On Tue, Feb 5, 2013 at 2:47 AM, Albert Chun-Chieh H. <
[email protected]> 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 H.(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
Michael D. [email protected] 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 H.(黃俊傑)
Blog: Random Notes, http://alberthuang314.blogspot.com/
I just checked in a change in r102664 <
Changeset 102664 – MacPorts >, 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 Mon, Feb 11, 2013 at 9:31 AM, Michael D. [email protected]
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
On Feb 4, 2013, at 11:37 AM, Tom R. [email protected] 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