>>>>> "Rupert" == Rupert Swarbrick <rswarbrick at gmail.com> writes:
>>> (snip: clisp failing miserably to print latin1 text for me)
>>
>> FWIW, this works for me on my Mac, using clisp 2.49. "zur?ck" is printed
>> (correctly with two dots over the second u).
Rupert> How confusing! Well, with clisp at least I can dig a bit deeper to see
Rupert> what's going wrong on my system. I'll spend a bit of time on it now, I
Rupert> think.
>> Not sure about LANG=es. I see
>>
>> los par??metros
>>
>> with both ccl, clisp and cmucl. I don't know if that's correct or not.
Rupert> Ah, well this looks like a bug in our transcoding. If you use Emacs, or
Rupert> another text editor that gives you control over coding systems, visit
Rupert> doc/info/es.utf8/maxima.info-1 and tell the editor that it should be
Rupert> utf-8 text. The first line of the build_info text has this mangled data,
Rupert> which looks like we didn't convert it correctly from latin1.
So I don't have to explicitly say LANG=es_ES:UTF-8 to get utf8? If
so, why are there es/ and es.utf8/ directories? I was guessing they
were different. (But didn't check to see how they differ.)
>> Also, I can't build with ecl anymore. It complains:
>>
>>
>> ; - Compiling source file
>> ; "/Volumes/share2/src/sourceforge/maxima/maxima-mac/src/locale.lisp"
>> ;;;
>> ;;; Compiling /Volumes/share2/src/sourceforge/maxima/maxima-mac/src/locale.lisp.
>> ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=2
>> ;;;
>> ;;; Compiling (DEFVAR *LOCALE-DEFNS* ...).
>>
>> Cannot find the external symbol LATIN-1 in #<"SI" package>.
The error message is actually from compiling the NEXT form, defvar
*external-formats*.
>>
>> Perhaps my version of ecl is too old (11.1)?
Rupert> Well, I'm only on 11.1.1, it seems, so that's a bit surprising. Looking
Rupert> at
Rupert> http://ecls.sourceforge.net/new-manual/ch19.html#ansi.streams.formats, I
Rupert> see that a unicode build of ECL is required though. Is it possible that
Rupert> this is what's missing? If so, I guess we've got to work out a sensible
Rupert> fallback. I can't spot a ":unicode" entry in *features* here, so this
Rupert> might be slightly nontrivial...
I have :unicode in *features* on my version of ecl. (find :unicode
*features*) -> :unicode.
>> Overall, it seems parse-info works fine. I didn't measure whether
>> this new scheme is faster than perl. Both are pretty fast enough on
>> my machines that I don't care.
>>
>> I wonder if we don't also need to set the external format for the
>> output stream. I would think that we be correct most of the time if
>> we could set the output stream to use utf8 always. All of my
>> terminals are set for utf8.
Rupert> I agree that we need to think about it, but I would sort of expect the
Rupert> lisp implementation to sort this out: My mental model is that if my lisp
Rupert> reads in a character (rather than byte) stream, it converts each
Rupert> character into its favoured internal coding system. Then, when it prints
Rupert> the character, it can look at the locale data ($LANG etc.) to figure
Rupert> out what the terminal is expecting. Presumably there are optimisations
Rupert> to avoid converting if input and output formats are equal and both are
Rupert> non-equal to the internal representation, but that's an implementation
Rupert> detail. But maybe my mental model is wrong. Hmm.
I don't know about other lisps, but cmucl doesn't do anything with
LANG. Perhaps it should, but it doesn't now. Or at least we can make
it do something with it for maxima.
Ray