[asdf-devel] asdf.x [was : Launchpad bug 502946

[james anderson]

good morning;

as is evident from the message attached below, for the past several  
days i have thought about things related to bug-502946, and asdf in  
general.
my state-of-mind as of last week was, for the reasons alluded to  
below, that it is not productive to try to reason about system  
construction issues in the concrete context of asdf, -1.502, as it  
was at the time. i do not refer to with matters of configuration, or  
pathname mapping, or even 'elegant' bootstrapping, but rather to the  
need for a platform on which to think about and implement tools to
- manage systems with articulated interfaces
- manipulate system definitions programmatically
- automate system definition construction and maintenance
the larger concerns for integration with production, build, and  
deployment systems do all matter, just not right now. if one would  
set out the tasks in more detail, one could think about how to  
approach the issues, but at present, it is difficult to think even  
just about how asdf works.

the only reasonable approach was to take asdf apart, isolate the  
functional components and reassemble them in a manner which allows to  
think about how a tool to manage program components works and how it  
might work. the current state is captured in de.setf.asdf.x[1]. there  
is a readme[2], which describes the intent, and the asdf-x.lisp[3]  
file, which reimplements asdf.lisp. there is also a unit test[4]  
which captures one interpretation of the 'strongly-dependent'  
requirement relation.

on one hand, as a radical rational reconstruction of the original, it  
does not contribute to the main stream. on the other, the result  
provides the terms to think about what "intra-system" dependency is  
and a concrete context in which to implement projective proposals.  
cf. the commit[5] to support strong dependency by adding a state  
variable to the constraint machinery and adding the declaration to  
control it to the system definition language. most of which took the  
form of additional methods.


---
[1]: http://github.com/lisp/de.setf.asdf.x
[2]: http://github.com/lisp/de.setf.asdf.x/blob/master/README.md
[3]: http://github.com/lisp/de.setf.asdf.x/blob/master/asdf-x.lisp
[4]: http://github.com/lisp/de.setf.asdf.x/blob/master/test/launchpad/ 
bug-502946.lisp
[5]: http://github.com/lisp/de.setf.asdf.x/commit/ 
285a38e4ee18e10b5ce887d8ab2dd5e2d352aa0a


Begin forwarded message:

> From: james anderson <james.anderson at setf.de>
> Date: 2010-02-07 23:45:56GMT+01:00
> To: rpgoldman at sift.info
> Subject: Re: [asdf-devel] Launchpad bug 502946
>
> good evening;
>
> you may, or may not be expecting this, but i got tired of trying to  
> understand traverse.
> and tired of trying to understand parse-component, and defsystem,  
> and pathname resolution, and ...
> i am now about 3/4 through rewriting asdf with clear protocols for
> - definition operators (at all three levels - system, module, element)
> - perform - with distinct qualifiers for requirement (dependency,  
> constituency) traversal, restart
> - requirement and constituency specification canonicalization
> - status evaluation for completion, features, other arbitrary  
> predicates
> - settings/environment assertions per component
> - pathname resolution which does not depend on the quirks of  
> *default-pathname-defaults*
>
> it's about the same amount of code - even though many of the  
> internal operators are decomposed to make the mechanism explicit.
>
> the most unsettling part is to ensure that - between the bnf in the  
> docs and the logic of the code, i've gotten the dependency  
> definitions right, but it won't be long. i've been chewing through  
> this since friday, so maybe by the time you're up tomorrow, there  
> will be some code up in github which passes the tests. the intent  
> is plug-compatible for the things i can understand, and i'm putting  
> it in a new package, so with a couple package-name swaps, one can  
> try things side-by-side. i will let you know.
>
>
> On 2010-02-07, at 22:40 , Robert Goldman wrote:
>
>> Wrt https://bugs.launchpad.net/asdf/+bug/502946,
>> module is not recompiled if _intra_-system dependency changes, I have
>> spent quite some time groveling over the source code to TRAVERSE,  
>> and I
>> believe that this is going to be quite difficult to fix.  There are a
>> number of assumptions baked into TRAVERSE, and some complicated  
>> uses of
>> a variable scoped over the body of TRAVERSE, together with a  
>> number of
>> local functions and a soupcon of unstated assumptions.
>>
>> I'm pretty sure that modules are substantially broken and, in the  
>> short
>> term, I would discourage ASDF system designers from using them at  
>> all.
>>
>> I have been banging my head on this for at least a working day's  
>> worth
>> of hours, and I need someone with whom to discuss the code, either by
>> voice, IM or IRC.  Email is not going to be high enough bandwidth.
>>
>> If anyone is interested in this enough to share the pain with me,  
>> please
>> drop me a line and we can coordinate.
>>
>> Thanks,
>> r
>>
>> _______________________________________________
>> asdf-devel mailing list
>> asdf-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100211/d0792015/attachment.html>