07.02.2013, 07:02, "Faré" fahree@gmail.com:
On Wed, Feb 6, 2013 at 9:22 PM, Anton Vodonosov avodonosov@yandex.ru wrote: I have impression that the code upgrade support is one of the most expensive features in ASDF.
It is, and by far.
Maybe I should have stuck with deleting the package ASDF and all packages that depend on it.
If the hot upgrade is difficult to support due to CL limitations, maybe we should not fight the language and just do not support hot upgrade? Even if it's possible to overcome the language limitations (even in C it is possible to switch implementation at run-time, if you use some indirection, like Bridge Pattern; in CL maybe other possibilities exit, like Pascal proposes to use only generic functions). But anyway, maintaining the hot upgrade requires efforts, I do not understand what is the justification.
I have read in the ASDF texts [1] that hot-upgrade of ASDF was necessary to overcome a social problem of distributing of new ASDF version with all the CL implementation.
Today it seems that collaboration is established between ASDF and CL implementation developers and CL implementations update ASDF often.
Also, if user wants to use newer version of ASDF than is provided with hist CL implementations, he just loads the newer ASDF. After this, even if he does (require :asdf) the ASDF version provided by the CL implementation is not loaded, because ASDF registers itself in cl:*modules*.
And Quicklisp could avoid (require :asdf). Instead it could just check if ASDF is already loaded. If it is, then use the version is loaded. If it isn't then immediately load the ASDF version shipped with Quicklisp.
I am testing now CCL and SBCL with Quicklisp patched in this manner and ASDF 2.28.6.
I may be missing something about the hot-upgrade. If it is the case, I would appreciate an explanation.