Dear Lisp hackers,
apparently, Xach thinks the name "package-system" is a bad name for the quick-build compatible extension to ASDF that I implemented and is going to be released with ASDF 3.1 — see file package-system.lisp, its use in lisp-interface-library, and the description in the ASDF manual (doc/asdf.texinfo in the master branch). Basic idea: each file starts with a defpackage or define-package, the packages it use's or import-from's or shadowing-import-from's are detected, each package is mapped back to a system, that itself may be mapped to files under a package-system.
Before the release is the best time for renaming things. If you have a suggestion for a better name, now is the time to speak, not later.
* package-system * quick-build * system-whose-dependencies-are-deduced-from-defined-package-and-whose-pathname-is-deduced-from-its-name * one-package-one-file-one-system * not-quite-faslpath * gangnam-style
I suppose the constraints are that it should not be too long, yet somewhat descriptive and not too confusing. Failing that, a brand name.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Where did the water from the Deluge come from, and where did it go?
On Tue, Apr 15, 2014 at 12:25 PM, Faré fahree@gmail.com wrote:
Dear Lisp hackers,
apparently, Xach thinks the name "package-system" is a bad name for the quick-build compatible extension to ASDF that I implemented and is going to be released with ASDF 3.1 — see file package-system.lisp, its use in lisp-interface-library, and the description in the ASDF manual (doc/asdf.texinfo in the master branch). Basic idea: each file starts with a defpackage or define-package, the packages it use's or import-from's or shadowing-import-from's are detected, each package is mapped back to a system, that itself may be mapped to files under a package-system.
Before the release is the best time for renaming things. If you have a suggestion for a better name, now is the time to speak, not later.
- package-system
- quick-build
- system-whose-dependencies-are-deduced-from-defined-package-and-whose-pathname-is-deduced-from-its-name
- one-package-one-file-one-system
- not-quite-faslpath
- gangnam-style
* package-based-system (proposed by rpgoldman) * package-mapped-system (my variant) * one-file-one-package-system * file-package-system * 1f1ps * 10ps (1f1 is 10.0) * electromagnetism (10 picosecond after the Bigbang is when electromagnetism appears as a separate phenomenon, says Wikipedia) * ups (unsophisticated package system)
Or maybe, unlike Xach, you *love* the name package-system, and vote against its renaming. I don't love the name "package-system", but I admit to preferring it to Robert's proposed alternative "package-based-system", and so far the existing name still has my vote.
I suppose the constraints are that it should not be too long, yet somewhat descriptive and not too confusing. Failing that, a brand name.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If you want to do good, work on the technology, not on getting power. — John McCarthy
On Apr 15, 2014, at 3:00 PM, Faré fahree@gmail.com wrote:
On Tue, Apr 15, 2014 at 12:25 PM, Faré fahree@gmail.com wrote:
Dear Lisp hackers,
...
I suppose the constraints are that it should not be too long, yet somewhat descriptive and not too confusing. Failing that, a brand name.
I’m jumping in late here, but why is this part of ASDF itself? I can see how someone might want this as an extension but it seems like the kind of thing that shouldn’t live in ASDF itself, IMO.
Shouldn’t ASDF’s goal be to make this sort of extension possible/easy but not to actually implement this sort of thing?
Thanks,
Cyrus
I’m jumping in late here, but why is this part of ASDF itself? I can see how someone might want this as an extension but it seems like the kind of thing that shouldn’t live in ASDF itself, IMO.
Shouldn’t ASDF’s goal be to make this sort of extension possible/easy but not to actually implement this sort of thing?
That's an excellent question.
nyef and drewc convinced me that this style was a good way to structure sizable CL programs, and my experience with asdf itself (converted while writing asdf 2.27, aka asdf3 pre-release) and lisp-interface-library confirm that indeed it is.
Since ASDF itself uses this style, I figure that it is proper for ASDF to actively support this style, and maybe one day adopt it as its bootstrap method (which I didn't do, to make transition easier, but would have done a year or two from now).
I really like this style, ASDF uses it, and I want to promote it. I believe that making it part of ASDF and eventually available with every implementation can really lower the barrier to entry to writing CL code, as compared to making it part of an external system that has to be downloaded separately and configured specially.
At the same time, the implementation is 99 lines of code. Even nyef's implementation, that is fully standalone and doesn't try to interoperate with ASDF and is missing bells and whistles and robustness and portability, is just 117 lines of code. That's a trivial amount compared to over 8000 lines of code total in ASDF+UIOP. (I count lines with lisp-stripper, which removes blank lines, comment lines, docstrings, etc.) It is NOT going to hog your systems.
I see a lot of benefit for precious little cost. As far as former extensions go, we already moved in the bundle support into ASDF (initially for the sake of ECL, but now to the benefit of everyone) and I believe that was extremely beneficial, so there is a precedent.
Certainly, if there is a huge backlash against including package-system support in ASDF, I'm sure Robert will remove it. But I strongly support the inclusion of it, and I invite you all to try this programming style if you haven't, and even if you're still using traditional .asd files. It can really help organize your source code.
PS: the reason I believe that package-system style is so good is that it enforces that inter-file dependencies are explicit, and forward references particularly so; it therefore really encourages better factoring of code, which makes it much more readable, too. Just try to make sense of ASDF 1.85 vs ASDF 3.0.3. The new code is so much easier to figure out, despite doing so much more work, and that's thanks to the package-system style. ASDF 3.0.3 is ten times the size of ASDF 1.85, but each of its file is smaller, often much smaller, than ASDF 1.85. And even maximum function size is smaller in ASDF 3.0.3 — the amount of information you must juggle with at a same time in your mind to grasp ASDF 3 is smaller than for ASDF 1. Yet ultimately, ASDF 3 does much more, and does it correctly. See my ASDF3 article: https://github.com/fare/asdf3-2013/
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Life is the worst of all social inequalities. To suppress inequalities, one must either resurrect all the dead people (and give life to all the potential living people), or exterminate all the actually living. Egalitarians, since they cannot further their goal by the former method, inevitably come to further it by the latter method.
On 16 Apr 2014, at 00:00, Faré fahree@gmail.com wrote:
Before the release is the best time for renaming things. If you have a suggestion for a better name, now is the time to speak, not later.
fasciculus
(Since we have alexandria and cesarum, we could go on…)
— __Pascal Bourguignon__
For what it's worth, I always thought of the style as being one-package-per-file, but I called the build system that I developed around it "quick build" for a completely unrelated reason.
I would suggest not calling it "quick-build", but other than that I'm not sure that I care.
On Tue, Apr 15, 2014 at 6:20 PM, Pascal J. Bourguignon < pjb@informatimago.com> wrote:
On 16 Apr 2014, at 00:00, Faré fahree@gmail.com wrote:
Before the release is the best time for renaming things. If you have a suggestion for a better name, now is the time to speak, not later.
fasciculus
(Since we have alexandria and cesarum, we could go on…)
— __Pascal Bourguignon__
fasciculus is nice (small package in latin) But one-package-per-file is nicer. *If* there's going to be a renaming, I'd vote for that, without a -system suffix: asdf/one-package-per-file.lisp (defsystem foo :class :one-package-per-file ...)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What is mind? No matter! What is matter? Never mind! — Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest
On Tue, Apr 15, 2014 at 7:02 PM, Alastair Bridgewater alastair.bridgewater@gmail.com wrote:
For what it's worth, I always thought of the style as being one-package-per-file, but I called the build system that I developed around it "quick build" for a completely unrelated reason.
I would suggest not calling it "quick-build", but other than that I'm not sure that I care.
On Tue, Apr 15, 2014 at 6:20 PM, Pascal J. Bourguignon pjb@informatimago.com wrote:
On 16 Apr 2014, at 00:00, Faré fahree@gmail.com wrote:
Before the release is the best time for renaming things. If you have a suggestion for a better name, now is the time to speak, not later.
fasciculus
(Since we have alexandria and cesarum, we could go on…)
— __Pascal Bourguignon__
FWIW, I also think that one-package-per-file is nicer, and better than anything else I have heard. So if my vote counts and we are voting shortly, that is likely what I would go with.
On Tue, Apr 15, 2014 at 4:13 PM, Faré fahree@gmail.com wrote:
fasciculus is nice (small package in latin) But one-package-per-file is nicer. *If* there's going to be a renaming, I'd vote for that, without a -system suffix: asdf/one-package-per-file.lisp (defsystem foo :class :one-package-per-file ...)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What is mind? No matter! What is matter? Never mind! — Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest
On Tue, Apr 15, 2014 at 7:02 PM, Alastair Bridgewater alastair.bridgewater@gmail.com wrote:
For what it's worth, I always thought of the style as being one-package-per-file, but I called the build system that I developed around it "quick build" for a completely unrelated reason.
I would suggest not calling it "quick-build", but other than that I'm not sure that I care.
On Tue, Apr 15, 2014 at 6:20 PM, Pascal J. Bourguignon pjb@informatimago.com wrote:
On 16 Apr 2014, at 00:00, Faré fahree@gmail.com wrote:
Before the release is the best time for renaming things. If you have a suggestion for a better name, now is the time to speak, not later.
fasciculus
(Since we have alexandria and cesarum, we could go on…)
— __Pascal Bourguignon__
Asdf-devel mailing list Asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Alastair Bridgewater wrote:
For what it's worth, I always thought of the style as being one-package-per-file, but I called the build system that I developed around it "quick build" for a completely unrelated reason.
If that's the name pattern, I'd prefer making it a little shorter and just have package-per-file.
I would suggest not calling it "quick-build", but other than that I'm not sure that I care.
Agreed. If anything it's "quick-define," not "quick-build." And that's an unhelpful name.
cheers, r
On Tue, 15 Apr 2014, Faré wrote:
Basic idea: each file starts with a defpackage or define-package, the packages it use's or import-from's or shadowing-import-from's are detected, each package is mapped back to a system, that itself may be mapped to files under a package-system.
Before the release is the best time for renaming things. If you have a suggestion for a better name, now is the time to speak, not later.
Brainstorming names is a welcome diversion right now.
“Like it? Well I don’t see why I oughtn’t to like it. Does a boy get a chance to whitewash a fence every day?”
Here are some other ideas.
asdf-pack package-per-file 1ppf java-style-packages ;) isopacktrick bijective-packages ezpack trivial-packages trivial-systems unipack tripack 1pack file=package=system autopack packsys paxis yaps ; yet another ... macedonia ; just because clyps pack-x xpacked ps1 defall
- Daniel
Daniel Herring wrote:
asdf-pack
Too much like a compression application...
package-per-file
Like
1ppf
Don't like the leading numeral
java-style-packages ;)
ick! ;-) ...
trivial-packages trivial-systems
Don't like these because all the other trivial- systems out there are trivial portability wrappers, and that's not what this is.
cheers, r
16.04.2014, 16:28, "Anton Vodonosov" avodonosov@yandex.ru:
Maybe one-file-per-package?
Or synonyms, like single-file-package (sfpack), etc
Variants of this: file-per-package, fileperpack
OK, so the main contender seem to be, without -system suffix:
one-package-per-file
Robert, are you alright with that name? Do you insist on the shorter variant package-per-file ?
I can do the renaming this weekend, and update the various relevant libraries.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I'm going to live forever, or die trying!" — Spider Robinson
Faré wrote:
OK, so the main contender seem to be, without -system suffix:
one-package-per-file
Robert, are you alright with that name? Do you insist on the shorter variant package-per-file ?
I can do the renaming this weekend, and update the various relevant libraries.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "I'm going to live forever, or die trying!" — Spider Robinson
I don't care so much about whether or not one- is there.
But it seems to me that it would be a LOT better if "SYSTEM" appeared somewhere in this name. Even to the point that PPF-SYSTEM would be better than PACKAGE-PER-FILE...
I guess
(DEFSYSTEM foo :CLASS ONE-PACKAGE-PER-FILE )
isn't terrible, but ONE-PACKAGE-PER-FILE doesn't scream "I am a subclass of SYSTEM" to me. Note for comparison that all of our file subtypes have -FILE (like STATIC-FILE, JAVA-FILE, etc.). That seems like a good convention.
Cheers, r
On Fri, Apr 18, 2014 at 5:09 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Faré wrote:
OK, so the main contender seem to be, without -system suffix:
one-package-per-file
Robert, are you alright with that name? Do you insist on the shorter variant package-per-file ?
I can do the renaming this weekend, and update the various relevant libraries.
I don't care so much about whether or not one- is there.
But it seems to me that it would be a LOT better if "SYSTEM" appeared somewhere in this name. Even to the point that PPF-SYSTEM would be better than PACKAGE-PER-FILE...
I guess
(DEFSYSTEM foo :CLASS ONE-PACKAGE-PER-FILE )
isn't terrible, but ONE-PACKAGE-PER-FILE doesn't scream "I am a subclass of SYSTEM" to me. Note for comparison that all of our file subtypes have -FILE (like STATIC-FILE, JAVA-FILE, etc.). That seems like a good convention.
On the one hand, I hear your arguments, on the other hand, they are mitigated by the fact that: * where there is a :class one-package-per-file, there are usually no :components being declared, and so little opportunity for confusion. * conversely, parse-component-form since ASDF3 has a guard against using a subclass of system as the class of a subcomponent: (when (and parent (subtypep class 'system)) (error 'non-toplevel-system :parent parent :name name))
That makes the -system suffix less necessary in my eyes, though I would usually have reacted just as you did, and in this case, I would drop it for the sake of concision, especially since one-package-per-file-system might confusingly sound like a filesystem that has only one package, which is the opposite of it.
I will still wait for comments, but unless a better proposal comes along and/or Robert vouches for a different name, I will rename package-system to: one-package-per-file
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Love doesn't scale. — Eric S. Raymond
On Fri, Apr 18, 2014 at 7:13 PM, Faré fare@tunes.org wrote:
I will still wait for comments, but unless a better proposal comes along and/or Robert vouches for a different name, I will rename package-system to: one-package-per-file
On the other hand, Jean-Philippe Paradis just proposed package-inferred-system that doesn't look bad.
Well, I'm hoping to hear from you about a choice between these two names (or other proposals).
one-package-per-file vs package-inferred-system
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Love thy neighbor as thyself, but choose your neighborhood. — Louise Beal
On Fri, Apr 18, 2014 at 8:42 PM, Faré fare@tunes.org wrote:
On Fri, Apr 18, 2014 at 7:13 PM, Faré fare@tunes.org wrote:
I will still wait for comments, but unless a better proposal comes along and/or Robert vouches for a different name, I will rename package-system
to:
one-package-per-fileOn the other hand, Jean-Philippe Paradis just proposed package-inferred-system that doesn't look bad.
I prefer package-inferred-system, although it invites the acronym PISS
How about package-derived(deduced)-system?
I prefer PIS (or PDS) to OPPF
Mirko
Faré wrote:
On Fri, Apr 18, 2014 at 7:13 PM, Faré fare@tunes.org wrote:
I will still wait for comments, but unless a better proposal comes along and/or Robert vouches for a different name, I will rename package-system to: one-package-per-file
On the other hand, Jean-Philippe Paradis just proposed package-inferred-system that doesn't look bad.
Well, I'm hoping to hear from you about a choice between these two names (or other proposals).
one-package-per-file vs package-inferred-system
I prefer package-inferred-system and package-derived-system, FWIW.
cheers,
r
Well, I'm hoping to hear from you about a choice between these two names (or other proposals).
one-package-per-file vs package-inferred-system
I prefer package-inferred-system and package-derived-system, FWIW.
OK, so the top contender is now package-inferred-system.
Speak today, or remain forever silent.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Living your life is a task so difficult, it has never been attempted before.
How about auto-system-config or some variant of it? Such as auto-asdf-config.
Mirko
On Sat, Apr 19, 2014 at 12:35 AM, Faré fare@tunes.org wrote:
Well, I'm hoping to hear from you about a choice between these two names (or other proposals).
one-package-per-file vs package-inferred-system
I prefer package-inferred-system and package-derived-system, FWIW.
OK, so the top contender is now package-inferred-system.
Speak today, or remain forever silent.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Living your life is a task so difficult, it has never been attempted before.
Asdf-devel mailing list Asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Mirko Vukovic wrote:
How about auto-system-config or some variant of it? Such as auto-asdf-config.
A problem with these is that they suggest configuration of ASDF itself (e.g., like automatically configuring the source file and fasl file locations), rather than configuring an ASDF system.
auto-configured-system
might work, but still loses all information about the fact that the system is configured by means of its package structures.
Based on this, I'd suggest any name we choose should have both "package" and "system" in it.
Best, r
jokingly: auto-asdf-facility -- a2sdf2 or aasdff - too cute.
On Sat, Apr 19, 2014 at 1:18 PM, Mirko Vukovic mirko.vukovic@gmail.comwrote:
How about auto-system-config or some variant of it? Such as auto-asdf-config.
Mirko
On Sat, Apr 19, 2014 at 12:35 AM, Faré fare@tunes.org wrote:
Well, I'm hoping to hear from you about a choice between these two names (or other proposals).
one-package-per-file vs package-inferred-system
I prefer package-inferred-system and package-derived-system, FWIW.
OK, so the top contender is now package-inferred-system.
Speak today, or remain forever silent.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Living your life is a task so difficult, it has never been attempted before.
Asdf-devel mailing list Asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
19.04.2014, 08:35, "Faré" fare@tunes.org:
OK, so the top contender is now package-inferred-system.
Speak today, or remain forever silent.
package-as-system
Anton Vodonosov wrote:
19.04.2014, 08:35, "Faré" fare@tunes.org:
OK, so the top contender is now package-inferred-system.
Speak today, or remain forever silent.
package-as-system
This keeps "package" and "system," but seems to imply that there's only one package per system, rather than that the dependency structure of the system is inferred from the dependencies between packages....
On Fri, Apr 18, 2014 at 9:47 PM, Robert P. Goldman rpgoldman@sift.info wrote:
one-package-per-file vs package-inferred-system
I prefer package-inferred-system and package-derived-system, FWIW.
The deed is done: the new name is package-inferred-system. I personally slightly preferred one-package-per-file, and so did drewc (the main other user publishing free software libraries using it), but it seems there is a clear plurality for package-inferred-system, and Robert's voice should weigh more, since he's the maintainer.
Anton: can you do a run of cl-test-grid with the latest ASDF from master (currently 3.1.0.116) ? I believe it's a release candidate.
If you have time, please also run the latest from the syntax-control branch, that I'd like to convince Robert is good to be merged before release rather than after (the only syntax variable it controls by default is *readtable*, which is pretty conservative, yet gets us most of the way to user-controlled syntax, and in particular, makes it safe to invoke ASDF from a REPL that has a different *readtable*).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The nine most terrifying words in the English language are: "I'm from the government and I'm here to help." — Ronald Reagan.
21.04.2014, 03:44, "Faré" fare@tunes.org:
Anton: can you do a run of cl-test-grid with the latest ASDF from master (currently 3.1.0.116) ? I believe it's a release candidate.
Tests started
21.04.2014, 03:44, "Faré" fare@tunes.org:
Anton: can you do a run of cl-test-grid with the latest ASDF from master (currently 3.1.0.116) ? I believe it's a release candidate.
Completed so far on ccl-1.9-f96-linux-x86 clisp-2.49-unix-x86 cmu-snapshot-2014-01__20e_unicode_-linux-x86 sbcl-1.1.11-linux-x86 sbcl-1.1.16-linux-x86
Other lisps are running.
The report: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-41.html
The most interesting error is cl-protobufs-tests: "don't recognize component type COMMON-LISP-USER::MODULE"
As for others, CCL-only failure of femlisp and graph-matrix is the problem we seen before: NO-APPLICABLE-METHOD-EXISTS CCL:SLOT-VALUE-USING-CLASS during ASDF upgrade on CCL (http://trac.clozure.com/ccl/ticket/1157)
teepeedee2 fails because it includes copy of babel in it's source tree, incompatible with the babel from quicklisp.
Best regards, - Anton
On Mon, Apr 21, 2014 at 5:18 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
21.04.2014, 03:44, "Faré" fare@tunes.org:
Anton: can you do a run of cl-test-grid with the latest ASDF from master (currently 3.1.0.116) ? I believe it's a release candidate.
Completed so far on ccl-1.9-f96-linux-x86 clisp-2.49-unix-x86 cmu-snapshot-2014-01__20e_unicode_-linux-x86 sbcl-1.1.11-linux-x86 sbcl-1.1.16-linux-x86
Other lisps are running.
The report: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-41.html
Thanks a lot!
The most interesting error is cl-protobufs-tests: "don't recognize component type COMMON-LISP-USER::MODULE"
That's a known bug, fixed upstream. Some sloppiness in the .asd that wasn't caught before.
As for others, CCL-only failure of femlisp and graph-matrix is the problem we seen before: NO-APPLICABLE-METHOD-EXISTS CCL:SLOT-VALUE-USING-CLASS during ASDF upgrade on CCL (http://trac.clozure.com/ccl/ticket/1157)
And again, I can't reproduce it at home. I do have a more recent femlisp than quicklisp, but I don't believe that is at stake.
teepeedee2 fails because it includes copy of babel in it's source tree, incompatible with the babel from quicklisp.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No one can make you feel inferior without your consent — Eleanor Roosevelt But you're only fooling yourself if you can't recognize your superiors — #f
22.04.2014, 01:18, "Anton Vodonosov" avodonosov@yandex.ru:
21.04.2014, 03:44, "Faré" fare@tunes.org:
Anton: can you do a run of cl-test-grid with the latest ASDF from master (currently 3.1.0.116) ? I believe it's a release candidate.
Completed so far on ccl-1.9-f96-linux-x86 clisp-2.49-unix-x86 cmu-snapshot-2014-01__20e_unicode_-linux-x86 sbcl-1.1.11-linux-x86 sbcl-1.1.16-linux-x86
Other lisps are running.
The report: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-41.html
The report is updated with results for abcl-1.2.0-fasl42-linux-x86 abcl-1.2.1-fasl42-linux-x86 abcl-1.3.0-svn-14688-fasl42-linux-x86 ecl-13.5.1-unknown-linux-i686-bytecode ecl-13.5.1-unknown-linux-i686-lisp-to-c
No new regressions found.
If you have time, please also run the latest from the syntax-control branch,
I am now testing qlalpha 2014-04-21 - pre-release of april's quicklisp update. Can test the syntax-control branch after that.
Best regards, - Anton
21.04.2014, 03:44, "Faré" fare@tunes.org:
If you have time, please also run the latest from the syntax-control branch,
Tested on quicklisp 2014-04-25 and abcl-1.2.1-fasl42-linux-x86 abcl-1.3.1-rc-2-svn-14695-fasl42-linux-x86 ccl-1.9-f96-linux-x86 clisp-2.49-unix-x86 cmu-snapshot-2014-01__20e_unicode_-linux-x86 ecl-13.5.1-unknown-linux-i686-bytecode ecl-13.5.1-unknown-linux-i686-lisp-to-c sbcl-1.1.11-linux-x86 sbcl-1.1.16-linux-x86
No regressions comparing to the ASDF versions originally shipped with those lisps: http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-42.html
Best regards, - Anton
-
Alastair Bridgewater -
Anton Vodonosov -
Cyrus Harmon -
Daniel Herring -
Drew Crampsie -
Faré -
Faré -
Mirko Vukovic -
Pascal J. Bourguignon -
Robert P. Goldman