Thanks again! I have applied this patch, as well, and am now testing. I can't imagine it will break anything on the other implementations, but just to be sure....
If this works out, I'll push tomorrow morning. Best, r On 8/30/17 Aug 30 -6:54 PM, Chun Tian (binghe) wrote: > I’m using a “naked” lispworks (I have renamed my .lispworks initialization > file), there’s no ASDF package at all. But when I compile “asdf.lisp” (after > applying the patch I posted in asdf mailing list), the *only* warning is this > “duplicated" definition of (deftype fatal-condition). And it’s this issue > blocking the whole testing process in LispWorks 6. > > I have checked the same compilation in LispWorks 7, using also a naked > console image. This time, zero warning! So now I conclude this should be a > small issue in LispWorks’ earlier compiler. It only remains to find a > workaround solution. > > I checked other DEFTYPE definitions in asdf.lisp, and found this one: > > ;;; stamps: a REAL or a boolean where T=-infinity, NIL=+infinity > (eval-when (#-lispworks :compile-toplevel :load-toplevel :execute) > (deftype stamp () '(or real boolean))) > > It seems that, in LispWorks, a DEFTYPE form shouldn’t be evaluated at > compile-time, maybe because there’s nothing to be compiled. Instead, just > evaluating the form at load-time (or execute time, as the latter two times > cannot happen together), it will be enough to “have” that type correctly > defined. So I have further modified asdf.lisp in this way: > > (eval-when (#-lispworks :compile-toplevel :load-toplevel :execute) > (deftype fatal-condition () > `(and serious-condition #+clozure (not ccl:process-reset)))) > > That is, instead of using with-upgradability, now we use EVAL-WHEN directly > and disable :compile-toplevel for LispWorks. It’s a solution for LispWorks 5 > and 6, and won’t cause any problem in LispWorks 7. > > With this further changes, now I can run the test suite and all your 67 tests > passed in LispWorks 6.1.1: > > -#--------------------------------------- > Using lispworks-6-1-1-console.exe > Ran 67 tests: > 67 passing and 0 failing > all tests apparently successful > -#——————————————————— > > For LispWorks 6.0.1, however, there’re 3 failures: > > -#--------------------------------------- > Using lispworks-6-0-1-console.exe > Ran 67 tests: > 64 passing and 3 failing > failing test(s): test-deprecation.script test-sysdef-asdf.script > test-utilities.script > -#——————————————————— > > For LispWorks 5.1.2, unfortunately the test scripts cannot quit from LW > environment after each test, I have to manually quit by pasting a (quit) into > REPL. But after doing such things 67 times, all tests have passed: > > -#--------------------------------------- > Using lispworks-5-1-2-console.EXE > Ran 67 tests: > 67 passing and 0 failing > all tests apparently successful > -#——————————————————— > > LispWorks 5.1 is the oldest non-free LispWorks edition I own on Windows. (On > Linux I have LispWorks 5.0 purchased in 2007) > > Attached new patch is a further enhancement of my previous patch. I think > the 3 failures in LispWorks 6.0 must be caused by separated issues specified > for that LW version, which I can try to fix later. > > Regards, > > Chun Tian > > > > > >> Il giorno 30 ago 2017, alle ore 22:58, Faré <fah...@gmail.com> ha scritto: >> >> Please apply the patch and run >> >> make t l=lispworks LISPWORKS=/path/to/lispworks6 >> >> after dumping a console executable for lispworks6 using >> >> echo '(hcl:save-image "lispworks-console" :environment nil)' > si.lisp >> lispworks-6-0-0-x86-linux -siteinit - -init - -build si.lisp >> >> and tell us if there are any failures. I can't do that, I don't have a >> LispWorks 6 license. >> >> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• >> http://fare.tunes.org >> When a man says money can do anything, that settles it: he hasn't got any. >> — Edgar Watson Howe >> >> >> On Wed, Aug 30, 2017 at 9:36 PM, Chun Tian (binghe) >> <binghe.l...@gmail.com> wrote: >>> Hi, >>> >>> In latest ASDF, the function #’sys:pid-exit-status is used for LispWorks 6 >>> and early versions, but I found this symbol doesn’t have a bounded function >>> at all: >>> >>> CL-USER 1 > (describe 'sys:pid-exit-status) >>> >>> SYSTEM:PID-EXIT-STATUS is a SYMBOL >>> NAME "PID-EXIT-STATUS" >>> VALUE #<unbound value> >>> FUNCTION #<unbound function> >>> PLIST NIL >>> PACKAGE #<The SYSTEM package, 6625/8192 internal, 1277/2048 external> >>> >>> In LispWorks 7.0, it’s even not an external symbol. On the other side, the >>> function #’sys:pipe-exit-status exists since at least LispWorks 5.1.2, I >>> think it should be used for all LispWorks versions, not just 7. >>> >>> The function #’sys:pipe-pid used in another ASDF function, exists since >>> LispWorks 6.1, but ASDF only use it for LispWorks after 7.0. I don’t know >>> if this could cause any potential problem in LispWorks 6.1, but I guess >>> there’s no problem calling it also in 6.1. >>> >>> Basically I don’t know the purpose of these function calls, no actually >>> tests were done. Use the patch with cautions … just calling non-exist >>> functions are definitely wrong. >>> >>> Regards, >>> >>> Chun Tian >>> >>> >
