Help!
How do I read input character by character *absolutely* controling the
behavior
of the reading function (i.e. using the read characters to perform
actions)?
Sounds simple but I'm totally frustrated as of right now.
The problem is that Allegro CL *insists* on using #\Newline to buffer
read-line
and further interprets #\Newline for read and read-char. The result is
that it seems
mpossible to actually read #\Newline (at least from a terminal) and perform
my own
action on it.
My application requires using #\Newline and terminates input on another
character
(#\.).
Any suggestions?
setting the macro characters has also not worked to this point.
Thanks!
Kirt Undercoffer
From: Kirt Undercoffer
Subject: Re: How do I read input char by char?
Date:
Message-ID: <5il9hc$6vb@portal.gmu.edu>
Kirt Undercoffer (········@osf1.gmu.edu) wrote:
: Help!
: How do I read input character by character *absolutely* controling the
: behavior
: of the reading function (i.e. using the read characters to perform
: actions)?
: Sounds simple but I'm totally frustrated as of right now.
: The problem is that Allegro CL *insists* on using #\Newline to buffer
: read-line
: and further interprets #\Newline for read and read-char. The result is
: that it seems
: mpossible to actually read #\Newline (at least from a terminal) and perform
: my own
: action on it.
: My application requires using #\Newline and terminates input on another
: character
: (#\.).
: Any suggestions?
: setting the macro characters has also not worked to this point.
: Thanks!
: Kirt Undercoffer
From: Kirt Undercoffer
Subject: Re: How do I read input char by char?
Date:
Message-ID: <5ilbd0$p93@portal.gmu.edu>
Sorry about the previous duplicate - I'm using a new laptop
and am unused to the keyboard.
Kirt Undercoffer (········@osf1.gmu.edu) wrote:
> > How do I read input character by character *absolutely* controling the
> > behavior
> > of the reading function (i.e. using the read characters to perform
> > actions)?
> > Any suggestions?
>
> How about reading bytes?
That hasn't been successful either. It could be Allegro Cl although I'm
hardly a Lisp expert. I was just about to post a clarification to what I
wrote -the problem is specifically with terminal io and nothing I do to
the readtable alters the behavior. Setting the behavior of #\Newline to
#\p (set-macro-character #\Newline (get-macro-character #\p)) followed by
(set-syntax #\Newline (get-syntax #\p)) where I just selected #\p because
it's definitely a constituent and close to my enter key doesn't work (I
had set #\. similarly from the #\Newline attributes prior to this).
All the books I read say that the reader is taking it's orders from the
readtable but altering the readtable to make #\Newline a constituent and
#\. a terminating macro has no effect whatsoever in Allegro CL. And
that's what I'm currently using.
I'd like to continue using Lisp (first of all I'm too deeply committed to
finishing a project not to and I do use Lisp to prototype programs at
work) but it really does seem at this point that this is an area in which
it appears *at this point* to be inferior to C/C++/Pascal/name your
imperative language.
All imperative language texts (okay - most of them, maybe not all) have a
scanner/parser example in the rudimentary sections of i/o material. I've
yet to find one such example for Lisp in general (although I have a whole
book on basically using Lisp to develop interpreters - it also seems not
to cover this problem as near as I can tell). Other examples in Netland
dealing with Lisp implementing interpreters do not *obviously* deal with
this either (CGOL is a good example - I don't know if it deals with this
or not - it *seems* not to).
My point here, aside from *really* needing to implement this, is that I
can easily write a loop in any imperative language collecting input
character by character without having the compiler interpret the
characters. So far, there seems to be no obvious way to turn off this
line buffering behavior and I've been at it off and on for quite a while.
Kirt Undercoffer
········@osf1.gmu.edu
In article <··········@portal.gmu.edu>,
Kirt Undercoffer <········@osf1.gmu.edu> wrote:
..
>Kirt Undercoffer (········@osf1.gmu.edu) wrote:
>
>> > How do I read input character by character *absolutely* controling the
...
>> How about reading bytes?
>
>That hasn't been successful either. It could be Allegro Cl although I'm
>hardly a Lisp expert. I was just about to post a clarification to what I
If you are trying to gather bytes off of the standard I/O (i.e. the Listener)
I don't think that stream allows byte-by-byte access... However, if you can
read your input from a file.....
(defun binfile-2-seq ( path )
"Read bytes out of the given file named by path producing a
sequence containing the corresponding bytes. Return NIL if there
determining the size of the file."
(with-open-file ( strm path
:direction :input
:element-type 'unsigned-byte )
(let ( (file-size (file-length strm)) )
(when file-size
(loop for index from 0 below file-size
with byte-vect = (make-array file-size
:element-type 'unsigned-byte)
do (setf (elt byte-vect index) (read-byte strm ))
finally (return byte-vect))))))
Now you are going to have to change those bytes back into characters if you
wish to use them as such. If the result of calling the above
were a bound to BYTE-VECT then (coerce (elt byte-vect index) 'character)
would retrieve the character at the given index.
Of course you don't have to read ALL of the stream like the above. :-)
( an example of reading/writing bytes is in Graham's ANSI Common Lisp book
it does a byte for byte copy of a file. )
>wrote -the problem is specifically with terminal io and nothing I do to
>the readtable alters the behavior. Setting the behavior of #\Newline to
>#\p (set-macro-character #\Newline (get-macro-character #\p)) followed by
If you're changing the Listener's readtable then perhaps they might stop
you from doing something "crazy" with it... like change #\Newline ...
for the read-eval-print loop that is a significant character. You'd
*never* be able to recover by issusing a
(setq *readtable* (copy-readtable nil))
at the prompt to get the "default" settings back. This is a copy of
readtable you are updating right? If it isn't then perhaps they
trap on this and ignore it... of course if they did they should
have issued a error/warning saying they couldn't comply.
Beyond that... venturing into the mysteries of the readtable is
an area I usually avoid...
--
Lyman S. Taylor "emacs - ... Do NOT use vi to edit your programs.
(·····@cc.gatech.edu) Watching you stuggle through the
edit/compile/debug cycle [with ] vi
will make me despair of your sanity..."
P. N. Hilfinger CS 164 Fall '92 Syllabus
In article <··········@pravda.cc.gatech.edu>,
Lyman S. Taylor <·····@cc.gatech.edu> wrote:
...
>
> at the prompt to get the "default" settings back. This is a copy of
> readtable you are updating right? If it isn't then perhaps they
P.S. How come common lisp doesn't have some construct similar to
WITH-OPEN-FILE for readtables? Something like:
(with-alternative-readtable ( ... any new initial remappings )
.... body ... )
Which would do a restore once exiting the body whether directly
or by an exception.... That way even if there is some sort of
catastrophic error things would be restored to normal once back
at the listener.
Of course I guess everyone could write their own... :-)
--
Lyman S. Taylor "emacs - ... Do NOT use vi to edit your programs.
(·····@cc.gatech.edu) Watching you stuggle through the
edit/compile/debug cycle [with ] vi
will make me despair of your sanity..."
P. N. Hilfinger CS 164 Fall '92 Syllabus
In article <··········@portal.gmu.edu>,
Kirt Undercoffer <········@osf1.gmu.edu> wrote:
..
>the readtable alters the behavior. Setting the behavior of #\Newline to
>#\p (set-macro-character #\Newline (get-macro-character #\p)) followed by
>(set-syntax #\Newline (get-syntax #\p)) where I just selected #\p because
well on the three lisp implementations I tried
(get-macro-character #\Newline) returns NIL.
So whatever is implementing this "policy" doesn't seem to be implemented
throught that mechanism.
I guess the disconnect is that you are sharing "standard in" with the
Listener. There may be a vendor specific call to be made, but there
probaby wouldn't be a portable way of specificing how this can be
done so it isn't in the language per se. In addition to making sure the
Listener regains control in some sort of reasonable state. Plus to make
things interesting....
? (your-fcn .... ... ) (some-other-expression .. )
when you function is executing what status is standard in? Has
the some-other-expression s-expression been read yet? Should it
be there after you get done? It would seem that you're "scanner" would
have to interact with the Listner's. Again kind of tough to specify in
a language standard.
--
Lyman S. Taylor "emacs - ... Do NOT use vi to edit your programs.
(·····@cc.gatech.edu) Watching you stuggle through the
edit/compile/debug cycle [with ] vi
will make me despair of your sanity..."
P. N. Hilfinger CS 164 Fall '92 Syllabus
While looking for something else on the CMU Lisp Repository, I ran
across the following:
CBREAK: Turns CBREAK mode on and off to allow Lisp to read the input
character by character.
lang/lisp/code/io/cbrk/
Most UNIX-based Lisp implementations buffer the input until a
carriage return is seen. This means that functions like
READ-CHAR, LISTEN and READ-CHAR-NO-HANG don't work as the
programmer might expect. For example to reply to Y-OR-N-P, one not
only has to type a Y or N, but hit the return key as well.
This package contains example code that shows how to turn CBREAK
mode on and off from within Lisp.
Copying: Public Domain.
CD-ROM: Prime Time Freeware for AI, Issue 1-1
Author(s): Mark Kantrowitz,
Keywords:
Authors!Kantrowitz, CBREAK Mode, IO, Input, Lisp!IO, Output,
Public Domain
References: ?
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu