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é" <fah...@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
