Re: Testing for ASDF 3.3.2 and beyond?

[Anton Vodonosov]

02.03.2018, 21:05, "Robert Goldman" :

>> You might be interested to know that ACL binds *readtable* on startup 
>> to an unmodifieble readtable
>> (which is a violation of CLHS http://clhs.lisp.se/Body/02_aac.htm :
>> "The initial readtable is distinct from the standard readtable. It is 
>> permissible for a conforming program to modify the initial 
>> readtable.")
>
> I don't see this behavior in ACL 10.1 (64 bit) on the Mac:
> 
> 
> CL-USER> *readtable*
> #
> CL-USER> (defun semicolon-reader (stream char)
> (declare (ignore char))
> ;; First swallow the rest of the current input line.
> ;; End-of-file is acceptable for terminating the comment.
> (do () ((char= (read-char stream nil #\Newline t) #\Newline)))
> ;; Return zero values.
> (values))
> SEMICOLON-READER
> CL-USER> (set-macro-character #\; #'semicolon-reader)
> T
> CL-USER>


Turns out this only happens when your code is evaluated via the -ee parameter 
with -batch parameter preset:

 ~/lisps/acl100/alisp -batch -ee "(set-dispatch-macro-character #\# #\u 
#'(lambda ( ignored)))"


An unhandled error occurred during initialization:
An error occurred
(Attempt to set dispatch macro in system readtable #; copy readtable first.)
during
the reading or evaluation of -e "(set-dispatch-macro-character #\\# #\\u 
#'(lambda ( ignored)))"

Re: Testing for ASDF 3.3.2 and beyond?

[Anton Vodonosov]

17.03.2018, 21:52, "Robert Goldman" :
> Thank you very much, Anton. Question: is the inner-conditional-test
> failure on SBCL 1.3.21 not a regression? 

Not a regression. Heap Exhausted often happens on SBCL for that library:
https://common-lisp.net/project/cl-test-grid/library/inner-conditional.html

That's a problem of SBCL's conservative garbage collector - it doesn't always
recognizes garbage that may be collected, thus exhausting heap.

>
> What about reversi on CCL 1.9? I guess if I understand correctly,
> reversi must have passed on CCL 1.10 and 1.11, so probably I shouldn't
> worry about this, either.

This error happens only with the presence of the new ASDF, but it's low-level
memory access level, thus it's, in any case, an error in CCL rather than
in ASDF lisp code. 

For the record, it's easy to reproduce this way (the failure happens about 80% 
of time): 

$ rm -rf /home/testgrid/.cache/common-lisp/ && rlwrap 
/home/testgrid/lisps/ccl-1.9/lx86cl --no-init --load 
/home/testgrid/quicklisp-asdf3/setup.lisp --eval '(ql:quickload :reversi)' 
--eval '(ccl:quit)'


And it only happens in CCL 1.9. Since 1.10 the error doesn't reproduce.
So no worries for ASDF developers.


>
> On 17 Mar 2018, at 7:51, Anton Vodonosov wrote:
>
>>  Results for these lisps:
>>
>>  abcl-1.5.0-fasl43-linux-x86
>>  ccl-1.10-r16196-f96-linux-x86
>>  ccl-1.11-r16635-f96-linux-x86
>>  ccl-1.9-r15756-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.1.16-linux-x86
>>  sbcl-1.3.21-linux-x86
>>
>>  show no regressions.
>>
>>  ACL tests are running - needed to re-run them because licence refresh
>>  was needed.
>>
>>  The report:
>>  https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
>>
>>  Best regards,
>>  - Anton
>>
>>  13.03.2018, 16:53, "Anton Vodonosov" :
>>>  I've started tests for 3.3.1.7
>>>
>>>  11.03.2018, 06:11, "Faré" :
   Dear Anton,

   can you try your test suite again against 3.3.1.7 ? I think we're
   mostly ready to release 3.3.2 this time, with its many bugs fixes
  (and
   bug fix fixes).

   Can you also try the branch made by Robert for syntax-control + a
  copy
   of the standard readtable as default?

   —♯ƒ • François-René ÐVB Rideau
  •Reflection• http://fare.tunes.org
   Wir Mathematiker sind alle ein bisschen meschugge.
   (We mathematicans are all a bit crazy). — Lev Landau

Re: Testing for ASDF 3.3.2 and beyond?

[Faré]

On Sat, Mar 17, 2018 at 2:52 PM, Robert Goldman  wrote:
> Thank you very much, Anton.  Question: is the inner-conditional-test failure
> on SBCL 1.3.21 not a regression?  I just loaded this system and tested it on
> my mac with SBCL 1.4.3, and it worked fine, so I'm inclined to treat this is
> not a problem.  Also, the inner conditional system has a readme saying it's
> not maintained and please not to use it.
>
> What about reversi on CCL 1.9?  I guess if I understand correctly, reversi
> must have passed on CCL 1.10 and 1.11, so probably I shouldn't worry about
> this, either.
>
> Fare, what do you think?  Should I release this version, or wait a little
> longer and see if we can get the syntax fix in, as well?
>
I think we're good for 3.3.2. There are often a few non-reproducible
failures and failures on older implementations, and I see nothing
worrisome there, even though I haven't tried to rerun the crashes and
timeouts in case their work the second time around.

> Maybe I should release this as 3.3.2, and make the syntax-fixed version of
> ASDF be 3.4, since (for some people) it might be a bigger change.
>
Yes, that might be prudent.

When you make a 3.4, be sure to test cl-test-grid with a branch that
includes the version update, because that's how you'll find problems
with deprecated functions (for which you should make sure to bump the
expiration date properly).

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
Whatever is worth doing at all is worth doing well.  — Chesterfield

Re: Testing for ASDF 3.3.2 and beyond?

[Robert Goldman]

Thank you very much, Anton.  Question: is the inner-conditional-test 
failure on SBCL 1.3.21 not a regression?  I just loaded this system and 
tested it on my mac with SBCL 1.4.3, and it worked fine, so I'm inclined 
to treat this is not a problem.  Also, the inner conditional system has 
a readme saying it's not maintained and please not to use it.


What about reversi on CCL 1.9?  I guess if I understand correctly, 
reversi must have passed on CCL 1.10 and 1.11, so probably I shouldn't 
worry about this, either.


Fare, what do you think?  Should I release this version, or wait a 
little longer and see if we can get the syntax fix in, as well?


Maybe I should release this as 3.3.2, and make the syntax-fixed version 
of ASDF be 3.4, since (for some people) it might be a bigger change.


Best,
r



On 17 Mar 2018, at 7:51, Anton Vodonosov wrote:


Results for these lisps:

abcl-1.5.0-fasl43-linux-x86
ccl-1.10-r16196-f96-linux-x86
ccl-1.11-r16635-f96-linux-x86
ccl-1.9-r15756-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.1.16-linux-x86
sbcl-1.3.21-linux-x86

show no regressions.

ACL tests are running - needed to re-run them because licence refresh 
was needed.


The report: 
https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html


Best regards,
- Anton

13.03.2018, 16:53, "Anton Vodonosov" :

I've started tests for 3.3.1.7

11.03.2018, 06:11, "Faré" :

 Dear Anton,

 can you try your test suite again against 3.3.1.7 ? I think we're
 mostly ready to release 3.3.2 this time, with its many bugs fixes 
(and

 bug fix fixes).

 Can you also try the branch made by Robert for syntax-control + a 
copy

 of the standard readtable as default?

 —♯ƒ • François-René ÐVB Rideau 
•Reflection• http://fare.tunes.org

 Wir Mathematiker sind alle ein bisschen meschugge.
 (We mathematicans are all a bit crazy). — Lev Landau

Re: Testing for ASDF 3.3.2 and beyond?

[Anton Vodonosov]

Yez, it is 3.3.1.717.03.2018, 17:38, "Robert P. Goldman" :Sorry. That was meant to be "master," not matter.Sent from my iPad On Mar 17, 2018, at 09:36, Robert P. Goldman  wrote: Just to be clear: this is matter, right? It's not one of the syntax control branches? Sent from my iPad On Mar 17, 2018, at 07:51, Anton Vodonosov  wrote: Results for these lisps: abcl-1.5.0-fasl43-linux-x86 ccl-1.10-r16196-f96-linux-x86 ccl-1.11-r16635-f96-linux-x86 ccl-1.9-r15756-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.1.16-linux-x86 sbcl-1.3.21-linux-x86 show no regressions. ACL tests are running - needed to re-run them because licence refresh was needed. The report: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-… Best regards, - Anton 13.03.2018, 16:53, "Anton Vodonosov" : I've started tests for 3.3.1.7 11.03.2018, 06:11, "Faré" : Dear Anton, can you try your test suite again against 3.3.1.7 ? I think we're mostly ready to release 3.3.2 this time, with its many bugs fixes (and bug fix fixes). Can you also try the branch made by Robert for syntax-control + a copy of the standard readtable as default? —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org Wir Mathematiker sind alle ein bisschen meschugge. (We mathematicans are all a bit crazy). — Lev Landau

Re: Testing for ASDF 3.3.2 and beyond?

[Robert P. Goldman]

Sorry. That was meant to be "master," not matter.

Sent from my iPad

> On Mar 17, 2018, at 09:36, Robert P. Goldman  wrote:
> 
> Just to be clear: this is matter, right? It's not one of the syntax control 
> branches?
> 
> Sent from my iPad
> 
>> On Mar 17, 2018, at 07:51, Anton Vodonosov  wrote:
>> 
>> Results for these lisps:
>> 
>> abcl-1.5.0-fasl43-linux-x86
>> ccl-1.10-r16196-f96-linux-x86
>> ccl-1.11-r16635-f96-linux-x86
>> ccl-1.9-r15756-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.1.16-linux-x86
>> sbcl-1.3.21-linux-x86
>> 
>> show no regressions.
>> 
>> ACL tests are running - needed to re-run them because licence refresh was 
>> needed.
>> 
>> The report: 
>> https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
>> 
>> Best regards,
>> - Anton
>> 
>> 13.03.2018, 16:53, "Anton Vodonosov" :
>>> I've started tests for 3.3.1.7
>>> 
>>> 11.03.2018, 06:11, "Faré" :
 Dear Anton,
 
 can you try your test suite again against 3.3.1.7 ? I think we're
 mostly ready to release 3.3.2 this time, with its many bugs fixes (and
 bug fix fixes).
 
 Can you also try the branch made by Robert for syntax-control + a copy
 of the standard readtable as default?
 
 —♯ƒ • François-René ÐVB Rideau •Reflection• 
 http://fare.tunes.org
 Wir Mathematiker sind alle ein bisschen meschugge.
 (We mathematicans are all a bit crazy). — Lev Landau
>> 
> 
> 

Re: Testing for ASDF 3.3.2 and beyond?

[Robert P. Goldman]

Just to be clear: this is matter, right? It's not one of the syntax control 
branches?

Sent from my iPad

> On Mar 17, 2018, at 07:51, Anton Vodonosov  wrote:
> 
> Results for these lisps:
> 
> abcl-1.5.0-fasl43-linux-x86
> ccl-1.10-r16196-f96-linux-x86
> ccl-1.11-r16635-f96-linux-x86
> ccl-1.9-r15756-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.1.16-linux-x86
> sbcl-1.3.21-linux-x86
> 
> show no regressions.
> 
> ACL tests are running - needed to re-run them because licence refresh was 
> needed.
> 
> The report: 
> https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html
> 
> Best regards,
> - Anton
> 
> 13.03.2018, 16:53, "Anton Vodonosov" :
>> I've started tests for 3.3.1.7
>> 
>> 11.03.2018, 06:11, "Faré" :
>>>  Dear Anton,
>>> 
>>>  can you try your test suite again against 3.3.1.7 ? I think we're
>>>  mostly ready to release 3.3.2 this time, with its many bugs fixes (and
>>>  bug fix fixes).
>>> 
>>>  Can you also try the branch made by Robert for syntax-control + a copy
>>>  of the standard readtable as default?
>>> 
>>>  —♯ƒ • François-René ÐVB Rideau •Reflection• 
>>> http://fare.tunes.org
>>>  Wir Mathematiker sind alle ein bisschen meschugge.
>>>  (We mathematicans are all a bit crazy). — Lev Landau
> 

Re: Testing for ASDF 3.3.2 and beyond?

[Anton Vodonosov]

Results for these lisps:

abcl-1.5.0-fasl43-linux-x86
ccl-1.10-r16196-f96-linux-x86
ccl-1.11-r16635-f96-linux-x86
ccl-1.9-r15756-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.1.16-linux-x86
sbcl-1.3.21-linux-x86

show no regressions.

ACL tests are running - needed to re-run them because licence refresh was 
needed.

The report: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-73.html

Best regards,
- Anton

13.03.2018, 16:53, "Anton Vodonosov" :
> I've started tests for 3.3.1.7
>
> 11.03.2018, 06:11, "Faré" :
>>  Dear Anton,
>>
>>  can you try your test suite again against 3.3.1.7 ? I think we're
>>  mostly ready to release 3.3.2 this time, with its many bugs fixes (and
>>  bug fix fixes).
>>
>>  Can you also try the branch made by Robert for syntax-control + a copy
>>  of the standard readtable as default?
>>
>>  —♯ƒ • François-René ÐVB Rideau •Reflection• 
>> http://fare.tunes.org
>>  Wir Mathematiker sind alle ein bisschen meschugge.
>>  (We mathematicans are all a bit crazy). — Lev Landau

Re: Testing for ASDF 3.3.2 and beyond?

[Faré]

Dear Anton,

can you try your test suite again against 3.3.1.7 ? I think we're
mostly ready to release 3.3.2 this time, with its many bugs fixes (and
bug fix fixes).

Can you also try the branch made by Robert for syntax-control + a copy
of the standard readtable as default?

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
Wir Mathematiker sind alle ein bisschen meschugge.
(We mathematicans are all a bit crazy). — Lev Landau

Re: Testing for ASDF 3.3.2 and beyond?

[Faré]

On Fri, Mar 2, 2018 at 1:05 PM, Robert Goldman  wrote:
> So as I see it we have three options for the *shared-readtable*
>
> Your original option -- the "initial-ish" readtable (since we can't control
> when ASDF is loaded)
Usually ASDF is loaded before any significant other software is. If
the user insists in modifying the initial readtable early, he's
probably on to something.

> My proposal: a copy of the standard readtable. We should consider what might
> happen in this case if ASDF is reloaded or upgraded. I don't know if option
> #1 has this same issue.
In either case, definitely use defvar rather than defparameter, unless
you're also going to clear-registered-systems at every update.

> An unmodifiable standard readtable. I don't believe that this is portably
> possible, is it? There's no ANSI method (unless I've overlooked something)
> to make a readtable unmodifiable, and there's no way to access the standard
> readtable portably (since it isn't required to be unique).
>
It's not portable for unmodifiability to be enforced, but it's
certainly non-conformant to try to modify even when the
implementations fails silently later rather than catches you
immediately. So far as I know, only SBCL, ECL, Allegro, CMUCL make it
unmodifiable. Maybe file bugs for other relevant implementations?

> I believe my proposal, #2, is the most portable of all of the solutions, but
> I am still open to correction.
>
For some definition of "portable". I know that some systems rely on
e.g. CCL or MCL extensions #$ or #_ — but they could be made to use
the *initial-readtable* that we definitely are going to save anyway.

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
A good answer is one that solves the asker's problem,
not one that (necessarily) fits his expectations.
Actually, if the asker has been seriously looking for a solution,
and did not find any, then there's a good deal of chance
that a good answer won't fit his expectations! (At least, not all of them.)

Re: Testing for ASDF 3.3.2 and beyond?

[Robert Goldman]

On 1 Mar 2018, at 21:45, Faré wrote:

You might be interested to know that ACL binds *readtable* on startup 
to an unmodifieble readtable

(which is a violation of CLHS http://clhs.lisp.se/Body/02_aac.htm :
"The initial readtable is distinct from the standard readtable. It is 
permissible for a conforming program to modify the initial 
readtable.")


I don't see this behavior in ACL 10.1 (64 bit) on the Mac:

```
CL-USER> *readtable*
#
CL-USER> (defun semicolon-reader (stream char)
   (declare (ignore char))
   ;; First swallow the rest of the current input line.
   ;; End-of-file is acceptable for terminating the comment.
   (do () ((char= (read-char stream nil #\Newline t) #\Newline)))
   ;; Return zero values.
   (values))
SEMICOLON-READER
CL-USER> (set-macro-character #\; #'semicolon-reader)
T
CL-USER>
```



The most visible result of this is puri and more than 150 other 
systems in Quicklisp depending on it, failing to load.




Well, that's a good argument for fixing puri & al, regardless of what
option ASDF picks in the future.
And maybe a good argument for making ASDF strict all the time on all
implementations that allow it.


So as I see it we have *three* options for the `*shared-readtable*`

1. Your original option -- the "initial-ish" readtable (since we can't 
control when ASDF is loaded)
2. My proposal: a copy of the standard readtable.  We should consider 
what might happen in this case if ASDF is reloaded or upgraded.  I don't 
know if option #1 has this same issue.
3.  An unmodifiable standard readtable.  I don't believe that this is 
portably possible, is it?  There's no ANSI method (unless I've 
overlooked something) to make a readtable unmodifiable, and there's no 
way to access the standard readtable portably (since it isn't required 
to be unique).


I believe my proposal, #2, is the most portable of all of the solutions, 
but I am still open to correction.


Best,
r

Re: Testing for ASDF 3.3.2 and beyond?

[Attila Lendvai]

>> There is no batch loading, each test is run in a fresh CL process.
>>
> Interesting. The memory load might still be sensitive to compilation
> order, if you reuse fasls shared with previous builds versus rebuild
> new ones.

it can help on SBCL to insert (sb-ext:gc :full t) to a few key places,
like after operations that generate a lot of garbage (e.g. compilation).

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Ultimately, man should not ask what the meaning of his life is, but
rather must recognize that it is *he* who is asked. In a word, each
man is questioned by life; and he can only answer to life by
*answering for* his own life; to life he can only respond by being
responsible.”
— Viktor E. Frankl (1905–1997), 'Man's Search for Meaning' (1946)

Re: Testing for ASDF 3.3.2 and beyond?

[Faré]

>> Maybe it's an artefact of SBCL using too much memory *while compiling*
>> and would go away if you used e.g. POIU to compile inside forks.
>
> How?
>
"Just" load POIU right after you load ASDF, and before you load anything else.
https://gitlab.common-lisp.net/qitab/poiu

> The test order is alphabetical (by projects, and then inside a project
> its ASDF systems are sorted alphabetically too).
>
> Fasls compiled by previous tests are reused by next tests.
>
OK, this *might* explain some cases of "succeeds the second time around".
I suggest always making a second try after a timeout or out-of-memory error.

> Yes, I plan to start syntax-control testing soon.
>
Thanks!

> You might be interested to know that ACL binds *readtable* on startup to an 
> unmodifieble readtable
> (which is a violation of CLHS http://clhs.lisp.se/Body/02_aac.htm :
> "The initial readtable is distinct from the standard readtable. It is 
> permissible for a conforming program to modify the initial readtable.")
>
> The most visible result of this is puri and more than 150 other systems in 
> Quicklisp depending on it, failing to load.
>
Well, that's a good argument for fixing puri & al, regardless of what
option ASDF picks in the future.
And maybe a good argument for making ASDF strict all the time on all
implementations that allow it.

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
Death is only a milestone — albeit one that is dropped on you
from a very great height
— Terry Pratchett.

Re: Testing for ASDF 3.3.2 and beyond?

[Anton Vodonosov]

02.03.2018, 05:33, "Faré" :
>>>  Often failures in cl-test-grid are "just" the result of using too
>>>  little memory,
>>
>>  not little memory, but SBCL's conservative (i.e. imprecise) garbage
>>  collection - it doesn't always recognize that an object is a garbage.
>>
>>  I saw cases where CCL compiles a project under a 100MB heap,
>>  while SBCL reproducibly runs out of 1GB heap.
>
> Maybe it's an artefact of SBCL using too much memory *while compiling*
> and would go away if you used e.g. POIU to compile inside forks.

How?

>
>>>  or batching system loads,
>>
>>  There is no batch loading, each test is run in a fresh CL process.
>
> Interesting. The memory load might still be sensitive to compilation
> order, if you reuse fasls shared with previous builds versus rebuild
> new ones.

The test order is alphabetical (by projects, and then inside a project
its ASDF systems are sorted alphabetically too).

Fasls compiled by previous tests are reused by next tests.


>
>>>  or some other reason, and
>>>  have to be retried.
>>
>>  I would put it differently: some failures may be ignored because
>>  on the previous version they were successful by a chance,
>>  and could faile the same way too.
>
> OK.
>
> PS: The newer test results look good. I'd like to see the results with
> the syntax-control branch, though. There also are a few minor bug
> fixes in the pipe that mean we'll have to re-test before release,
> anyway.
>

Yes, I plan to start syntax-control testing soon. 

You might be interested to know that ACL binds *readtable* on startup to an 
unmodifieble readtable
(which is a violation of CLHS http://clhs.lisp.se/Body/02_aac.htm : 
"The initial readtable is distinct from the standard readtable. It is 
permissible for a conforming program to modify the initial readtable.")

The most visible result of this is puri and more than 150 other systems in 
Quicklisp depending on it, failing to load.

Another hint: when you review test results, it might be helpful
to see how particular library is built in other implementations and in the 
previous Quicklisp.
Here you can find such build results for every library:
https://common-lisp.net/project/cl-test-grid/library/

Best regards,
- Anton

Re: Testing for ASDF 3.3.2 and beyond?

[Robert Goldman]

On 1 Mar 2018, at 20:33, Faré wrote:

> PS: The newer test results look good. I'd like to see the results with
> the syntax-control branch, though. There also are a few minor bug
> fixes in the pipe that mean we'll have to re-test before release,
> anyway.

Concur...

Re: Testing for ASDF 3.3.2 and beyond?

[Anton Vodonosov]

I updated the report with the rest of the results. The lisps tested:

abcl-1.5.0-fasl43-linux-x86
acl-10.0-linux-x86
acl-10.0m-linux-x86
acl-10.0ms-linux-x86
acl-10.0s-linux-x86
ccl-1.10-r16196-f96-linux-x86
ccl-1.11-r16635-f96-linux-x86
ccl-1.9-r15756-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.1.16-linux-x86
sbcl-1.3.21-linux-x86

https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-72.html

Re: Testing for ASDF 3.3.2 and beyond?

[Anton Vodonosov]

16.02.2018, 22:02, "Faré" :
>
> Often failures in cl-test-grid are "just" the result of using too
> little memory, 

not little memory, but SBCL's conservative (i.e. imprecise) garbage
collection - it doesn't always recognize that an object is a garbage.

I saw cases where CCL compiles a project under a 100MB heap,
while SBCL reproducibly runs out of 1GB heap.


> or batching system loads, 

There is no batch loading, each test is run in a fresh CL process.

> or some other reason, and
> have to be retried.

I would put it differently: some failures may be ignored because
on the previous version they were successful by a chance,
and could faile the same way too.

Re: Testing for ASDF 3.3.2 and beyond?

[Robert Goldman]

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• 
http://fare.tunes.org

Pain is inevitable. Suffering is optional.



On Fri, Feb 16, 2018 at 11:42 AM, Robert Goldman  
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:


Lisps tested so far:



abcl-1.5.0-fasl43-linux-x86

acl-10.0s-linux-x86

ccl-1.11-r16635-f96-linux-x86

Re: Testing for ASDF 3.3.2 and beyond?

[Faré]

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• http://fare.tunes.org
Pain is inevitable. Suffering is optional.



On Fri, Feb 16, 2018 at 11:42 AM, Robert Goldman  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:
>> 
>>
>> 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" :
>>
>>> 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
> 

Re: Testing for ASDF 3.3.2 and beyond?

[Robert Goldman]

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: 



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" :

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]()> 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]()>

 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]()>:



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

 

 
 

 —♯ƒ • François-René ÐVB Rideau 
•Reflection• 
[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.

Re: Testing for ASDF 3.3.2 and beyond?

[Anton Vodonosov]

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.htmlLisps tested so far: abcl-1.5.0-fasl43-linux-x86acl-10.0s-linux-x86ccl-1.11-r16635-f96-linux-x86clisp-2.49-unix-x86ecl-16.1.2-unknown-linux-x86-bytecodeecl-16.1.2-unknown-linux-x86-lisp-to-csbcl-1.3.21-linux-x86 Best regards,- Anton  14.02.2018, 22:02, "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!rOn 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 iPadOn Feb 13, 2018, at 20:15, Anton Vodonosov  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 2a5bc3bece8f97fdf64dc73a4e0544a55ae38f9dAuthor: Robert P. Goldman Date: Tue Jan 16 16:20:15 2018 -0600Bump version to 3.3.1.302.02.2018, 23:06, "Faré" :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 arelease candidate for 3.3.2? It has been too long since 3.3.1 wasreleased with several bugs that have impacted Quicklisp users.2- Can you test what is currently in the syntax-control branch as arelease 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 sametime as the bug fixes. Also...3- Can you test what is currently in the syntax-control branch as arelease candidate for 3.3.3 or 3.4.0, but with the following additionjust after you load asdf but before you start using it: (defparameteruiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to seewhat breaks if we disable extensions implementation-specific readerextensions. Test most important on CCL. I don't expect much breakageon 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 readtableread-only.The thing is, we really want to have this syntax control, but we alsowant to preserve backward compatibility, and we can't make asdfstricter until every client is fixed (famous last word; of course wefailed at exactly that in 3.3.1 — we could build correctly, but wouldalso spuriously rebuild if secondary systems were misnamed; fixed in3.3.1.3).https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-control.mdhttps://gitlab.common-lisp.net/asdf/asdf/merge_requests/86http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.orgA friend once asked me if I had ever considered terrorism as a means forpolitical 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. 

Re: 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  
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 
Date:   Tue Jan 16 16:20:15 2018 -0600

   Bump version to 3.3.1.3



02.02.2018, 23:06, "Faré" :

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

Re: Testing for ASDF 3.3.2 and beyond?

[Robert P. Goldman]

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  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 
> Date:   Tue Jan 16 16:20:15 2018 -0600
> 
>Bump version to 3.3.1.3
> 
> 
> 
> 02.02.2018, 23:06, "Faré" :
>> 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• 
>> 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.

Re: Testing for ASDF 3.3.2 and beyond?

[Anton Vodonosov]

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 
Date:   Tue Jan 16 16:20:15 2018 -0600

Bump version to 3.3.1.3



02.02.2018, 23:06, "Faré" :
> 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• 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.