>>>>> "Sam" == Sam Steingold <sds@...> writes:
>> * In message <3AD48ECF.15A33202@...> * On the subject of
>> "[clisp-list] internationalization problem" * Sent on Wed, 11
>> Apr 2001 19:05:20 +0200 * Honorable bernard URBAN
>> <bernard.urban@...> writes:
>> $ clisp -q -norc -L francais > (/ 0) *** - Message
>> inimprimable *** - invalid byte #xF3 in CHARSET:UTF-8
>> conversion, not a Unicode-16
Sam> Please try the following: - build libiconv (part of CLISP) -
Sam> install libiconv - reconfigure and re-build CLISP.
Done, but problem remains the same.
Outside Solaris, I also have the same problem on a Linux (Debian) box.
On Solaris, I tried the clisp-2.25.1 binaries, same problem.
More details on Solaris:
libiconv.a and libintl.a are build in base and full directories.
There are Sun /usr/lib/libintl.so and /usr/include/iconv.h on
my Solaris box. clisp insists on building libiconv.a, even if it
detects this system iconv.
It would be helpful to start from a platform where these things work.
I guess that Bruno Haible uses the german interface and it works for
him, so what is he using for his computer ?
Last time I had a working internationalized clisp was on HP-UX
(version from 1999).
This bug is really annoying to investigate, as by definition, most
messages printing in the clisp debugger are subject to the same error,
so you have an error in the debugger itself,
and so all things end messed up. At least, I have no infinite loop...
Perhaps printing in the debugger should be (optionally) formatted
without internationalization ?
>> And about internationalization, how do the clisp developpers
>> edit their files with all these Unicode codings ? Basic emacs
>> does not seem to understand Unicode.
Sam> Emacs 21 does - that's what I use (I have access to the CVS).
Ok, you are ahead of the crowd... I will try some japanese (!) MULE
extension which is rumored to do Unicode.
Thank you for trying to help on this topic.