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