[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
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ecl-devel