[EMAIL PROTECTED] (Paul Jarc) writes:
>
> But the output can be immediate without splitting it up into multiple
> system calls. (display "foo") can result in write(1, "foo", 3), and
> as long as that write is done before (display) returns, it's still
> just as immediate.
Yep, that's the sort of c
Kevin Ryde <[EMAIL PROTECTED]> wrote:
> Alas I think that'd be an incompatible change, programs printing a
> prompt or progress info probably depend on immediate output as the
> default.
But the output can be immediate without splitting it up into multiple
system calls. (display "foo") can result
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> We could certainly do this, but I think I remember a thread where it was
> suggested that we treat any occurrence of a macro in non-car position as
> an error - which would catch the problem more generally.
I suppose it depends if a macro should be a f
Play Backgammon for Real Money or for Free!
Unsubscribe
<><>___
Guile
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Actually, I hadn't considered using it because `stdout' is line-buffered
> by default, at least on GNU/Linux
Guile doesn't actually use stdio.
> (SUSv2 states that it shall be "fully-buffered" by default [1, 2]).
Fully buffered on a non-tty. On a
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> What happened to the port buffering?
Indeed, it occurred to me that this is easily fixed by making the port
line-buffered with `setvbuf'...
Actually, I hadn't considered using it because `stdout' is line-buffered
by default, at least on GNU/Linux (SU
