2009/12/1 Robert Goldman rpgoldman@sift.info:

I just checked, and I see that my documentation patches have not been pushed.  Any objection to pushing them before the release?

If you are willing to do that, I'd appreciate it.  I prefer not to do anything irrevocable to the git repo....

Sure. Those of you who have patches you want included in the next release, please re-send them to me, if possible based on my development repo at http://common-lisp.net/project/xcvb/git/asdf.git

Note that now that we have an asdf.asd, I'd like to keep anything not necessary to bootstrap in separate systems -- though I could be convinced otherwise and will yield to majority opinion on anything regarding ASDF.

Actually, I'd even like to declare asdf:run-shell-command deprecated copy it somewhere else for those who'd officially like to use it. A cursory look at google/codesearch for "asdf:run-shell-program" finds cclan, asdf-install which are readily fixable, but also a few others, too. There might be some that are not indexed or import the symbol, though.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The superior man understands what is right; the inferior man understands what will sell. -- Confucius

2009/12/1 Robert Goldman rpgoldman@sift.info:

...

Sure. Those of you who have patches you want included in the next release, please re-send them to me, if possible based on my development repo at   http://common-lisp.net/project/xcvb/git/asdf.git

OK, I will resend.

I got two small documentation patches from you that I committed to my repo. I also committed tiny source documentation/comment fixes.

If no one speaks against what's in my repo, it will be pushed to the official repo next week.

...

Actually, I'd even like to declare asdf:run-shell-command deprecated copy it somewhere else for those who'd officially like to use it. A cursory look at google/codesearch for "asdf:run-shell-program" finds cclan, asdf-install which are readily fixable, but also a few others, too. There might be some that are not indexed or import the symbol, though.

I would very much prefer that we not do this.

Removing asdf:run-shell-command will break existing asd systems.  I have, for example, used asdf:run-shell-command as a portable means for running perl scripts and make inside ASDF system definitions.  I don't really think that google/codesearch is an adequate resource for assessing the danger of such breakage.  It certainly would only reveal O(1%) of my asdf system definitions, since many of my systems are not of general interest, and are only of use in my company, in a small group, etc.

I would prefer a far more conservative approach to evolving ASDF, one that emphasizes not breaking existing systems.

Yes. My proposal was preposterous. I've added a comment in my repo saying that I'd like it deprecated but that we'll support it until there's a better solution AND everyone has had plenty of time to migrate.

I'm also concerned that you have talked about pushing stuff to contribs, but we don't yet have an announced plan for distributing such contribs. Do they just come with ASDF, or are they separate downloads?  I could possibly live with contribs that come in the distribution of ASDF, but separate downloads would not be acceptable.  Indeed, we have just taken a step in the other direction, rolling asdf-binary-locations into core ASDF.

My plan for contribs is that the ASDF distribution would come with its contribs that have .asd files and that you can (asdf:load-system :asdf-blah) assuming your asdf is itself properly loaded and configured.

Two other issues:

1. ASDF does not have a graceful way of loading extensions.  We have

just heard some complaints from Samium G about the way looking for a system definition can cause source code loading.  This is forced upon ASDF users by a limitation of the model.  There is no clean way for us to say "this ASDF extension is required by this system definition."  All we can do is put

(asdf:oos 'asdf:load-op <my-asdf-extension>)

in our .asd files....

So every time we move a core function out of asdf, not only do we break existing systems, but we also make asdf less declarative and more imperative.

I think that it is the very design of ASDF that a .asd file is Lisp source code, and that we thus reuse Lisp as the language to do magic there. What better way to load extensions in your .asd than that? After all, you need the extension there before you even try to parse the defsystem statement with the loaded extension.

2. Existing ASDF extensions get stuffed into the ASDF package.  This

seems like something that's likely eventually to cause us pain (as in "name collisions" and "method definition collisions").

To do this gracefully, we must move in the direction of providing an ASDF-extender API.  For example, a package like ASDF-INTERNALS that exports a lot more of the ASDF symbols, and some more method combination hacks, like the one that allows ASDF to have "around" methods inside :around methods defined by ASDF users.

In my opinion, such a careful, graceful treatment of ASDF unbundling would require more effort than we are likely to recoup in benefits. Certainly, it's not where I'd like to put my open source hours (but if others do, more power to you!).

Yup. I'd rather work on XCVB.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If you're wrong against the dominant ideology, you'll be laughed at. If you're right against the dominant ideology, you'll be hated.

On Tue, Dec 1, 2009 at 9:05 PM, Faré fahree@gmail.com wrote:

I think that it is the very design of ASDF that a .asd file is Lisp source code, and that we thus reuse Lisp as the language to do magic there. What better way to load extensions in your .asd than that? After all, you need the extension there before you even try to parse the defsystem statement with the loaded extension.

Sometimes great power brings great responsibility and the fact that *.asd files can be any lisp becomes a burden for people wanting to port those libraries. Specially when then the library itself depends for instance on extensions that are defined in the *.asd file and not in the lisp objects themselves. I am right now thinking on software like ECL's extensions for packing libraries into monolithic FASL files or standalone programs.

Juanjo