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

Re: CLIM philosophy wrt to X.

  Date: Mon, 26 Aug 91 13:00 EDT
  From: "David C. P. Linden" <DCPL@fuji.ila.com>
  Subject: Re: CLIM philosophy wrt to X. 
  To: kanderso@BBN.COM, "David C. P. Linden" <DCPL@fuji.ila.com>
  cc: chee@isi.edu, clim@BBN.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).

Perhaps, but things never seem as optimized as i might like.  Sometimes,
i'd rather rely on things i know i can implement quickly, rather than wait
for an optimizer.

The DRAW-...* functions are an example of this.  Since they take a large
pile of keywords they rely on compiler optimizers to over come the cost of
cracking the keywords on every call.  These optimizers may not exist in
every CLIM implementation, such as Lucid for CLIM 0.9.  Another other
implementation, such as letting WITH-DRAWING-OPTIONS handle the keywords,
might not have required optimizers to improve performance.
  
      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.
  
      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.
  
That's almost right, i guess i have trouble with the semantics of
WITH-BUFFERED-OUTPUT and how i'd use it.

Lets say WITH-BUFFERED-OUTPUT looks something like this:

(defmacro with-buffered-output ((stream buffered-p) &body body) ...)

I'm having trouble figuring out when i'd ever say (WITH-BUFFERED-OUTPUT
(STREAM NIL) ...).  Maybe:

1.  If i wanted to simulate a DW application in X, i could wrap
WITH-BUFFERED-OUTPUT around the whole thing.  But that would lead to
performance lossage.

2.  If i was doing low level stuff like a rubout handler.

I guess i'm just afraid that too much unbuffering would happen.  While i've
been burned with the Genera network example too, i'd rather think of
FORCE-OUTPUT as a way of SYNCRONIZING the display with the application than
have anthing to do with BUFFERING.  

      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."

Yes, i guess this is like X doing a FORCE-OUTPUT whenever a mouse event
happens.  This is how our users have learned that slowly rubbing the mouse
over a window helps their results appear.  Of course, it doesn't speed up
anything, it just gives them something to look at while they wait.

0,,
References:
Main Index | Thread Index