Sam Steingold wrote:
>this is apparently because your iconv (libiconv or libc) does not
>support this encoding.
>can you check it with "iconv --list"?
clisp> iconv --list
The following list contain all the coded character sets known. This =
not necessarily mean that all combinations of these names can be used =
the FROM and TO command line parameters. One coded character set can =
listed with several different names (aliases).
10646-1:1993, 10646-1:1993/UCS4, ANSI_X3.4-1968, ANSI_X3.4-1986, =
ASCII, CP367, CSASCII, CSUCS4, IBM367, ISO-10646, ISO-10646/UCS2,
ISO-10646/UCS4, ISO-10646/UTF-8, ISO-10646/UTF8, ISO-IR-6, =
ISO646-US, ISO_646.IRV:1991, OSF00010020, OSF00010100, OSF00010101,
OSF00010102, OSF00010104, OSF00010105, OSF00010106, OSF05010001, =
UCS-2BE, UCS-2LE, UCS-4, UCS-4BE, UCS-4LE, UCS2, UCS4, UNICODEBIG,
UNICODELITTLE, US-ASCII, US, UTF-8, UTF8, WCHAR_T
>I have a patch for your to comment upon that I'll submit in=20
>the next few days.
Sam patched the exact same lines - differently - in encoding.d as a =
response to my e-mail. I did not test his patch.
I still have a patch to another file in that matter, waiting for =
Note however that it hit me that CLISP's playing games with uninterning =
or exporting symbols from package CHARSET is broken w.r.t. shared =
Shared libraries mean that the available encodings should be =
redetermined for every run.
What CLISP does is to cache this information from its first run, and =
use that when restarted from an image. [I first thought that it may =
reduce even further the number of exported symbols, since it may again =
unintern some of the remaining symbols, but CLISP does not call =
init_encodings anymore when loading from an image].
Symbols are never made visible (interned into package CHARSET) again.
1. if you distribute an image built on a system with few encodings, =
you'll never be able to use encodings on a system having many of them.
2. when you update your own shared libiconv to add more encodings, =
CLISP will not notice until you recreate an image. That's certainly not =
what users expect from dynamic libraries.
IMHO, this concept about uninerning symbols from CHARSET needs =
A. have a set of symbols as large as possible, and have BOUNDP() =
uniquely determine availability or not. That may be an incompatible =
B. unintern as previously but also reintern+export from CHARSET when =
available. Note that this may create strange behaviour with image files =
created by users, since they may hold these symbols in data structures, =
and then they suddenly become uninterned. I'm not sure about possible =
E.g., a hypothetical (function-lambda-expression) of my utf-16/ffi =
testcase would then show up as
(with-foreign-string (... :charset #:utf-16) ...)
which looks weird, to say the least.
Uninterned symbols present the risk that people then may create =
charset::utf-16 themselves, while CLISP internally still has a grasp on =
its S(utf16) symbol -- the uninterned one, not EQ...
Package COMMON-LISP exports a known and constant set of symbols. Maybe =
CHARSET should behave the same -- the issue is open.