Looks like SBCL 1.4.7 changed the slots of sb-c::compiler-error-context (in particular enclosing-source -> %enclosing-source, source -> %source, and original-source was removed). As a result, deferred warnings are broken. Attached is the output of `./run-tests.sh sbcl test-deferred-warnings.script`
-Eric
Oops. Can you provide a patch? If possible one that uses #. to test what symbols are present and does the right thing? There are a few examples of #+sbcl #.( in filesystem.lisp and image.lisp.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Government — If you think the problems we create are bad, just wait until you see our solutions.
On Tue, May 29, 2018 at 11:51 PM Eric Timmons etimmons@mit.edu wrote:
Looks like SBCL 1.4.7 changed the slots of sb-c::compiler-error-context (in particular enclosing-source -> %enclosing-source, source -> %source, and original-source was removed). As a result, deferred warnings are broken. Attached is the output of `./run-tests.sh sbcl test-deferred-warnings.script`
-Eric
On 29 May 2018, at 22:51, Eric Timmons wrote:
Looks like SBCL 1.4.7 changed the slots of sb-c::compiler-error-context (in particular enclosing-source -> %enclosing-source, source -> %source, and original-source was removed). As a result, deferred warnings are broken. Attached is the output of `./run-tests.sh sbcl test-deferred-warnings.script`
-Eric
Thanks for letting me know. Looks like there was a change to lazily compute some of these, and now there is an API to get their values, instead of directly poking into the structure.
I'll have a look at fixing this bug, ideally today.
If anyone knows how to identify SBCL version reliably, that would help. I see I can use `sb-ext:assert-version->=` but it claims to use subversion revision numbers, based on the manual, which suggests it's probably broken now. I guess I can use `version-satisfies` and `(uiop/os:lisp-version-string)` (which uses `lisp-implementation-version`).
Does anyone have any suggestions about testing against multiple versions of SBCL? This brings to a head a problem that has been pending for a long time -- how should I be keeping around old versions of lisp implementations so that I can check that a fix needed to handle a new release doesn't break an old one? I can try putting an extra version of SBCL into the linux box that runs the ASDF tests, but can't possibly do this for multiple different lisp implementations, nor can I handle more than a limited number of versions per implementation. Any suggestions very welcome.
Dave Cooper developed a partial solution for the multiple versions of Allegro, but only for the multiple *concurrent* versions. Similarly, I'm testing on only 64-bit CCL, not 32, etc.
[The irony of Stas B being the one who introduced this backward-incompatible change is not lost on me...]
On Wed, May 30, 2018 at 10:47 AM, Robert Goldman rpgoldman@sift.info wrote:
Does anyone have any suggestions about testing against multiple versions of SBCL? This brings to a head a problem that has been pending for a long time -- how should I be keeping around old versions of lisp implementations so that I can check that a fix needed to handle a new release doesn't break an old one? I can try putting an extra version of SBCL into the linux box that runs the ASDF tests, but can't possibly do this for multiple different lisp implementations, nor can I handle more than a limited number of versions per implementation. Any suggestions very welcome.
We've fully embraced Docker for this sort of thing. You can keep multiple versions of SBCL/CCL/etc. around as separate Docker images and then spin up a container with the code mounted into it for testing.
Somewhat related, I was curious why ASDF doesn't use Gitlab CI to automatically run tests. It probably wouldn't have helped in this particular case since the root cause was a change outside ASDF, but it's still nice for things like merge requests.
-Eric
On Wed, May 30, 2018 at 12:53 PM Eric Timmons etimmons@mit.edu wrote:
Somewhat related, I was curious why ASDF doesn't use Gitlab CI to automatically run tests. It probably wouldn't have helped in this particular case since the root cause was a change outside ASDF, but it's still nice for things like merge requests.
Well, there's about ten different scriptable implementations on three major platforms, plus multiple versions of each compiler and maybe extra architectures to test for some of them. And then there are the software licensing issues for those operating systems and the proprietary implementations. Finally, a complete test set would probably include non-regression with cl-test-grid.
Testing ASDF is a major undertaking. And even when all tests pass on all platforms, we have bad surprises, as demonstrated by the bumpy releases 3.2 and 3.3.
That said, even one image running tests on one implementation without cl-test-grid would be an obvious improvement over the current situation.
Not being the maintainer anymore, nor paid to do it anymore, not using it for work or for fun anymore, I'd say "patches welcome".
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The state is the coldest of all cold monsters. Coldly it lies, too; and this lie creeps from its mouth: "I, the state, am the people." — Nietzsche
I have just pushed a merge request and topic branch for this.
See https://gitlab.common-lisp.net/asdf/asdf/merge_requests/95
I'm pretty scared about this -- we are getting in there and rooting around in SBCL internals in ways that seem almost guaranteed to break again later. But for now, I think it's fixed.
Comments welcome -- especially comments involving a nicer rewrite of what I wrote.
Best, R
On 30 May 2018, at 12:13, Faré wrote:
On Wed, May 30, 2018 at 12:53 PM Eric Timmons etimmons@mit.edu wrote:
Somewhat related, I was curious why ASDF doesn't use Gitlab CI to automatically run tests. It probably wouldn't have helped in this particular case since the root cause was a change outside ASDF, but it's still nice for things like merge requests.
Well, there's about ten different scriptable implementations on three major platforms, plus multiple versions of each compiler and maybe extra architectures to test for some of them. And then there are the software licensing issues for those operating systems and the proprietary implementations. Finally, a complete test set would probably include non-regression with cl-test-grid.
Testing ASDF is a major undertaking. And even when all tests pass on all platforms, we have bad surprises, as demonstrated by the bumpy releases 3.2 and 3.3.
That said, even one image running tests on one implementation without cl-test-grid would be an obvious improvement over the current situation.
Not being the maintainer anymore, nor paid to do it anymore, not using it for work or for fun anymore, I'd say "patches welcome".
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The state is the coldest of all cold monsters. Coldly it lies, too; and this lie creeps from its mouth: "I, the state, am the people." — Nietzsche
Whoops. Looks like this doesn't work on older SBCLs. I'll fix that now.
R
On 30 May 2018, at 15:08, Robert Goldman wrote:
I have just pushed a merge request and topic branch for this.
See https://gitlab.common-lisp.net/asdf/asdf/merge_requests/95
I'm pretty scared about this -- we are getting in there and rooting around in SBCL internals in ways that seem almost guaranteed to break again later. But for now, I think it's fixed.
Comments welcome -- especially comments involving a nicer rewrite of what I wrote.
Best, R
On 30 May 2018, at 12:13, Faré wrote:
On Wed, May 30, 2018 at 12:53 PM Eric Timmons etimmons@mit.edu wrote:
Somewhat related, I was curious why ASDF doesn't use Gitlab CI to automatically run tests. It probably wouldn't have helped in this particular case since the root cause was a change outside ASDF, but it's still nice for things like merge requests.
Well, there's about ten different scriptable implementations on three major platforms, plus multiple versions of each compiler and maybe extra architectures to test for some of them. And then there are the software licensing issues for those operating systems and the proprietary implementations. Finally, a complete test set would probably include non-regression with cl-test-grid.
Testing ASDF is a major undertaking. And even when all tests pass on all platforms, we have bad surprises, as demonstrated by the bumpy releases 3.2 and 3.3.
That said, even one image running tests on one implementation without cl-test-grid would be an obvious improvement over the current situation.
Not being the maintainer anymore, nor paid to do it anymore, not using it for work or for fun anymore, I'd say "patches welcome".
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The state is the coldest of all cold monsters. Coldly it lies, too; and this lie creeps from its mouth: "I, the state, am the people." — Nietzsche
Also, if you fix reify-warnings, you may have to fix unreify-warnings with it. For a test, try to (uiop:enable-deferred-warnings-check) before you build software.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Passive hope is wishful thinking, a poison of the mind. Active hope is creative passion, the mover of the universe.
On Wed, May 30, 2018 at 4:12 PM Robert Goldman rpgoldman@sift.info wrote:
Whoops. Looks like this doesn't work on older SBCLs. I'll fix that now.
R
On 30 May 2018, at 15:08, Robert Goldman wrote:
I have just pushed a merge request and topic branch for this.
See https://gitlab.common-lisp.net/asdf/asdf/merge_requests/95
I'm pretty scared about this -- we are getting in there and rooting around in SBCL internals in ways that seem almost guaranteed to break again later. But for now, I think it's fixed.
Comments welcome -- especially comments involving a nicer rewrite of what I wrote.
Best, R
On 30 May 2018, at 12:13, Faré wrote:
On Wed, May 30, 2018 at 12:53 PM Eric Timmons etimmons@mit.edu wrote:
Somewhat related, I was curious why ASDF doesn't use Gitlab CI to automatically run tests. It probably wouldn't have helped in this particular case since the root cause was a change outside ASDF, but it's still nice for things like merge requests.
Well, there's about ten different scriptable implementations on three major platforms, plus multiple versions of each compiler and maybe extra architectures to test for some of them. And then there are the software licensing issues for those operating systems and the proprietary implementations. Finally, a complete test set would probably include non-regression with cl-test-grid.
Testing ASDF is a major undertaking. And even when all tests pass on all platforms, we have bad surprises, as demonstrated by the bumpy releases 3.2 and 3.3.
That said, even one image running tests on one implementation without cl-test-grid would be an obvious improvement over the current situation.
Not being the maintainer anymore, nor paid to do it anymore, not using it for work or for fun anymore, I'd say "patches welcome".
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The state is the coldest of all cold monsters. Coldly it lies, too; and this lie creeps from its mouth: "I, the state, am the people." — Nietzsche
AFAICT, `UNREIFY-WARNINGS` only `APPLY`s the SBCL constructor to stashed property list. So it's only the `REIFY` function that needs fixing.
I'm having a lot of difficulty figuring out exactly how to do the conditional compilation, though, because of ticklish issues about when, exactly code is being evaluated, read, etc.
On 30 May 2018, at 15:30, Faré wrote:
Also, if you fix reify-warnings, you may have to fix unreify-warnings with it. For a test, try to (uiop:enable-deferred-warnings-check) before you build software.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Passive hope is wishful thinking, a poison of the mind. Active hope is creative passion, the mover of the universe.
On Wed, May 30, 2018 at 4:12 PM Robert Goldman rpgoldman@sift.info wrote:
Whoops. Looks like this doesn't work on older SBCLs. I'll fix that now.
R
On 30 May 2018, at 15:08, Robert Goldman wrote:
I have just pushed a merge request and topic branch for this.
See https://gitlab.common-lisp.net/asdf/asdf/merge_requests/95
I'm pretty scared about this -- we are getting in there and rooting around in SBCL internals in ways that seem almost guaranteed to break again later. But for now, I think it's fixed.
Comments welcome -- especially comments involving a nicer rewrite of what I wrote.
Best, R
On 30 May 2018, at 12:13, Faré wrote:
On Wed, May 30, 2018 at 12:53 PM Eric Timmons etimmons@mit.edu wrote:
Somewhat related, I was curious why ASDF doesn't use Gitlab CI to automatically run tests. It probably wouldn't have helped in this particular case since the root cause was a change outside ASDF, but it's still nice for things like merge requests.
Well, there's about ten different scriptable implementations on three major platforms, plus multiple versions of each compiler and maybe extra architectures to test for some of them. And then there are the software licensing issues for those operating systems and the proprietary implementations. Finally, a complete test set would probably include non-regression with cl-test-grid.
Testing ASDF is a major undertaking. And even when all tests pass on all platforms, we have bad surprises, as demonstrated by the bumpy releases 3.2 and 3.3.
That said, even one image running tests on one implementation without cl-test-grid would be an obvious improvement over the current situation.
Not being the maintainer anymore, nor paid to do it anymore, not using it for work or for fun anymore, I'd say "patches welcome".
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The state is the coldest of all cold monsters. Coldly it lies, too; and this lie creeps from its mouth: "I, the state, am the people." — Nietzsche
-
Eric Timmons -
Faré -
Robert Goldman