[asdf-devel] Change in the way ASDF performs a plan? Or :force semantics?

[Robert Goldman]

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