Is there a way to flush chout (and cherr) other than sending "\n"? Hans
chout.flush() does the trick. cherr is flushed constantly, right?
Andrew
On Tue, Nov 24, 2009 at 7:04 AM, Hans Aberg
Is there a way to flush chout (and cherr) other than sending "\n"?
Hans
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
2009/11/24 Andrew C. Smith
chout.flush() does the trick. cherr is flushed constantly, right?
Maybe you are on the cvs build? There was/is a bug with chout.flush() (which crashed) and IO.newline() didn't correctly force a flush. Ge was working on a fix which I would expect to be in cvs right now as the cause had been pinpointed. Good thing I kept notes here; http://wiki.cs.princeton.edu/index.php/ChucK/Bugs/Release as I had forgotten the exact details. Yours, Kas.
On 24 Nov 2009, at 15:35, Kassen wrote:
chout.flush() does the trick. cherr is flushed constantly, right?
Maybe you are on the cvs build? There was/is a bug with chout.flush() (which crashed) and IO.newline() didn't correctly force a flush. Ge was working on a fix which I would expect to be in cvs right now as the cause had been pinpointed.
Good thing I kept notes here; http://wiki.cs.princeton.edu/index.php/ChucK/Bugs/Release as I had forgotten the exact details.
Yes, chout.flush() hangs for a while, and then reports bus error. "\n" seems to flush, but for the VT100 terminal 2D display I mentioned before I want to avoid unnecessary newlines. It would also be nice if one could do C++ style manipulators. Like std::ostream& f(std::ostream& os) { ... return os; } And then chout <= ... <= f <= ...; Hans
Hans; Yes, chout.flush() hangs for a while, and then reports bus error. "\n" seems
to flush, but for the VT100 terminal 2D display I mentioned before I want to avoid unnecessary newlines.
Yeah, under the current conditions chout is a bit hard to work with. At least we caught and pinpointed the issue quite quickly. It would also be nice if we could try to get OS-independent coloured printing. This would be useful when our program regularly prints notifications but sometimes needs special attention that's not severe enough to be cause for a me.exit() (for example when it doesn't find the expected MIDI device, when running out of voices, when recording, etc). Right now we can do coloured printing in various ways depending on the OS (with Windows being the odd one out) as this needs system calls. It would be nice if we could abstract the differences away for convenience and compatibility. I feel that anything that depends on the OS of the user that might be needed in normal ChucKage (if such a thing exists...) is a bad thing. Even the Mac-only graphical interface elements lead to confusion in new users on the forum. On top of that system calls are expensive. I'm not at all sure how realistic this is as a wishlist item though. Kas.
On 24 Nov 2009, at 16:42, Kassen wrote:
Yes, chout.flush() hangs for a while, and then reports bus error. "\n" seems to flush, but for the VT100 terminal 2D display I mentioned before I want to avoid unnecessary newlines.
Yeah, under the current conditions chout is a bit hard to work with.
As for the VT100 interface, I found that one can return strings. The syntax is chout <= VT100.pos(12, 3) <= VT100.fgbg(VT100.magenta, VT100.yellow) <= "Hello World!\n"; which will set the cursor at (x, y) = (12, 3), foreground color to magenta, and background color to yellow.
At least we caught and pinpointed the issue quite quickly.
But it would be nice to get rid of the "\n". So flush() might come in handy.
It would also be nice if we could try to get OS-independent coloured printing. This would be useful when our program regularly prints notifications but sometimes needs special attention that's not severe enough to be cause for a me.exit() (for example when it doesn't find the expected MIDI device, when running out of voices, when recording, etc).
Right now we can do coloured printing in various ways depending on the OS (with Windows being the odd one out) as this needs system calls. It would be nice if we could abstract the differences away for convenience and compatibility. I feel that anything that depends on the OS of the user that might be needed in normal ChucKage (if such a thing exists...) is a bad thing. Even the Mac-only graphical interface elements lead to confusion in new users on the forum. On top of that system calls are expensive.
Since it is an emulation of a VT100 terminal, it will be OS independent - one needs a console that emulates it. The standard is here: http://www.xfree86.org/current/ctlseqs.html But it is just a hack, not a replacement for more advanced solutions like miniAudicle. Hans
participants (3)
-
Andrew C. Smith -
Hans Aberg -
Kassen