<div class="gmail_quote">On Fri, Feb 19, 2010 at 7:55 PM, Tobias C. Rittweiler <span dir="ltr"><<a href="mailto:tcr@freebits.de">tcr@freebits.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Juan Jose Garcia-Ripoll writes:<br>
<br>
> On Wed, Feb 17, 2010 at 8:55 PM, Tobias C. Rittweiler <<a href="mailto:tcr@freebits.de">tcr@freebits.de</a>> wrote:<br>> There is now a function called EXT:ALL-ENCODINGS that lists all<br>
> available encoding names.<br>
><br>
> Juanjo<br>
<br>
</div>That seems to return the same list regardless of whether ECL was built<br>
with --enable-unicode or --disable-unicode.<br></blockquote><div><br></div><div>This is because you forgot to cleanup your installation when using --disable-unicode : there is a stale directory of encodings left out in lib/ecl-10.2.1 or whatever. I will add a bit more intelligence to the function to avoid this problem.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Your Slime patch which just comments out the definition of<br>
FIND-EXTERNAL-FORMAT in swank-ecl.lisp is not really right. Even when<br>
ECL was built without unicode, it supposedly supports (all or some of,<br>
pardon my ignorance on this issue) the LATIN-N encodings.<br></blockquote><div><br></div><div>No, it does not. It uses whatever encoding the OS has, but we have no way to know which one. For that reason in that case no external format symbol is supported except :DEFAULT The fact that it uses an I/O function called latin1* internally is because it is just an 8-bit reading function and I did not want to duplicate lines of code.</div>
<div><br></div><div>Juanjo </div></div><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>