I’m having issues adding a QT Range block into my flow graph.
Sine Signal -> Low Pass Filter -> QT Sink
with filer bandwidth hard code, the flowgraph runs without an issue,
but when I replace the bandwidth with a variable that is controlled by a
QT Range block I receive the following error:
Traceback (most recent call last):
File “top_block.py”, line 17, in
import PyQt4.Qwt5 as Qwt
File
“/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/Qwt5/init.py”,
line 32, in
from Qwt import *
RuntimeError: the sip module implements API v10.0 but the PyQt4.Qwt5.Qwt
module requires API v8.1
Here are the details about my environment:
I’m running gnuradio on a Mac, compiled gnuradio and dependancies from
source with Homebrew with the following versions:
I’ve searched best I can for a solution to this, but it appears that
pyqwt
is no longer being actively maintained, so it is unclear how the API
implementations will be updated. Are others experiencing this issue or
have developed a workaround to be able to use the QT Range block?
Hi Joe - I have GNU Radio 3.7 installed via MacPorts, all up to date.
If I issue “import PyQt4.Qwt5 as Qwt” from Python, it works; no comments
about API versions or requirements. If you provide me with a .grc file
or Python script to run with the Qt Range block, I’ll do that & see if
it works. Beyond that, I have no issues running GNU Radio Wx or Qt
stuff on OSX (10.8, latest). - MLD
Joe and I had a discussion off-list. Here’s the end-result, confirmed
via both internet search as well as local testing:
The error generated by the Python command:
{{{
import PyQt4.Qwt5 as Qwt
File
“/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/Qwt5/init.py”,
line 32, in
from Qwt import *
RuntimeError: the sip module implements API v10.0 but the PyQt4.Qwt5.Qwt
module requires API v8.1
}}}
is the result of PyQwt being compiled using SIP API 8.1 (SIP version
4.13.3), while the currently installed SIP API is 10.0 (SIP version
4.14.7). Depending on what one is trying to do with SIP, the above
might actually work; and SIP provides a means to allow it to work by
using a special import command (or, at least that’s my reading of the
code).
I do not see this issue within MacPorts because the MacPorts maintainers
been diligent about updating SIP dependencies whenever SIP is updated.
I had thought MacPorts would catch SIP updates and force reinstallation
of dependencies (via a new binary or from source), but in my testing it
does not automatically do so. Hence, that task now falls back onto the
maintainer of SIP in MacPorts, who happens to be me; lucky me!) . - MLD
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.