I placed new asdf.lisp into quicklisp and changed (defvar *required-asdf-version* "2.28") in quicklisp/setup.lisp to the lates version - 2.28.
lisps/ccl-1.8/lx86cl --no-init --load quicklisp-patched2/setup.lisp
Error: Error while trying to load definition for system quicklisp from pathname /home/testgrid/quicklisp-patched2/quicklisp/quicklisp.asd: Undefined function #:|ASDF::COMPONENT-VERSION| called with arguments ("2012112500" #<SYSTEM "quicklisp">) . While executing: (:INTERNAL ASDF/FIND-SYSTEM:LOAD-ASD), in process listener(1). Type :GO to continue, :POP to abort, :R for a list of available restarts. If continued: Retry applying #:|ASDF::COMPONENT-VERSION| to ("2012112500" #<SYSTEM "quicklisp">). Type :? for other options.
On Tue, Feb 5, 2013 at 4:03 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
I placed new asdf.lisp into quicklisp and changed (defvar *required-asdf-version* "2.28") in quicklisp/setup.lisp to the lates version - 2.28.
This looks like the bad interaction of files compiled with a previous ASDF and files compiled with the new one. Did you clean your fasl cache after you upgraded? I'll investigate tomorrow.
It's also possible that my upgrade tricks don't work so well on CCL, and I need to punt like I do on CLISP. However, CCL does pass all my automated upgrade tests so far, so if that's the case I need to improve those tests.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Pournelle's Iron Law of Bureaucracy states that in any bureaucratic organization there will be two kinds of people: those who work to further the actual goals of the organization, and those who work for the organization itself. Examples in education would be teachers who work and sacrifice to teach children, vs. union representative who work to protect any teacher including the most incompetent. The Iron Law states that in all cases, the second type of person will always gain control of the organization, and will always write the rules under which the organization functions.
lisps/ccl-1.8/lx86cl --no-init --load quicklisp-patched2/setup.lisp
Error: Error while trying to load definition for system quicklisp from pathname /home/testgrid/quicklisp-patched2/quicklisp/quicklisp.asd: Undefined function #:|ASDF::COMPONENT-VERSION| called with arguments ("2012112500" #<SYSTEM "quicklisp">) . While executing: (:INTERNAL ASDF/FIND-SYSTEM:LOAD-ASD), in process listener(1). Type :GO to continue, :POP to abort, :R for a list of available restarts. If continued: Retry applying #:|ASDF::COMPONENT-VERSION| to ("2012112500" #<SYSTEM "quicklisp">). Type :? for other options.
05.02.2013, 07:44, "Faré" fahree@gmail.com:
On Tue, Feb 5, 2013 at 4:03 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
I placed new asdf.lisp into quicklisp and changed (defvar *required-asdf-version* "2.28") in quicklisp/setup.lisp to the lates version - 2.28.
This looks like the bad interaction of files compiled with a previous ASDF and files compiled with the new one. Did you clean your fasl cache after you upgraded? I'll investigate tomorrow.
Yes, I did rm -r .cache/common-lisp/
Anton,
the failure you found seems to be a case of quicklisp compiling asdf without having loaded it as source first.
To compile asdf even when a previous asdf was loaded, it is currently necessary to first load asdf.lisp as source. quicklisp (require)'s the previous asdf, then compiles the new one without loading it. That won't work.
To make it work, I would essentially have to have each and every form in asdf.lisp wrapped in an eval-when.
I suppose I could do just that; it wouldn't be worse than loading asdf.lisp before compiling it, and it would be simpler for Zach and other people.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Each new generation born is in effect an invasion of civilization by little barbarians, who must be civilized before it is too late. — Thomas Sowell
Similar situation on ECL:
$ lisps/ecl-bin-12.12.1/bin/ecl -norc -load quicklisp-patched2/setup.lisp [ ... log of compilation output ... ] An error occurred during initialization: The function ASDF/OPERATE:OPERATE is undefined..
Dear Anton,
the failure you found seems to be a case of quicklisp compiling asdf without having loaded it as source first.
I've modified ASDF so that each and every form is in an eval-when, which allows ASDF to be compiled without having been loaded (as source) first.
I also fixed other issues reported on launchpad.
And I also fixed another issue revealed by your tests, whereby the version of the asdf system itself wasn't properly set for the fallback system (when no asdf.asd is registered).
Can you test again with the latest ASDF?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org People are not born rich and become poor because of some dreadful phenomenon. They are born deprived of anything and become rich when they do but by the accumulated fruits of their own and their ancestors' labor: their capital.
Trying with ASDF 2.28.4
The ECL problem has gone, but CCL still can't run quicklisp:
lisps/ccl-1.8/lx86cl --no-init --load quicklisp-patched2/setup.lisp
Error: Error while trying to load definition for system quicklisp from pathname /home/testgrid/quicklisp-patched2/quicklisp/quicklisp.asd: Undefined function #:|ASDF::COMPONENT-VERSION| called with arguments ("2012112500" #<SYSTEM "quicklisp">) . While executing: (:INTERNAL ASDF/FIND-SYSTEM:LOAD-ASD), in process listener(1). Type :GO to continue, :POP to abort, :R for a list of available restarts. If continued: Retry applying #:|ASDF::COMPONENT-VERSION| to ("2012112500" #<SYSTEM "quicklisp">). Type :? for other options.
On Wed, Feb 6, 2013 at 9:22 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Trying with ASDF 2.28.4
The ECL problem has gone, but CCL still can't run quicklisp:
OK, I committed a workaround to ASDF 2.28.5.
lisps/ccl-1.8/lx86cl --no-init --load quicklisp-patched2/setup.lisp
Error: Error while trying to load definition for system quicklisp from pathname /home/testgrid/quicklisp-patched2/quicklisp/quicklisp.asd: Undefined function #:|ASDF::COMPONENT-VERSION| called with arguments ("2012112500" #<SYSTEM "quicklisp">) . While executing: (:INTERNAL ASDF/FIND-SYSTEM:LOAD-ASD), in process listener(1). Type :GO to continue, :POP to abort, :R for a list of available restarts. If continued: Retry applying #:|ASDF::COMPONENT-VERSION| to ("2012112500" #<SYSTEM "quicklisp">). Type :? for other options.
This is a problem with package upgrade of the setf-function. Background: CCL and CLISP both use a trick whereby (setf foo::bar) is internally resolved to some regular symbol, bound to a function, SETF::|FOO::BAR| in the case of CCL. When ASDF is split into several packages and ASDF:COMPONENT-VERSION becomes ASDF/COMPONENT:COMPONENT-VERSION, care is taken to move the SETF symbols so that SETF::|ASDF::COMPONENT-VERSION| is replaced by SETF::|ASDF/COMPONENT::COMPONENT-VERSION| in the mapping table; but apparently something is not right between ASDF and CCL 1.8, so that the new parse-component-form gets compiled with the old uninterned SETF symbol. A recent CCL 1.9 doesn't seem to have the same issue. It's harder for me to write a real solution without being able to reproduce locally.
My current workaround is to use SETF SLOT-VALUE instead of the accessor, and eschew this SETF symbol issue. Ugly, but seems to work, or at least to get us further. Maybe I need more magic in define-package for SETF symbols on older CCLs, or maybe I need to detect bad ASDF/CCL combos and punt on upgrades in these cases. Or maybe I just need to convince Xach that he should do the safe thing and load asdf from source before to compile-file it, since my recent attempt at putting everything in an EVAL-WHEN to make that unnecessary seems to have failed on CCL.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "To speak algebraically, Mr. M. is execrable, but Mr. G. is (x+1)ecrable." — Edgar Alan Poe
07.02.2013, 05:54, "Faré" fahree@gmail.com:
On Wed, Feb 6, 2013 at 9:22 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
OK, I committed a workaround to ASDF 2.28.5.
Have you pushed it? The comment on the top of asdf.lisp still says "This is ASDF 2.28.4"
I have impression that the code upgrade support is one of the most expensive features in ASDF.
07.02.2013, 05:54, "Faré" fahree@gmail.com:
On Wed, Feb 6, 2013 at 9:22 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
OK, I committed a workaround to ASDF 2.28.5.
Have you pushed it? The comment on the top of asdf.lisp still says "This is ASDF 2.28.4"
I was experiencing Internet connection issues from this remote country house in France. Now that the 'net is back, and it's pushed. Sorry for the delay.
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.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Failure is not an option. It comes bundled with your Microsoft product. — Ferenc Mantfeld
-
Anton Vodonosov -
Faré