- sbcl is failing test-retry-loading-component-1:
Running test-retry-loading-component-1.script with sbcl-1.2.0-macosx-x64 ; loading #P"/Users/rpg/lisp/asdf/test/test-retry-loading-component-1.script" TEST ABORTED: READ error during LOAD:
:ASCII stream decoding error on #<SB-SYS:FD-STREAM for "file/Users/rpg/lisp/asdf/test/test-retry-loading-component-1.script" {100566ACA3}>:
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?