This may be a result of buffer sizes. I don't know enough about C++ to
know how to do it, but maybe if you reduce the buffer size, it will
reduce the latency.
On 08/22/14 11:08, David Lamkins wrote:
I agree: cout << endl should flush the buffer. It does when stdout is
a tty. For some reason, t
I agree: cout << endl should flush the buffer. It does when stdout is a
tty. For some reason, the buffering becomes much more aggressive when the
stdout is a pipe.
On Fri, Aug 22, 2014 at 6:14 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> Hi David,
>
> thanks, included in SVN
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
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 wrote:
> I've been puzzled by the interaction between GNU APL and aplwrap, in which
> ⎕ and ⍞ output doesn't appear until APL pr
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.
It turns out that the C++ std lib is responsi
