Hi,
I'm setting up a new lisp system on a new debian lenny machine and one of the lisp libraries I'm trying to load is asking to load the asdf-utilities package, but this package doesn't exist.
Was this included with ASDF1 and not ASDF2? If so, how do people work around those libraries that require asdf-utilities?
I'm using the latest version of openmcl/clozure/ccl from trunk. The asdf version that loads is 2.009. I believe asdf is included with ccl. Appreciate any ideas.
Thanks, Lou Vanek
On 11 October 2010 09:19, Lou Vanek lou.vanek@gmail.com wrote:
I'm setting up a new lisp system on a new debian lenny machine and one of the lisp libraries I'm trying to load is asking to load the asdf-utilities package, but this package doesn't exist.
Was this included with ASDF1 and not ASDF2? If so, how do people work around those libraries that require asdf-utilities?
I'm using the latest version of openmcl/clozure/ccl from trunk. The asdf version that loads is 2.009. I believe asdf is included with ccl. Appreciate any ideas.
Sorry, it's a bug introduced in ASDF2, then resolved in ASDF2.
I introduced ASDF-UTILITIES some time before ASDF 2.000, as a replacement for the ill-fated ASDF-EXTENSIONS, before I realized that ASDF-EXTENSIONS had never been used in ASDF1 anyway (didn't export anything), and that the demand from the public was to leave utilities in ASDF and not have extra packages (bug 620579), which was fixed in 2.006, with various attempts at enhancing backwards compatibility in 2.007, 2.008, 2.009.
Apparently, this was a big fail, and you need to remove FASLs compiled with versions of ASDF earlier than 2.006 if any of them uses internal ASDF utilities. My apologies for the big mess.
If FASL compatibility is required, maybe I should make ASDF-UTILITIES a nickname for ASDF? Or maybe I should display a prominent warning or cerror if ASDF-UTILITIES existed and was deleted? What do you think?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The program isn't debugged until the last user is dead.
On Mon, Oct 11, 2010 at 11:10 AM, Faré fahree@gmail.com wrote:
On 11 October 2010 09:19, Lou Vanek lou.vanek@gmail.com wrote:
I'm setting up a new lisp system on a new debian lenny machine and one of the lisp libraries I'm trying to load is asking to load the asdf-utilities package, but this package doesn't exist.
Was this included with ASDF1 and not ASDF2? If so, how do people work around those libraries that require asdf-utilities?
I'm using the latest version of openmcl/clozure/ccl from trunk. The asdf version that loads is 2.009. I believe asdf is included with ccl. Appreciate any ideas.
Sorry, it's a bug introduced in ASDF2, then resolved in ASDF2.
I introduced ASDF-UTILITIES some time before ASDF 2.000, as a replacement for the ill-fated ASDF-EXTENSIONS, before I realized that ASDF-EXTENSIONS had never been used in ASDF1 anyway (didn't export anything), and that the demand from the public was to leave utilities in ASDF and not have extra packages (bug 620579), which was fixed in 2.006, with various attempts at enhancing backwards compatibility in 2.007, 2.008, 2.009.
Apparently, this was a big fail, and you need to remove FASLs compiled with versions of ASDF earlier than 2.006 if any of them uses internal ASDF utilities. My apologies for the big mess.
If FASL compatibility is required, maybe I should make ASDF-UTILITIES a nickname for ASDF? Or maybe I should display a prominent warning or cerror if ASDF-UTILITIES existed and was deleted? What do you think?
Either a prominent warning or comprehensive error message would have saved me about 2 hours of Googling and would have let me compile my project a day earlier on this new machine. One vote here for some kind of notification.
FASL compatibility isn't required by me -- I just assumed that since I had properly set up SBCL to automatically recompile stale fasls that I had done the same for clozure, which I just figured out I did not. My bad.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The program isn't debugged until the last user is dead.
Thanks for the explanation. All is well now.
Lou Vanek
Lou Vanek lou.vanek@gmail.com writes:
FASL compatibility isn't required by me -- I just assumed that since I had properly set up SBCL to automatically recompile stale fasls that I had done the same for clozure, which I just figured out I did not. My bad.
The problem is not "stale" fasls in the normal sense of a fasl format change. The problem is that the package structure of ASDF changed from minor version to minor version, so fasls that reference one minor version's packages might contain invalid package references if you upgrade to a new minor version.
If you attempt a recompile on any error, rather than just the invalid fasl error, you might be able to automatically get around this problem.
Zach
On 10/11/10 Oct 11 -11:12 AM, Zach Beane wrote:
Lou Vanek lou.vanek@gmail.com writes:
FASL compatibility isn't required by me -- I just assumed that since I had properly set up SBCL to automatically recompile stale fasls that I had done the same for clozure, which I just figured out I did not. My bad.
The problem is not "stale" fasls in the normal sense of a fasl format change. The problem is that the package structure of ASDF changed from minor version to minor version, so fasls that reference one minor version's packages might contain invalid package references if you upgrade to a new minor version.
If you attempt a recompile on any error, rather than just the invalid fasl error, you might be able to automatically get around this problem.
See my ticket. This is risky. The right thing is to use something like find to smash all the fasls and start over. If you're lucky, attempting recompile will work, but it's not the safe bet.
On Mon, Oct 11, 2010 at 12:12 PM, Zach Beane xach@xach.com wrote:
Lou Vanek lou.vanek@gmail.com writes:
FASL compatibility isn't required by me -- I just assumed that since I had properly set up SBCL to automatically recompile stale fasls that I had done the same for clozure, which I just figured out I did not. My bad.
The problem is not "stale" fasls in the normal sense of a fasl format change. The problem is that the package structure of ASDF changed from minor version to minor version, so fasls that reference one minor version's packages might contain invalid package references if you upgrade to a new minor version.
If you attempt a recompile on any error, rather than just the invalid fasl error, you might be able to automatically get around this problem.
Zach
You're, of course, correct, since this later version of clozure happily loaded the older fasl/lx32fsl. So my new asdf :around method that automatically recompiles stale fasls would not have fixed the asdf-utilities issue.
Lou Vanek
On 11 October 2010 12:12, Zach Beane xach@xach.com wrote:
The problem is not "stale" fasls in the normal sense of a fasl format change. The problem is that the package structure of ASDF changed from minor version to minor version, so fasls that reference one minor version's packages might contain invalid package references if you upgrade to a new minor version.
Maybe ASDF should be made to have a (:nicknames "ASDF-UTILITIES") for the purpose of compatibility with such files while we obsolete that name?
If you attempt a recompile on any error, rather than just the invalid fasl error, you might be able to automatically get around this problem.
That's another solution.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "Ask not what the government can do for you. Ask what the government is doing to you." — David Friedman, "The Machinery of Freedom", p. 21
On 11 October 2010 18:10, Faré fahree@gmail.com wrote:
Apparently, this was a big fail, and you need to remove FASLs compiled with versions of ASDF earlier than 2.006 if any of them uses internal ASDF utilities. My apologies for the big mess.
I wanted to take this as an opportunity to point to the recent question "can we determine fasl-compatibility without loading the fasl"?
No. While you may be able to approximate it with implementation-specific fasl-header tests, there can always be stuff in fasls that breaks compatibility anyways -- as demonstrated above.
Cheers,
-- Nikodemus
On 10/11/10 Oct 11 -11:08 AM, Nikodemus Siivola wrote:
On 11 October 2010 18:10, Faré fahree@gmail.com wrote:
Apparently, this was a big fail, and you need to remove FASLs compiled with versions of ASDF earlier than 2.006 if any of them uses internal ASDF utilities. My apologies for the big mess.
I wanted to take this as an opportunity to point to the recent question "can we determine fasl-compatibility without loading the fasl"?
No. While you may be able to approximate it with implementation-specific fasl-header tests, there can always be stuff in fasls that breaks compatibility anyways -- as demonstrated above.
Bah. See my post to the launchpad ticket for asdf --- this is bad because without a lookahead at the wrong-fasl errors, asdf can't really properly handle and react to fasls with the wrong version. The existing workarounds are not well-formed because they can't hook into ASDF's plan generation.
Maybe this will be the impetus I need to get my CLEAN-OP (really stolen from Paolo, IIRC) into ASDF2...
best, r
-
Faré -
Lou Vanek -
Nikodemus Siivola -
Robert Goldman -
Zach Beane