Could SLIME adopt ASDF as a way to compile itself and other software?
I understand that ASDF was quite insufficient for the needs of SLIME back in the bad old days, but these days, ASDF 2 (1) is available via (require "asdf") on *every* implementation that has been released in the last two years (i.e. not on corman gcl genera rmcl scl - though it runs on all of them) (2) already manages a decent FASL cache so SLIME doesn't have to. (3) can upgrade itself correctly if needed.
ASDF has also improved a lot in the last few years. The upcoming release 2.27 formalizes a lot of the portability support that had accumulated through the years, improves on it, and adds features like condition control, saving of deferred warnings, image dump and restore, etc.
In any case, that would be as much bad code duplication that could die.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If debugging is the process of removing bugs, then programming must be the process of putting them in. — Dijkstra
Yay for that plan.
When Allegro came out with 9.0 SMP (with incompatible fasls to the non-SMP) the swank fasls from SMP were colliding with the ones left over from a previous non-SMP startup... I submitted a patch for it and it's fixed now. Not a really big deal (at least for me, but did create work for Helmut too), but even that kind of little dance will not be needed if swank can just go ahead and start using asdf:*output-translations* for its fasls.
On Sat, Jan 19, 2013 at 5:32 PM, Faré fahree@gmail.com wrote:
Could SLIME adopt ASDF as a way to compile itself and other software?
I understand that ASDF was quite insufficient for the needs of SLIME back in the bad old days, but these days, ASDF 2 (1) is available via (require "asdf") on *every* implementation that has been released in the last two years (i.e. not on corman gcl genera rmcl scl - though it runs on all of them) (2) already manages a decent FASL cache so SLIME doesn't have to. (3) can upgrade itself correctly if needed.
ASDF has also improved a lot in the last few years. The upcoming release 2.27 formalizes a lot of the portability support that had accumulated through the years, improves on it, and adds features like condition control, saving of deferred warnings, image dump and restore, etc.
In any case, that would be as much bad code duplication that could die.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If debugging is the process of removing bugs, then programming must be the process of putting them in. — Dijkstra
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Faré fahree@gmail.com writes:
Could SLIME adopt ASDF as a way to compile itself and other software?
I understand that ASDF was quite insufficient for the needs of SLIME back in the bad old days, but these days, ASDF 2 (1) is available via (require "asdf") on *every* implementation that has been released in the last two years (i.e. not on corman gcl genera rmcl scl - though it runs on all of them) (2) already manages a decent FASL cache so SLIME doesn't have to. (3) can upgrade itself correctly if needed.
ASDF has also improved a lot in the last few years. The upcoming release 2.27 formalizes a lot of the portability support that had accumulated through the years, improves on it, and adds features like condition control, saving of deferred warnings, image dump and restore, etc.
In any case, that would be as much bad code duplication that could die.
Avoiding code duplication is not really a concern for Slime, it already implements its own socket, threads and other abstractions. The way Slime manages loading of lisp files works quite well currently, there's no reason to subject the users to possible problems resulting from transition to ASDF.
On Sat, Jan 19 2013, Faré wrote:
Could SLIME adopt ASDF as a way to compile itself and other software?
This is a rather vague question. If you want to have a change to swank.asd or swank-asdf.lisp then just go ahead and send a patch.
OTOH, changing the startup procedure is a much more delicate issue and "avoid code duplication" is not a sufficient justification.
There might be arguments in favor of clbuild. A tool to start any Lisp with the same set of command line parameters would certainly be desirable. As a bonus it can load ASDF and Quicklisp for us.
Helmut
-
Dave Cooper -
Faré -
Helmut Eller -
Stas Boukarev