Hello:
(write-line "¦¨¥\") failed in both SBCL and Corman Lisp,
because the character "¥\" is a5 5c, while 5c is backslash \
Those Chinese characters work in most moderen language like Java,
C#, Ruby,
and in recent C++ compilers it works too.
I am not sure if these Chinese characters are currently unsupported,
or if some configuration needs to be set.
·············@gmail.com" <············@gmail.com> writes:
> (write-line "成功") failed in both SBCL and Corman Lisp,
I tried via Emacs/Slime with this configuration (I used the first one
for sbcl):
(setq slime-lisp-implementations ; choose alternative with M-- M-x slime
'((sbcl ("/usr/bin/sbcl" "--noinform") :coding-system utf-8-unix)
(sbcl-l1 ("/usr/bin/sbcl" "--noinform"))
(clisp ("/usr/bin/clisp" "-K full"))
(cmucl ("/usr/bin/cmucl" "-quiet"))))
CL-USER> (write-line "成功")
成功
"成功"
Just works. :)
If I use sbcl-l1 I get a warning from slime about coding system mismatch.
--
Stefan.
·············@gmail.com" <············@gmail.com> writes:
> Hello:
>
> (write-line "成功") failed in both SBCL and Corman Lisp,
> because the character "功" is a5 5c, while 5c is backslash \
You are wrong. 功 is 529F.
C/USER[2]> (princ #\ua55c)
ꕜ
#\UA55C
C/USER[3]> (format t "~X" (char-code #\功))
529F
NIL
C/USER[4]> (princ #\u529f)
功
#\U529F
C/USER[5]>
http://www.cliki.net/CloserLookAtCharacters
> Those Chinese characters work in most moderen language like Java,
> C#, Ruby,
> and in recent C++ compilers it works too.
> I am not sure if these Chinese characters are currently unsupported,
> or if some configuration needs to be set.
The problem is that you need to specify the character encoding to be
used for files and terminals.
With sbcl and clisp (I don't know for Corman Lisp), you can specify
the encoding in LC_CTYPE:
[···@thalassa tmp]$ export LC_CTYPE=en_US.UTF-8 ; sbcl --userinit /dev/null
* (write-line "成功")
成功
"成功"
*
--
__Pascal Bourguignon__ http://www.informatimago.com/
Un chat errant
se soulage
dans le jardin d'hiver
Shiki
Pascal Bourguignon ¼g¹D¡G
> ·············@gmail.com" <············@gmail.com> writes:
>
> > Hello:
> >
> > (write-line "¦¨¥\") failed in both SBCL and Corman Lisp,
> > because the character "¥\" is a5 5c, while 5c is backslash \
>
> You are wrong. ¥\ is 529F.
The code I mentioned is not unicode, it's the encoding of
big-5(codepage 950), that's why there is a backslash in the second byte
of the character.
············@gmail.com wrote, On 14/12/06 3:03 PM:
> (write-line "���\") failed in both SBCL and Corman Lisp,
Are you trying this in an emacs buffer using SLIME? If you are, try
putting this in your ~/.emacs file
(setf slime-net-coding-system 'utf-8-unix)
That worked for me using the latest sbcl.
When I tried the write-line in sbcl called from the command line of an
ordinary terminal shell, it worked with no problem.
--
Sidney Markowitz
http://www.sidney.com
On Wed, 13 Dec 2006 18:03:28 -0800, ············@gmail.com wrote:
> Hello:
>
> (write-line "成功") failed in both SBCL and Corman Lisp,
It works in CLisp. CMUCL I know has problems with UTF-8 (at least under
Slime) and it seems SBCL and Corman Lisp might as well.
> Those Chinese characters work in most moderen language like Java,
> C#, Ruby, and in recent C++ compilers it works too.
Good for them. They can join CLisp in the 'good UTF-8 handling' corner.
> I am not sure if these Chinese characters are currently unsupported,
> or if some configuration needs to be set.
Support varies by the implementation.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Chris Barts <··············@tznvy.pbz> writes:
> On Wed, 13 Dec 2006 18:03:28 -0800, ············@gmail.com wrote:
>
>> Hello:
>>
>> (write-line "成功") failed in both SBCL and Corman Lisp,
>
> It works in CLisp. CMUCL I know has problems with UTF-8 (at least under
> Slime) and it seems SBCL and Corman Lisp might as well.
Well, even if it works, it may not work.
Assuming a 8-bit clean implementation end-to-end, it could be that
(length "成功") /= 2 ! (eg it could be 6 if you send UTF-8 bytes,
interpreted as ISO-8859-1+control-code-mapped-to-some-character by
your lisp, and interpreted back as UTF-8 bytes by the terminal.
So what you need, is to ensure that you have configured the same
encoding from end to end, from the keyboard or the input file, in the
lisp program, and on the terminal or the output file.
In sbcl, you can do it with the LC_CTYPE environment variable:
LC_CTYPE=en_US.${encoding} ; export LC_CTYPE ; sbcl
where encoding is something like: UTF-8, ISO-8859-1, etc.
or with current versions, with the unsupported, undocumented lisp variable:
(SETF SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* encoding)
where encoding is a lisp keyword such as :UTF-8, :ISO-8859-1, etc
(You can find the list of encoding supported by sbcl with this
unsupported, undocumented expression:
(mapcar 'first SB-IMPL::*EXTERNAL-FORMATS*)
In any case, before using (write-line "成功"),
be sure to test (assert (= 2 (length "成功"))).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay