<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Take 2.<br></div><div class="gmail_quote"><br>On Tue, Mar 25, 2014 at 3:12 AM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br>
<br>
Problems I found:<br>
1- you look for encodings in #p"SYS:ENCODINGS;" (upper case,<br>
as per the standard), which is mapped to .../lib/mkcl-1.1.8/encodings/<br>
(lower case, as customary on Unix, thus as per the standard).<br>
However, the directory and its files have upper case names, and<br>
are therefore not found. This breaks asdf-encodings and thus the<br>
test-encodings.script test. Note: you need to download the latest<br>
version of asdf-encodings for this test to work.<br></blockquote><div><br></div><div>The fix should be in the MKCL git repo master head now.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2- even assuming SYS:ENCODINGS; were found, it is not obvious at all<br>
what is the right way to detect the presence of an encoding.<br>
i.e. given the keyword :latin-2, what is the recommended way<br>
to detect if an encoding is supported and/or to list supported<br>
encodings? e.g. check (si::make-encoding :latin-2),<br>
or see that mk-ext::latin-2 in bound to a keyword?<br></blockquote><div><br></div><div>#'si::make-encoding returns NIL on failure plus a string as secondary value<br>to explain the failure, it returns non-NIL on success. But that is surely awkward for your purpose. There is (si::all-encodings) that return a list of keywords each of which names a valid encoding. So I think that (member :latin-2 (si::all-encodings)) will do what you want.<br>
<br></div><div>BTW, the gimmick of binding symbols in package :mk-ext (not to a keyword but to a hashtable) is a part of that legacy code that is going away soon (MKCL 1.2.0), so please do not rely on it. Use #'si::all-encodings instead.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3- if I uncomment the lines:<br>
;;(unless (or #+ecl (use-ecl-byte-compiler-p))<br>
;; (setf *load-system-operation* 'load-bundle-op))<br>
I get an error in test-logical-pathname,<br>
with the .fasb apparently mapped to the wrong directory.<br>
<div class=""><br></div></blockquote><div><br></div><div>I am still scratching my head on this one. It feels so much like an optimization concern of questionable wisdom... Is it the fear of hitting some wall I am unaware of, like the 1024 file descriptor one, or something else I haven't seen yet? Is it some concern about memory consumption in a development environment where memory use is through the roof already anyway? I don't get it, and I am ready to wait until this becomes a real/confirmed problem before I address it (I bet it will take a very long time to see that happen). Can't we just drop this one?<br>
<br></div></div></div></div>