On Sun, Oct 5, 2014 at 11:03 PM, Faré fahree@gmail.com wrote:
test-try-refinding.script is a relatively new test (introduced shortly before the 3.1.3 release), so its failure might not be a regression in ASDF if none of us tested 3.1.3 with MKCL (did we?). Now, infinite looping is certainly a bad failure mode in the test. This looks like a MKCL-specific bug, though:
If I replace the culprit loop (just before (DBG "Refinding test successful.")) by this debugging variant, I find that the variable tried-once is somehow magically reset to NIL after having been set to T, and that, even if it's a defparameter instead of a lexical variable (I tried both), but happily not with a defvar (where the script only fails, doesn't infinitely loops). The problem is that it restarts the wrong frame! Instead of resuming after the handler-bind handlers from test-try-refinding.script, it resumes a frame way up there in the call stack in function run-test-script in script-support.lisp, that has its own handler-bind (but no restart) via macro with-test. Looks like a MKCL compiler bug.
(defvar tried-once nil) (assert ;;(let ((tried-once nil)) (with-asdf-cache (:override t) (handler-bind ((asdf:missing-component #'(lambda (c) (DBG "Caught MISSING-COMPONENT condition.") (nest (progn (DBG 1 tried-once)) (if tried-once (error c)) ;; avoid infinite looping (progn (DBG 2)) (progn (setf tried-once t)) (progn (DBG 3 tried-once)) (let ((missing (asdf::missing-requires c))) (assert (equal missing "test-asdf/force1")) (setf asdf:*central-registry* *old-registry*) (invoke-restart 'asdf:retry)))))) (asdf:find-system "test-asdf/force1" t))));;)
Output: Running test-try-refinding.script with mkcl-1.1.10-linux-x64 ;;; Loading "test-try-refinding.script" ; Loading system definition for test-asdf from /home/tunes/cl/asdf/test/test-asdf.asd ;;; Loading "/home/tunes/cl/asdf/test/test-asdf.asd" ; Registering #<SYSTEM "test-asdf"> ; Registering #<SYSTEM "test-asdf/force1"> Clearing the caches and finding. Correctly failed to find system. Caught MISSING-COMPONENT condition. 1 ASDF-TEST::TRIED-ONCE => NIL 2 3 ASDF-TEST::TRIED-ONCE => T Running test-try-refinding.script with mkcl-1.1.10-linux-x64 ;;; Loading "test-try-refinding.script" ... repeat ad vitam aeternam
Wow! That is bad indeed! I will try to fix it in the coming 24 hours. Thank you for the bug report.
PS: unrelatedly, several bugs were recently fixed in clasp and ECL that may or may not be present in MKCL; check the (not very active, this year) git log of ECL for details.
I do read the ECL git log and bug list on a frequent and regular basis and I try in MKCL each test case mentioned in them when they seem relevant. But the fact is that by now MKCL and ECL have evolved far enough apart that a large (and growing larger) part of those ECL bug reports/fix don't apply to MKCL anymore. I keep on reading though...
Robert: I suggest we disable this test for MKCL until JCB fixes his compiler bug, and/or use defvar as above.
As I said here below, I may take a day or two before I have a fix for this one. So, please, do the workaround in the meantime.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org As the Chinese say, 1001 words is worth more than a picture. — John McCarthy
On Sun, Oct 5, 2014 at 9:20 PM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
On Sun, Oct 5, 2014 at 8:57 PM, Faré fahree@gmail.com wrote:
Dear JCB,
You suggestion indeed fixes test-bundle.script, but now this test loops indefinitely for me, using the latest mkcl from git: make t l=mkcl t=test-try-refinding.script
This one does not look like a mere typo. I will have to investigate
deeper
but I don't have much spare cycles right now so it may take a little
while
(1-2 days, I hope).
I hope this is not blocking something essential, is it?
Cheers,
Jean-Claude