[asdf-devel] Change in the way ASDF performs a plan? Or :force semantics?
Pascal Costanza
pc at p-cos.net
Wed Feb 6 19:16:52 UTC 2013
Just a question for understanding this better: CLOS provides clean ways to update methods with newer versions. Why do you use fmakunbound instead? Is this to stay backwards-compatible? Would it be a good idea to switch to a CLOS-based solution in the future to prevent such problems?
I'm probably missing something…
Thanks,
Pascal
On 6 Feb 2013, at 12:42, Faré <fahree at gmail.com> 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.
> 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.
>
> 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.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> Money doesn't change men, it merely unmasks them. If a man is naturally selfish
> or arrogant or greedy, the money brings that out, that's all. — Henry Ford
>
>
> On Wed, Feb 6, 2013 at 1:41 AM, Robert Goldman <rpgoldman at sift.info> wrote:
>> I was having a case where some package wrangling in one of our systems behaved
>> differently with new ASDF than with the ASDF 2 that ships with ACL.
>>
>> It seemed like there was an :AFTER method on one of my modules that simply
>> wasn't being called.
>>
>> I took my usual resort and did
>>
>> (TRACE ASDF:PERFORM).
>>
>> I was very surprised to see that my
>>
>> (asdf:load-system "circa-csm" :force t)
>>
>> resulted in only four calls to perform, and all of them had to do with ASDF:
>>
>> CL-USER> (asdf:load-system "circa-csm" :force t)
>> ; Loading /Users/rpg/lisp/asdf/asdf.asd
>> ; Loading /Users/rpg/lisp/asdf/asdf-driver.asd
>> 0[7]: (ASDF/ACTION:PERFORM #<ASDF/LISP-ACTION:PREPARE-OP >
>> #<ASDF/SYSTEM:SYSTEM "asdf">)
>> 0* (MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD
>> ASDF/ACTION:PERFORM
>> :BEFORE
>> (ASDF/OPERATION:OPERATION
>> ASDF/COMPONENT:COMPONENT)>
>> #<STANDARD-METHOD
>> ASDF/ACTION:PERFORM
>> (ASDF/LISP-ACTION:PREPARE-OP
>> ASDF/COMPONENT:COMPONENT)>)
>> #<STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER
>> (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)>)
>> 0[7]: returned NIL
>> 0[7]: (ASDF/ACTION:PERFORM #<ASDF/LISP-ACTION:PREPARE-OP >
>> #<ASDF/COMPONENT:MODULE "asdf" "build">)
>> 0* (MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD
>> ASDF/ACTION:PERFORM
>> :BEFORE
>> (ASDF/OPERATION:OPERATION
>> ASDF/COMPONENT:COMPONENT)>
>> #<STANDARD-METHOD
>> ASDF/ACTION:PERFORM
>> (ASDF/LISP-ACTION:PREPARE-OP
>> ASDF/COMPONENT:COMPONENT)>)
>> #<STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER
>> (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)>)
>> 0[7]: returned NIL
>> 0[7]: (ASDF/ACTION:PERFORM #<ASDF/LISP-ACTION:PREPARE-OP >
>> #<ASDF/LISP-ACTION:CL-SOURCE-FILE
>> "asdf" "build" "asdf">)
>> 0* (MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD
>> ASDF/ACTION:PERFORM
>> :BEFORE
>> (ASDF/OPERATION:OPERATION
>> ASDF/COMPONENT:COMPONENT)>
>> #<STANDARD-METHOD
>> ASDF/ACTION:PERFORM
>> (ASDF/LISP-ACTION:PREPARE-OP
>> ASDF/COMPONENT:COMPONENT)>)
>> #<STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER
>> (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)>)
>> 0[7]: returned NIL
>> 0[7]: (ASDF/ACTION:PERFORM #<ASDF/LISP-ACTION:LOAD-OP >
>> #<ASDF/LISP-ACTION:CL-SOURCE-FILE
>> "asdf" "build" "asdf">)
>> 0* (MULTIPLE-VALUE-PROG1 (PROGN #<STANDARD-METHOD
>> ASDF/ACTION:PERFORM
>> :BEFORE
>> (ASDF/OPERATION:OPERATION
>> ASDF/COMPONENT:COMPONENT)>
>> #<STANDARD-METHOD
>> ASDF/ACTION:PERFORM
>> (ASDF/LISP-ACTION:LOAD-OP
>> ASDF/LISP-ACTION:CL-SOURCE-FILE)>)
>> #<STANDARD-METHOD ASDF/ACTION:PERFORM :AFTER
>> (ASDF/OPERATION:OPERATION ASDF/COMPONENT:COMPONENT)>)
>> ; Fast loading
>> ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf/build/asdf.fasl
>> 0[7]: returned T
>>
>> ;;; from here on down there's lots of loading, but no recompilation (as I
>> ;;; expected from :force t) and no calls to PERFORM.
>> ; Fast loading
>> ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/circa/code/csm/musliner-tools.fasl
>> ; Fast loading
>> ; /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/circa/code/csm/stochastic.fasl
>>
>> Or -- oh, wait! Did the recompilation of ASDF killed the tracing?
>>
>> If so, I don't think that :force t should be causing ASDF itself to rebuild. I
>> understand why it's a dependency, but this shows why it's inappropriate:
>> rebuilding asdf destroys our ability to inspect its behavior.
>>
>> Oh, and maybe it's also killing the PERFORM :after method in my system definition?
>>
>> I'd suggest :force t should stop before it gets to ASDF itself. Maybe we need
>> to add :force :omg to do that! ;-)
>
> _______________________________________________
> asdf-devel mailing list
> asdf-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
--
Pascal Costanza
More information about the asdf-devel
mailing list