[clisp-list] READ-BYTE-ARRAY now accepts :NO-HANG keyword argument + RFE: how much could ext:convert-from-string process?

[Hoehle, Joerg-C. <Joe...@t-...>]

Hi,

Sam wrote:
>when you call READ-BYTE-ARRAY with :NO-HANG T and the sequence being a
>(VECTOR (UNSIGNED-BYTE 8)), it performs at most one read(2) call and
>returns whatever is available:
There's progress.

No-hang is misleading, as it depends on the programmer having set non-blocking-mode on this socket. This is not strictly necessary when using select()/poll() loops. The call may well hang.


I believe the next thing that people will ask for is how to deal with multibyte encodings.

I think that EXT:CONVERT-STRING-FROM-BYTES should return an extra value (like PARSE-INTEGER) to indicate whether it could process everything (NIL, as for typical :END convention) or stopped earlier (index, as in PARSE-INTEGER, usable as :END or :START) because it hit an incomplete character.

So people could combine partial (or no-hang) reads and conversion to characters and produce correct sequences.

Note that this does not solve CRLF issues. Converting "A<CR>" can be considered complete (Mac style), but processing the following "<LF>B<CR><LF>" must not yield two lines.


>a similar interface to write(2), i.e., WRITE-BYTE-SEQUENCE :NO-HANG,
>is trickier: it is not clear how WRITE-BYTE-SEQUENCE should indicate
>incomplete output.  maybe an extra return value?
Sounds reasonable.
>or maybe make it always return the same as READ-BYTE-ARRAY -
>the number of elements processed?
That's too late, as this function has been available for many years and documented as returning the sequence. An extra value is the only option. Unless you introduce a new function, which is not your favourite choice (you prefer adding keywords).

Regards,
	Jorg Hohle.