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