Dear Zach,
I'm a bit concerned about quicklisp shipping with a very old version of ASDF. Quicklisp says it depends on ASDF 2.011 or later in its *required-asdf-version*, but then you ship with 2.014.6 to load if the implementation's ASDF is too old. Both 2.011 and 2.014.6 are antique by ASDF standards, and what more, being older than 2.015, have trouble with self-upgrade as part of loading other systems that depend on ASDF. Actually, the good version for self-upgrade is 2.014.8, but I'm rounding to the next stable release; which brings me to my next point: 2.014.6 is not just old, but it's not a supported release version (not that all release versions are stable; 2.015 had many issues; but the supported answer is always to upgrade to the next stable release).
What is the policy for upgrading the ASDF in Quicklisp? If it's not "never, ever", is it possible to upgrade your ASDF to something more recent?
For instance, quicklisp contains asdf-encodings and xcvb which depend on asdf 2.21 for its :encoding feature, and asdf-finalizers which depends on asdf 2.23 for its :compile-check feature. Even without speaking of features, numerous implementation-specific fixes were committed since 2.014.6, and new implementations are supported.
Why, of all CL software, is ASDF the only one never to be updated with Quicklisp? Is there anything I can do to make things more comfortable for you with respect to upgrading ASDF?
PS: I otherwise think your work with Quicklisp is wonderful.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The penalty for laughing in a courtroom is six months in jail; if it were not for this penalty, the jury would never hear the evidence. — H. L. Mencken
Faré fahree@gmail.com writes:
Dear Zach,
I'm a bit concerned about quicklisp shipping with a very old version of ASDF. Quicklisp says it depends on ASDF 2.011 or later in its *required-asdf-version*, but then you ship with 2.014.6 to load if the implementation's ASDF is too old. Both 2.011 and 2.014.6 are antique by ASDF standards, and what more, being older than 2.015, have trouble with self-upgrade as part of loading other systems that depend on ASDF. Actually, the good version for self-upgrade is 2.014.8, but I'm rounding to the next stable release; which brings me to my next point: 2.014.6 is not just old, but it's not a supported release version (not that all release versions are stable; 2.015 had many issues; but the supported answer is always to upgrade to the next stable release).
What is the policy for upgrading the ASDF in Quicklisp? If it's not "never, ever", is it possible to upgrade your ASDF to something more recent?
For instance, quicklisp contains asdf-encodings and xcvb which depend on asdf 2.21 for its :encoding feature, and asdf-finalizers which depends on asdf 2.23 for its :compile-check feature. Even without speaking of features, numerous implementation-specific fixes were committed since 2.014.6, and new implementations are supported.
Why, of all CL software, is ASDF the only one never to be updated with Quicklisp?
Is there anything I can do to make things more comfortable for you with respect to upgrading ASDF?
I stopped updating ASDF versions when it seemed to require asdf-ecl.lisp to work on ECL. Is the case? Can ECL get by with asdf.lisp alone?
Quicklisp is geared towards providing libraries ("systems"), and I see ASDF is an application for loading systems, not a library. It has a parallel and separate system for updates in Quicklisp. I have put time and effort into making it possible to "downgrade" library sets with Quicklisp, providing an escape hatch for harmful changes to libraries, there is no easy mechanism for ASDF. (There's also no easy mechanism for Quicklisp itself, but I am not too troubled by that since I can make quick updates to Quicklisp directly if needed.)
I'm up for upgrading the provided version to a more recent ASDF if it is still a single file on all implementations and if it doesn't cause any major compatibility problems. Of course, those always seem to crop up after things have been pushed into wide use, not during testing.
Jumping on a frequent upgrade cycle for ASDF does not excite me, though.
Zach
On Fri, Oct 12, 2012 at 10:31 AM, Zach Beane xach@xach.com wrote:
I stopped updating ASDF versions when it seemed to require asdf-ecl.lisp to work on ECL. Is the case? Can ECL get by with asdf.lisp alone?
Wait: inasmuch as ECL likes to have asdf-ecl.lisp loaded, this has *ALWAYS* been the case, since back in the days of ASDF 1. The difference is that at the time, everyone was forced to use whichever version of ASDF was bundled with their implementation, which in the case of ECL would include asdf-ecl, even though asdf-ecl wasn't included in the upstream version of ASDF.
If anything, ASDF 2 has made things BETTER for those who load asdf without loading asdf-ecl: I've moved into asdf.lisp all the essential bits that were previously in asdf-ecl.lisp (if only for the sake of asdf self-upgrade). Also, if you fail to load asdf-ecl, you may now find that the same functionality is now available as part of asdf-bundle (though it's largely untested by lack of test cases; I suppose I could modify cl-launch to test some of it).
Note that if you're concerned about ECL, ECL support was notably improved since the version of ASDF you picked (2.014.6). The latest significant change for ECL support is in 2.23.1 (merging in various enhancements made in the ECL source tree), with various subsequent cleanups before 2.24, as I added MKCL support and refactored ECL and MKCL support together. But for the sake of running on ECL without asdf-ecl, you really want at least 2.21 (though 2.018 or 2.019 might do; I would have to re-test; 2.20 had a bug with ECL).
Quicklisp is geared towards providing libraries ("systems"), and I see ASDF is an application for loading systems, not a library.
Yes, but some libraries require recent versions of ASDF to use recent features (:defsystem-depends-on, :encoding, :around-compile, :compile-check) or bug fixes (nikodemus I'm sure would be delighted to be able to rely on a fixed default-component-class; also fixed was weakly-depends-on). Many implementations also require a recent ASDF: lispworks-personal-edition has been broken for a while before stassats noticed (since it has no command-line, it's not part of my automated tests); XCL, MKCL were added; abcl, allegro, ccl, clisp, lispworks have had notable fixes, as well as cormanlisp, GCL, Genera, RMCL (if anyone still uses them). Windows search paths have been fixed (also something I don't test automatically). Logical-pathnames were fixed (again). Self-upgrading has been made more robust on all platforms. Various instabilities you yourself reported when using quicklisp were fixed. Many other bugfixes, tweaks, usability improvements were made.
It has a parallel and separate system for updates in Quicklisp. I have put time and effort into making it possible to "downgrade" library sets with Quicklisp, providing an escape hatch for harmful changes to libraries, there is no easy mechanism for ASDF. (There's also no easy mechanism for Quicklisp itself, but I am not too troubled by that since I can make quick updates to Quicklisp directly if needed.)
The "self-upgrade" of ASDF can also be used for self-downgrade, although there were bugs and limitations that have been lifted with 2.015 (i.e. if the *initial* ASDF is earlier than 2.015, you must load the new ASDF alone *before* you load any other system; if you load a system that depends on ASDF, the upgrade won't go smoothly).
I'm up for upgrading the provided version to a more recent ASDF if it is still a single file on all implementations and if it doesn't cause any major compatibility problems. Of course, those always seem to crop up after things have been pushed into wide use, not during testing.
Yes. I always think to myself "this is the LAST asdf release", and right after I release it, someone tells me about a bug. Happily, the bugs seem to get smaller after each release, these days.
Jumping on a frequent upgrade cycle for ASDF does not excite me, though.
I'm not asking for a *frequent* upgrade. But considering how much ASDF has evolved recently, I think it reasonable to request that you should upgrade at least once a year. 2.014.6 is from April 2011, which is well past its due date.
PS: Attila Lendvai pushed a fix to hu.dwim.asdf so you should be all set there.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The rule is perfect: in all matters of opinion our adversaries are insane. — Mark Twain
Faré fahree@gmail.com writes:
Quicklisp is geared towards providing libraries ("systems"), and I see ASDF is an application for loading systems, not a library.
Yes, but some libraries require recent versions of ASDF to use recent features
I think this is primarily, though not exclusively, your libraries, and primarily, though not exclusively, because you are the controller of ASDF.
Zach
On Fri, Oct 12, 2012 at 11:12 AM, Zach Beane xach@xach.com wrote:
Faré fahree@gmail.com writes:
Quicklisp is geared towards providing libraries ("systems"), and I see ASDF is an application for loading systems, not a library.
Yes, but some libraries require recent versions of ASDF to use recent features
I think this is primarily, though not exclusively, your libraries, and primarily, though not exclusively, because you are the controller of ASDF.
Yes, I am the first one to rely on the new features: I know it's there, I know it needs to be tested in a real example, and I know it needs to be show-cased before it takes on. If I don't use it, it may end up being actually unusable, like :defsystem-depends-on which was proposed early on for asdf 2, added in 2.010, but only actually working and useful in 2.016 when I started using it.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Down to Gehenna or up to the Throne, He travels the fastest who travels alone. — Rudyard Kipling
On Fri, Oct 12, 2012 at 4:31 PM, Zach Beane xach@xach.com wrote:
I stopped updating ASDF versions when it seemed to require asdf-ecl.lisp to work on ECL. Is the case? Can ECL get by with asdf.lisp alone?
Since Faré took over ASDF, ASDF has worked perfectly fine with ECL so that is not a reason not to upgrade. However, asdf-ecl.lisp was not developed to fix asdf.lisp, but to introduce operations that make ASDF more efficient with ECL.
In other words, ECL can do with asdf alone but this is undesirable. For instance, quicklisp's reliance on 'ASDF:LOAD-OP implies loading an average of 10 times more files than ECL's ASDF:LOAD-FASL-OP, and also a greater pressure on the operating system, for ECL relies on native methods for loading binaries.
Moreover, asdf-ecl allows one to take quicklisp distribution and produce a standalone executable, or a shared library (DLL) with one ASDF operation. This, which I find extremely nice, has been ported by Fare to other implementations in a successor to asdf-ecl that I have not yet had the time to integrate in ECL.
Juanjo
Juan Jose Garcia-Ripoll juanjose.garciaripoll@gmail.com writes:
On Fri, Oct 12, 2012 at 4:31 PM, Zach Beane xach@xach.com wrote:
I stopped updating ASDF versions when it seemed to require asdf-ecl.lisp to work on ECL. Is the case? Can ECL get by with asdf.lisp alone?Since Faré took over ASDF, ASDF has worked perfectly fine with ECL so that is not a reason not to upgrade. However, asdf-ecl.lisp was not developed to fix asdf.lisp, but to introduce operations that make ASDF more efficient with ECL.
In other words, ECL can do with asdf alone but this is undesirable. For instance, quicklisp's reliance on 'ASDF:LOAD-OP implies loading an average of 10 times more files than ECL's ASDF:LOAD-FASL-OP, and also a greater pressure on the operating system, for ECL relies on native methods for loading binaries.
Moreover, asdf-ecl allows one to take quicklisp distribution and produce a standalone executable, or a shared library (DLL) with one ASDF operation. This, which I find extremely nice, has been ported by Fare to other implementations in a successor to asdf-ecl that I have not yet had the time to integrate in ECL.
Does ECL include asdf-ecl already, and track each new release of ASDF?
Zach
On Fri, Oct 12, 2012 at 8:22 PM, Zach Beane xach@xach.com wrote:
Does ECL include asdf-ecl already, and track each new release of ASDF?
Though I have failed to track a couple of the latest releases, I try to keep as close as possible to ASDF's releases. The configuration of ECL is such that (require :asdf) loads a bundle asdf-ecl + asdf which is precompiled and stored in ECL's directories (this also loads the compiler).
Juanjo
-
Faré -
Juan Jose Garcia-Ripoll -
Zach Beane