I have two builds of gnuradio, one that uses ‘maint’ and one that is
‘master’ … in the master, I’m finding that GUIs are not showing.
For example, if I run uhd_fft or uhd_siggen_gui using the master
branch then I have no window that pops up. It is building gr-wxgui
and I believe I have the appropriate wx and SWIG libraries. I do not
get any errors or warnings whatsoever. All of these applications seem
to continue running as if the window exists but it’s invisible. This
does not happen using the ‘maint’ branch.
This is on Ubuntu 12.04 and I’ve attached my cmake configuration
output. Is this a known issue? I can provide more details/debugging.
output. Is this a known issue? I can provide more details/debugging.
George
George,
I couldn’t quickly find the email, but I believe someone else reported
a similar problem (Michael D., maybe). They fixed it locally,
though I can’t remember what the fix was. Hopefully, whoever it was
will see this and speak up. Otherwise, you might look through the
mailing list archives for the past month or so.
I couldn’t quickly find the email, but I believe someone else reported
a similar problem (Michael D., maybe). They fixed it locally,
though I can’t remember what the fix was. Hopefully, whoever it was
will see this and speak up. Otherwise, you might look through the
mailing list archives for the past month or so.
Wasn’t me. In my testing using master and maint from yesterday
(20130617), both produce wx GUIs items (slider, FFT plot) correctly on
Mac OS X. The Qt GUI fails on both in the same general way:
Traceback (most recent call last):
File “/Users/mlk/Desktop/dial_tone.py”, line 149, in
tb = dial_tone()
File “/Users/mlk/Desktop/dial_tone.py”, line 101, in init
self.top_layout.addWidget(self._qtgui_sink_x_0_win)
File
“/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/gr/top_block.py”,
line 94, in getattr
return getattr(self._tb, name)
AttributeError: ‘gr_top_block_sptr’ object has no attribute ‘top_layout’
The MacPorts versions of GNU Radio include the wx OpenGL fixes that were
removed a while back, and will continue to do so until a better fix is
found that is more cross-OS compatible. - MLD
I couldn’t quickly find the email, but I believe someone else reported
a similar problem (Michael D., maybe). They fixed it locally,
though I can’t remember what the fix was. Hopefully, whoever it was
will see this and speak up. Otherwise, you might look through the
mailing list archives for the past month or so.
Wasn’t me. In my testing using master and maint from yesterday (20130617), both
produce wx GUIs items (slider, FFT plot) correctly on Mac OS X. The Qt GUI fails
on both in the same general way:
Ah, ok.
Traceback (most recent call last):
File “/Users/mlk/Desktop/dial_tone.py”, line 149, in
tb = dial_tone()
File “/Users/mlk/Desktop/dial_tone.py”, line 101, in init
self.top_layout.addWidget(self._qtgui_sink_x_0_win)
File
“/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/gr/top_block.py”,
line 94, in getattr
return getattr(self._tb, name)
AttributeError: ‘gr_top_block_sptr’ object has no attribute ‘top_layout’
That means you haven’t selected QTGUI in the Options block in GRC.
The MacPorts versions of GNU Radio include the wx OpenGL fixes that were removed
a while back, and will continue to do so until a better fix is found that is more
cross-OS compatible. - MLD
On Tue, Jun 18, 2013 at 2:51 PM, Sylvain M. [email protected]
wrote:
The MacPorts versions of GNU Radio include the wx OpenGL fixes that were
removed a while back, and will continue to do so until a better fix is
found that is more cross-OS compatible. - MLD
Yeah, btw, I think that the only thing that was wrong with that patch
(5f0aaf3d5397675d6f87acd7ab20526ac1fb0d4e ) is this part :
I’d be very happy to include into the pending 3.7.0rc0 release a tested
fix
that solves OSX issues without affecting Linux.
That means you haven’t selected QTGUI in the Options block in GRC.
Ah; yes. I’d forgotten about that setting. Moving the dial_tone.grc
sliders over to Qt widgets, and dropping in a Qt FFT plot, and making
that setting, I now get:
QWidget: Must construct a QApplication before a QPaintDevice
The MacPorts versions of GNU Radio include the wx OpenGL fixes that were removed
a while back, and will continue to do so until a better fix is found that is more
cross-OS compatible. - MLD
Yeah, btw, I think that the only thing that was wrong with that patch
(5f0aaf3d5397675d6f87acd7ab20526ac1fb0d4e ) is this part :
attribList); # Specifically use the CTOR which does NOT create an
implicit GL context
the attribList is given as a positional argument instead of keyword
argument … except attribList is not in that position at all and so
the attriblib gets ignored and you can get a canvas without the
properties needed (like RGBA or double buffer).
But if this were reverted, the Linux build should not be currently broken
on the master HEAD, should it?
I reverted the commit during the hackfest in Virginia a couple weeks
ago.
I can’t replicate any issues with Ubuntu 12.04 32- or 64-bit, and
recently
used 13.04 32-bit with no problems. It may be be GL driver related; all
the above configurations were using the nvidia binary driver.
My build is running on Ubuntu 12.04 within Parallels ,8 on a OS X
10.8.4 host (MacBook Air). If there’s any more debugging I can do to
help this out, let me know
Trying to divide and conquer with a little bit of intelligence in what
was committed…
Using git bisect is the best way I’ve found to discover these things; it
takes the guesswork out and scales O(log(n)) in the number of commits
between good and bad versions.
Great suggestion, Jonathan. I’ve never used bisect (still migrating
myself over to the git world), but I’ll check out bisect and see if I
can track down this bug.
George,
This should already be fixed. I pushed it to master an hour ago or so.
I’d be very happy to include into the pending 3.7.0rc0 release a tested fix
that solves OSX issues without affecting Linux.
Attached is a fixed up version of the
5f0aaf3d5397675d6f87acd7ab20526ac1fb0d4e
As far as testing goes, all I can say is that the original commit made
my WX fft flicker a lot under linux.
This commit seems to change nothing for me. (i.e. works fine before
and after, running on Gentoo Linux).
Now it should be tested by people on OSX to make sure it still fixes
their issue and it should be tested by other linux users to make sure
it doesn’t break …
Comparing this file to the commit that was reverted, the only difference
I see is:
This file:
{{{
wx.glcanvas.GLCanvas.init(self, parent, wx.ID_ANY,
attribList=attribList); # Specifically use the CTOR which does NOT
create an implicit GL context
}}}
So fixing the init call as above with “attribList=attribList” should fix
a bug that might effect all implementations. If the prior commit worked
on OSX, and I believe it did, then this version should too since all it
does differently is fix this one bug. Nice catch, Sylvain!
I would encourage other Linux & Windows users to try out this fix, to
make sure it works across all major platforms. - MLD
On Fri, Jun 21, 2013 at 6:48 PM, Michael D. [email protected]
wrote:
So fixing the init call as above with “attribList=attribList” should fix a
bug that might effect all implementations. If the prior commit worked on
OSX, and I believe it did, then this version should too since all it does
differently is fix this one bug. Nice catch, Sylvain!
I would encourage other Linux & Windows users to try out this fix, to make
sure it works across all major platforms. - MLD
I’ve restored Balint’s original fix, added the one line change from
Sylvain, and merged it into maint/master.
Great suggestion, Jonathan. I’ve never used bisect (still migrating
myself over to the git world), but I’ll check out bisect and see if I
can track down this bug.