[chuck-users] chout and cherr confuse me [BUG?]
Spencer D Salazar
ssalazar at CS.Princeton.EDU
Wed Oct 21 05:32:43 EDT 2009
While there should be no debate that stdout buffering is a nearly universal implementation strategy of C/C++ IO, the exact behavior Kassen is reporting was concerning to me. I then remembered that one common detail in how stdout is buffered is that the buffer is flushed less often when stdout is directed to a file or a pipe.
It just so happens that to enable the Console Monitor, miniAudicle has to redirect stderr and stdout to a pipe.
As far as I can tell, Kassen's original example works fine in command line chuck. As you have reported, not so much in the mini. I think the fix for this is pretty straightforward, so that should be in SVN shortly*.
Kassen, thanks for reporting this and sticking to your guns!
* By the way, miniAudicle's active source repository has moved to SVN, hosted by Google Code.
----- "Kassen" <signal.automatique at gmail.com> wrote:
> Hi, Ge!
> In short, chout prints to stdout (buffered output, higher
> performance), and cherr prints to stderr (more timely and synchronous,
> handled differently by console/pipes/redirect). The existing <<< >>>
> operators prints to stderr by default (there was actually no way to
> print to stdout before chout).
> Check, that's quite clear then.
> If one desires truly synchronous output, then cherr is probably the
> way to go. At the same time, there are a few nuances of cout (C++) -
> there is a method to force flushing the buffer - this actually exists
> for chout - just invoke .flush(). Inserting an "endl" into C++ cout
> effectively flushes the output stream - this is currently not
> implemented. I've made
> this addition in CVS (IO.newline() or "\n" by itself will cause a
> flush on chout), and this should be in the next release.
> Well.... now I have a new issue;
> ...will crash the Mini for me. It even crashes when that's the only
> line in the file.
> I'm also sorry to have to say that I'm still not sold on the idea that
> chout works properly. I can accept it being slow but here it is being
> slow in a very predictable way that's related to what ChucK does.
> Especially as IO.newline() doesn't seem to -by itself- flush all data
> out. If you look at my example code you'll see all print commands use
> newline() yet at the end of running the file there is still a print
> command up in limbo.
> Sorry to persist like this.
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users