Testing for ASDF 3.3.2 and beyond?

Mon Feb 19 23:44:41 UTC 2018

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

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 at SIFT.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20180219/33bddbb3/attachment-0001.html>