Testing for ASDF 3.3.2 and beyond?

[Faré]

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
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 Vodonosov]

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 <***@sift.net>
Date: Tue Jan 16 16:20:15 2018 -0600

Bump version to 3.3.1.3

Post by Faré
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
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]

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

Post by Anton Vodonosov
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
Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3

Post by Faré
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
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 Goldman]

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

Post by Robert P. Goldman
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

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
Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3

Post by Faré
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
(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
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 Vodonosov]

[Robert Goldman]

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

Robert, what delay are you apologizing for? I'm aware only of the
delay from my side. :)
<https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html>
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

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

Post by Robert P. Goldman
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

Post by Robert P. Goldman

On Feb 13, 2018, at 20:15, Anton Vodonosov

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
Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré"

Post by Robert P. Goldman

Post by Faré
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
(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](<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é]

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.

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

Robert, what delay are you apologizing for? I'm aware only of the delay
from my side. :)
<https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html>
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

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

Post by Robert P. Goldman
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

Post by Robert P. Goldman

On Feb 13, 2018, at 20:15, Anton Vodonosov

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
Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré"

Post by Robert P. Goldman

Post by Faré
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](<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 Goldman]

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

Post by Faré
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.

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

Robert, what delay are you apologizing for? I'm aware only of the delay
from my side. :)
<https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html>
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

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

Post by Robert P. Goldman
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

Post by Robert P. Goldman

On Feb 13, 2018, at 20:15, Anton Vodonosov

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
Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré"

Post by Robert P. Goldman

Post by Faré
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
(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](<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: [phone]
Email: ***@SIFT.net

[Anton Vodonosov]

Post by Faré
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.

Post by Faré
or batching system loads,

There is no batch loading, each test is run in a fresh CL process.

Post by Faré
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.

[Anton Vodonosov]

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

[Faré]

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

[Anton Vodonosov]

I've started tests for 3.3.1.7

Post by Faré
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

[Anton Vodonosov]

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

Post by Anton Vodonosov
I've started tests for 3.3.1.7

 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

[Robert P. Goldman]

Just to be clear: this is matter, right? It's not one of the syntax control branches?

Sent from my iPad

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

Post by Anton Vodonosov
I've started tests for 3.3.1.7

Post by Faré
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

[Robert P. Goldman]

Sorry. That was meant to be "master," not matter.

Sent from my iPad

Post by Robert P. Goldman
Just to be clear: this is matter, right? It's not one of the syntax control branches?
Sent from my iPad

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

Post by Anton Vodonosov
I've started tests for 3.3.1.7

Post by Faré
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

[Anton Vodonosov]

[Robert Goldman]

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

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.
https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
Best regards,
- Anton

Post by Anton Vodonosov
I've started tests for 3.3.1.7

 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

[Faré]

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

[Anton Vodonosov]

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.

 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.
 https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
 Best regards,
 - Anton

 I've started tests for 3.3.1.7

  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

[Faré]

Post by Anton Vodonosov

Post by Faré
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.

Post by Anton Vodonosov

Post by Faré
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.

Post by Anton Vodonosov

Post by Faré
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

[Robert Goldman]

Post by Faré
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.

Concur...

[Anton Vodonosov]

Post by Faré

 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?

Post by Faré

 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.

Post by Faré

 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

[Faré]

Post by Anton Vodonosov

Post by Faré
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

Post by Anton Vodonosov
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.

Post by Anton Vodonosov
Yes, I plan to start syntax-control testing soon.

Thanks!

Post by Anton Vodonosov
You might be interested to know that ACL binds *readtable* on startup to an unmodifieble readtable
"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.

[Robert Goldman]

Post by Anton Vodonosov
You might be interested to know that ACL binds *readtable* on startup
to an unmodifieble readtable

Post by Anton Vodonosov
"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>
```

Post by Anton Vodonosov

Post by Anton Vodonosov
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

[Faré]

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.)

[Anton Vodonosov]

Post by Robert Goldman

Post by Anton Vodonosov
You might be interested to know that ACL binds *readtable* on startup
to an unmodifieble readtable
"The initial readtable is distinct from the standard readtable. It is
permissible for a conforming program to modify the initial
readtable.")

CL-USER> *readtable*
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)))"

[Attila Lendvai]

Post by Faré

Post by Anton Vodonosov
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).
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Ultimately, man should not ask what the meaning of his life is, but
rather must recognize that it is *he* who is asked. In a word, each
man is questioned by life; and he can only answer to life by
*answering for* his own life; to life he can only respond by being
responsible.”
— Viktor E. Frankl (1905–1997), 'Man's Search for Meaning' (1946)