(no subject)

[torkell]

Interesting.

My System.out.println() statements are printing only if I'm in the Eclipse debugger, and only if there's a breakpoint on the line containing them.

Some more digging shows that any println() statement that are before the call to CUP work, as long as I flush the output. Which implies that CUP (or possibly JFlex) is doing something evil to System.out.

Hmm, a full rebuild later and it works, for given values of work. Stupid race conditions between System.out and System.err, and a pox upon Java and Eclipse for doing weird things with buffering.

Comments

[tau-iota-mu-c.livejournal.com]

I came to the conclusion a few weeks ago that there really does not seem to be a point anymore to buffering of STDIO in any language.

If it's I/Outputting to a screen, then there's not enough data involved to worry about efficiency (come on, X/the console is going to be slower than what an unbuffered print can achieve anyway). If its outputting to a pipe, then you can't tell whether that pipe cares about getting data immediately, or whether its a harmless filter that's just going to end up dumped into a file.

So many log programs just aren't useful once you've used a grep or perhaps two in the pipeline. IIRC, tail -f /var/log/blah | grep -v 'asd' | grep -v 'bsd' is buffered, perhaps because grep itself decides to buffer the output if it is outputting to a pipe (and a big fat warning is associated with the non-default --line-buffered switch in the manpage. Won't anybody think of the poor performance!?). That's no use when you want realtime output.

All my programs (that I remember about -- it's helped when I use my hiliteStdErr program which colours stderr and stdout differently) do an eqivalent of:

select(STDIN ); $| = 1; #input is unbuffered
select(STDERR); $| = 1; #output is unbuffered
select(STDOUT); $| = 1; #output is unbuffered