I’m a noob to gnuradio, but believe it or not, I was able to build it on
my Mac
G4 15" powerbook running osx 10.4.8. After fixing some problems with my
PYTHONPATH, the multi_tone.py example ran like a charm.
However, when I try to run audio_fft.py, I get a blank window with the
title
audio_fft, and a long list of errors in my term window like ‘invalid
context’
following stuff about the window redraw.
Has anyone experienced such behavior? Any clues? I can give more info,
but i’m
not at that computer…
Which audio module are you using (gr-audio-osx or gr-portaudio)?
Could you go ahead and send on the errors to the list when you get a
chance? I’ll check this out when I next have a USRP and a console
(maybe Monday, but more likely Tuesday morning). I can say that I
can run the script with no problems on a Dual G5 running the latest
DarwinPorts libraries, fully updated OSX, and latest SVN of GNU
Radio. Since I’m not on the console, I can’t see what’s going on …
but the script does execute properly. - MLD
How was wxPython installed - by hand, DarwinPorts, Fink, whatever?
This can make a difference. - MLD
I don’t think this is a problem with gnuradio, but rather with wxPython.
I tried
running some demos downloaded from wxpython.org, and none of them work.
It’s
the same problem with updating the window. Looking for a fix…
Quoting M. Dickens [email protected]:
It was installed from binary, version 2.7.1.1, unicode. I subsequently
installed
version 2.6.3.3 from binary and audio_fft came to life. The waterfall is
wonky
though.
Quoting M. Dickens [email protected]:
On Oct 22, 2006, at 12:34 PM, Brett I Balogh wrote:
It was installed from binary, version 2.7.1.1, unicode. I
subsequently installed
version 2.6.3.3 from binary and audio_fft came to life. The
waterfall is wonky
though.
So what you’re saying is that it’s the version of wxPython that was
working or not? I’m using 2.6.3 as installed by DarwinPorts (from
source), and it does just fine (though slow; more below on that).
Any other OSX users of GR using 2.7.X successfully?
When you say “wonky” what exactly do you mean?
I know that the GNU Radio GUI stuff is -slow- on OSX because it does
wx(Python)->X11->Aqua/CoreGraphics, and the “X11->” part is a big
bottleneck. Linux has faster graphics because it uses native X11
processing. In theory it would be possible to create a module for
“gr-gui-osx” (and thence “gr-gui-wx”, “gr-gui-window” and such via a
means similar to gr-audio-*), and then all of the GUI’s would be
native to their host, which would certainly speed things up for OSX
(and I would presume Windows too). That would also mean rewriting
any GUI stuff for a common API which would be supported by all of the
GUI modules … which IMHO is certainly doable if anyone wants to do
it. Has anyone thought of this aspect of GNU Radio? Certainly seems
like there are other OS-specific modules and/or sections, so why not
for the GUI as well? - MLD
On Sun, 2006-10-22 at 13:41 -0400, Michael D. wrote:
In theory it would be possible to create a module for
“gr-gui-osx” (and thence “gr-gui-wx”, “gr-gui-window” and such via a
means similar to gr-audio-*), and then all of the GUI’s would be
native to their host, which would certainly speed things up for OSX
(and I would presume Windows too). That would also mean rewriting
any GUI stuff for a common API which would be supported by all of the
GUI modules …
In theory, that is precisely what wxPython (and the gr-wxgui layer on
top) is supposed to do. wxPython itself is an abstraction that provides
the same external API to the windowing system whether it be Win32,
WinCE, Unix (X11, GTK+, Motif)…and Mac.
While I’ve used wxPython (or the underlying C++ wxWidgets) extensively
on Win32 and Linux/GTK, I know nothing of the Mac port. I guess it was
easy to just port the X11 version to use X11 on the Mac but as you point
out that’s gotta be really slow.
The solution would be to have a wxWidgets over Aqua implementation, not
change wxPython or gr-wxgui.
–
Johnathan C.
[email protected]
On Oct 22, 2006, at 1:54 PM, Johnathan C. wrote:
In theory, that is precisely what wxPython (and the gr-wxgui layer on
top) is supposed to do. wxPython itself is an abstraction that
provides
the same external API to the windowing system whether it be Win32,
WinCE, Unix (X11, GTK+, Motif)…and Mac.
Looking further into this, it does look like wxPython is designed for
OS-native GUI support. As of 2.4 support was marginal; 2.6 is
supposed to be better, and 2.7 even better. I will test out this
theory next week … try running ‘audio_fft.py’ from a Terminal
instead of X11 (and without X11 running). - MLD
I’m seeing a similar issue…
The non-WxPython apps seem to run fine, but the windows freeze
immediately after popping up (some apps just give me a spinning
pinwheel after drawing a frame-box). I have Darwin ports py-wxpython
2.6 installed.
This smells like a WxPython issue, rather than GnuRadio…joy.
On 10/21/06, Brett I Balogh [email protected] wrote:
can run the script with no problems on a Dual G5 running the latest
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
“Truth and technology will triumph over bullsh*t and bureaucracy!” -
Rene Anselmo.
Dave - Could you give details about which Mac you’re running on, OS
version, how you installed GR and prerequisites, and the like? That
might help (might not too, but at least it’s another statistic). - MLD
Here is some info…
Mac OS X 10.4.8, iBook G4 1.2 GHz
Python 2.4.3 (from Darwin Ports)
The rest:
wxWidgets @2.6.3 graphics/wxWidgets
wxWindows @2.4.2 graphics/wxWindows
py-wxpython @2.6.3.2 python/py-wxpython
rb-wxruby @0.6 ruby/rb-wxruby
wxgtk @2.4.2 x11/wxgtk
I just upgraded from 2.x CVS to the 3.0 tarball, but no change.
Most (if not all) prereqs were installed via DarwinPorts. Configure
and make all run pretty clean from what I’ve seen.
When I run a python program, I use ‘pythonw’ when widgets are needed.
That too is 2.4.3.
Thanks for taking the time to look at this. Let me know if there is
more info or any other info…
Dave
On 10/22/06, Michael D. [email protected] wrote:
Dave - Could you give details about which Mac you’re running on, OS
version, how you installed GR and prerequisites, and the like? That
might help (might not too, but at least it’s another statistic). - MLD
On Oct 22, 2006, at 5:29 PM, Dave hartzell wrote:
The non-WxPython apps seem to run fine, but the windows freeze
immediately after popping up (some apps just give me a spinning
pinwheel after drawing a frame-box). I have Darwin ports py-wxpython
2.6 installed.
–
“Truth and technology will triumph over bullsh*t and bureaucracy!” -
Rene Anselmo.