[Ecls-list] Sequence streams

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Mon Aug 29 07:27:52 UTC 2011

On Mon, Aug 29, 2011 at 8:13 AM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> If I understand the above, READ-CHAR on a binary/bytes sequence stream,
> created on top of an array of UTF-8 octets would then work if the
> EXTERNAL-FORMAT was UTF-8 (and signal a decoding error with restart on
> invalid octets).

Yes, it works like a file.

> If that's what it means, this is what I need.  I need
> to leverage ECL's UTF-8 decoder to convert arbitrary binary byte/octets
> to create unicode strings[...]
> I also need to be able to encode ECL unicode characters (and strings,
> also without worrying about the internal representation) to UTF-8
> binary octets

Ok, then you should be safe with the first part of the example.

I understand that ECL uses the internal representation that it wishes
> (currently UBCS-4 for unicode, or LATIN-1), and that string streams will
> also use that, and I shouldn't have to worry about it.

Yes, that's how string streams work. And that's why there is no
:external-format there. We could have extended them, but I prefer to keep
ANSI CL and our extensions well separated.

> On a tengent, I remember a previous thread where the internal ECL
> unicode format representation was discussed, that it could perhaps be
> changed eventually, at least on Windows

I was discouraged to do so in the end.

> Unfortunately the mmap changes broke the ECL build and I couldn't
> immediately test your latest changes:

I am a bit surprised about this. I removed MAP_FILE because it does not work
in Solaris and the POSIX specifications says it is not needed: MAP_SHARED
should make the changes available for other processes immediately. Moreover,
the Linux man page and the OpenBSD one both state that MAP_FILE is default
and just a compatibility leftover... I will investigate, though, but I am a
bit confused.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110829/d670c2f7/attachment.html>

More information about the ecl-devel mailing list