Subject: [clisp-list] read-line (clisp 2.30/woody) - read-no-hang-p and (format ~A)

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Thu Jan 23 04:50:03 2003

Michael Koehne wrote:

>> It's not that good an idea to write out a string using 
>(format t "~A" #)
BTW, never use that. That's what PRINC can do directly
And (format nil "~A" x) is PRINC-TO-STRING or

	(WRITE-TO-STRING x :escape nil)
where you even can add many additional keywords like :base for *print-base* etc.
It's worth looking it up!

>  when you expect to look at non-printable characters.
>  *hm* whats the best way doing this ?
I recently used (format t "-~:C-") -> -a--Newline--a--Null--Bell-

>> >  I think I need two low level lisp functions :
>> >        (unix-read array &optional stream) => count; errno
>> >        (unix-write array &optional stream) => count; errno
>> Such a partial result only makes sense for the smallest entity:
>
>  !NO! - think about 1000 users ;-( I want to read complete blocks,
>  as they are, as they come - low level. So only !ONE! read() call
>  per socket that has input. So i just need access to the low level
>  read and write. To implement the logic in LISP.

I was unclear. READ-SOME-[8bit]BYTES does exactly that: one call. I was saying that there should be no READ-SOME-CHARS or above, as anything which can take more than 1 byte is causing headaches. There also was a thread in comp.lang.lisp last year about this.

Here I quote Duane Rettig (from Allegro CL fame) in comp.lang.lisp: Checking for EOF
>simple-streams offers a read-no-hang-p function to check _any_
>avaiability of data on the stream, including just one octet, whereas
>listen, stream-listen, and read-char-no-hang all try to build a
>character, and might end up either giving you a false end-of-file
>indication half-a-character early, or else never giving you an eof
>(each being consequenses of not being able to complete that last
>character).

>> My feeling is that CLISP ought to implement simple streams natively.
>  a simple stream means that there is 1 process waiting for read-line ?
It has nothing to do with processes. IMHO it's a layered API to composable streams, where the lowest-level works in terms of 8bit bytes and above everything is possible.
http://www.cliki.net/simple-stream
There was also a speak or tutorial on them at the recent intl. Lisp conference (ILC).

>  does clisp has its internal multithreading ? or internal processes ?
Not for the moment. There's also nothing similar to the cheap CMUCL functionality of input dispatchers (like in Emacs-Lisp): when waiting for input from the keyboard, CMUCL and Emacs check other fd/sockets for input and call handlers.

Regards,
	Jorg Hohle.