Re: [chuck-users] chout and cherr confuse me [BUG?]
Howdy,
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!
spencer
* By the way, miniAudicle's active source repository has moved to SVN, hosted by Google Code.
----- "Kassen"
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;
chout.flush();
...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.
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Spencer;
It just so happens that to enable the Console Monitor, miniAudicle has to redirect stderr and stdout to a pipe.
As they shout at all of the most exciting parties; BINGO! :-)
Kassen, thanks for reporting this and sticking to your guns!
Thanks for looking into this!
* By the way, miniAudicle's active source repository has moved to SVN,
hosted by Google Code.
Ah, so you are back to more active development? That would be great. If so could you look into the long standing issue of new buffers or old ones that we just switched to not getting automatic keyboard focus and ctrl+tab not cycling through them on Linux? These very minor points are a big usability issues for the mini in Linux-based livecoding. These days I have a second laptop running Linux exclusively so I tend to do more casual Linux-based livecoding and run into this more often. Thanks again for your care, Kas.
On 21 Oct 2009, at 11:32, Spencer D Salazar wrote:
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 looked into a book on the C standard, and it did not say if stdout & stderr must be synchronized if tied to the same stream. But I think perhaps the normal is that one opens only one stream, and then ties the two to them. Hans
I found this section from the C standard (n1124.pdf), 7.19.3 Files, about buffering: 7 At program startup, three text streams are predefined and need not be opened explicitly —standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). As initially opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device. So it seems they should not be buffered, unless changed (like to a file). (The C++ streams just refer to these C streams.) Hans
participants (3)
-
Hans Aberg -
Kassen -
Spencer D Salazar