|
| From: | David Lamkins |
| Subject: | Re: [Bug-apl] Patch: cout buffer control |
| Date: | Fri, 22 Aug 2014 08:08:48 -0700 |
Hi David,
thanks, included in SVN 443.
This is interesting because I normally use something like out << endl which should have flushed the buffer.
On the other hand ⍞ is somewhat special because it prints a prompt but no endl so that the user enters her input
on the same line.
I have added a few cout << flush for ⎕/⍞ so maybe the patch isn't needed anymore (I guess unbuffered output
is slightly slower than buffered output).
/// Jürgen
On 08/22/2014 05:11 AM, David Lamkins wrote:
Oops. Here's the same patch, but inquiring about the correct file descriptor.(It'll work either way in some cases...)
On Thu, Aug 21, 2014 at 8:06 PM, David Lamkins <address@hidden> wrote:
I've been puzzled by the interaction between GNU APL and aplwrap, in which ⎕ and ⍞ output doesn't appear until APL prompts for input. This behavior is bad for the case where the program tries to emit periodic progress messages during long computations.I learned that cout's buffering behavior can be be changed using the call:
It turns out that the C++ std lib is responsible for this behavior. While cerr is unbuffered, cout holds onto buffered content for as long as possible. (Apparently it only does this when stdout is not a terminal, as running the same test in a shell window does not exhibit the aggressive buffering behavior.)
std::cout.setf(std::ios::unitbuf);
This can be called sometime before running the main APL loop, and will cause cout's buffer to be flushed at each <<, the same as cerr.
The attached patch (GNU APL SVN 441) runs the 'unitbuf' code only in the case that stdin is not a tty.
--
"The secret to creativity is knowing how to hide your sources."Albert Einstein
--
"The secret to creativity is knowing how to hide your sources."Albert Einstein
| [Prev in Thread] | Current Thread | [Next in Thread] |