[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 tty you're right the tradition is line buffered output. > But it looks like Guile's file ports are unbuffered by default. Ah yes, on a tty. (scm_init_standard_ports in init.c.) > Maybe _this_ should be changed? Alas I think that'd be an incompatible change, programs printing a prompt or progress info probably depend on immediate output as the default. (In C stdio a prompt is handled by stdout automatically flushing when stdin is read, but there's no such interlock in guile, I think.) It'd be good to add a bit to the manual somewhere about this. I just realized I struck something similar to what you're talking about only the other day, running a guile subprocess from emacs. I fiddled about with strings to ensure decent size chunks got written for performance. (Emacs uses a pseudo-tty to talk to subprocesses, rather than a pipe.) > It looks better to call `scm_lfwrite ()' once than `scm_putc ()' for > each character, especially since `scm_putc ()' calls `scm_lfwrite ()' Yes, but I would limit that to what can be done easily locally, like two adjacent putcs turned into one write. I'd leave general sort of buffering to the port or an application. > `scm_lfwrite ()' does this so Guile code doesn't have to care about it. Yep, format.scm started as portable to systems without builtin output column tracking, I think. I thought of changing to use the port as a simplification, I guess it's also an optimization. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
