MKCL fails when non-erroneous condition is signaled

[Faré]

Regarding these ASDF failures on MKCL:
* test-program was a bug in my latest ASDF tweaks, now fixes.
* test-bundle and test3 smell like another case where MKCL errors out
due to non-serious conditions being signalled, this time inside a
require.
* test-defsystem-depends-on-phase-overlap.script is because said test
tries to undefine a class using
(setf (find-class 'asdf::my-cl-source-file) nil)
and MKCL disapproves, unlike all other tested CL implementations, erroring with:
"TEST ABORTED: NIL is not of type SI:INSTANCE."
Is that a compliant way to undefine a class? If not, is there one and
what is it?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If you could ask a unique question to a computer during a Turing test,
what would you ask?
— Douglas Hofstadter, Metamagical Themas


On Sun, Jul 23, 2017 at 1:03 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> After update now I see 4 failures also:
>
> test-bundle.script
> test-defsystem-depends-on-phase-overlap.script
> test-program.script
> test3.script
>
> [as an aside, we should probably re-title test3.script to make it more
> clear what it is that it is intended to test.]
>
> test-bundle seems like it might be an mkcl build process issue.  The
> error I see for this is:
>
> Test the pre-compiled system feature
> TEST ABORTED: Module error: Error while loading module SOCKETS: system
> sockets is out of date
>
> After a clean build of mkcl I see this:
>
> $ find /usr/local/lib/mkcl-1.1.10/contrib/ -iname 'sockets*' -exec ls -l
> {} \;
> -rw-r--r-- 1 root root 57 Jul 23 11:35
> /usr/local/lib/mkcl-1.1.10/contrib/sockets.as2
> -rw-r--r-- 1 root root 941964 Jun 20 15:18
> /usr/local/lib/mkcl-1.1.10/contrib/sockets.a
> -rw-r--r-- 1 root root 229708 Jul 23 11:35
> /usr/local/lib/mkcl-1.1.10/contrib/SOCKETS.a
> -rw-r--r-- 1 root root 194 Jul 23 11:35
> /usr/local/lib/mkcl-1.1.10/contrib/sockets.asd
> -rwxr-xr-x 1 root root 628800 Jun 20 15:18
> /usr/local/lib/mkcl-1.1.10/contrib/sockets.fasb
> -rwxr-xr-x 1 root root 184872 Jul 23 11:35
> /usr/local/lib/mkcl-1.1.10/contrib/SOCKETS.fasb
>
> Is there any chance the old, lower-cased files are causing my problem
> here?  Or is it the upcased ones?
>
> Here's the date of the asd file:
>
> -rw-r--r-- 1 root root 194 Jul 23 11:56
> /usr/local/lib/mkcl-1.1.10/contrib/sockets.asd
>
>
> Looks newer than the corresponding library files.
>
> For the phase overlap test, I believe the following is the proximate error:
>
> 6: (#<bytecompiled-function SI:BYTECODE> ((#:G-31773-1570)
> (#:G-31773-1569 . ASDF/INTERFACE::MY-CL-SOURCE-FILE)))
>
> I believe that this is returning NIL.  But this may be a symptom, not a
> root cause.
>
> test-program is having the same test failure we see on ECL:
>
> TEST ABORTED: These two expressions fail comparison with EQUAL:
>  (RUN-PROGRAM
>   (SI:QUASIQUOTE
>    ((SI:UNQUOTE (NATIVE-NAMESTRING (OUTPUT-FILE 'PROGRAM-OP
> 'HELLO-NO-UIOP)))))
>   :OUTPUT
>   :LINES
>   :ERROR-OUTPUT
>   T) evaluates to ("Look ma, no UIOP!" "But no TEST-PACKAGE :-(!"
>                    "And no ASDF!")
>  '("Look ma, no UIOP!" "And TEST-PACKAGE!" "And no ASDF!") evaluates to
> ("Look ma, no UIOP!"
>
> "And TEST-PACKAGE!"
>
> "And no ASDF!")
>
> ...and test3 looks like it has the same problem as the phase overlap test.
>
> Cheers,
> r
>
>
> On 7/23/17 Jul 23 -10:06 AM, Faré wrote:
>> On Sun, Jul 23, 2017 at 3:07 AM, Jean-Claude Beaudoin
>> <jean.claude.beaudoin at gmail.com> wrote:
>>> The fix I intend for this bug is currently on MKCL's github repo master
>>> head.
>>> Please give it a try.
>>>
>> Works for me. There are now only 4 ASDF failures instead of 67/67 in
>> the "plan" branch, and they are probably my bad. I'll investigate.
>>
>>>> Perhaps those of us who care about quality programs have not spoken up
>>>> often
>>>> enough — `for bad programs to triumph requires only that good programmers
>>>> remain silent.' I call this passivity the `Silence of the Lambdas.' —
>>>> hbaker
>>>
>>> Probably your best footer quote ever!
>>>
>> I'm glad you liked it. I have many others, including by the same author.
>>
>> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
>> [A] Computer [programming] language is inherently a pun — [it] needs
>> to be interpreted by both men & machines. — Henry Baker
>>
>