Qtgui sink - flakiness at deconstruction time

I have noticed (either through direct observation, or people’s reports
to me) that there is some “flakiness” when a flow graph with a qtgui
sink deconstructs.

(linux) When a flowgraph with a qtgui sink is shutdown, the
deconstructor for the uhd block does not get called.

(windows) When closing the gui app (sometimes), a windows pops up
telling me about an error and asking if i want to debug the program.
(this has also be reproduced with pyqt_example.py).

I think, that most likely, this is an issue of the qtgui deconstructor
throwing an exception. But I cannot say for sure.
http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9

Any suggestions? Anyone else notice this issue?
-Josh

On Sun, Mar 27, 2011 at 3:24 AM, Josh B. [email protected] wrote:

I think, that most likely, this is an issue of the qtgui deconstructor
throwing an exception. But I cannot say for sure.
http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9

Any suggestions? Anyone else notice this issue?
-Josh

Yes, I’ve known about this issue for a while but decided to ignore it
since
it didn’t seem to be harming anyone (and I had no idea what was causing
it).
Since it’s actually starting to affect people, I’ll look into it.

Mike C. has made some big changes to the qtgui framework that I
have
yet to find the time to work on merging it. But today seems like a good
a
day as any to dive in and start hammering away at these problems.

Also, from another thread, I agree that being able to put multiply
streams
into a single scope plot would be really useful. I’ll see what I can do
about that, too, but that’s going to take some serious surgery since all
of
the plots (fft, waterfall, scope, constellation, etc.) are generated at
the
same time.

Tom

Tom

On 03/27/2011 12:28 PM, Tom R. wrote:

Also, from another thread, I agree that being able to put multiply
streams into a single scope plot would be really useful. I’ll see what
I can do about that, too, but that’s going to take some serious
surgery since all of the plots (fft, waterfall, scope, constellation,
etc.) are generated at the same time.

Yeah, the “monolith” approach that’s currently used for the Qt-GUI
“sink” is a bit awkward for making changes.

My main reason for going down this path is to hopefully avoid some of
the OpenGL flakiness, the somewhat-better performance, and a
(subjective) nice “look” to the Qt GUI widgets as compared to the
WxPython ones.

One of the “hacks” I was thinking of implementing was that if the user
had selected only the time-domain plot, and the sample-rate was
“low”, then it would automatically do a strip-chart type display.
But that was simply a way to avoid changing the API in any way.

Strip-chart is fairly easy to implement as a “preprocessor” for the
regular time-domain display. Instead of waiting for a buffers-worth of
samples before calling the time-domain plotter, you shift all the
samples in the buffer over by one (dropping one off the end), then
insert the fresh sample at the beginning, then call the plotter. The
difference is that the plotter gets called on every sample addition,
instead
of every DISPLAY-SIZE samples. Obviously, you only want to do this
for fairly low-rate data, but strip-charts tend to be used for
low-data-rate stuff, a few samples per second is the usual maximum.

The time-domain plotter already supports separate “pens” for I and Q, so
adding more pens shouldn’t be that huge a deal at the level
of the plotter. But the “work” function needs to be made aware of
potentially more than 1 input data stream.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs