The report at http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-24.html is updated with ABCL results - nothing new in ABCL. Also, I investigated a little remaining failures, and added notes to the report. A CCL-specific failure only happens with cl-l10n system, and only when ASDF upgrade is performed. Without ASDF upgrate the cl-l10n loads OK, while after ASDF upgrade CCL:SLOT-VALUE-USING-CLASS function fails with NO-APPLICABLE-METHOD. If you want to reproduce, here are command lines: # with ASDF upgrade rlwrap ./lisps/ccl-1.9/lx86cl --no-init --load ~/quicklisp-patched/setup.lisp # without ASDF upgrade rlwrap ./lisps/ccl-1.9/lx86cl --no-init --load ~/asdf/build/asdf.lisp --load ~/quicklisp-patched/setup.lisp Then try (ql:quickload :cl-l10n) And another type of errors we have is failure to load hu.dwim.computed-class+hu.dwim.logger, hu.dwim.computed-class.test and caveman-test. It is caused by Quicklisp problem to handle :defsystem-depends-on. As can be seen from the stacktrace at http://cl-test-grid.appspot.com/blob?key=52ginnerq3 Quicklisp tires (asdf:find-system "hu.dwim.computed-class+hu.dwim.logger" nil) ;; nil is passed to error-p parameter ASDF finds the hu.dwim.computed-class+hu.dwim.logger.asd file and while parsing it then tries to resolve :defsystem-depends-on (:hu.dwim.logger), but hu.dwim.logger is not downloaded to the local disk yet, so ASDF is unable to find :hu.dwim.logger and signals an error. This error can happen with previous ASDF as well, we only need to have hu.dwim.computed-class already downloaded and hu.dwim.logger not downloaded. To summarize, the testing so far reveals only two ASDF-specific issues: - ASDF upgrade on CMUCL always fails - ASDF upgrade on CCL breaks cl-l10n somehow Best regards, - Anton 02.01.2014, 23:02, "Faré" <fahree@gmail.com>:
It turns out to be a Quicklisp bug. Indeed, quicklisp 2013-12-13 records exscribe-typeset as a dependency of exscribe.
OK, I modified exscribe to not use the :feature feature, but quicklisp probably needs to be fixed to support it, too. The feature was already present in late ASDF 1, but nobody used it, because it was broken until late ASDF 2. So that's QL bug #1, that triggers bug #2.
Why it behaves differently. [...]
Thanks for this brilliant analysis. Bug #2 is QL thinks a dependency exists (erroneously above, correctly below), but no .asd file directly provides it, so it fails to locate it, and dies. Yet, it obviously knows how to handle magically required asdf systems such as :sb-posix. Thus, it can probably be told how to handle systems that don't have a direct QL-managed, user-defined .asd file.
I haven't reviewed the lil failures. Maybe they are caused by the same bug as exscribe.
I think it's the same bug indeed.
I have added your ssh key to user testgrid at cl-test-grid.cloud.efficito.com - the machine where testing was performed. If you will need to experiment and reproduce problems, you should be able to login.
Thanks!
Well, SBCL still can't load lil, because it first tries to locate lil/interface/all and fails. I suppose it somehow works for me because I forced installation of all QL packages including lil, so that once installed, QL finds it. But QL won't do the implicit installation, because it tries to recurse on a dependency, and fails to find it. The place where to find it is under the hierarchy that contains lil.asd, courtesy of asdf/package-system.
The report at http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-24.html is updated with ECL results. Also, as you can see the excribe failure is annotated by "Quicklisp bug". It's a new feature of cl-test-grid - I can record notes near the failures we clarified already, so it's easier to see what remains. Started tests for ABCL.
Cool.
Thanks a lot for your diligent testing!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Do not handicap your children by making their lives easy. — Robert Heinlein