<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">I'm reviewing the tests now.</p>

<p dir="auto">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.</p>

<p dir="auto">ECL seems like you are saying that lisp-executable is simply incompatible with the new ASDF, so we can ignore that.</p>

<p dir="auto">The ACL failure on type-i.test seems to be pretty much a failure <em>without</em> 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.</p>

<p dir="auto">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.  </p>

<p dir="auto">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.</p>

<p dir="auto">So maybe we are good to go.</p>

<p dir="auto">R</p>

<p dir="auto">On 16 Feb 2018, at 13:01, Faré wrote:</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Anton,<br>
<br>
thanks a lot for the test! asdf 3.3.1.3 looks good to go.<br>
<br>
Robert,<br>
<br>
I had no trouble loading clws or lime with clisp, cl-rrt or<br>
cl-sat.minisat.test or inner-conditional-test with sbcl (using asdf<br>
3.3.1.3 from master).<br>
<br>
The ecl failures I could reproduce, but I'm not worried, as<br>
lisp-executable is not supported with recent asdf, and a reproducible<br>
out-of-memory error on one system :trivia.balland2006.enabled.test<br>
isn't outrageous.<br>
<br>
CL_SOURCE_REGISTRY='(:source-registry<br>
:ignore-inherited-configuration)' rlwrap clisp -I -x "(and '(#.(load<br>
\"/home/fare/cl/asdf/build/asdf.lisp\") #.(in-package :asdf)<br>
#.(upgrade-asdf) #.(load \"~/quicklisp/setup.lisp\") #.(ql:quickload<br>
:clws)) ())"<br>
CL_SOURCE_REGISTRY='(:source-registry<br>
:ignore-inherited-configuration)' rlwrap clisp -I -x "(and '(#.(load<br>
\"/home/fare/cl/asdf/build/asdf.lisp\") #.(in-package :asdf)<br>
#.(upgrade-asdf) #.(load \"~/quicklisp/setup.lisp\") #.(ql:quickload<br>
:lime)) ())"<br>
<br>
CL_SOURCE_REGISTRY='(:source-registry<br>
:ignore-inherited-configuration)' rlwrap sbcl --eval "(and '(#.(load<br>
\"/home/fare/cl/asdf/build/asdf.lisp\") #.(in-package :asdf)<br>
#.(upgrade-asdf) #.(load \"~/quicklisp/setup.lisp\") #.(ql:quickload<br>
:cl-rrt)) ())"<br>
CL_SOURCE_REGISTRY='(:source-registry<br>
:ignore-inherited-configuration)' rlwrap sbcl --eval "(and '(#.(load<br>
\"/home/fare/cl/asdf/build/asdf.lisp\") #.(in-package :asdf)<br>
#.(upgrade-asdf) #.(load \"~/quicklisp/setup.lisp\") #.(ql:quickload<br>
:cl-sat.minisat.test )) ())"<br>
CL_SOURCE_REGISTRY='(:source-registry<br>
:ignore-inherited-configuration)' rlwrap sbcl --eval "(and '(#.(load<br>
\"/home/fare/cl/asdf/build/asdf.lisp\") #.(in-package :asdf)<br>
#.(upgrade-asdf) #.(load \"~/quicklisp/setup.lisp\") #.(ql:quickload<br>
:inner-conditional-test )) ())"<br>
<br>
CL_SOURCE_REGISTRY='(:source-registry<br>
:ignore-inherited-configuration)' rlwrap ecl --eval "'(#.(load<br>
\"/home/fare/cl/asdf/build/asdf.lisp\") #.(in-package :asdf)<br>
#.(upgrade-asdf) #.(load \"~/quicklisp/setup.lisp\") #.(ql:quickload<br>
:lisp-executable-example)#.(quit))"<br>
CL_SOURCE_REGISTRY='(:source-registry<br>
:ignore-inherited-configuration)' rlwrap ecl --eval "'(#.(load<br>
\"/home/fare/cl/asdf/build/asdf.lisp\") #.(in-package :asdf)<br>
#.(upgrade-asdf) #.(load \"~/quicklisp/setup.lisp\") #.(ql:quickload<br>
:trivia.balland2006.enabled.test )#.(quit))"<br>
<br>
Often failures in cl-test-grid are "just" the result of using too<br>
little memory, or batching system loads, or some other reason, and<br>
have to be retried.<br>
<br>
I can try to activate that Windows VM and run the all the tests there,<br>
if you want...<br>
<br>
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" style="color:#777">http://fare.tunes.org</a><br>
Pain is inevitable. Suffering is optional.<br>
<br>
<br>
<br>
On Fri, Feb 16, 2018 at 11:42 AM, Robert Goldman <rpgoldman@sift.net> wrote:</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">Thanks for sending that.  Had a quick look.  One nice thing is that there's<br>
a very limited number of regressions.  I'll look at those when I can.<br>
<br>
Faré: I didn't believe it was possible to downgrade ASDF, but we see this<br>
here in a couple of cases for ECL.  ECL is trying to reload "prebuilt-asdf".<br>
I think we can ignore these failures on ECL. They just should not do that,<br>
and it's not really and ASDF test failure if they load a conflicting version<br>
of ASDF, breaking our upgrade method.<br>
<br>
clisp I refuse to care about, since it's effectively abandonware, unless you<br>
are willing to build from source, which I am not.  Certainly clisp 2.49 is<br>
abandonware.k<br>
<br>
That leaves only the SBCL and ACL failures for us to worry about....  I'm<br>
pretty busy this weekend, but I will have a look.<br>
<br>
Best,<br>
Robert<br>
<br>
<br>
On 15 Feb 2018, at 22:11, Anton Vodonosov wrote:<br>
</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">Robert, what delay are you apologizing for? I'm aware only of the delay<br>
from my side. :)<br>
<br>
<br>
<br>
The results for ASDF 3.3.1.3:<br>
<<a href="https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html" style="color:#BBB">https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html</a>><br>
<br>
Lisps tested so far:<br>
<br>
<br>
<br>
abcl-1.5.0-fasl43-linux-x86<br>
<br>
acl-10.0s-linux-x86<br>
<br>
ccl-1.11-r16635-f96-linux-x86<br>
<br>
clisp-2.49-unix-x86<br>
<br>
ecl-16.1.2-unknown-linux-x86-bytecode<br>
<br>
ecl-16.1.2-unknown-linux-x86-lisp-to-c<br>
<br>
sbcl-1.3.21-linux-x86<br>
<br>
<br>
<br>
Best regards,<br>
<br>
\- Anton<br>
<br>
<br>
<br>
<br>
<br>
14.02.2018, 22:02, "Robert Goldman" <rpgoldman@sift.net>:<br>
</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">OK, as I said, sorry about the delay. Anton, in place of Fare's #3 below,<br>
will you please just test what's in the<br>
`syntax-control-based-on-standard-syntax` branch? The comparison between 2<br>
and 3 will tell us to what extent it's an issue to lock in standard syntax<br>
instead of whatever happens to be the current readtable when ASDF is loaded.<br>
<br>
Thanks!<br>
 r<br>
<br>
On 13 Feb 2018, at 22:36, Robert P. Goldman wrote:<br>
</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">I'll get you a branch with the other setting for the syntax control, so<br>
you can just test with that instead of having to modify anything yourself.<br>
I'll get it pushed sometime tomorrow.</p>
</blockquote><p dir="auto"> Sorry for the delay.<br>
<br>
 Sent from my iPad</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">On Feb 13, 2018, at 20:15, Anton Vodonosov<br>
<[avodonosov@yandex.ru](<<a href="mailto:avodonosov@yandex.ru" style="color:#BBB">mailto:avodonosov@yandex.ru</a>>)> wrote:</p>
</blockquote></blockquote><p dir="auto"> Faré, hello.<br>
<br>
 Sorry for replying so long - I'm almost paralyzed by too many things I<br>
need to deal with currently.<br>
 I've started tests for the following commit. Will follow-up with the<br>
results.<br>
<br>
 commit 2a5bc3bece8f97fdf64dc73a4e0544a55ae38f9d<br>
 Author: Robert P. Goldman<br>
<[rpgoldman@sift.net](<<a href="mailto:rpgoldman@sift.net" style="color:#BBB">mailto:rpgoldman@sift.net</a>>)><br>
 Date: Tue Jan 16 16:20:15 2018 -0600<br>
<br>
 Bump version to 3.3.1.3<br>
<br>
<br>
<br>
 02.02.2018, 23:06, "Faré"<br>
<[fahree@gmail.com](<<a href="mailto:fahree@gmail.com" style="color:#BBB">mailto:fahree@gmail.com</a>>)>:<br>
</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">Dear Anton,</p>
</blockquote></blockquote></blockquote><p dir="auto"> can you run the below tests, in order or priority?<br>
<br>
 1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a<br>
 release candidate for 3.3.2? It has been too long since 3.3.1 was<br>
 released with several bugs that have impacted Quicklisp users.<br>
<br>
 2- Can you test what is currently in the syntax-control branch as a<br>
 release candidate for 3.3.3 or 3.4.0? We want to merge syntax control,<br>
 but it's a significant enough change that we don't want it at the same<br>
 time as the bug fixes. Also...<br>
<br>
 3- Can you test what is currently in the syntax-control branch as a<br>
 release candidate for 3.3.3 or 3.4.0, but with the following addition<br>
 just after you load asdf but before you start using it: (defparameter<br>
 uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see<br>
 what breaks if we disable extensions implementation-specific reader<br>
 extensions. Test most important on CCL. I don't expect much breakage<br>
 on other implementations, but it may exist, too.<br>
<br>
 4- While you're at it, can you also run the test, at least on sbcl,<br>
 with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*))<br>
 ? This will detect what breaks when we make the default readtable<br>
 read-only.<br>
<br>
 The thing is, we really want to have this syntax control, but we also<br>
 want to preserve backward compatibility, and we can't make asdf<br>
 stricter until every client is fixed (famous last word; of course we<br>
 failed at exactly that in 3.3.1 — we could build correctly, but would<br>
 also spuriously rebuild if secondary systems were misnamed; fixed in<br>
 3.3.1.3).<br>
<br>
<br>
<<a href="https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-control.md" style="color:#BBB">https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-control.md</a>><br>
 <<a href="https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86" style="color:#BBB">https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86</a>><br>
 <<a href="http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html" style="color:#BBB">http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html</a>><br>
<br>
 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•<br>
[<a href="http://fare.tunes.org" style="color:#BBB">http://fare.tunes.org</a>](<<a href="http://fare.tunes.org/" style="color:#BBB">http://fare.tunes.org/</a>>)<br>
 A friend once asked me if I had ever considered terrorism as a means for<br>
 political change. I replied that yes, I had considered it... and<br>
rejected it.<br>
 Because it only causes change for the worse.<br>
 Killing innocent people does not promote a culture of peaceful<br>
interaction.<br>
<br>
</p>
</blockquote></blockquote></blockquote></blockquote></div>
<div style="white-space:normal">

<p dir="auto">Robert P. Goldman<br>
Research Fellow<br>
Smart Information Flow Technologies (d/b/a SIFT, LLC)</p>

<p dir="auto">319 N. First Ave., Suite 400<br>
Minneapolis, MN 55401</p>

<p dir="auto">Voice:    (612) 326-3934<br>
Email:    <a href="mailto:rpgoldman@SIFT.net" style="color:#3983C4">rpgoldman@SIFT.net</a></p>
</div>
</div>
</body>
</html>