Re: CLIM philosophy wrt to X.

• To: "David C. P. Linden" <DCPL@fuji.ila.com>
• Subject: Re: CLIM philosophy wrt to X.
• From: kanderso@BBN.COM
• Date: Mon, 26 Aug 91 11:28:57 -0400
• Cc: chee@isi.edu, clim@BBN.COM
• In-Reply-To: Your message of Mon, 26 Aug 91 09:45:00 -0400. <19910826134509.6.DCPL@DIAMOND-HEAD.ILA.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
  
  
  Some of your concern is addressed by a
  thought-about-but-never-implemented macro called with-buffered-output.
  The full semantics have never been absolutely clear (including the
  default), but the intent is to give some control back to the programmer
  to say "The output in this dynamical scope is to be forced out as it
  happens" and "The output in this dynamic scope may be buffered (e.g.,
  for efficiency and speed)."  Would this be an acceptable solution to
  your concern, or do you need more?

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.

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

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

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.

k

0,,

• CLIM philosophy wrt to X.
• From: "David C. P. Linden" <DCPL@fuji.ila.com>

• Prev: CLIM philosophy wrt to X.
• Next: Re: CLIM philosophy wrt to X.
• Index: CLIM Mailing list (5-Oct-90 to 31-Dec-91)
• Thread: CLIM Mailing list Index (5-Oct-90 to 31-Dec-91)