Testing for ASDF 3.3.2 and beyond?

[Robert Goldman]

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> 
>> 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>
>> 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>:
>>> 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
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20180214/f1406919/attachment.html>