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 <rpgold...@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.beaud...@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 >> >
