Re: wither ASDF

C Y wrote:
> I'll preface my comments with the remark that I've fooled around with asdf while working on ASDF-Literate (http://bzflag.bz/~starseeker/asdf-literate.pdf), but am not an expert the way most of the folks here are so I may be a bit "behind the times".
> 
> --- On Wed, 1/14/09, Gary King <[email protected]> wrote:
> 
>> Questions (or perhaps vague musings) that I have from time
>> to time are:
>>
....
>> * how do we get ASDF to be included in all Lisp
>>   distributions?
> 
> That's a policy decision on the part of each distribution.  The real answer is probably to get the ANSI Common Lisp spec updated to include ASDF - unfortunately that would involve re-building the teams officially able to do so, and that's probably not happening any time soon (takes $$ to play).

Is this really a problem?  I find it in the two Lisps I use most (SBCL
and ACL).  There's a lot of discussion about making ABCL work well with
ASDF, so presumably they want to see it there.  I don't know whether CCL
or LispWorks bundle ASDF, but if they don't, it's so easy to get it that
I don't see a problem.

Propose we table this as a non-issue...
> 
>> * how do we make ASDF better?
> 
> I'd say a concrete set of desired features and a central way to manage them would help - this inclines me to vote for a c-l.net project just for ASDF.  IMHO it is certainly important enough to rate its own project.

having a project for ASDF seems fine.  Having a wish list somewhere
seems fine, too.  I don't see the benefit of any more management beyond
that and a more active process of reviewing and pushing patches into the
system.  More management seems to me likely to just suck up some of the
all-too-few hours to get the real work done.
> 
> It might be heresy to mention it here, but what does the ASDF crowd think about XCVB?  Is it the "next generation" of ASDF?  Does it make design decisions unacceptable to ASDF users?  Does it have good ideas?  Perhaps a viable direction would be to ensure it can handle everything ASDF currently does?
> 
>> * how does ASDF relate to ASDF-Install and what about these
>>   new-fangled kids like mudballs, cl-build, and so on.
> 
> I view ASDF as being strictly inside the Lisp world.  From what I can tell, cl-build at least is solving a somewhat different problem.  It's a core problem whenever considering doing a "stand alone" application in Lisp - the build process and configuration information (plus little things like required external downloads) can't be assumed in most cases. 
> 
> I admit I don't make use of ASDF-INSTALL, so I'm not qualified to comment on it specifically.
> 
>> * Who wants to lead ASDF development (and who has the time!)
> 
> Is that a request for volunteers? ;-)  I'd say someone who uses it regularly and wants to see improvements to it would be a logical choice, but if you're asking for specific names I'm not much help (although I will say I'm impressed by tools like Lift, asdf-binary-locations, etc... *cough* :-)
> 
>> * Is ASDF maintenance a democracy, an oligarchy or a
>>   monarchy (and, in every case, who is doing the directing?)
> 
> Um... a herd of cats, if you count extensions? ;-)  

There needs to be a willing person to gate commits into the core, and to
occasionally wrangle web site/hosting.   I don't see the need for more
than that.  Open source projects with a strong central figure who
doesn't demotivate a larger group of contributors seems to be the
accepted recipe for success.

Personally, I would like to see ASDF maintained in a trunk where patches
are reviewed by the community and ultimately judged by a central figure.
  I would also like to see our CVS (or replacement) opened up to more
branches, so that it's easier to experiment with new features and share
them for evaluation.  I am sorry to be a Philistine, but I have used
DCVSes as well as CVS and Subversion, and so far I've been a lot happier
with Subversion.  If we must have a DCVS, I would prefer git as being
the current central tendency; based on my assumption that that choice is
likely to minimize the sum of the learning cost over the set of possible
contributors.

> 
>> For the last few years, ASDF has been stable (but perhaps
>> too stable).  There are a lot of directions it could go.
> 
> For my part, if ASDF is to grow, I would like to see two things in the short term:
> 
> 1.  Merging in functionality from extensions that is not platform specific and is generally useful into the main ASDF tool.
> 
> 2.  Getting a central "Using ASDF" manual that is kept up to date as new features are merged in, so people know what is there, how to use it, and why it's good.  Again, this would probably be helped quite a lot by a c-l.net home.
> 
>> IMHO, ASDF should not change greatly but should keep
>> improving around the edges. I'll try to write up a list of ideas for
>> ASDF later tonight or tomorrow. Maybe that could be used for discussion?
> 
> Sounds good.

My favorite new possibilities (but these are ambitious):

1.  Some blocking of the operations applied to a system so that it's
possible to wrap an :around method around the entire set of
sub-operations on a single component.

2.  Better support for subclassing operations.  Extending component
types is easy to do and works well.  Extending operations, not so much.
 The method of dependency computation seems to militate against this.
Last time I was forced to retreat to treating the original-initargs slot
as a proplist.  That may be the best we can do if we want to maintain
backwards compatibility.  In that case, warning people off extending the
operation classes in the manual might be a good idea.

Cheers,
r


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword