CLIM mail archive
[Prev][Next][Index][Thread]

Re: CLIM philosophy wrt to X.

    Date: Mon, 26 Aug 1991 13:00 EDT
    From: "David C. P. Linden" <DCPL@fuji.ila.com>

	Date: Mon, 26 Aug 91 11:28:57 -0400
	From: kanderso@BBN.COM

	  Date: Mon, 26 Aug 91 09:45 EDT
	  From: "David C. P. Linden" <DCPL@fuji.ila.com>
	  Subject: CLIM philosophy wrt to X.
	  To: chee@isi.edu, clim@BBN.COM

	I don't think a macro would be a good idea because:

	1.  it would require low level routines to check if they should buffer or
	    not, and they are already slow enough.

    The check cost could be as low the cost of a SLOT-VALUE operation.
    Optimized implementations might manage to put this inline with the
    output methods instead of defining :AFTER methods (which would introduce
    more slowness).

	2.  if the macro was implemented as a closure, this would cons in those
	    Common LISP's that still don't stack allocate closures.

    I think with-buffered-output is intended to be a sufficiently high level
    macro that it is executed infrequently enough compared to the rest of
    the program that consing a closure is relatively insignificant.

Of the five Lisp implementations I use, none would cause anything to
be consed for an implementation of WITH-BUFFERED-OUTPUT that writes a
simple continuation function.

	3.  Usually i don't want lots of operations unbufferred, i just want to be
	    sure  the  buffer is flushed by a particular time.

    and that's what force-output is for.

    I think the original question was "What is CLIM's stance/convention on
    getting output forced to the target, especially for interactive
    streams?"  X apparently requires programs to use a force-output
    mechanism.  Genera's DW doesn't.  I know from hard experience that many
    a Genera network program of mine didn't work initially because network
    streams are buffered and I forgot to do a FORCE-OUTPUT.  If I may
    suggest some words into your (kanderson's) mouth, it sounds like you are
    saying "I'd rather not get in the habit of depending on some streams
    being auto-force-output, or even being tempted by having the option to
    enable auto-force-output.  I'm content with sprinking calls to
    FORCE-OUTPUT in places I deem appropriate."  Is that a fair statement?
    It is reasonable and certainly safe across all HW&SW platforms that I
    can imagine.

	I'd rather just put FORCE-OUTPUT's where i know i really want the output
	buffer emptied.  I don't mind this being a noop on streams that don't
	buffer.

	It would be reasonable for CLIM to put FORCE-OUTPUT's in some obvious
	places like the loop inside TRACKING-POINTER, but i also think it is
	reasonable to expect a developer to add others too.

    General (beyond Lisp and CLIM) philosophy: There is one
    auto-force-output scenario I think all bidirection streams should adher
    to, and that is: "Doing a <read> operation with an empty read buffer
    should do a FORCE-OUTPUT."

CLIM 1.0 attempts to do this, but I cannot honestly claim that it does a
complete job.  If it does not, it's a bug that should be reported.

0,,
Follow-Ups: References:
Main Index | Thread Index