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.
On 2/7/13 Feb 7 -2:49 PM, Anton Vodonosov wrote:
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.
Question: is this enough for Quicklisp? Does quicklisp ever need to specify a particular version of ASDF?
I think of people running with release versions of implementations that are not so eagerly updated.
E.g., if you install the SBCL that comes with your linux install, instead of building yourself, if you use a CCL 1.8 release, instead of building from svn, or if you use a commercial CL implementation....
I had the impression that in some of these cases you might find yourself with an ASDF that is not sufficient to run the latest QL. Is that not so?
best, r
08.02.2013, 01:11, "Robert Goldman" rpgoldman@sift.info:
On 2/7/13 Feb 7 -2:49 PM, Anton Vodonosov wrote:
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.
Question: is this enough for Quicklisp? Does quicklisp ever need to specify a particular version of ASDF?
I think of people running with release versions of implementations that are not so eagerly updated.
E.g., if you install the SBCL that comes with your linux install, instead of building yourself, if you use a CCL 1.8 release, instead of building from svn, or if you use a commercial CL implementation....
I had the impression that in some of these cases you might find yourself with an ASDF that is not sufficient to run the latest QL. Is that not so?
If user lods his own version of ASDF in the beginning, then the ASDF distributed with CL implementation is not used. Right?
On 2/7/13 Feb 7 -3:29 PM, Anton Vodonosov wrote:
08.02.2013, 01:11, "Robert Goldman" rpgoldman@sift.info:
On 2/7/13 Feb 7 -2:49 PM, Anton Vodonosov wrote:
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.
Question: is this enough for Quicklisp? Does quicklisp ever need to specify a particular version of ASDF?
I think of people running with release versions of implementations that are not so eagerly updated.
E.g., if you install the SBCL that comes with your linux install, instead of building yourself, if you use a CCL 1.8 release, instead of building from svn, or if you use a commercial CL implementation....
I had the impression that in some of these cases you might find yourself with an ASDF that is not sufficient to run the latest QL. Is that not so?
If user lods his own version of ASDF in the beginning, then the ASDF distributed with CL implementation is not used. Right?
I'm still not following you. If I have a stale copy of ASDF that came with my implementation, and I load it, then I start using QL, doesn't the version of ASDF that comes with QL need to hot upgrade?
thanks, r
08.02.2013, 01:34, "Robert Goldman" rpgoldman@sift.info:
I'm still not following you. If I have a stale copy of ASDF that came with my implementation, and I load it,
No, you do not load stale version.
then I start using QL, doesn't the version of ASDF that comes with QL need to hot upgrade?
On 2/7/13 Feb 7 -3:36 PM, Anton Vodonosov wrote:
08.02.2013, 01:34, "Robert Goldman" rpgoldman@sift.info:
I'm still not following you. If I have a stale copy of ASDF that came with my implementation, and I load it,
No, you do not load stale version.
Is this always achievable?
I don't know enough about the range of implementations to know if it's always possible to avoid loading a stale ASDF.
Is there any case where the implementation uses ASDF enough that one must load ASDF in order to get the implementation into a position where it can load Quicklisp?
08.02.2013, 01:43, "Robert Goldman" rpgoldman@sift.info:
On 2/7/13 Feb 7 -3:36 PM, Anton Vodonosov wrote:
08.02.2013, 01:34, "Robert Goldman" rpgoldman@sift.info:
I'm still not following you. If I have a stale copy of ASDF that came with my implementation, and I load it,
No, you do not load stale version.
Is this always achievable?
I don't know enough about the range of implementations to know if it's always possible to avoid loading a stale ASDF.
Is there any case where the implementation uses ASDF enough that one must load ASDF in order to get the implementation into a position where it can load Quicklisp?
I haven't tested all the implementations. Fare told me once that he is not aware of any implementation that loads ASDF without you explicitly doing a (require "asdf").
On 2/7/13 Feb 7 -3:56 PM, Anton Vodonosov wrote:
08.02.2013, 01:43, "Robert Goldman" rpgoldman@sift.info:
On 2/7/13 Feb 7 -3:36 PM, Anton Vodonosov wrote:
08.02.2013, 01:34, "Robert Goldman" rpgoldman@sift.info:
I'm still not following you. If I have a stale copy of ASDF that came with my implementation, and I load it,
No, you do not load stale version.
Is this always achievable?
I don't know enough about the range of implementations to know if it's always possible to avoid loading a stale ASDF.
Is there any case where the implementation uses ASDF enough that one must load ASDF in order to get the implementation into a position where it can load Quicklisp?
I haven't tested all the implementations. Fare told me once that he is not aware of any implementation that loads ASDF without you explicitly doing a (require "asdf").
If I do a (require <FOO>) for <FOO> some internally supplied library of SBCL, doesn't that trigger the use of ASDF to load <FOO>?
Best, r
08.02.2013, 02:12, "Robert Goldman" rpgoldman@sift.info:
If I do a (require <FOO>) for <FOO> some internally supplied library of SBCL, doesn't that trigger the use of ASDF to load <FOO>?
It does. For example, (require :sb-bsd-sockets) also loads ASDF.
But If if I load my ASDF before doing (require :sb-bsd-sockets) then my ASDF is used.
The question: is this situation mean that ASDF must be hot-upgradable? IMHO not, because there is enough freedom for user to load his ASDF in the beginning.
If I do a (require <FOO>) for <FOO> some internally supplied library of SBCL, doesn't that trigger the use of ASDF to load <FOO>?
It does. For example, (require :sb-bsd-sockets) also loads ASDF.
Note that if and when SBCL uses ASDF 3, it will be trivial to update its contrib to use the one-fasl-for-the-entire-contrib approach, and not have any contrib require ASDF. But we're not there yet.
But If if I load my ASDF before doing (require :sb-bsd-sockets) then my ASDF is used.
Yes.
The question: is this situation mean that ASDF must be hot-upgradable? IMHO not, because there is enough freedom for user to load his ASDF in the beginning.
In the current world, ASDF must still be hot-upgradable.
It is conceivable that we could move toward a world where it need not. Beware, though, of the perverse incentives that used to exist in the previous situation where it was not: http://fare.livejournal.com/149264.html You will need some force capable of countering them.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The main difference between a computer salesman and a used car salesman is that the used car salesman can probably drive and knows when he's lying. - Peter da Silva
-
Anton Vodonosov -
Faré -
Robert Goldman