[asdf-devel] new asdf does not like matlisp.asd

[james anderson]

good afternoon;

reading traverse is not my idea of a good time, but when i persevere,  
i do not arrive at the same conclusion.
in addition, when i specialize a method for operation-done-p for  
compile-op and module to iterate over the constituents and collect  
the results, the matlispbug system behaves as my reading of traverse  
would imply: it compiles the f77/ffi code once only.

the first time through it compiles everything.
the second time through it first asks each constituent individually,  
in turn, if it is done (this is the traverse recursion in its module- 
ops clause) and then asks each one again as a consequence of asking  
the module (this is the operation-done-p for the module itself in the  
when clause).
if the results are consistently "done", the dependents do not recompile.

?

nb. if the method is specialized on (operation component), things do  
not turn out well, but that looks like it may be unrelated to the  
general issue and instead an interaction with the particular way the  
system's specialized components implements compilation.

On 2010-04-11, at 15:48 , Robert P. Goldman wrote:

> Unfortunately, I don't believe this is possible. This is YA problem  
> arising from the fact that asdf has no object that stands for the  
> module with it's components. Operation-done-p on a module doesn't  
> mean the op is done on this module & components, only on the suffix  
> of the module after it's components.
>
> E.g., if you have a module m & component c, for op o, you will see  
> first
> (perform o c)
> Then
> (perform o m)
> In the plan, so operation-done-p does not prevent doing o on c,  
> only on the m object itself.
>
> Traverse does a postorder traversal on the system tree.
>
> I could not figure out how to fix this while maintaining any  
> semblance of backward compatibility.
>
> On Apr 11, 2010, at 8:09, james anderson <james.anderson at setf.de>  
> wrote:
>
>> good afternoon;
>>
>> if one invoked load-system with the factors traced which contribute
>> to done-ness, it reads as if operation-done-p needs to be specialized
>> for modules to delegate to the constituents.
>> of the asdf/test/*module*.asd examples, there is one which has a
>> similar structure.
>> it is not obvious clear why the matlisp .asd behaves differently.
>>
>> On 2010-04-11, at 13:28 , Mario S. Mommer wrote:
>>
>>>
>>> Hello,
>>>
>>> Faré <fahree at gmail.com> writes:
>>>> Ahem. I admit this is a part of ASDF I am not familiar with.
>>>>
>>>> What does traverse return? Can you trace every exported  
>>>> defgeneric in
>>>> ASDF and attach to a launchpad bug traces of what happens in either
>>>> ASDF 1 or ASDF 2?
>>>
>>> I can try. For now I made a much smaller .asd, whith a defsystem
>>> that looks
>>> like this:
>>>
>>> (defsystem :matlispbug
>>>    :components
>>>  ((:unix-dso "alien code"
>>>              :pathname ""
>>>              :dso-name "libmatlisp"
>>>              :components
>>>              ((:alien-module "CPOLY"
>>>                              :pathname "lib-src/cpoly/"
>>>                              :components
>>>                              ((:fortran-source-file "cpoly")))))
>>>   (:file "packages")
>>>   (:module "foreign-interface"
>>>            :pathname "src/"
>>>            :depends-on ("packages" "alien code")
>>>            :components ((:file "f77-mangling")
>>>                         (:file "ffi-sbcl")))))
>>>
>>> and that shows the behavior of interest. That is, with the new
>>> asdf, the
>>> module "foreign-interface" gets compiled every time I load the  
>>> system,
>>> whereas under the old asdf that does not happen. From staring at the
>>> source of the .asd, I haven't been able to see what is wrong.
>>>
>>> I have uploaded a tarball with an abridged (to reduce size)  
>>> version of
>>> matlisp to common-lisp.net, in case anyone wants to try:
>>>
>>> http://common-lisp.net/~mmommer/matlispasdfissue.tar.gz
>>>
>>> The shortened .asd is called matlispbug.asd.
>>>
>>> To readers in the future: I will remove the file as soon as this  
>>> issue
>>> is resolved, and then this link will be broken.
>>>
>>> Regards, and thanks,
>>>
>>>         Mario.
>>>
>>>
>>> _______________________________________________
>>> asdf-devel mailing list
>>> asdf-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>>
>>
>> _______________________________________________
>> asdf-devel mailing list
>> asdf-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel