On 04/28/2010 09:33 PM, Johnathan Corgan wrote:
> On Wed, Apr 28, 2010 at 18:15, Marcus D. Leech <mle...@ripnet.com> wrote:
>
> Marcus, thanks for all the testing/fixes/ideas for the GRC/gr-wxgui
> code. You're uncovering places where we've (well, *I*'ve) been less
> than...diligent in coding things.
>
Diligence? Diligence is for the weak! :-) :-) :-)
> I really need to get you set up as a git-based contributor so we can
> easily test/merge what you're doing.
>
>
>
Yup, that would probably be good.
I've done a number of things this evening to my own code base:
o added a new method in gr_file_sink_base, ::set_unbuffered() that
causes the ::work method to
always issue a fflush() after the write loop. This is critical
for outputs to named pipes
where the input data rate is modest--even when you're writing
complex-floats, it can take
a long time to fill up a stdio BUFSIZ. One would be tempted
to add a function that
places a call to setvbuf(), with an appropriately small buffer,
but setvbuf() can only be
used properly before any I/O has taken place on the file stream.
I updated the file_sink.xml for GRC to match the new method, in
that there's a creation-time
option to make this file_sink unbuffered.
o Used the "prefs" functionality to control a few things in the
wxgui sinks:
o A boolean 'run_always' controls whether your plot-type
things run all the time, or only when visible
o A long 'trig_mode' that sets the default trigger mode when an
OSCOPE comes up. No fancy converter
here, it has to be between 0..3 or lord alone knows what
will happen.
o a string 'waterfall_color' (notice how I deferred to the
American spelling of colour to maintain
consistency with the code :-) ), which sets the default
waterfall colour-map on init.
This is an OK, but not wonderful, way to do this. Ideally, of course,
all the functionality within a wxgui
object should be programmatically accessible, but I admit that
making that happen is a daunting
task. The params list for these things is already really freaking
long, and we'd end up adding probably
10 new params, which has implications for GRC, etc, etc.
I wonder how easy it would be to tweak the "prefs" module to support
app-specific preferences? Hmmm.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
