Dear Anton,
can you run the below tests, in order or priority?
1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users.
2- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0? We want to merge syntax control, but it's a significant enough change that we don't want it at the same time as the bug fixes. Also...
3- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0, but with the following addition just after you load asdf but before you start using it: (defparameter uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see what breaks if we disable extensions implementation-specific reader extensions. Test most important on CCL. I don't expect much breakage on other implementations, but it may exist, too.
4- While you're at it, can you also run the test, at least on sbcl, with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*)) ? This will detect what breaks when we make the default readtable read-only.
The thing is, we really want to have this syntax control, but we also want to preserve backward compatibility, and we can't make asdf stricter until every client is fixed (famous last word; of course we failed at exactly that in 3.3.1 — we could build correctly, but would also spuriously rebuild if secondary systems were misnamed; fixed in 3.3.1.3).
https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-cont... https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A friend once asked me if I had ever considered terrorism as a means for political change. I replied that yes, I had considered it... and rejected it. Because it only causes change for the worse. Killing innocent people does not promote a culture of peaceful interaction.
Faré, hello.
Sorry for replying so long - I'm almost paralyzed by too many things I need to deal with currently. I've started tests for the following commit. Will follow-up with the results.
commit 2a5bc3bece8f97fdf64dc73a4e0544a55ae38f9d Author: Robert P. Goldman rpgoldman@sift.net Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré" fahree@gmail.com:
Dear Anton,
can you run the below tests, in order or priority?
1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users.
2- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0? We want to merge syntax control, but it's a significant enough change that we don't want it at the same time as the bug fixes. Also...
3- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0, but with the following addition just after you load asdf but before you start using it: (defparameter uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see what breaks if we disable extensions implementation-specific reader extensions. Test most important on CCL. I don't expect much breakage on other implementations, but it may exist, too.
4- While you're at it, can you also run the test, at least on sbcl, with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*)) ? This will detect what breaks when we make the default readtable read-only.
The thing is, we really want to have this syntax control, but we also want to preserve backward compatibility, and we can't make asdf stricter until every client is fixed (famous last word; of course we failed at exactly that in 3.3.1 — we could build correctly, but would also spuriously rebuild if secondary systems were misnamed; fixed in 3.3.1.3).
https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-cont... https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A friend once asked me if I had ever considered terrorism as a means for political change. I replied that yes, I had considered it... and rejected it. Because it only causes change for the worse. Killing innocent people does not promote a culture of peaceful interaction.
I'll get you a branch with the other setting for the syntax control, so you can just test with that instead of having to modify anything yourself. I'll get it pushed sometime tomorrow.
Sorry for the delay.
Sent from my iPad
On Feb 13, 2018, at 20:15, Anton Vodonosov avodonosov@yandex.ru wrote:
Faré, hello.
Sorry for replying so long - I'm almost paralyzed by too many things I need to deal with currently. I've started tests for the following commit. Will follow-up with the results.
commit 2a5bc3bece8f97fdf64dc73a4e0544a55ae38f9d Author: Robert P. Goldman rpgoldman@sift.net Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré" fahree@gmail.com:
Dear Anton,
can you run the below tests, in order or priority?
1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users.
2- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0? We want to merge syntax control, but it's a significant enough change that we don't want it at the same time as the bug fixes. Also...
3- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0, but with the following addition just after you load asdf but before you start using it: (defparameter uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see what breaks if we disable extensions implementation-specific reader extensions. Test most important on CCL. I don't expect much breakage on other implementations, but it may exist, too.
4- While you're at it, can you also run the test, at least on sbcl, with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*)) ? This will detect what breaks when we make the default readtable read-only.
The thing is, we really want to have this syntax control, but we also want to preserve backward compatibility, and we can't make asdf stricter until every client is fixed (famous last word; of course we failed at exactly that in 3.3.1 — we could build correctly, but would also spuriously rebuild if secondary systems were misnamed; fixed in 3.3.1.3).
https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-cont... https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A friend once asked me if I had ever considered terrorism as a means for political change. I replied that yes, I had considered it... and rejected it. Because it only causes change for the worse. Killing innocent people does not promote a culture of peaceful interaction.
OK, as I said, sorry about the delay. Anton, in place of Fare's #3 below, will you please just test what's in the `syntax-control-based-on-standard-syntax` branch? The comparison between 2 and 3 will tell us to what extent it's an issue to lock in standard syntax instead of whatever happens to be the current readtable when ASDF is loaded.
Thanks! r
On 13 Feb 2018, at 22:36, Robert P. Goldman wrote:
I'll get you a branch with the other setting for the syntax control, so you can just test with that instead of having to modify anything yourself. I'll get it pushed sometime tomorrow.
Sorry for the delay.
Sent from my iPad
On Feb 13, 2018, at 20:15, Anton Vodonosov avodonosov@yandex.ru wrote:
Faré, hello.
Sorry for replying so long - I'm almost paralyzed by too many things I need to deal with currently. I've started tests for the following commit. Will follow-up with the results.
commit 2a5bc3bece8f97fdf64dc73a4e0544a55ae38f9d Author: Robert P. Goldman rpgoldman@sift.net Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré" fahree@gmail.com:
Dear Anton,
can you run the below tests, in order or priority?
1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users.
2- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0? We want to merge syntax control, but it's a significant enough change that we don't want it at the same time as the bug fixes. Also...
3- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0, but with the following addition just after you load asdf but before you start using it: (defparameter uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see what breaks if we disable extensions implementation-specific reader extensions. Test most important on CCL. I don't expect much breakage on other implementations, but it may exist, too.
4- While you're at it, can you also run the test, at least on sbcl, with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*)) ? This will detect what breaks when we make the default readtable read-only.
The thing is, we really want to have this syntax control, but we also want to preserve backward compatibility, and we can't make asdf stricter until every client is fixed (famous last word; of course we failed at exactly that in 3.3.1 — we could build correctly, but would also spuriously rebuild if secondary systems were misnamed; fixed in 3.3.1.3).
https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-cont... https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A friend once asked me if I had ever considered terrorism as a means for political change. I replied that yes, I had considered it... and rejected it. Because it only causes change for the worse. Killing innocent people does not promote a culture of peaceful interaction.
Thanks for sending that. Had a quick look. One nice thing is that there's a very limited number of regressions. I'll look at those when I can.
Faré: I didn't believe it was possible to downgrade ASDF, but we see this here in a couple of cases for ECL. ECL is trying to reload "prebuilt-asdf". I think we can ignore these failures on ECL. They just should not do that, and it's not really and ASDF test failure if they load a conflicting version of ASDF, breaking our upgrade method.
clisp I refuse to care about, since it's effectively abandonware, unless you are willing to build from source, which I am not. Certainly clisp 2.49 is abandonware.k
That leaves only the SBCL and ACL failures for us to worry about.... I'm pretty busy this weekend, but I will have a look.
Best, Robert
On 15 Feb 2018, at 22:11, Anton Vodonosov wrote:
Robert, what delay are you apologizing for? I'm aware only of the delay from my side. :)
The results for ASDF 3.3.1.3: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html
Lisps tested so far:
abcl-1.5.0-fasl43-linux-x86
acl-10.0s-linux-x86
ccl-1.11-r16635-f96-linux-x86
clisp-2.49-unix-x86
ecl-16.1.2-unknown-linux-x86-bytecode
ecl-16.1.2-unknown-linux-x86-lisp-to-c
sbcl-1.3.21-linux-x86
Best regards,
- Anton
14.02.2018, 22:02, "Robert Goldman" rpgoldman@sift.net:
OK, as I said, sorry about the delay. Anton, in place of Fare's #3 below, will you please just test what's in the `syntax-control-based-on-standard-syntax` branch? The comparison between 2 and 3 will tell us to what extent it's an issue to lock in standard syntax instead of whatever happens to be the current readtable when ASDF is loaded.
Thanks! r
On 13 Feb 2018, at 22:36, Robert P. Goldman wrote:
I'll get you a branch with the other setting for the syntax control, so you can just test with that instead of having to modify anything yourself. I'll get it pushed sometime tomorrow.
Sorry for the delay.
Sent from my iPad
On Feb 13, 2018, at 20:15, Anton Vodonosov <[avodonosov@yandex.ru](mailto:avodonosov@yandex.ru)> wrote:
Faré, hello.
Sorry for replying so long - I'm almost paralyzed by too many things I need to deal with currently. I've started tests for the following commit. Will follow-up with the results.
commit 2a5bc3bece8f97fdf64dc73a4e0544a55ae38f9d Author: Robert P. Goldman <[rpgoldman@sift.net](mailto:rpgoldman@sift.net)> Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré" <[fahree@gmail.com](mailto:fahree@gmail.com)>:
Dear Anton,
can you run the below tests, in order or priority?
1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users.
2- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0? We want to merge syntax control, but it's a significant enough change that we don't want it at the same time as the bug fixes. Also...
3- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0, but with the following addition just after you load asdf but before you start using it: (defparameter uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see what breaks if we disable extensions implementation-specific reader extensions. Test most important on CCL. I don't expect much breakage on other implementations, but it may exist, too.
4- While you're at it, can you also run the test, at least on sbcl, with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*)) ? This will detect what breaks when we make the default readtable read-only.
The thing is, we really want to have this syntax control, but we also want to preserve backward compatibility, and we can't make asdf stricter until every client is fixed (famous last word; of course we failed at exactly that in 3.3.1 — we could build correctly, but would also spuriously rebuild if secondary systems were misnamed; fixed in 3.3.1.3).
https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-control.md https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• [http://fare.tunes.org%5D(http://fare.tunes.org/) A friend once asked me if I had ever considered terrorism as a means for political change. I replied that yes, I had considered it... and rejected it. Because it only causes change for the worse. Killing innocent people does not promote a culture of peaceful interaction.
Anton,
thanks a lot for the test! asdf 3.3.1.3 looks good to go.
Robert,
I had no trouble loading clws or lime with clisp, cl-rrt or cl-sat.minisat.test or inner-conditional-test with sbcl (using asdf 3.3.1.3 from master).
The ecl failures I could reproduce, but I'm not worried, as lisp-executable is not supported with recent asdf, and a reproducible out-of-memory error on one system :trivia.balland2006.enabled.test isn't outrageous.
CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap clisp -I -x "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :clws)) ())" CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap clisp -I -x "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :lime)) ())"
CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap sbcl --eval "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :cl-rrt)) ())" CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap sbcl --eval "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :cl-sat.minisat.test )) ())" CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap sbcl --eval "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :inner-conditional-test )) ())"
CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap ecl --eval "'(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :lisp-executable-example)#.(quit))" CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap ecl --eval "'(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :trivia.balland2006.enabled.test )#.(quit))"
Often failures in cl-test-grid are "just" the result of using too little memory, or batching system loads, or some other reason, and have to be retried.
I can try to activate that Windows VM and run the all the tests there, if you want...
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Pain is inevitable. Suffering is optional.
On Fri, Feb 16, 2018 at 11:42 AM, Robert Goldman rpgoldman@sift.net wrote:
Thanks for sending that. Had a quick look. One nice thing is that there's a very limited number of regressions. I'll look at those when I can.
Faré: I didn't believe it was possible to downgrade ASDF, but we see this here in a couple of cases for ECL. ECL is trying to reload "prebuilt-asdf". I think we can ignore these failures on ECL. They just should not do that, and it's not really and ASDF test failure if they load a conflicting version of ASDF, breaking our upgrade method.
clisp I refuse to care about, since it's effectively abandonware, unless you are willing to build from source, which I am not. Certainly clisp 2.49 is abandonware.k
That leaves only the SBCL and ACL failures for us to worry about.... I'm pretty busy this weekend, but I will have a look.
Best, Robert
On 15 Feb 2018, at 22:11, Anton Vodonosov wrote:
Robert, what delay are you apologizing for? I'm aware only of the delay from my side. :)
The results for ASDF 3.3.1.3: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html
Lisps tested so far:
abcl-1.5.0-fasl43-linux-x86
acl-10.0s-linux-x86
ccl-1.11-r16635-f96-linux-x86
clisp-2.49-unix-x86
ecl-16.1.2-unknown-linux-x86-bytecode
ecl-16.1.2-unknown-linux-x86-lisp-to-c
sbcl-1.3.21-linux-x86
Best regards,
- Anton
14.02.2018, 22:02, "Robert Goldman" rpgoldman@sift.net:
OK, as I said, sorry about the delay. Anton, in place of Fare's #3 below, will you please just test what's in the `syntax-control-based-on-standard-syntax` branch? The comparison between 2 and 3 will tell us to what extent it's an issue to lock in standard syntax instead of whatever happens to be the current readtable when ASDF is loaded.
Thanks! r
On 13 Feb 2018, at 22:36, Robert P. Goldman wrote:
I'll get you a branch with the other setting for the syntax control, so you can just test with that instead of having to modify anything yourself. I'll get it pushed sometime tomorrow.
Sorry for the delay.
Sent from my iPad
On Feb 13, 2018, at 20:15, Anton Vodonosov <[avodonosov@yandex.ru](mailto:avodonosov@yandex.ru)> wrote:
Faré, hello.
Sorry for replying so long - I'm almost paralyzed by too many things I need to deal with currently. I've started tests for the following commit. Will follow-up with the results.
commit 2a5bc3bece8f97fdf64dc73a4e0544a55ae38f9d Author: Robert P. Goldman <[rpgoldman@sift.net](mailto:rpgoldman@sift.net)> Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré" <[fahree@gmail.com](mailto:fahree@gmail.com)>:
Dear Anton,
can you run the below tests, in order or priority?
1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users.
2- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0? We want to merge syntax control, but it's a significant enough change that we don't want it at the same time as the bug fixes. Also...
3- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0, but with the following addition just after you load asdf but before you start using it: (defparameter uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see what breaks if we disable extensions implementation-specific reader extensions. Test most important on CCL. I don't expect much breakage on other implementations, but it may exist, too.
4- While you're at it, can you also run the test, at least on sbcl, with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*)) ? This will detect what breaks when we make the default readtable read-only.
The thing is, we really want to have this syntax control, but we also want to preserve backward compatibility, and we can't make asdf stricter until every client is fixed (famous last word; of course we failed at exactly that in 3.3.1 — we could build correctly, but would also spuriously rebuild if secondary systems were misnamed; fixed in 3.3.1.3).
https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-control.md https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• [http://fare.tunes.org%5D(http://fare.tunes.org/) A friend once asked me if I had ever considered terrorism as a means for political change. I replied that yes, I had considered it... and rejected it. Because it only causes change for the worse. Killing innocent people does not promote a culture of peaceful interaction.
I'm reviewing the tests now.
clisp I don't care about: as far as I'm concerned, 2.49 is dead, and I'm going to ignore clisp until there's a new release.
ECL seems like you are saying that lisp-executable is simply incompatible with the new ASDF, so we can ignore that.
The ACL failure on type-i.test seems to be pretty much a failure *without* the latest ASDF. So I don't know if that's our fault or just that the old ASDF happened to squeak through under the deadline when the new one doesn't. I'll check it with a timeout and see what happens. I'd love to know if it's failing in our code or in its own.
The SBCL failures on cl-rrt.benchmark and inner-conditional-test are a little more worrisome. I have just looked at the CL-RRT test, and it has randomness in it. I don't think that failure is ASDF's fault.
I was not able to replicate the inner-conditional-test failure. I started SBCL (1.4.3), loaded new ASDF, loaded "inner-conditional," loaded "inner-conditional-test", and it loaded and ran successfully.
So maybe we are good to go.
R
On 16 Feb 2018, at 13:01, Faré wrote:
Anton,
thanks a lot for the test! asdf 3.3.1.3 looks good to go.
Robert,
I had no trouble loading clws or lime with clisp, cl-rrt or cl-sat.minisat.test or inner-conditional-test with sbcl (using asdf 3.3.1.3 from master).
The ecl failures I could reproduce, but I'm not worried, as lisp-executable is not supported with recent asdf, and a reproducible out-of-memory error on one system :trivia.balland2006.enabled.test isn't outrageous.
CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap clisp -I -x "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :clws)) ())" CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap clisp -I -x "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :lime)) ())"
CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap sbcl --eval "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :cl-rrt)) ())" CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap sbcl --eval "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :cl-sat.minisat.test )) ())" CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap sbcl --eval "(and '(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :inner-conditional-test )) ())"
CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap ecl --eval "'(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :lisp-executable-example)#.(quit))" CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' rlwrap ecl --eval "'(#.(load "/home/fare/cl/asdf/build/asdf.lisp") #.(in-package :asdf) #.(upgrade-asdf) #.(load "~/quicklisp/setup.lisp") #.(ql:quickload :trivia.balland2006.enabled.test )#.(quit))"
Often failures in cl-test-grid are "just" the result of using too little memory, or batching system loads, or some other reason, and have to be retried.
I can try to activate that Windows VM and run the all the tests there, if you want...
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Pain is inevitable. Suffering is optional.
On Fri, Feb 16, 2018 at 11:42 AM, Robert Goldman rpgoldman@sift.net wrote:
Thanks for sending that. Had a quick look. One nice thing is that there's a very limited number of regressions. I'll look at those when I can.
Faré: I didn't believe it was possible to downgrade ASDF, but we see this here in a couple of cases for ECL. ECL is trying to reload "prebuilt-asdf". I think we can ignore these failures on ECL. They just should not do that, and it's not really and ASDF test failure if they load a conflicting version of ASDF, breaking our upgrade method.
clisp I refuse to care about, since it's effectively abandonware, unless you are willing to build from source, which I am not. Certainly clisp 2.49 is abandonware.k
That leaves only the SBCL and ACL failures for us to worry about.... I'm pretty busy this weekend, but I will have a look.
Best, Robert
On 15 Feb 2018, at 22:11, Anton Vodonosov wrote:
Robert, what delay are you apologizing for? I'm aware only of the delay from my side. :)
The results for ASDF 3.3.1.3: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html
Lisps tested so far:
abcl-1.5.0-fasl43-linux-x86
acl-10.0s-linux-x86
ccl-1.11-r16635-f96-linux-x86
clisp-2.49-unix-x86
ecl-16.1.2-unknown-linux-x86-bytecode
ecl-16.1.2-unknown-linux-x86-lisp-to-c
sbcl-1.3.21-linux-x86
Best regards,
- Anton
14.02.2018, 22:02, "Robert Goldman" rpgoldman@sift.net:
OK, as I said, sorry about the delay. Anton, in place of Fare's #3 below, will you please just test what's in the `syntax-control-based-on-standard-syntax` branch? The comparison between 2 and 3 will tell us to what extent it's an issue to lock in standard syntax instead of whatever happens to be the current readtable when ASDF is loaded.
Thanks! r
On 13 Feb 2018, at 22:36, Robert P. Goldman wrote:
I'll get you a branch with the other setting for the syntax control, so you can just test with that instead of having to modify anything yourself. I'll get it pushed sometime tomorrow.
Sorry for the delay.
Sent from my iPad
On Feb 13, 2018, at 20:15, Anton Vodonosov <[avodonosov@yandex.ru](mailto:avodonosov@yandex.ru)> wrote:
Faré, hello.
Sorry for replying so long - I'm almost paralyzed by too many things I need to deal with currently. I've started tests for the following commit. Will follow-up with the results.
commit 2a5bc3bece8f97fdf64dc73a4e0544a55ae38f9d Author: Robert P. Goldman <[rpgoldman@sift.net](mailto:rpgoldman@sift.net)> Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré" <[fahree@gmail.com](mailto:fahree@gmail.com)>:
> Dear Anton,
can you run the below tests, in order or priority?
1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users.
2- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0? We want to merge syntax control, but it's a significant enough change that we don't want it at the same time as the bug fixes. Also...
3- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0, but with the following addition just after you load asdf but before you start using it: (defparameter uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see what breaks if we disable extensions implementation-specific reader extensions. Test most important on CCL. I don't expect much breakage on other implementations, but it may exist, too.
4- While you're at it, can you also run the test, at least on sbcl, with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*)) ? This will detect what breaks when we make the default readtable read-only.
The thing is, we really want to have this syntax control, but we also want to preserve backward compatibility, and we can't make asdf stricter until every client is fixed (famous last word; of course we failed at exactly that in 3.3.1 — we could build correctly, but would also spuriously rebuild if secondary systems were misnamed; fixed in 3.3.1.3).
https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-control.md https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• [http://fare.tunes.org%5D(http://fare.tunes.org/) A friend once asked me if I had ever considered terrorism as a means for political change. I replied that yes, I had considered it... and rejected it. Because it only causes change for the worse. Killing innocent people does not promote a culture of peaceful interaction.
Robert P. Goldman Research Fellow Smart Information Flow Technologies (d/b/a SIFT, LLC)
319 N. First Ave., Suite 400 Minneapolis, MN 55401
Voice: (612) 326-3934 Email: rpgoldman@SIFT.net
16.02.2018, 22:02, "Faré" fahree@gmail.com:
Often failures in cl-test-grid are "just" the result of using too little memory,
not little memory, but SBCL's conservative (i.e. imprecise) garbage collection - it doesn't always recognize that an object is a garbage.
I saw cases where CCL compiles a project under a 100MB heap, while SBCL reproducibly runs out of 1GB heap.
or batching system loads,
There is no batch loading, each test is run in a fresh CL process.
or some other reason, and have to be retried.
I would put it differently: some failures may be ignored because on the previous version they were successful by a chance, and could faile the same way too.
I updated the report with the rest of the results. The lisps tested:
abcl-1.5.0-fasl43-linux-x86 acl-10.0-linux-x86 acl-10.0m-linux-x86 acl-10.0ms-linux-x86 acl-10.0s-linux-x86 ccl-1.10-r16196-f96-linux-x86 ccl-1.11-r16635-f96-linux-x86 ccl-1.9-r15756-f96-linux-x86 clisp-2.49-unix-x86 ecl-16.1.2-unknown-linux-x86-bytecode ecl-16.1.2-unknown-linux-x86-lisp-to-c sbcl-1.1.16-linux-x86 sbcl-1.3.21-linux-x86
https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html
Dear Anton,
can you try your test suite again against 3.3.1.7 ? I think we're mostly ready to release 3.3.2 this time, with its many bugs fixes (and bug fix fixes).
Can you also try the branch made by Robert for syntax-control + a copy of the standard readtable as default?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wir Mathematiker sind alle ein bisschen meschugge. (We mathematicans are all a bit crazy). — Lev Landau
I've started tests for 3.3.1.7
11.03.2018, 06:11, "Faré" fahree@gmail.com:
Dear Anton,
can you try your test suite again against 3.3.1.7 ? I think we're mostly ready to release 3.3.2 this time, with its many bugs fixes (and bug fix fixes).
Can you also try the branch made by Robert for syntax-control + a copy of the standard readtable as default?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wir Mathematiker sind alle ein bisschen meschugge. (We mathematicans are all a bit crazy). — Lev Landau
Results for these lisps:
abcl-1.5.0-fasl43-linux-x86 ccl-1.10-r16196-f96-linux-x86 ccl-1.11-r16635-f96-linux-x86 ccl-1.9-r15756-f96-linux-x86 clisp-2.49-unix-x86 ecl-16.1.2-unknown-linux-x86-bytecode ecl-16.1.2-unknown-linux-x86-lisp-to-c sbcl-1.1.16-linux-x86 sbcl-1.3.21-linux-x86
show no regressions.
ACL tests are running - needed to re-run them because licence refresh was needed.
The report: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
Best regards, - Anton
13.03.2018, 16:53, "Anton Vodonosov" avodonosov@yandex.ru:
I've started tests for 3.3.1.7
11.03.2018, 06:11, "Faré" fahree@gmail.com:
Dear Anton,
can you try your test suite again against 3.3.1.7 ? I think we're mostly ready to release 3.3.2 this time, with its many bugs fixes (and bug fix fixes).
Can you also try the branch made by Robert for syntax-control + a copy of the standard readtable as default?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wir Mathematiker sind alle ein bisschen meschugge. (We mathematicans are all a bit crazy). — Lev Landau
Just to be clear: this is matter, right? It's not one of the syntax control branches?
Sent from my iPad
On Mar 17, 2018, at 07:51, Anton Vodonosov avodonosov@yandex.ru wrote:
Results for these lisps:
abcl-1.5.0-fasl43-linux-x86 ccl-1.10-r16196-f96-linux-x86 ccl-1.11-r16635-f96-linux-x86 ccl-1.9-r15756-f96-linux-x86 clisp-2.49-unix-x86 ecl-16.1.2-unknown-linux-x86-bytecode ecl-16.1.2-unknown-linux-x86-lisp-to-c sbcl-1.1.16-linux-x86 sbcl-1.3.21-linux-x86
show no regressions.
ACL tests are running - needed to re-run them because licence refresh was needed.
The report: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
Best regards,
- Anton
13.03.2018, 16:53, "Anton Vodonosov" avodonosov@yandex.ru:
I've started tests for 3.3.1.7
11.03.2018, 06:11, "Faré" fahree@gmail.com:
Dear Anton,
can you try your test suite again against 3.3.1.7 ? I think we're mostly ready to release 3.3.2 this time, with its many bugs fixes (and bug fix fixes).
Can you also try the branch made by Robert for syntax-control + a copy of the standard readtable as default?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wir Mathematiker sind alle ein bisschen meschugge. (We mathematicans are all a bit crazy). — Lev Landau
Sorry. That was meant to be "master," not matter.
Sent from my iPad
On Mar 17, 2018, at 09:36, Robert P. Goldman rpgoldman@sift.net wrote:
Just to be clear: this is matter, right? It's not one of the syntax control branches?
Sent from my iPad
On Mar 17, 2018, at 07:51, Anton Vodonosov avodonosov@yandex.ru wrote:
Results for these lisps:
abcl-1.5.0-fasl43-linux-x86 ccl-1.10-r16196-f96-linux-x86 ccl-1.11-r16635-f96-linux-x86 ccl-1.9-r15756-f96-linux-x86 clisp-2.49-unix-x86 ecl-16.1.2-unknown-linux-x86-bytecode ecl-16.1.2-unknown-linux-x86-lisp-to-c sbcl-1.1.16-linux-x86 sbcl-1.3.21-linux-x86
show no regressions.
ACL tests are running - needed to re-run them because licence refresh was needed.
The report: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
Best regards,
- Anton
13.03.2018, 16:53, "Anton Vodonosov" avodonosov@yandex.ru:
I've started tests for 3.3.1.7
11.03.2018, 06:11, "Faré" fahree@gmail.com:
Dear Anton,
can you try your test suite again against 3.3.1.7 ? I think we're mostly ready to release 3.3.2 this time, with its many bugs fixes (and bug fix fixes).
Can you also try the branch made by Robert for syntax-control + a copy of the standard readtable as default?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wir Mathematiker sind alle ein bisschen meschugge. (We mathematicans are all a bit crazy). — Lev Landau
Thank you very much, Anton. Question: is the inner-conditional-test failure on SBCL 1.3.21 not a regression? I just loaded this system and tested it on my mac with SBCL 1.4.3, and it worked fine, so I'm inclined to treat this is not a problem. Also, the inner conditional system has a readme saying it's not maintained and please not to use it.
What about reversi on CCL 1.9? I guess if I understand correctly, reversi must have passed on CCL 1.10 and 1.11, so probably I shouldn't worry about this, either.
Fare, what do you think? Should I release this version, or wait a little longer and see if we can get the syntax fix in, as well?
Maybe I should release this as 3.3.2, and make the syntax-fixed version of ASDF be 3.4, since (for some people) it might be a bigger change.
Best, r
On 17 Mar 2018, at 7:51, Anton Vodonosov wrote:
Results for these lisps:
abcl-1.5.0-fasl43-linux-x86 ccl-1.10-r16196-f96-linux-x86 ccl-1.11-r16635-f96-linux-x86 ccl-1.9-r15756-f96-linux-x86 clisp-2.49-unix-x86 ecl-16.1.2-unknown-linux-x86-bytecode ecl-16.1.2-unknown-linux-x86-lisp-to-c sbcl-1.1.16-linux-x86 sbcl-1.3.21-linux-x86
show no regressions.
ACL tests are running - needed to re-run them because licence refresh was needed.
The report: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
Best regards,
- Anton
13.03.2018, 16:53, "Anton Vodonosov" avodonosov@yandex.ru:
I've started tests for 3.3.1.7
11.03.2018, 06:11, "Faré" fahree@gmail.com:
Dear Anton,
can you try your test suite again against 3.3.1.7 ? I think we're mostly ready to release 3.3.2 this time, with its many bugs fixes (and bug fix fixes).
Can you also try the branch made by Robert for syntax-control + a copy of the standard readtable as default?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wir Mathematiker sind alle ein bisschen meschugge. (We mathematicans are all a bit crazy). — Lev Landau
On Sat, Mar 17, 2018 at 2:52 PM, Robert Goldman rpgoldman@sift.net wrote:
Thank you very much, Anton. Question: is the inner-conditional-test failure on SBCL 1.3.21 not a regression? I just loaded this system and tested it on my mac with SBCL 1.4.3, and it worked fine, so I'm inclined to treat this is not a problem. Also, the inner conditional system has a readme saying it's not maintained and please not to use it.
What about reversi on CCL 1.9? I guess if I understand correctly, reversi must have passed on CCL 1.10 and 1.11, so probably I shouldn't worry about this, either.
Fare, what do you think? Should I release this version, or wait a little longer and see if we can get the syntax fix in, as well?
I think we're good for 3.3.2. There are often a few non-reproducible failures and failures on older implementations, and I see nothing worrisome there, even though I haven't tried to rerun the crashes and timeouts in case their work the second time around.
Maybe I should release this as 3.3.2, and make the syntax-fixed version of ASDF be 3.4, since (for some people) it might be a bigger change.
Yes, that might be prudent.
When you make a 3.4, be sure to test cl-test-grid with a branch that includes the version update, because that's how you'll find problems with deprecated functions (for which you should make sure to bump the expiration date properly).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Whatever is worth doing at all is worth doing well. — Chesterfield
17.03.2018, 21:52, "Robert Goldman" rpgoldman@sift.net:
Thank you very much, Anton. Question: is the inner-conditional-test failure on SBCL 1.3.21 not a regression?
Not a regression. Heap Exhausted often happens on SBCL for that library: https://common-lisp.net/project/cl-test-grid/library/inner-conditional.html
That's a problem of SBCL's conservative garbage collector - it doesn't always recognizes garbage that may be collected, thus exhausting heap.
What about reversi on CCL 1.9? I guess if I understand correctly, reversi must have passed on CCL 1.10 and 1.11, so probably I shouldn't worry about this, either.
This error happens only with the presence of the new ASDF, but it's low-level memory access level, thus it's, in any case, an error in CCL rather than in ASDF lisp code.
For the record, it's easy to reproduce this way (the failure happens about 80% of time):
$ rm -rf /home/testgrid/.cache/common-lisp/ && rlwrap /home/testgrid/lisps/ccl-1.9/lx86cl --no-init --load /home/testgrid/quicklisp-asdf3/setup.lisp --eval '(ql:quickload :reversi)' --eval '(ccl:quit)'
And it only happens in CCL 1.9. Since 1.10 the error doesn't reproduce. So no worries for ASDF developers.
On 17 Mar 2018, at 7:51, Anton Vodonosov wrote:
Results for these lisps:
abcl-1.5.0-fasl43-linux-x86 ccl-1.10-r16196-f96-linux-x86 ccl-1.11-r16635-f96-linux-x86 ccl-1.9-r15756-f96-linux-x86 clisp-2.49-unix-x86 ecl-16.1.2-unknown-linux-x86-bytecode ecl-16.1.2-unknown-linux-x86-lisp-to-c sbcl-1.1.16-linux-x86 sbcl-1.3.21-linux-x86
show no regressions.
ACL tests are running - needed to re-run them because licence refresh was needed.
The report: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
Best regards, - Anton
13.03.2018, 16:53, "Anton Vodonosov" avodonosov@yandex.ru:
I've started tests for 3.3.1.7
11.03.2018, 06:11, "Faré" fahree@gmail.com:
Dear Anton,
can you try your test suite again against 3.3.1.7 ? I think we're mostly ready to release 3.3.2 this time, with its many bugs fixes (and bug fix fixes).
Can you also try the branch made by Robert for syntax-control + a copy of the standard readtable as default?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Wir Mathematiker sind alle ein bisschen meschugge. (We mathematicans are all a bit crazy). — Lev Landau
Often failures in cl-test-grid are "just" the result of using too little memory,
not little memory, but SBCL's conservative (i.e. imprecise) garbage collection - it doesn't always recognize that an object is a garbage.
I saw cases where CCL compiles a project under a 100MB heap, while SBCL reproducibly runs out of 1GB heap.
Maybe it's an artefact of SBCL using too much memory *while compiling* and would go away if you used e.g. POIU to compile inside forks.
or batching system loads,
There is no batch loading, each test is run in a fresh CL process.
Interesting. The memory load might still be sensitive to compilation order, if you reuse fasls shared with previous builds versus rebuild new ones.
or some other reason, and have to be retried.
I would put it differently: some failures may be ignored because on the previous version they were successful by a chance, and could faile the same way too.
OK.
PS: The newer test results look good. I'd like to see the results with the syntax-control branch, though. There also are a few minor bug fixes in the pipe that mean we'll have to re-test before release, anyway.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Foolishness is rarely a matter of lack of intelligence or even lack of information. — John McCarthy
02.03.2018, 05:33, "Faré" fahree@gmail.com:
Often failures in cl-test-grid are "just" the result of using too little memory,
not little memory, but SBCL's conservative (i.e. imprecise) garbage collection - it doesn't always recognize that an object is a garbage.
I saw cases where CCL compiles a project under a 100MB heap, while SBCL reproducibly runs out of 1GB heap.
Maybe it's an artefact of SBCL using too much memory *while compiling* and would go away if you used e.g. POIU to compile inside forks.
How?
or batching system loads,
There is no batch loading, each test is run in a fresh CL process.
Interesting. The memory load might still be sensitive to compilation order, if you reuse fasls shared with previous builds versus rebuild new ones.
The test order is alphabetical (by projects, and then inside a project its ASDF systems are sorted alphabetically too).
Fasls compiled by previous tests are reused by next tests.
or some other reason, and have to be retried.
I would put it differently: some failures may be ignored because on the previous version they were successful by a chance, and could faile the same way too.
OK.
PS: The newer test results look good. I'd like to see the results with the syntax-control branch, though. There also are a few minor bug fixes in the pipe that mean we'll have to re-test before release, anyway.
Yes, I plan to start syntax-control testing soon.
You might be interested to know that ACL binds *readtable* on startup to an unmodifieble readtable (which is a violation of CLHS http://clhs.lisp.se/Body/02_aac.htm : "The initial readtable is distinct from the standard readtable. It is permissible for a conforming program to modify the initial readtable.")
The most visible result of this is puri and more than 150 other systems in Quicklisp depending on it, failing to load.
Another hint: when you review test results, it might be helpful to see how particular library is built in other implementations and in the previous Quicklisp. Here you can find such build results for every library: https://common-lisp.net/project/cl-test-grid/library/
Best regards, - Anton
Maybe it's an artefact of SBCL using too much memory *while compiling* and would go away if you used e.g. POIU to compile inside forks.
How?
"Just" load POIU right after you load ASDF, and before you load anything else. https://gitlab.common-lisp.net/qitab/poiu
The test order is alphabetical (by projects, and then inside a project its ASDF systems are sorted alphabetically too).
Fasls compiled by previous tests are reused by next tests.
OK, this *might* explain some cases of "succeeds the second time around". I suggest always making a second try after a timeout or out-of-memory error.
Yes, I plan to start syntax-control testing soon.
Thanks!
You might be interested to know that ACL binds *readtable* on startup to an unmodifieble readtable (which is a violation of CLHS http://clhs.lisp.se/Body/02_aac.htm : "The initial readtable is distinct from the standard readtable. It is permissible for a conforming program to modify the initial readtable.")
The most visible result of this is puri and more than 150 other systems in Quicklisp depending on it, failing to load.
Well, that's a good argument for fixing puri & al, regardless of what option ASDF picks in the future. And maybe a good argument for making ASDF strict all the time on all implementations that allow it.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Death is only a milestone — albeit one that is dropped on you from a very great height — Terry Pratchett.
On 1 Mar 2018, at 21:45, Faré wrote:
You might be interested to know that ACL binds *readtable* on startup to an unmodifieble readtable
(which is a violation of CLHS http://clhs.lisp.se/Body/02_aac.htm : "The initial readtable is distinct from the standard readtable. It is permissible for a conforming program to modify the initial readtable.")
I don't see this behavior in ACL 10.1 (64 bit) on the Mac:
``` CL-USER> *readtable* #<readtable @ #x100022d3a2> CL-USER> (defun semicolon-reader (stream char) (declare (ignore char)) ;; First swallow the rest of the current input line. ;; End-of-file is acceptable for terminating the comment. (do () ((char= (read-char stream nil #\Newline t) #\Newline))) ;; Return zero values. (values)) SEMICOLON-READER CL-USER> (set-macro-character #; #'semicolon-reader) T CL-USER> ```
The most visible result of this is puri and more than 150 other systems in Quicklisp depending on it, failing to load.
Well, that's a good argument for fixing puri & al, regardless of what option ASDF picks in the future. And maybe a good argument for making ASDF strict all the time on all implementations that allow it.
So as I see it we have *three* options for the `*shared-readtable*`
1. Your original option -- the "initial-ish" readtable (since we can't control when ASDF is loaded) 2. My proposal: a copy of the standard readtable. We should consider what might happen in this case if ASDF is reloaded or upgraded. I don't know if option #1 has this same issue. 3. An unmodifiable standard readtable. I don't believe that this is portably possible, is it? There's no ANSI method (unless I've overlooked something) to make a readtable unmodifiable, and there's no way to access the standard readtable portably (since it isn't required to be unique).
I believe my proposal, #2, is the most portable of all of the solutions, but I am still open to correction.
Best, r
On Fri, Mar 2, 2018 at 1:05 PM, Robert Goldman rpgoldman@sift.net wrote:
So as I see it we have three options for the *shared-readtable*
Your original option -- the "initial-ish" readtable (since we can't control when ASDF is loaded)
Usually ASDF is loaded before any significant other software is. If the user insists in modifying the initial readtable early, he's probably on to something.
My proposal: a copy of the standard readtable. We should consider what might happen in this case if ASDF is reloaded or upgraded. I don't know if option #1 has this same issue.
In either case, definitely use defvar rather than defparameter, unless you're also going to clear-registered-systems at every update.
An unmodifiable standard readtable. I don't believe that this is portably possible, is it? There's no ANSI method (unless I've overlooked something) to make a readtable unmodifiable, and there's no way to access the standard readtable portably (since it isn't required to be unique).
It's not portable for unmodifiability to be enforced, but it's certainly non-conformant to try to modify even when the implementations fails silently later rather than catches you immediately. So far as I know, only SBCL, ECL, Allegro, CMUCL make it unmodifiable. Maybe file bugs for other relevant implementations?
I believe my proposal, #2, is the most portable of all of the solutions, but I am still open to correction.
For some definition of "portable". I know that some systems rely on e.g. CCL or MCL extensions #$ or #_ — but they could be made to use the *initial-readtable* that we definitely are going to save anyway.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A good answer is one that solves the asker's problem, not one that (necessarily) fits his expectations. Actually, if the asker has been seriously looking for a solution, and did not find any, then there's a good deal of chance that a good answer won't fit his expectations! (At least, not all of them.)
02.03.2018, 21:05, "Robert Goldman" rpgoldman@sift.net:
You might be interested to know that ACL binds *readtable* on startup to an unmodifieble readtable (which is a violation of CLHS http://clhs.lisp.se/Body/02_aac.htm : "The initial readtable is distinct from the standard readtable. It is permissible for a conforming program to modify the initial readtable.")
I don't see this behavior in ACL 10.1 (64 bit) on the Mac:
CL-USER> *readtable* #<readtable @ #x100022d3a2> CL-USER> (defun semicolon-reader (stream char) (declare (ignore char)) ;; First swallow the rest of the current input line. ;; End-of-file is acceptable for terminating the comment. (do () ((char= (read-char stream nil #\Newline t) #\Newline))) ;; Return zero values. (values)) SEMICOLON-READER CL-USER> (set-macro-character #; #'semicolon-reader) T CL-USER>
Turns out this only happens when your code is evaluated via the -ee parameter with -batch parameter preset:
~/lisps/acl100/alisp -batch -ee "(set-dispatch-macro-character ## #\u #'(lambda (&rest ignored)))"
An unhandled error occurred during initialization: An error occurred (Attempt to set dispatch macro in system readtable #<readtable @ #x2012072a>; copy readtable first.) during the reading or evaluation of -e "(set-dispatch-macro-character #\# #\u #'(lambda (&rest ignored)))"
There is no batch loading, each test is run in a fresh CL process.
Interesting. The memory load might still be sensitive to compilation order, if you reuse fasls shared with previous builds versus rebuild new ones.
it can help on SBCL to insert (sb-ext:gc :full t) to a few key places, like after operations that generate a lot of garbage (e.g. compilation).
-
Anton Vodonosov -
Attila Lendvai -
Faré -
Robert Goldman -
Robert P. Goldman