© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
If you're willing to merge in the changes, I can help with improving the ASDF support.
However, one question remains to me: how old ASDF versions do you want to support?
Many things can be simplified by assuming ASDF 2.000 or newer, and even more things can be simplified if we can assume a relatively recent ASDF (quicklisp has 2.014.6, SBCL from 2011-08-22 or CCL from 2011-07-28 has 2.017, etc).
On the one hand, we should never assume that SLIME runs on super-recent software: debugging, by definition, may happen on software written long ago.
On the other hand, the very idea behind ASDF2 is that you can always upgrade an existing image to use the latest ASDF, even on top of an existing old ASDF.
On the first hand, when you upgrade ASDF, it invalidates previous defsystems in memory, because of potential incompatibilities.
On the second hand, after the defsystems have been invalidated, they can always be reloaded from disk.
On the first hand, you might not always have the exact source used to compile the image version you're debugging.
On the second hand, if you don't have the matching source, then you're not going to have much use for the original system definitions, anyway.
So there. I believe my conclusion is that we should NOT be worrying about ASDF versions that are too old, and that older than 2.000 is probably too old, considering that all maintained implementations have adopted ASDF 2 some time between 2010 and 2011. Hopefully, we can declare anything older than 2.011 obsolete (valid as per 2010-11-28). Actually, I'd really like to declare things before 2.015 obsolete, but that isn't realistic yet, considering that quicklisp still sports 2.014.6 (yikes).