William Stein wrote:
> > On Thu, 05 Mar 2009 at 10:45PM -0800, Alex Lara wrote:
> >> *** - invalid byte #xC3 in CHARSET:ASCII conversion
Try this: change the environment variable LC_CTYPE
e.g. LC_CTYPE=ES_es or LC_CTYPE=ES_es.UTF-8 or something
like that. Or maybe somehow indicated ISO 8859-1 or Latin-1 or
something. Then Clisp might know how to decode the offending bytes.
Another tactic: put the following in your $HOME/.clisprc file.
(format t "HELLO FROM CLISPRC~%")
(ignore-errors
(progn (setf custom:*default-file-encoding*
(ext:make-encoding :input-error-action #\?))
(setf custom:*terminal-encoding*
custom:*default-file-encoding*)))
That replaces undecodable bytes by '?' characters.
(The "hello" message is just to verify the code is loaded ....)
> That's a good guess. There is a known major bug in Maxima + clisp where
> it totally fails to work if there are certain non-ascii characters in the
> filenames in the current directory or PATH. I can't wait until clisp isn't
> in Sage.
The bad news is that it's not exactly a Clisp idiosyncrasy.
Clisp is trying to "do the right thing" when faced with undecodable
bytes.
Unfortunately the Common Lisp spec, while it recognizes the
existence of character encoding issues, doesn't specify what to do
when a byte can't be decoded to a character. Other Lisp
implementations
probably have their own ways to handle it.
FWIW
Robert Dodier
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
