[Ecls-list] Sequence streams

[Juan Jose Garcia-Ripoll]

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.

Juanjo


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