|Subject:||Re: [Discuss-gnuradio] Automated Simulation Quirk|
|Date:||Tue, 27 Oct 2015 09:43:45 -0700|
you can flush an outputstream using std::flush, e.g
std::out << "This is a message that I hope doesn't get delayed" <<
On 10/27/2015 06:18 AM, Richard Bell wrote:
> Sure how would I do that? I'm not familiar with buffering related to std::cout.
> Sent from my iPad
>> On Oct 26, 2015, at 10:33 AM, Martin Braun <address@hidden> wrote:
>> can you confirm that the output is actually occurring when you think it
>> is? I.e., there's no buffering going on and older data is displayed?
>>> On 26.10.2015 10:20, Richard Bell wrote:
>>> Hi all,
>>> I've got a flowgraph I made running from a python script in a for loop.
>>> Each run through the loop different parameters are set for various
>>> settings of the radio.
>>> The quirk I'm seeing, is that some std::cout statements generated from
>>> flowgraph blocks are outputting 0's when they are not 0. Does anyone
>>> know why this might be?
>>> For example, the variable num_bit_errors is what the flowgraph ends a
>>> simulation on. If num_bit_errors > 100, I return WORK_DONE, which moves
>>> the script onto the next loop iteration. This works fine, there is no
>>> deadlock in the system. However, in the same area of code, I also do
>>> std::cout << num_bit_errors so that I have a sense of how far along the
>>> simulation is. These cout statements almost always return 0's, even
>>> right before the flowgraph makes it past the if num_bit_errors > 100
>>> check. Another words, to make it through that if statements and complete
>>> the flowgraph run, num_bit_errors must be non-zero. However, std::cout
>>> reports that num_bit_error is 0.
>>> Not sure what's going on.
>>> Discuss-gnuradio mailing list
>> Discuss-gnuradio mailing list
> Discuss-gnuradio mailing list
Discuss-gnuradio mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|