Matthew Mondor <mm_li...@pulsar-zone.net> writes: > I'm unsure if it's because we are too few on this list, if ECL users > are alltogether too few (I know the CL community itself is not large), > or if it's because most ECL users don't consider themselves qualified, > but I do remember Juan asking a few times on this list for help, and > recently he reminded us that noone actually joined the project yet. > It's also possible that at such requests we had no idea in which > direction help was needed.
> I'm reticent to ask to officially maintain ECL for the following > reasons: > > - Time constraints, as always I'm in a similar situation. While I would be enchanted to be able to maintain ecl (and improve it notably on iOS and Android), the big problem is that of time (ie. money). The other points could be solved on the job. > - I think that eventual transparent support for "UTF8-B" with streams > would be a good idea. In this mode invalid UTF-8 sequences would be > read and mapped automatically to characters within the UTF-16 > surrogate range, to preserve their original octets. In output mode, > those would be output as octets. This would provide lower overhead > than having to use signals to detect invalid sequences and restarts > to convert them, and would allow to preserve the original "mixed > encoding" data. Examples where mixed UTF-8 and LATIN-* data are > common are filenames in some file systems, IRC lines, etc. Currently > one can gracefully deal with these when treated as bytes or 8-bit > characters, unless one also needs to have an extended character set > interface, in which case some conversion must be done anyway. > If I remember there exists a limitation in the current system to > easily implement this without touching the stream or > encoding/decoding system much, but I forgot the details (I have notes > somewhere on this though). The HTML experiment would indicate that this is probably not a good idea. Recovering the meaning of invalid byte sequences and converting them to a normalized form can be the job of a tool, but it should not be done automatically by general applications. When reading utf-8 or other unicode streams, invalid byte sequences can signal errors, be substituted by a given character, or be encoded into application reseved code points to be able to transparently transmit the invalid byte sequence. Cf. clisp :INPUT-ERROR-ACTION parameter of ext:make-encoding (clisp encodings are external-format values). http://clisp.org/impnotes/encoding.html#make-encoding -- __Pascal Bourguignon__ http://www.informatimago.com/ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
