On 2/6/13 Feb 6 -5:42 AM, Faré wrote:
Dear Robert,
it looks like the issue is that you loaded your methods to extend ASDF before upgrading ASDF itself, which won't work. Upgrading ASDF includes a FMAKUNBOUND on several functions, including PERFORM, which indeed UNTRACE's them on many implementations.
ASDF 3 will always try to upgrade itself before any operation, precisely to avoid squashing your methods in the middle of the operation, which would be far worse.
I'm afraid that this behavior needs refinement. Consider what we are doing: * we load my system definition * we load/upgrade ASDF3 * ASDF3 destroys part of my system definition and *quietly* goes ahead and does the wrong thing, loading a damaged system definition. I can't imagine a case where the programmer wants this behavior. I could be convinced that ASDF should upgrade itself, but I believe my example shows that any time ASDF upgrades itself it must reload all system definitions, because they have potentially been damaged. That seems like a tall order, so a more modest alternative would be: ASADF should raise an error and refuse to continue after reloading itself, forcing the programmer to re-do any operations that triggered the reload. In that case, it should mark all loaded system definitions as invalid, since they may contain method definitions that have been removed.
But if it was already upgraded, this should be a No-Op (unless there's a bug in ASDF). Moreover, :force t should not apply to ASDF, because it has the :builtin-system-p t flag. I just tried at home, and it worked.
I just retried and got the same behavior. No git operations done this morning. This is on ACL 8.2, Mac OS X, 64-bit Enterprise: CL-USER> (push "home:lisp;asdf;" asdf:*central-registry*) ("home:lisp;asdf;" "home:lisp;franz-clx;" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/" "~/lisp/asdf-systems/" "~/lisp/asdf-install-systems/systems/") CL-USER> (asdf:load-system "asdf") ; Loading /Users/rpg/lisp/asdf/asdf.asd ; Fast loading ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf/build/asdf.fasl ; Upgrading ASDF from version 2.23.7 to version 2.28 T CL-USER> (circa) Configuring for CIRCA systems... CIRCA ASDFs now in load path. NIL CL-USER> (asdf:load-system "circa-csm" :force t) ; Loading /Users/rpg/circa/code/csm/circa-csm.asd ; Loading /Users/rpg/circa/code/csm/logical-pathname.lisp ; Loading /Users/rpg/circa/code/csm/optimization-boilerplate.lisp ; Fast loading /usr/local/acl/acl82.64/code/CLX.001 ;;; Installing clx patch, version 1. ; Autoloading for package "CLTL1": ; Fast loading from bundle code/cltl1.fasl. ; Foreign loading clx:excldep.dylib. ; Loading /Users/rpg/lisp/asdf/asdf.asd ; Loading /Users/rpg/lisp/asdf/asdf-driver.asd ; Fast loading ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf/build/asdf.fasl ..... I verify that this behavior does *NOT* occur in SBCL, loading the same system definition. The only suspicious thing I see in the transcript from ACL is the loading of CLX. I wonder if there's any chance that this triggers some interaction with ASDF? That would be bad.
Considering that you seem to already have had ASDF 3 installed (since it did the automatic upgrade attempt), the issue seems to be that you git pull'ed after loading your ASDF overrides, and they thus got squashed during the implicit ASDF upgrade.
No, the above experiment shows that is not the explanation. Something stranger is going on. Best, r