[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
common lisp stream to an X window
It's true that traditional Common Lisp input functions really can't be
directly supported using the message/event paradigm of window systems
like X, Microsoft Windows, or the Macintosh. This is a real pain when
one wishes to call READ on user input. An intermediate facility is needed
to `turn around' the input paradigm.
Gold Hill gets around this problem with Window Streams, which are an
extension to Gold Hill Windows (a simplification of Common Windows).
Unlike Common Windows (at least in the earlier drafts), windows are
not streams. Window streams are only used to provide traditional
(blocking) input and sequential output operations that are required by
the stream paradigm. Window streams are connected to windows, they
are not a kind of window.
There is still a traditional thread of computation that is not event
driven in GCLisp even under Gold Hill Windows, in which the Lisp
Listener runs. When a keystroke occurs, the CHAR-IN method for a
window to which the window stream is attached places the character in
a ring buffer. When a character is needed (through a call to
READ-CHAR, for example), if one is in the buffer, it is pulled out,
otherwise the Lisp thread `waits' and tries again.
Under Gold Hill Windows, this is implemented by repeatedly calling a
function which yields control back to the window system and allows
things to happen, the hope being that somebody will hit a key, thus
updating the buffer and causing the thread which is waiting for a
character to advance.
It was easy to implement Window Streams in GCLisp because all the
neccessary functions are available from Gold Hill Windows (the ``allow
events'' primitive was requested by me, but even then there were other
scheduling primitives that could have been used, albeit with the
consequences of sluggish typeahead response), and GCLisp has a
advertised and well-defined protocol (much like NIL and the Lisp
Machine) for new kinds of streams that are acceptable to Common Lisp
IO functions. (Of course, being an insider, I used inside information
to speed up output, but that's only a performance issue.)
You said that Unix file handles are available -- I thought Unix CL
implementations offered functions that made Lisp streams out of Unix
file handles. Of course, maybe character IO to such file handles
really doesn't work anyway.
If you can't make a new kind of stream, or if window streams are not
provided, READ is useless. One gross hack is the following:
1. Set aside a string buffer for expression input.
2. Have the character input method for your window
do the following:
* VECTOR-PUSH-EXTEND the character
* Does READ-FROM-STRING get an error (use eof-errorp NIL) ?
Yes: Do nothing
No: Stash or return the result
I think that a Common Lisp window system interface should offer some
facility for streams connected to windows, otherwise a great deal of
the IO power is lost.