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