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
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@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
On 8/30/17 Aug 30 -2:36 PM, Chun Tian (binghe) 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.
I'll try this with LW 7, to be sure, then if it works for you I'll push it. Thank you very much for catching this! R
On 8/30/17 Aug 30 -4:33 PM, Robert Goldman wrote:
On 8/30/17 Aug 30 -2:36 PM, Chun Tian (binghe) 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.
I'll try this with LW 7, to be sure, then if it works for you I'll push it.
Thank you very much for catching this!
Worked for me on LW 7, so if this works on LW 6, I'll merge it. cheers, r
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@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@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
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@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@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
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.
If that's what it takes to make it work without warnings, that sounds good to me.
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 -#———————————————————
Great. And I suppose you also tested that you didn't break LispWorks 7.0.0 ?
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.
I don't think anyone else but you is using those versions of LispWorks. Certainly neither Robert nor I. We will gladly accept your patches, as long as you make sure you don't break anything by passing all tests on all recent implementations that could be affected by your changes (including notably LispWorks 7, but also, say, SBCL, for good measure). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It ain't what a man don't know that makes him a fool; it's the things he knows that ain't so. — Josh Billings
No, I didn’t break LispWorks 7, as Robert has already confirmed. Besides, I’ve tested latest ASDF also on LispWorks 5.0 on Linux, all 67 tests passed: LispWorks(R): The Common Lisp Programming Environment Copyright (C) 1987-2006 LispWorks Ltd. All rights reserved. Version 5.0.2 Saved by binghe as lispworks-5-0-2-64-bit-console, at 31 Aug 2017 2:55 User binghe on debian5 CL-USER 1 > (quit) Using lispworks-console, wild-module.script passed -#--------------------------------------- Using lispworks-console Ran 67 tests: 67 passing and 0 failing all tests apparently successful -#——————————————————— I must say ASDF team has done a great job for not breaking old versions of supporting platforms, even when you may not have all the testing environments. Regards, Chun Tian
Il giorno 31 ago 2017, alle ore 05:09, Faré <fahree@gmail.com> ha scritto:
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.
If that's what it takes to make it work without warnings, that sounds good to me.
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 -#———————————————————
Great. And I suppose you also tested that you didn't break LispWorks 7.0.0 ?
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.
I don't think anyone else but you is using those versions of LispWorks. Certainly neither Robert nor I. We will gladly accept your patches, as long as you make sure you don't break anything by passing all tests on all recent implementations that could be affected by your changes (including notably LispWorks 7, but also, say, SBCL, for good measure).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It ain't what a man don't know that makes him a fool; it's the things he knows that ain't so. — Josh Billings
I tested this on all implementations on Mac last night; testing on Linux this morning. If it passes, as I expect it will, I will push it, and hope to resume the long-postponed release process. On 8/31/17 Aug 31 -10:03 AM, Chun Tian (binghe) wrote:
No, I didn’t break LispWorks 7, as Robert has already confirmed. Besides, I’ve tested latest ASDF also on LispWorks 5.0 on Linux, all 67 tests passed:
LispWorks(R): The Common Lisp Programming Environment Copyright (C) 1987-2006 LispWorks Ltd. All rights reserved. Version 5.0.2 Saved by binghe as lispworks-5-0-2-64-bit-console, at 31 Aug 2017 2:55 User binghe on debian5
CL-USER 1 > (quit) Using lispworks-console, wild-module.script passed
-#--------------------------------------- Using lispworks-console Ran 67 tests: 67 passing and 0 failing all tests apparently successful -#———————————————————
I must say ASDF team has done a great job for not breaking old versions of supporting platforms, even when you may not have all the testing environments.
Regards,
Chun Tian
Il giorno 31 ago 2017, alle ore 05:09, Faré <fahree@gmail.com> ha scritto:
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.
If that's what it takes to make it work without warnings, that sounds good to me.
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 -#———————————————————
Great. And I suppose you also tested that you didn't break LispWorks 7.0.0 ?
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.
I don't think anyone else but you is using those versions of LispWorks. Certainly neither Robert nor I. We will gladly accept your patches, as long as you make sure you don't break anything by passing all tests on all recent implementations that could be affected by your changes (including notably LispWorks 7, but also, say, SBCL, for good measure).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It ain't what a man don't know that makes him a fool; it's the things he knows that ain't so. — Josh Billings
participants (3)
-
Chun Tian (binghe) -
Faré -
Robert Goldman