[asdf-devel] Port of ASDF 184.108.40.206 to MKCL
jean.claude.beaudoin at gmail.com
Wed Mar 26 06:00:07 UTC 2014
On Tue, Mar 25, 2014 at 3:12 AM, Faré <fahree at gmail.com> wrote:
> Problems I found:
> 1- you look for encodings in #p"SYS:ENCODINGS;" (upper case,
> as per the standard), which is mapped to .../lib/mkcl-1.1.8/encodings/
> (lower case, as customary on Unix, thus as per the standard).
> However, the directory and its files have upper case names, and
> are therefore not found. This breaks asdf-encodings and thus the
> test-encodings.script test. Note: you need to download the latest
> version of asdf-encodings for this test to work.
The fix should be in the MKCL git repo master head now.
> 2- even assuming SYS:ENCODINGS; were found, it is not obvious at all
> what is the right way to detect the presence of an encoding.
> i.e. given the keyword :latin-2, what is the recommended way
> to detect if an encoding is supported and/or to list supported
> encodings? e.g. check (si::make-encoding :latin-2),
> or see that mk-ext::latin-2 in bound to a keyword?
#'si::make-encoding returns NIL on failure plus a string as secondary value
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.
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.
> 3- if I uncomment the lines:
> ;;(unless (or #+ecl (use-ecl-byte-compiler-p))
> ;; (setf *load-system-operation* 'load-bundle-op))
> I get an error in test-logical-pathname,
> with the .fasb apparently mapped to the wrong directory.
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asdf-devel