lispworks patch

[Robert Goldman]

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é <fahree at 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.lisp at 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
>>>
>>>
>