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 <rpgold...@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" <rpgold...@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
<[avodono...@yandex.ru](<mailto:avodono...@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
<[rpgold...@sift.net](<mailto:rpgold...@sift.net>)>
Date: Tue Jan 16 16:20:15 2018 -0600
Bump version to 3.3.1.3
02.02.2018, 23:06, "Faré"
<[fah...@gmail.com](<mailto:fah...@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](<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: rpgold...@sift.net
