With the sbcl/windows regression on uiop:run-program fixed (1), and the lib-op and monolithic-lib-op features reasonably implemented on all implementations beyond ECL & co (though requiring a CFFI patch), I believe we're all set for ASDF 3.1.6. Anton, do you have time to make a test run of cl-test-grid? If some of you believe the C linking features should (or shouldn't) be included in this release (or the next one), now is the time to voice your opinion. It's 300 to 400 more lines of code — or 800 if we splurge and merge in most of lisp-invocation as we go instead of special-casing it. (1) A real fix requires fixing SBCL. https://bugs.launchpad.net/asdf/+bug/1501373 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When you've seen one nuclear war, you've seen them all.
All tests pass for ASDF 3.1.5.20 on Linux x64 for: ccl clisp sbcl ecl ecl_bytecodes cmucl allegro lispworks mkcl abcl allegromodern Anton, can you run cl-test-grid against it? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A child of five would understand this. Send someone to fetch a child of five. — Groucho Marx On Tue, Oct 6, 2015 at 9:05 PM, Faré <fahree@gmail.com> wrote:
With the sbcl/windows regression on uiop:run-program fixed (1), and the lib-op and monolithic-lib-op features reasonably implemented on all implementations beyond ECL & co (though requiring a CFFI patch), I believe we're all set for ASDF 3.1.6.
Anton, do you have time to make a test run of cl-test-grid?
If some of you believe the C linking features should (or shouldn't) be included in this release (or the next one), now is the time to voice your opinion. It's 300 to 400 more lines of code — or 800 if we splurge and merge in most of lisp-invocation as we go instead of special-casing it.
(1) A real fix requires fixing SBCL. https://bugs.launchpad.net/asdf/+bug/1501373
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When you've seen one nuclear war, you've seen them all.
Ok, will do (sorry, read this message only today) 10.10.2015, 10:13, "Faré" <fahree@gmail.com>:
All tests pass for ASDF 3.1.5.20 on Linux x64 for: ccl clisp sbcl ecl ecl_bytecodes cmucl allegro lispworks mkcl abcl allegromodern
Anton, can you run cl-test-grid against it?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A child of five would understand this. Send someone to fetch a child of five. — Groucho Marx
On Tue, Oct 6, 2015 at 9:05 PM, Faré <fahree@gmail.com> wrote:
With the sbcl/windows regression on uiop:run-program fixed (1), and the lib-op and monolithic-lib-op features reasonably implemented on all implementations beyond ECL & co (though requiring a CFFI patch), I believe we're all set for ASDF 3.1.6.
Anton, do you have time to make a test run of cl-test-grid?
If some of you believe the C linking features should (or shouldn't) be included in this release (or the next one), now is the time to voice your opinion. It's 300 to 400 more lines of code — or 800 if we splurge and merge in most of lisp-invocation as we go instead of special-casing it.
(1) A real fix requires fixing SBCL. https://bugs.launchpad.net/asdf/+bug/1501373
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When you've seen one nuclear war, you've seen them all.
If you are interested, this version of ASDF fails on SBCL 1.0.58: ; caught ERROR: ; READ error during COMPILE-FILE: ; ; Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG package. ; ; Line: 4307, Column: 29, File-Position: 210191 ; ; Stream: #<SB-SYS:FD-STREAM ; for "file /home/testgrid/quicklisp-asdf3/asdf.lisp" {ADDDA29}> 10.10.2015, 13:16, "Anton Vodonosov" <avodonosov@yandex.ru>:
Ok, will do (sorry, read this message only today)
10.10.2015, 10:13, "Faré" <fahree@gmail.com>:
All tests pass for ASDF 3.1.5.20 on Linux x64 for: ccl clisp sbcl ecl ecl_bytecodes cmucl allegro lispworks mkcl abcl allegromodern
Anton, can you run cl-test-grid against it?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A child of five would understand this. Send someone to fetch a child of five. — Groucho Marx
On Tue, Oct 6, 2015 at 9:05 PM, Faré <fahree@gmail.com> wrote:
With the sbcl/windows regression on uiop:run-program fixed (1), and the lib-op and monolithic-lib-op features reasonably implemented on all implementations beyond ECL & co (though requiring a CFFI patch), I believe we're all set for ASDF 3.1.6.
Anton, do you have time to make a test run of cl-test-grid?
If some of you believe the C linking features should (or shouldn't) be included in this release (or the next one), now is the time to voice your opinion. It's 300 to 400 more lines of code — or 800 if we splurge and merge in most of lisp-invocation as we go instead of special-casing it.
(1) A real fix requires fixing SBCL. https://bugs.launchpad.net/asdf/+bug/1501373
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When you've seen one nuclear war, you've seen them all.
On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
If you are interested, this version of ASDF fails on SBCL 1.0.58:
; caught ERROR: ; READ error during COMPILE-FILE: ; ; Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG package. ; ; Line: 4307, Column: 29, File-Position: 210191 ; ; Stream: #<SB-SYS:FD-STREAM ; for "file /home/testgrid/quicklisp-asdf3/asdf.lisp" {ADDDA29}>
Apparently, the first release that include PRINT-BACKTRACE is 1.1.5 from February 2013. I'll let Robert decide whether it's OK to drop support for SBCL releases older than that. I'd weakly vote "yes, it's OK to stop supporting things more than 2 years old", but that's just me. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A man who procrastinates in his choosing will inevitably have his choice made for him by circumstance. — Hunter S Thompson
Got results for ccl-1.10-r16196-f96-linux-x86 clisp-2.49-unix-x86 cmu-snapshot-2014-12___20f_unicode_-linux-x86 sbcl-1.2.6-linux-x86 So far looks good - no failures which could be attributed to new ASDF. Waiting for other lisps to finish. 10.10.2015, 18:26, "Faré" <fahree@gmail.com>:
On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
If you are interested, this version of ASDF fails on SBCL 1.0.58:
; caught ERROR: ; READ error during COMPILE-FILE: ; ; Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG package. ; ; Line: 4307, Column: 29, File-Position: 210191 ; ; Stream: #<SB-SYS:FD-STREAM ; for "file /home/testgrid/quicklisp-asdf3/asdf.lisp" {ADDDA29}>
Apparently, the first release that include PRINT-BACKTRACE is 1.1.5 from February 2013.
I'll let Robert decide whether it's OK to drop support for SBCL releases older than that.
I'd weakly vote "yes, it's OK to stop supporting things more than 2 years old", but that's just me.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A man who procrastinates in his choosing will inevitably have his choice made for him by circumstance. — Hunter S Thompson
Currently these lisps are finished: abcl-1.3.2-fasl42-linux-x86 ccl-1.10-r16196-f96-linux-x86 ccl-1.11-rc1-r16536-f96-linux-x86 ccl-1.8-r15286m-f95-linux-x86 ccl-1.9-r15756-f96-linux-x86 clisp-2.49-unix-x86 cmu-snapshot-2014-05-dirty__20e_unicode_-linux-x86 cmu-snapshot-2014-12___20f_unicode_-linux-x86 ecl-13.5.1-unknown-linux-i686-bytecode ecl-13.5.1-unknown-linux-i686-lisp-to-c ecl-16.0.0-98fc12d3-linux-i686-bytecode ecl-16.0.0-98fc12d3-linux-i686-lisp-to-c sbcl-1.1.11-linux-x86 sbcl-1.1.16-linux-x86 sbcl-1.2.6-linux-x86 The status remains the same - no failures which could be attributed to new ASDF. Some other versions of these lisp implementations will be tested too. I will followup. For the record, reports are here: Full diff https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-49.html As you see, there are many "improvements" on old lisps just because many systems use new ASDF features not provided by the ASDF version shipped with those old lisp impls. For convenience, here is the diff report including only the tests which fail on new ASDF: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-50.html Best regards, - Anton 11.10.2015, 16:31, "Anton Vodonosov" <avodonosov@yandex.ru>:
Got results for
ccl-1.10-r16196-f96-linux-x86 clisp-2.49-unix-x86 cmu-snapshot-2014-12___20f_unicode_-linux-x86 sbcl-1.2.6-linux-x86
So far looks good - no failures which could be attributed to new ASDF.
Waiting for other lisps to finish.
10.10.2015, 18:26, "Faré" <fahree@gmail.com>:
On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
If you are interested, this version of ASDF fails on SBCL 1.0.58:
; caught ERROR: ; READ error during COMPILE-FILE: ; ; Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG package. ; ; Line: 4307, Column: 29, File-Position: 210191 ; ; Stream: #<SB-SYS:FD-STREAM ; for "file /home/testgrid/quicklisp-asdf3/asdf.lisp" {ADDDA29}>
Apparently, the first release that include PRINT-BACKTRACE is 1.1.5 from February 2013.
I'll let Robert decide whether it's OK to drop support for SBCL releases older than that.
I'd weakly vote "yes, it's OK to stop supporting things more than 2 years old", but that's just me.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A man who procrastinates in his choosing will inevitably have his choice made for him by circumstance. — Hunter S Thompson
On 10/10/15 Oct 10 -10:26 AM, Faré wrote:
On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
If you are interested, this version of ASDF fails on SBCL 1.0.58:
; caught ERROR: ; READ error during COMPILE-FILE: ; ; Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG package. ; ; Line: 4307, Column: 29, File-Position: 210191 ; ; Stream: #<SB-SYS:FD-STREAM ; for "file /home/testgrid/quicklisp-asdf3/asdf.lisp" {ADDDA29}>
Apparently, the first release that include PRINT-BACKTRACE is 1.1.5 from February 2013.
I'll let Robert decide whether it's OK to drop support for SBCL releases older than that.
I'd weakly vote "yes, it's OK to stop supporting things more than 2 years old", but that's just me.
I agree. I believe that it's appropriate. I'd be willing to see us drop support for the 1.1.x series, for that matter. IMO it's easier to keep track of "1.1 is unsupported" than try to remember which monthly release in particular is unsupported. Agreeable policy? Question for someone more knowledgeable: is there a brief explanation of the difference between 1.1 and 1.2 SBCLs? What triggered the bump of minor version? thanks, r
On Sun, Oct 11, 2015 at 12:57 PM, Robert Goldman <rpgoldman@sift.net> wrote:
On 10/10/15 Oct 10 -10:26 AM, Faré wrote:
On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
If you are interested, this version of ASDF fails on SBCL 1.0.58:
; caught ERROR: ; READ error during COMPILE-FILE: ; ; Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG package. ; ; Line: 4307, Column: 29, File-Position: 210191 ; ; Stream: #<SB-SYS:FD-STREAM ; for "file /home/testgrid/quicklisp-asdf3/asdf.lisp" {ADDDA29}>
Apparently, the first release that include PRINT-BACKTRACE is 1.1.5 from February 2013.
I'll let Robert decide whether it's OK to drop support for SBCL releases older than that.
I'd weakly vote "yes, it's OK to stop supporting things more than 2 years old", but that's just me.
I agree. I believe that it's appropriate. I'd be willing to see us drop support for the 1.1.x series, for that matter. IMO it's easier to keep track of "1.1 is unsupported" than try to remember which monthly release in particular is unsupported. Agreeable policy?
Question for someone more knowledgeable: is there a brief explanation of the difference between 1.1 and 1.2 SBCLs? What triggered the bump of minor version?
Considering that the propagation latency for ASDF itself is about 2 years, it might be a bad idea to drop support for things that are only a bit over a year old (sbcl 1.1.18, last in the series). That said, it's true that SBCL upgrades ASDF about every year, so that makes more sense. Still. I would say that 2 year old is probably a better rule of thumb. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You cannot teach a man anything; you can only help him find it for himself. — attributed to Galileo Galilei
On 10/11/15 Oct 11 -12:14 PM, Faré wrote:
On Sun, Oct 11, 2015 at 12:57 PM, Robert Goldman <rpgoldman@sift.net> wrote:
On 10/10/15 Oct 10 -10:26 AM, Faré wrote:
On Sat, Oct 10, 2015 at 11:06 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:
If you are interested, this version of ASDF fails on SBCL 1.0.58:
; caught ERROR: ; READ error during COMPILE-FILE: ; ; Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG package. ; ; Line: 4307, Column: 29, File-Position: 210191 ; ; Stream: #<SB-SYS:FD-STREAM ; for "file /home/testgrid/quicklisp-asdf3/asdf.lisp" {ADDDA29}>
Apparently, the first release that include PRINT-BACKTRACE is 1.1.5 from February 2013.
I'll let Robert decide whether it's OK to drop support for SBCL releases older than that.
I'd weakly vote "yes, it's OK to stop supporting things more than 2 years old", but that's just me.
I agree. I believe that it's appropriate. I'd be willing to see us drop support for the 1.1.x series, for that matter. IMO it's easier to keep track of "1.1 is unsupported" than try to remember which monthly release in particular is unsupported. Agreeable policy?
Question for someone more knowledgeable: is there a brief explanation of the difference between 1.1 and 1.2 SBCLs? What triggered the bump of minor version?
Considering that the propagation latency for ASDF itself is about 2 years, it might be a bad idea to drop support for things that are only a bit over a year old (sbcl 1.1.18, last in the series). That said, it's true that SBCL upgrades ASDF about every year, so that makes more sense. Still. I would say that 2 year old is probably a better rule of thumb.
The problem with this rule of thumb is that it requires the ASDF maintainer (me) to track SBCL releases and be able to map release numbers to dates. I don't like that. It's more work and cognitive load that I really don't have room for. Given that some version of 1.1.x of SBCL can no longer be supported, I'd prefer to write off all of 1.1 Cheers, r
On Wed, Oct 14, 2015 at 6:55 PM, Robert Goldman <rpgoldman@sift.net> wrote:
Apparently, the first release that include PRINT-BACKTRACE is 1.1.5 from February 2013.
Considering that the propagation latency for ASDF itself is about 2 years, it might be a bad idea to drop support for things that are only a bit over a year old (sbcl 1.1.18, last in the series). That said, it's true that SBCL upgrades ASDF about every year, so that makes more sense. Still. I would say that 2 year old is probably a better rule of thumb.
The problem with this rule of thumb is that it requires the ASDF maintainer (me) to track SBCL releases and be able to map release numbers to dates. I don't like that. It's more work and cognitive load that I really don't have room for.
Given that some version of 1.1.x of SBCL can no longer be supported, I'd prefer to write off all of 1.1
Well in cases like this where we introduce backward incompatibility, we still have to use git to identify the change back to which we remain compatible, to make sure it's old enough — and at that point, git gives us both the date and number of the first release that includes the change for free. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Taxation with representation ain't so hot either. – Gerald Barzan
On 10/15/15 Oct 15 -12:40 AM, Faré wrote:
On Wed, Oct 14, 2015 at 6:55 PM, Robert Goldman <rpgoldman@sift.net> wrote:
Apparently, the first release that include PRINT-BACKTRACE is 1.1.5 from February 2013.
Considering that the propagation latency for ASDF itself is about 2 years, it might be a bad idea to drop support for things that are only a bit over a year old (sbcl 1.1.18, last in the series). That said, it's true that SBCL upgrades ASDF about every year, so that makes more sense. Still. I would say that 2 year old is probably a better rule of thumb.
The problem with this rule of thumb is that it requires the ASDF maintainer (me) to track SBCL releases and be able to map release numbers to dates. I don't like that. It's more work and cognitive load that I really don't have room for.
Given that some version of 1.1.x of SBCL can no longer be supported, I'd prefer to write off all of 1.1
Well in cases like this where we introduce backward incompatibility, we still have to use git to identify the change back to which we remain compatible, to make sure it's old enough — and at that point, git gives us both the date and number of the first release that includes the change for free.
I'm sorry, that's too much cognitive load. 2 significant digits is all I'm willing to track, and I'm not willing to track dates. So I'm not going to reject patches that will support SBCL 1.1.x versions, but as far as I'm concerned, ASDF only supports 1.2.x Best, r
participants (3)
-
Anton Vodonosov -
Faré -
Robert Goldman