Real time input

[hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle)]

Edward Loper writes:
 > functions.  I'm trying to make a program which will read 
 > characters as they are typed, but do other things if they 
 > are not typed.  This is, as far as I can tell, the 
 > function of read-char-no-hang.  However, clisp seems to 
 > wait until a newline has been pressed before putting 
It's not really CLISP, CLISP is simply reading characters in cooked
mode, using some OS-supplied functions. Cooked-mode reads one line at
a time, leaving you the usual editing capabilities of your console.

 > also seems to echo each character to the screen when it is
 > typed; I would prefer if it would let me handle this.  Is
You have to leave cooked-mode for this to work.

 > there a special variable which I need to set in order to
 > tell clisp that I want each character put into the input
 > buffer as it is read?  Or is there some other way in which

There are different things one can do.

First there is (sys::terminal-raw *terminal-io* T/NIL) available on
some platforms (Amiga, UNIX, ACORN). On the Amiga (newer CLISPs), this
will do exactly what you want, namely no echo, read one character at a
time, working listen and read-char-no-hang. However the draw-back is
that if you enter the debugger or if your program requests input,
you'll be left in raw-mode and very disappointed (the next version
might switch modes in the debugger). You have to switch modes
yourself. Some implementations of CLISP switch modes internally,
causing portability problems.

Then there is (with-keyboard (read-char *keyboard-input*)) which uses
terminal-raw or some other magic. Following the documentation, it is
forbidden to access *terminal-io* (thus normally also
*standard-output*) while with-keyboard is active. Thus it's also
forbidden to enter the debugger then, if *debug-io* is synonym to
*terminal-io* as usually is the case :-)

All of the above is specific to CLISP.


 >   1. How portable is the screen package?  Is it only portable across

 >      or is it only implemented in clisp?
That's the answer.

 >   2. Because clisp doesn't compile to a machine-specific binary, is
 >      there no way to make a stand alone executable?  Is there some
Why do you absolutely need a stand alone executable? Why can't you
start a binary with some switches?
 >      way to link clisp and my program into one binary file, and if
 >      so, do I have to worry about licensing stuff etc?  
See the newer foreign stuff, which allows you to link .o files to
CLISP, or build an own version of CLISP (primarily add some
functions). In this case, main() remains in the control of CLISP though.

 >      would be to add a step to the compiler, specific to a particular
 >      architexture, which would translate the intermediate language
 >      representation into machine instructions."  I was wondering if
Why not use one of the Common-Lisp to C compilers around then?

 	Joerg Hoehle.
hoehle@inf-wiss.uni-konstanz.de