Testing for ASDF 3.3.2 and beyond?

Fri Feb 16 19:01:41 UTC 2018

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 at 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 at 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 at yandex.ru](<mailto:avodonosov at 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 at sift.net](<mailto:rpgoldman at 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 at gmail.com](<mailto:fahree at 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.
>>>
>>>
>