[Asdf-devel] Mac test update status
fahree at gmail.com
Thu Oct 9 15:15:07 UTC 2014
> 2. sbcl is failing test-retry-loading-component-1:
> Running test-retry-loading-component-1.script with sbcl-1.2.0-macosx-x64
> ; loading
> TEST ABORTED: READ error during LOAD:
> :ASCII stream decoding error on
> for "file
> the octet sequence #(195) cannot be decoded.
> (in form starting at line: 8, column: 69, file-position:
> This smells like a Unicode regression to me. Now, *ASDF* defaults to
> loading UTF-8 files, but our *script* files are just loaded any old way.
> "Déjà vu" is a terrible error message, anyway -- cute, but cryptic and
> unhelpful -- so I'm just going to kill it, rather than drive myself
> crazy trying to figure out how to load .script files as UTF-8 on every
> possible Lisp implementation.
OK, I now understand what's happening: the default default encoding
for SBCL might be :US-ASCII, such that any 7-bit-unclean file will
cause loading errors, and so any file that may be loaded with CL:LOAD
instead of UIOP:LOAD* must be 7-bit clean. The "regression" might just
be that your configuration no longer specifies UTF-8 or some 8-bit
encoding as LC_CTYPE, and SBCL falls back to strict 7-bit ASCII, and
now hell breaks lose. We need to make sure all our lisp files (since
asdf.lisp may be loaded by LOAD, and its contribs and main test files
too) and .script files are 7-bit clean. This doesn't apply to .asd
files and test .lisp files only loaded via ASDF.
NB: I just pushed a patch making the debug.lisp contrib 7-bit clean.
As for the clisp issue, I'm still without a clue, and can't reproduce.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Future scholars will only have copies of copies of copies of manuscripts.
How will they authenticate what really WAS said in our dark ages?
More information about the asdf-devel