I have been running with ASDF from ACL and sometimes overloading it with ASDF from git.
This gives me package errors like the following:
; Fast loading /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf-context/set-context.fasl Error loading #P"/Users/rpg/clinit.cl": No package exists of name ASDF/LISP-ACTION.
I suspect this happened because ASDF-context was compiled in an image with ASDF 3 loaded, and is being loaded in an image with ASDF 2.x (shipped by Franz with Allegro).
Is there something I can do in systems that build on ASDF to avoid this from happening?
Putting (:depends-on ASDF) in the relevant system (here my "asdf-context" system) does not solve the problem.
It seems that we need a mechanism that says "if ASDF has changed its package structure, you must recompile."
I understand the original motivation for subdividing the packages, but I think in future we need to be careful not to do this without an explicit plan to ensure it doesn't cause this kind of bug.
It's an interesting unforeseen issue in the plan to be able to upgrade ASDF -- you need also to be able to downgrade! I.e., if I want to be able to test new ASDF, I may still need to work with colleagues who are using an older, implementation-provided version.
For now, I can simply blow away my cache, and I expect that will solve the problem, but it's something to consider.
thanks, r
If this is a big problem, we could add a -asdf3 or -a3 or such to the name of the implementation string directory.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Better, faster, cheaper — pick any two.
On Wed, May 29, 2013 at 2:16 PM, Robert Goldman rpgoldman@sift.info wrote:
I have been running with ASDF from ACL and sometimes overloading it with ASDF from git.
This gives me package errors like the following:
; Fast loading /Users/rpg/.cache/common-lisp/acl-8.2-macosx-x64/Users/rpg/lisp/asdf-context/set-context.fasl Error loading #P"/Users/rpg/clinit.cl": No package exists of name ASDF/LISP-ACTION.
I suspect this happened because ASDF-context was compiled in an image with ASDF 3 loaded, and is being loaded in an image with ASDF 2.x (shipped by Franz with Allegro).
Is there something I can do in systems that build on ASDF to avoid this from happening?
Putting (:depends-on ASDF) in the relevant system (here my "asdf-context" system) does not solve the problem.
It seems that we need a mechanism that says "if ASDF has changed its package structure, you must recompile."
I understand the original motivation for subdividing the packages, but I think in future we need to be careful not to do this without an explicit plan to ensure it doesn't cause this kind of bug.
It's an interesting unforeseen issue in the plan to be able to upgrade ASDF -- you need also to be able to downgrade! I.e., if I want to be able to test new ASDF, I may still need to work with colleagues who are using an older, implementation-provided version.
For now, I can simply blow away my cache, and I expect that will solve the problem, but it's something to consider.
thanks, r
-
Faré -
Robert Goldman