Hello.
I have a local project, it's ASDF system specifies :depends-on (#:fiveam ...)
The recent quicklisp delivers new version of fiveam. But when my program performed asdf:load-op on that system, the system didn't get recompiled, and old .fasl files are loaded (with error, because they become incompatible).
Is it expected behaviour of ASDF or should I dig more and isolate the problem in reproducible test case?
Best regards, - Anton
07.07.2012, 15:40, "Anton Vodonosov" avodonosov@yandex.ru:
Hello.
I have a local project, it's ASDF system specifies :depends-on (#:fiveam ...)
The recent quicklisp delivers new version of fiveam. But when my program performed asdf:load-op on that system, the system didn't get recompiled, and old .fasl files are loaded (with error, because they become incompatible).
Is it expected behaviour of ASDF or should I dig more and isolate the problem in reproducible test case?
BTW, maybe it is important: fiveam was already loaded at the time asdf:load-op was performed on my system.
I am afraid that this is a known misfeature of ASDF. ASDF doesn't recursively check the freshness of depended-on systems. We left this as is, in order to avoid a more substantial rewrite, and maintain compatibility.
See bugs 627173 and 479522 (the second one should probably be retitled).
Best, R
Sent from my iPad
On Jul 7, 2012, at 6:55, Anton Vodonosov avodonosov@yandex.ru wrote:
07.07.2012, 15:40, "Anton Vodonosov" avodonosov@yandex.ru:
Hello.
I have a local project, it's ASDF system specifies :depends-on (#:fiveam ...)
The recent quicklisp delivers new version of fiveam. But when my program performed asdf:load-op on that system, the system didn't get recompiled, and old .fasl files are loaded (with error, because they become incompatible).
Is it expected behaviour of ASDF or should I dig more and isolate the problem in reproducible test case?
BTW, maybe it is important: fiveam was already loaded at the time asdf:load-op was performed on my system.
asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On Sat, Jul 7, 2012 at 7:55 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
I have a local project, it's ASDF system specifies :depends-on (#:fiveam ...)
The recent quicklisp delivers new version of fiveam. But when my program performed asdf:load-op on that system, the system didn't get recompiled, and old .fasl files are loaded (with error, because they become incompatible).
Is it expected behaviour of ASDF or should I dig more and isolate the problem in reproducible test case?
BTW, maybe it is important: fiveam was already loaded at the time asdf:load-op was performed on my system.
IIUC, this is the well-known, long-standing bug 479522. https://bugs.launchpad.net/asdf/+bug/479522
I think it's time to fix the bug. There once was a rationale for keeping it around (i.e. some people might rely on the current behavior; also, compilation was much slower then and avoiding it was a big win); but it makes less sense now that :force and :force-not work and should allow whoever doesn't like the default behavior to override it.
PS: do you use Lisp at Yandex?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Guns & bullets don't kill people — blood loss and organ damage kills people.
07.07.2012, 19:11, "Faré" fahree@gmail.com:
IIUC, this is the well-known, long-standing bug 479522. https://bugs.launchpad.net/asdf/+bug/479522
I think it's time to fix the bug. There once was a rationale for keeping it around (i.e. some people might rely on the current behavior; also, compilation was much slower then and avoiding it was a big win); but it makes less sense now that :force and :force-not work and should allow whoever doesn't like the default behavior to override it.
Ok, thanks.
PS: do you use Lisp at Yandex?
I don't work for that company. They just provide public email services (like gmail or yahoo).
In the companies I worked so far we haven't used Lisp, only C++, Java, etc. So I am a hobbyist lisper - just learning programming and do some personal projects.
-
Anton Vodonosov -
Faré -
Robert P. Goldman