chout and cherr confuse me [BUG?]
Fellow ChucKists, Consider this edit of one of the new examples, I just made this because I was trying to figure out the difference between chout and cherr and why the plain example's output had the order in which the results of the operations were printed reversed; ---------------------8<-------------------------- // 'chout' is chuck out, pronounced "shout" // 'cherr' is chuck err, pronounced "Cher" // output to console on stdout chout <= 1 <= " foo " <= 5.5 <= IO.newline(); // output to console on stderr cherr <= 2 <= " bar " <= 5.5 <= IO.newline(); <<<"start pause">>>; second => now; <<<"end pause">>>; // output to console on stderr cherr <= 3 <= " bar " <= 5.5 <= IO.newline(); // output to console on stdout chout <= 4 <= " foo " <= 5.5 <= IO.newline(); -----------------------------8<-------------------------------------- Now, the output this gives varies with how many times we used the various commands in the recent past and on what, but it stabilises to this after running it a few times; [chuck](VM): sporking incoming shred: 1 (*chout.ck)... 2 bar 5.5 "start pause" : (string) 4 foo 5.5 1 foo 5.5 "end pause" : (string) 3 bar 5.5 It seems to me that chout has some sort of internal buffer and that it takes two chout commands to reach the actual console, instead of one, like I expected. It also seems like cherr has a higher priority of some sort. maybe cherr commands print immediately while chout ones are delayed until time is advanced? I'd like to know what the intended behaviour is as I'm now just guessing about the difference between the two. Right now I'm leaning towards suspecting at least a bug in chout. Yours, Kas.
2009/10/20 Kassen
It seems to me that chout has some sort of internal buffer and that it takes two chout commands to reach the actual console, instead of one, like I expected. It also seems like cherr has a higher priority of some sort. maybe cherr commands print immediately while chout ones are delayed until time is advanced?
I'd like to know what the intended behaviour is as I'm now just guessing about the difference between the two. Right now I'm leaning towards suspecting at least a bug in chout.
Although they end up in the same terminal, stdout and stderr are separate output streams with separate buffers that will flush at different times. This is why you can redirect chuck's stdout like "chuck file.ck > output.txt" and lines to stderr still appear. You cannot get consistent ordering of output on the two streams. I'm not saying there's nothing special going on with chout and cherr, but that the behavior you're describing is to be expected in general. -- Tom Lieber http://AllTom.com/
Tom;
I'm not saying there's nothing special going on with chout and cherr, but that the behavior you're describing is to be expected in general.
So you are saying it's reasonable for a print command to be stuck in a cue until the file is ran again, potentially a hour or so later? That doesn't seem very reasonable to me. Messages that use different channels might arrive out of order, I can accept that, but this is quite different (and the order I get them in seems constant, just wrong). I would like the messages I am printing to arrive at the screen while the file is running, not next time the program is run, in-between other messages, and I have a hard time seeing why I shouldn't expect that. Yours, Kas.
2009/10/20 Kassen
I'm not saying there's nothing special going on with chout and cherr, but that the behavior you're describing is to be expected in general.
So you are saying it's reasonable for a print command to be stuck in a cue until the file is ran again, potentially a hour or so later? That doesn't seem very reasonable to me. Messages that use different channels might arrive out of order, I can accept that, but this is quite different (and the order I get them in seems constant, just wrong). I would like the messages I am printing to arrive at the screen while the file is running, not next time the program is run, in-between other messages, and I have a hard time seeing why I shouldn't expect that.
I don't think it will ever take that long to print something. chout may wait for its buffer to be a certain size before it prints, but I don't think it will be too big a problem. flush() for stdout may be useful for those times when you need to know something has printed. -- Tom Lieber http://AllTom.com/
Tom;
I don't think it will ever take that long to print something.
Well, my issue is that here it takes as long as the next usage before it prints, that might be 10::hour. Did you run my example script? First usage gives me three lines of output, from there on 4 with the first chout line being the last chout call of the previous time I ran it. This is the latest Mini (+CNoise fix) in Alsa mode on the latest LTS of Ubuntu. cherr calls are independant from this, seem to get precedence, and work about like you described what I could expect. I don't think that's right. Sorry if these exact symptoms weren't clear from my last post. Can anybody reproduce this? Kas.
Hey Kas, I'm not the expert, but I'm pretty sure that you can expect ChucK's handling of stdout vs stderr to be exactly the same as <insert favorite OS here>. I believe that printing to stdout gets flushed more aggressively than printing to stdout, but the flip side is that printing to stdout is overall more efficient. (That's why you see cherr output appear before chout.) But the bottom line: if you've been happy with the way printing to stdout and stderr works your OS works, you'll be fine with ChucK. - Rob On 20 Oct 2009, at 15:42, Kassen wrote:
Tom;
I don't think it will ever take that long to print something.
Well, my issue is that here it takes as long as the next usage before it prints, that might be 10::hour.
Did you run my example script? First usage gives me three lines of output, from there on 4 with the first chout line being the last chout call of the previous time I ran it. This is the latest Mini (+CNoise fix) in Alsa mode on the latest LTS of Ubuntu. cherr calls are independant from this, seem to get precedence, and work about like you described what I could expect.
I don't think that's right. Sorry if these exact symptoms weren't clear from my last post. Can anybody reproduce this?
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hey Rob,
But the bottom line: if you've been happy with the way printing to stdout and stderr works your OS works, you'll be fine with ChucK.
Well, I'm distinctly non-happy with ChucK here for the reasons in my last post. Three messages the first time i run it, then four with this offset seems like a bug to me. Yours, kas.
Greetings! Indeed an important question! 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). 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. I hope this helps - thanks! Best, Ge! On Wed, 21 Oct 2009, Kassen wrote:
Hey Rob,
But the bottom line: if you've been happy with the way printing to stdout and stderr works your OS works, you'll be fine with ChucK.
Well, I'm distinctly non-happy with ChucK here for the reasons in my last post. Three messages the first time i run it, then four with this offset seems like a bug to me.
Yours, kas.
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.
Hi Kassen!
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.
Oh yes, that is indeed an issue (with ChucK, not mini) - working on it now!
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.
As I expressed in my last email, IO.newline() is currently NOT causing a flush (as it should). I've fixed this issue in CVS, and we will release it in the next version. Hopefully we can fix the flush issue as well, and things should be better then!
Sorry to persist like this.
Hah - you and I both know this is how we make ChucK suck less! (and you've uncovered two bugs already here!) Thanks for the persistence and rock on! All the best, Ge!
Hey, Ge! Oh yes, that is indeed an issue (with ChucK, not mini) - working on it now!
Yes, I thought so, but as the mini has it's own window to print to I thought it might be relevant to mention that. As I expressed in my last email, IO.newline() is currently NOT causing
a flush (as it should). I've fixed this issue in CVS, and we will release it in the next version. Hopefully we can fix the flush issue as well, and things should be better then!
Ah, right, I think I read too quickly. Ok, then we are on the same page; this ought to fix it.
Hah - you and I both know this is how we make ChucK suck less! (and you've uncovered two bugs already here!)
True, but I did need to go "no, it's wrong" a few times.
Thanks for the persistence and rock on!
T'a's cool. Onwards to taking LiSa to town with smoothed .sync signals as that needs to be done by next weekend. And practice. And try not to go insane :-). Yours, Kas.
Dear Kas,
I fear that this has to do with buffering (whether a stream is buffered or
not), and if buffered, buffer size makes a difference, too.
For example, in C/C++, if you want to see the output of a fprintf() call for
sure, you have to call fflush(). I don't know if it has a ChucK equivalent,
though.
Szilveszter aka Hillaby
2009/10/20 Kassen
Fellow ChucKists,
Consider this edit of one of the new examples, I just made this because I was trying to figure out the difference between chout and cherr and why the plain example's output had the order in which the results of the operations were printed reversed; ---------------------8<-------------------------- // 'chout' is chuck out, pronounced "shout" // 'cherr' is chuck err, pronounced "Cher"
// output to console on stdout chout <= 1 <= " foo " <= 5.5 <= IO.newline();
// output to console on stderr cherr <= 2 <= " bar " <= 5.5 <= IO.newline();
<<<"start pause">>>; second => now; <<<"end pause">>>;
// output to console on stderr cherr <= 3 <= " bar " <= 5.5 <= IO.newline();
// output to console on stdout chout <= 4 <= " foo " <= 5.5 <= IO.newline(); -----------------------------8<--------------------------------------
Now, the output this gives varies with how many times we used the various commands in the recent past and on what, but it stabilises to this after running it a few times;
[chuck](VM): sporking incoming shred: 1 (*chout.ck)... 2 bar 5.5 "start pause" : (string) 4 foo 5.5 1 foo 5.5 "end pause" : (string) 3 bar 5.5
It seems to me that chout has some sort of internal buffer and that it takes two chout commands to reach the actual console, instead of one, like I expected. It also seems like cherr has a higher priority of some sort. maybe cherr commands print immediately while chout ones are delayed until time is advanced?
I'd like to know what the intended behaviour is as I'm now just guessing about the difference between the two. Right now I'm leaning towards suspecting at least a bug in chout.
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hi, Szilveszter!
I fear that this has to do with buffering (whether a stream is buffered or not), and if buffered, buffer size makes a difference, too.
For example, in C/C++, if you want to see the output of a fprintf() call for sure, you have to call fflush(). I don't know if it has a ChucK equivalent, though.
Ah, we're getting there! This, combined with Ge's last mail and my own report on chout.flush() crashing is going to fix it, or so I hope. Thanks! Kas.
Alright! I am happy to report that both .flush() and IO.newline() and "\n" triggering flush on chout has been fixed/implemented (I think), along with a number of associated "features" fixed. The code is in CVS and will be released with the next version, which we might just release soon! Thanks again Kassen and all!! Best, Ge! On Wed, 21 Oct 2009, Kassen wrote:
Hi, Szilveszter!
I fear that this has to do with buffering (whether a stream is buffered or not), and if buffered, buffer size makes a difference, too.
For example, in C/C++, if you want to see the output of a fprintf() call for sure, you have to call fflush(). I don't know if it has a ChucK equivalent, though.
Ah, we're getting there! This, combined with Ge's last mail and my own report on chout.flush() crashing is going to fix it, or so I hope.
Thanks!
Kas.
Hi, Ge!
Maybe I missed something on the web site, but I could not find a list for
the fixed bugs that'll probably be included in the next release (including
your "hot" fixes for std* streams).
Is there a "coming soon" feature list somewhere?
Regards,
Szilveszter aka Hillaby
2009/10/21 Ge Wang
Alright! I am happy to report that both .flush() and IO.newline() and "\n" triggering flush on chout has been fixed/implemented (I think), along with a number of associated "features" fixed. The code is in CVS and will be released with the next version, which we might just release soon!
Thanks again Kassen and all!!
Best, Ge!
On Wed, 21 Oct 2009, Kassen wrote:
Hi, Szilveszter!
I fear that this has to do with buffering (whether a stream is buffered or not), and if buffered, buffer size makes a difference, too.
For example, in C/C++, if you want to see the output of a fprintf() call for sure, you have to call fflush(). I don't know if it has a ChucK equivalent, though.
Ah, we're getting there! This, combined with Ge's last mail and my own report on chout.flush() crashing is going to fix it, or so I hope.
Thanks!
Kas.
_______________________________________________
chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Maybe I missed something on the web site, but I could not find a list for the fixed bugs that'll probably be included in the next release (including your "hot" fixes for std* streams).
Is there a "coming soon" feature list somewhere?
This might be close; http://wiki.cs.princeton.edu/index.php/ChucK/Bugs/Release Not everyone uses it but I've been trying to advocate that page for centralised tracking and documenting of open bugs because otherwise some will slip through. Whenever there is news on fixes I try to put it on there. Not as good as we could do but it does list the majority of known issues which can save trouble. Kas.
On 21 Oct 2009, at 13:45, Ge Wang wrote:
Alright! I am happy to report that both .flush() and IO.newline() and "\n" triggering flush on chout has been fixed/implemented (I think), along with a number of associated "features" fixed. The code is in CVS and will be released with the next version, which we might just release soon!
I think that the normal behavior in C/C++ is that '\n' does not flush. - One might have a multiline display, just wanting to flush after all has been written. Hans
participants (6)
-
Ge Wang -
Hans Aberg -
Kassen -
Robert Poor -
Szilveszter Tóth -
Tom Lieber