Sam Steingold (sds) probed me on some old bugs, which led me to waste a day debugging issues on and with CLISP.
First I reproduced CLISP bug 677, figured out what CLISP was doing wrong (incorrect merging of logical pathnames in compile-file), and implemented a workaround (physicalize everything I can, trust compile-file's return value over my :output-file argument): https://sourceforge.net/p/clisp/bugs/677/
Then, I found a cleaner fix to the issue with DIRECTORY wanting "*" rather than "*.*" as the match-all pattern on CLISP and GCL.
I also dug out the information in the old README.md that Robert stripped. I moved anything that may have been redundant with doc/index.html, move there what was complementary, and put back in README.md (after some editing) things that were not covered by either the home page or the manual: the documentation on how to navigate our source code, build and test ASDF, etc.
Robert, please tell me if that's OK, since you were the one who deleted that information arguing of unmaintainable redundancy with web page and manual.
I also slightly tweaked said web page and manual.
Also, I see you disabled make doc in the Makefile. I presume it should be restored.
Finally, I renamed make.bat to make-asdf.bat so that on Windows there is no risk of typing "make" and run make.bat in the current directory while believing one had run make.exe from the %PATH%. This may or may not help Robert make his tests pass on Windows.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org ...so this guy walks into a bar. "The usual, Mr. Descartes?" the barman asked. "I think not," Rene replied, and promptly disappeared.
On 28 Aug 2016, at 02:28, Faré fahree@gmail.com wrote:
Sam Steingold (sds) probed me on some old bugs, which led me to waste a day debugging issues on and with CLISP.
First I reproduced CLISP bug 677, figured out what CLISP was doing wrong (incorrect merging of logical pathnames in compile-file), and implemented a workaround (physicalize everything I can, trust compile-file's return value over my :output-file argument): https://sourceforge.net/p/clisp/bugs/677/
Then, I found a cleaner fix to the issue with DIRECTORY wanting "*" rather than "*.*" as the match-all pattern on CLISP and GCL.
Dear Faré,
with 3.1.7.7, clisp-2.49 and clisp-git(*) passed test-logical-pathname.script for me. With 3.1.7.8, clisp-git continues to pass test-logical-pathname.script for me, but clisp-2.49 now fails.
As far as I can tell, that’s because previously part of the test was disabled for clisp and is now unconditionally enabled.
I just want to make sure that this was intentional and known. I don’t know if functionality probed in the relevant part of the tests is crucial in order for ASDF to function but this might mean that clisp 2.49 can no longer be supported. If so, I would drop it from the list of platforms I’m testing with.
Elias
(*) https://github.com/Distrotech/clisp.git
PS: I’ve switched to another machine since I last compiled the list of supported platforms and the issue I had with clisp-git is gone now.
On 9/1/16 Sep 1 -9:17 AM, Elias Pipping wrote:
On 28 Aug 2016, at 02:28, Faré fahree@gmail.com wrote:
Sam Steingold (sds) probed me on some old bugs, which led me to waste a day debugging issues on and with CLISP.
First I reproduced CLISP bug 677, figured out what CLISP was doing wrong (incorrect merging of logical pathnames in compile-file), and implemented a workaround (physicalize everything I can, trust compile-file's return value over my :output-file argument): https://sourceforge.net/p/clisp/bugs/677/
Then, I found a cleaner fix to the issue with DIRECTORY wanting "*" rather than "*.*" as the match-all pattern on CLISP and GCL.
Dear Faré,
with 3.1.7.7, clisp-2.49 and clisp-git(*) passed test-logical-pathname.script for me. With 3.1.7.8, clisp-git continues to pass test-logical-pathname.script for me, but clisp-2.49 now fails.
As far as I can tell, that’s because previously part of the test was disabled for clisp and is now unconditionally enabled.
I just want to make sure that this was intentional and known. I don’t know if functionality probed in the relevant part of the tests is crucial in order for ASDF to function but this might mean that clisp 2.49 can no longer be supported. If so, I would drop it from the list of platforms I’m testing with.
Even worse, AFAICT clisp does not make its version number available to the lisp context.
There's a SYSTEM::VERSION, but:
[2]> (system::version) (20080430)
which doesn't say "2.49" to me :-(
I'm not sure what to do about this, since clisp seems to have lost the ability to make releases. I'm reluctant to start building clisp from source -- on three different platforms yet -- just to test it. Especially if this isn't relevant to what clisp users are actually getting.
If you're in touch with Sam, Faré, maybe you could encourage him to make a release.
Indeed, I'm prepared to threaten to back out fixes that work on clisp from source, and break release clisp. Or at least re-disable the clisp tests.
I don't think it should be the ASDF maintainer's job to track every lisp implementation from source.
Hey,
fwiw, to get a version you get a first token from (lisp-implementation-version):
[2]> (lisp-implementation-version) "2.49+ (2010-07-17) (built 3664370621) (memory 3664370857)"
Best regards, Daniel
Robert Goldman writes:
On 9/1/16 Sep 1 -9:17 AM, Elias Pipping wrote:
On 28 Aug 2016, at 02:28, Faré fahree@gmail.com wrote:
Sam Steingold (sds) probed me on some old bugs, which led me to waste a day debugging issues on and with CLISP.
First I reproduced CLISP bug 677, figured out what CLISP was doing wrong (incorrect merging of logical pathnames in compile-file), and implemented a workaround (physicalize everything I can, trust compile-file's return value over my :output-file argument): https://sourceforge.net/p/clisp/bugs/677/
Then, I found a cleaner fix to the issue with DIRECTORY wanting "*" rather than "*.*" as the match-all pattern on CLISP and GCL.
Dear Faré,
with 3.1.7.7, clisp-2.49 and clisp-git(*) passed test-logical-pathname.script for me. With 3.1.7.8, clisp-git continues to pass test-logical-pathname.script for me, but clisp-2.49 now fails.
As far as I can tell, that’s because previously part of the test was disabled for clisp and is now unconditionally enabled.
I just want to make sure that this was intentional and known. I don’t know if functionality probed in the relevant part of the tests is crucial in order for ASDF to function but this might mean that clisp 2.49 can no longer be supported. If so, I would drop it from the list of platforms I’m testing with.
Even worse, AFAICT clisp does not make its version number available to the lisp context.
There's a SYSTEM::VERSION, but:
[2]> (system::version) (20080430)
which doesn't say "2.49" to me :-(
I'm not sure what to do about this, since clisp seems to have lost the ability to make releases. I'm reluctant to start building clisp from source -- on three different platforms yet -- just to test it. Especially if this isn't relevant to what clisp users are actually getting.
If you're in touch with Sam, Faré, maybe you could encourage him to make a release.
Indeed, I'm prepared to threaten to back out fixes that work on clisp from source, and break release clisp. Or at least re-disable the clisp tests.
I don't think it should be the ASDF maintainer's job to track every lisp implementation from source.
On 9/1/16 Sep 1 -2:16 PM, Daniel Kochmański wrote:
Hey,
fwiw, to get a version you get a first token from (lisp-implementation-version):
[2]> (lisp-implementation-version) "2.49+ (2010-07-17) (built 3664370621) (memory 3664370857)"
Thanks!
For some reason, I missed that in (apropos '#:version) but I see that now.
Best regards, Daniel
Robert Goldman writes:
On 9/1/16 Sep 1 -9:17 AM, Elias Pipping wrote:
On 28 Aug 2016, at 02:28, Faré fahree@gmail.com wrote:
Sam Steingold (sds) probed me on some old bugs, which led me to waste a day debugging issues on and with CLISP.
First I reproduced CLISP bug 677, figured out what CLISP was doing wrong (incorrect merging of logical pathnames in compile-file), and implemented a workaround (physicalize everything I can, trust compile-file's return value over my :output-file argument): https://sourceforge.net/p/clisp/bugs/677/
Then, I found a cleaner fix to the issue with DIRECTORY wanting "*" rather than "*.*" as the match-all pattern on CLISP and GCL.
Dear Faré,
with 3.1.7.7, clisp-2.49 and clisp-git(*) passed test-logical-pathname.script for me. With 3.1.7.8, clisp-git continues to pass test-logical-pathname.script for me, but clisp-2.49 now fails.
As far as I can tell, that’s because previously part of the test was disabled for clisp and is now unconditionally enabled.
I just want to make sure that this was intentional and known. I don’t know if functionality probed in the relevant part of the tests is crucial in order for ASDF to function but this might mean that clisp 2.49 can no longer be supported. If so, I would drop it from the list of platforms I’m testing with.
Even worse, AFAICT clisp does not make its version number available to the lisp context.
There's a SYSTEM::VERSION, but:
[2]> (system::version) (20080430)
which doesn't say "2.49" to me :-(
I'm not sure what to do about this, since clisp seems to have lost the ability to make releases. I'm reluctant to start building clisp from source -- on three different platforms yet -- just to test it. Especially if this isn't relevant to what clisp users are actually getting.
If you're in touch with Sam, Faré, maybe you could encourage him to make a release.
Indeed, I'm prepared to threaten to back out fixes that work on clisp from source, and break release clisp. Or at least re-disable the clisp tests.
I don't think it should be the ASDF maintainer's job to track every lisp implementation from source.
Sorry, I was using the latest CLISP from hg, and hadn't noticed that things were failing for older versions.
On the version of CLISP from Ubuntu 16.04, that claims it has version "2.49 (2010-07-07) (built on toyol.buildd [127.0.1.1])" the tests pass up until the same point as ABCL. On the version of CLISP from hg it passes all tests. (Before 3.1.7.8, CLISP would fail even earlier in the test file)
Can you tell me where the tests fail for you? make t l=clisp t=test-logical-pathname.script
Yes, we should disable the tests where they fail. At least, until a new CLISP is released and we can rely on its version number to enable or disable tests.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Meta is Better. Anything you can do, I can do Meta. — Patrick Logan
On Thu, Sep 1, 2016 at 3:22 PM, Robert Goldman rpgoldman@sift.net wrote:
On 9/1/16 Sep 1 -2:16 PM, Daniel Kochmański wrote:
Hey,
fwiw, to get a version you get a first token from (lisp-implementation-version):
[2]> (lisp-implementation-version) "2.49+ (2010-07-17) (built 3664370621) (memory 3664370857)"
Thanks!
For some reason, I missed that in (apropos '#:version) but I see that now.
Best regards, Daniel
Robert Goldman writes:
On 9/1/16 Sep 1 -9:17 AM, Elias Pipping wrote:
On 28 Aug 2016, at 02:28, Faré fahree@gmail.com wrote:
Sam Steingold (sds) probed me on some old bugs, which led me to waste a day debugging issues on and with CLISP.
First I reproduced CLISP bug 677, figured out what CLISP was doing wrong (incorrect merging of logical pathnames in compile-file), and implemented a workaround (physicalize everything I can, trust compile-file's return value over my :output-file argument): https://sourceforge.net/p/clisp/bugs/677/
Then, I found a cleaner fix to the issue with DIRECTORY wanting "*" rather than "*.*" as the match-all pattern on CLISP and GCL.
Dear Faré,
with 3.1.7.7, clisp-2.49 and clisp-git(*) passed test-logical-pathname.script for me. With 3.1.7.8, clisp-git continues to pass test-logical-pathname.script for me, but clisp-2.49 now fails.
As far as I can tell, that’s because previously part of the test was disabled for clisp and is now unconditionally enabled.
I just want to make sure that this was intentional and known. I don’t know if functionality probed in the relevant part of the tests is crucial in order for ASDF to function but this might mean that clisp 2.49 can no longer be supported. If so, I would drop it from the list of platforms I’m testing with.
Even worse, AFAICT clisp does not make its version number available to the lisp context.
There's a SYSTEM::VERSION, but:
[2]> (system::version) (20080430)
which doesn't say "2.49" to me :-(
I'm not sure what to do about this, since clisp seems to have lost the ability to make releases. I'm reluctant to start building clisp from source -- on three different platforms yet -- just to test it. Especially if this isn't relevant to what clisp users are actually getting.
If you're in touch with Sam, Faré, maybe you could encourage him to make a release.
Indeed, I'm prepared to threaten to back out fixes that work on clisp from source, and break release clisp. Or at least re-disable the clisp tests.
I don't think it should be the ASDF maintainer's job to track every lisp implementation from source.
- Robert Goldman ectbyqzna@fvsg.arg [2016-09-01 12:34:11 -0500]:
Even worse, AFAICT clisp does not make its version number available to the lisp context.
CLISP, like all the other implementations striving for ANSI CL compliance, exports `lisp-implementation-version' (http://clhs.lisp.se/Body/f_lisp_i.htm).
However, testing version numbers is not the best way to achieve cross-release compatibility; it is much better to test for specific behavior.
There's a SYSTEM::VERSION, but:
[2]> (system::version) (20080430)
This is an internal function, the version of the byte code.
I'm not sure what to do about this, since clisp seems to have lost the ability to make releases.
We had a GSoC project to make a release; alas, the student did not complete the project. We still hope that the release will happen this year.
On 9/1/16 Sep 1 -6:15 PM, Sam Steingold wrote:
- Robert Goldman ectbyqzna@fvsg.arg [2016-09-01 12:34:11 -0500]:
Even worse, AFAICT clisp does not make its version number available to the lisp context.
CLISP, like all the other implementations striving for ANSI CL compliance, exports `lisp-implementation-version' (http://clhs.lisp.se/Body/f_lisp_i.htm).
However, testing version numbers is not the best way to achieve cross-release compatibility; it is much better to test for specific behavior.
True, but this is not for code -- it's for regression testing. For regression-testing, I think it's fine if we say "on clisp, if the version is less than or equal to 2.49, disable this test."
Until now we have just been saying "on clisp, disable this test."
Unfortunately, since I believe that clisp in git has not been bumped beyond 2.49, reading LISP-IMPLEMENTATION-VERSION may not solve our problem.
If you will tell me how to distinguish between clisp 2.49 release and clisp 2.50 release candidate, I can make that happen. From my PoV, one alternative would be to just make your LISP-IMPLEMENTATION-VERSION be 2.49.1, instead of 2.49.
If I don't have a way to distinguish between 2.49 and pre-release 2.50, I am left with a choice of undesirable alternatives:
1. Go back to disabling this test on clisp, which will keep anyone from making sure that behavior will be good in your coming release or
2. Treating release clisp as unsupported and no longer testing ASDF on it.
I understand that it's not ideal, but I'm testing up to 8 lisp implementations, on three platforms. I simply cannot track the 6 open source versions off revision control systems. I must have releases, or I cannot maintain my testing discipline. Indeed, on windows, I must have binary releases, since I do not have a build environment for Windows.
Thanks, r
On Thu, Sep 1, 2016 at 7:38 PM, Robert Goldman rpgoldman@sift.net wrote:
Until now we have just been saying "on clisp, disable this test."
Unfortunately, since I believe that clisp in git has not been bumped beyond 2.49, reading LISP-IMPLEMENTATION-VERSION may not solve our problem.
I pushed a tweak that checks for clisp 2.50 or later, hoping that 2.50 will be released soon.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Suicidal terrorists may have short shelf lives. — John McCarthy
- Robert Goldman ectbyqzna@fvsg.arg [2016-09-01 18:38:12 -0500]:
On 9/1/16 Sep 1 -6:15 PM, Sam Steingold wrote:
- Robert Goldman ectbyqzna@fvsg.arg [2016-09-01 12:34:11 -0500]:
Even worse, AFAICT clisp does not make its version number available to the lisp context.
CLISP, like all the other implementations striving for ANSI CL compliance, exports `lisp-implementation-version' (http://clhs.lisp.se/Body/f_lisp_i.htm).
However, testing version numbers is not the best way to achieve cross-release compatibility; it is much better to test for specific behavior.
True, but this is not for code -- it's for regression testing. For regression-testing, I think it's fine if we say "on clisp, if the version is less than or equal to 2.49, disable this test."
Until now we have just been saying "on clisp, disable this test."
Unfortunately, since I believe that clisp in git has not been bumped beyond 2.49, reading LISP-IMPLEMENTATION-VERSION may not solve our problem.
lisp-implementation-version does provide the information you seek. the released version is 2.49, the development is 2.49+. we use hg, not git.
https://sourceforge.net/p/clisp/clisp/ci/default/tree/version.sh
Indeed, on windows, I must have binary releases, since I do not have a build environment for Windows.
If you wish, you can request a clisp windows binary on the clisp-devel mailing list.
On 9/1/16 Sep 1 -9:57 PM, Sam Steingold wrote:
- Robert Goldman ectbyqzna@fvsg.arg [2016-09-01 18:38:12 -0500]:
On 9/1/16 Sep 1 -6:15 PM, Sam Steingold wrote:
- Robert Goldman ectbyqzna@fvsg.arg [2016-09-01 12:34:11 -0500]:
Even worse, AFAICT clisp does not make its version number available to the lisp context.
CLISP, like all the other implementations striving for ANSI CL compliance, exports `lisp-implementation-version' (http://clhs.lisp.se/Body/f_lisp_i.htm).
However, testing version numbers is not the best way to achieve cross-release compatibility; it is much better to test for specific behavior.
True, but this is not for code -- it's for regression testing. For regression-testing, I think it's fine if we say "on clisp, if the version is less than or equal to 2.49, disable this test."
Until now we have just been saying "on clisp, disable this test."
Unfortunately, since I believe that clisp in git has not been bumped beyond 2.49, reading LISP-IMPLEMENTATION-VERSION may not solve our problem.
lisp-implementation-version does provide the information you seek. the released version is 2.49, the development is 2.49+. we use hg, not git.
https://sourceforge.net/p/clisp/clisp/ci/default/tree/version.sh
OK. Sorry -- I realize I am being fussy, but it's a lot easier for us if we can have something like
(version>= (clisp-implementation-version) "2.49.0")
which works as do all ASDF version numbers, on the \d+ (. \d+)* pattern.
If we have to wrestle with clisp's "2.49+" and someone else's "2.50rc" and someone else's "2.50beta3", it's just crazy-making and unsustainable.
If there is another standard that people are adhering to, I'd be interested in ASDF supporting it, but not one version numbering scheme per implementation. Well, it's not the scheme per se, it's the need for us to maintain a >= relationship for each such scheme.
On 28 Aug 2016, at 02:28, Faré fahree@gmail.com wrote:
First I reproduced CLISP bug 677, figured out what CLISP was doing wrong (incorrect merging of logical pathnames in compile-file), and implemented a workaround (physicalize everything I can, trust compile-file's return value over my :output-file argument): https://sourceforge.net/p/clisp/bugs/677/
That bug has been fixed a few days ago.
-
Daniel Kochmański -
Elias Pipping -
Faré -
Robert Goldman -
Sam Steingold