Results are coming, these lisps are ready:
ccl-1.10-r16196-f96-linux-x86 cmu-snapshot-2016-12__21b_unicode_-linux-x86 sbcl-1.3.12-linux-x86
The following report is the part of the diff including only results where new version fails: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-54.html
As we can see, other systems than asdf-systems-connections fails with the " OPERATION instances must only be created through MAKE-OPERATION." too. This error constitures the majority of failures.
To make it easier seeing other errors, the next report filters out the " OPERATION instances must only be created through MAKE-OPERATION." and leaves only other errors: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-55.html
Notable are the cl-python failure, the "Unknown CFFI type (:STRUCT TUNION1)" error, the "Component CLSQL-UFFI-SYSTEM::UFFI does not match version 2.0, required by #<SYSTEM "clsql-uffi">"
Best regards, - Anton
26.12.2016, 11:57, "Anton Vodonosov" avodonosov@yandex.ru:
Tests are running (wht updated slime, cffi, asdf-systems-connections)
26.12.2016, 08:22, "Faré" fahree@gmail.com:
I see no unexplained failure in Anton's previous test run, but it's possible that the explained failures are hiding further failures down the line.
Anton: can you re-run with an updated asdf-systems-connections AND an updated SLIME?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Have the courage to take your own thoughts seriously, for they will shape you. — Albert Einstein
On Mon, Dec 26, 2016 at 12:00 AM, Faré fahree@gmail.com wrote:
I see a lot of failures on ECL that seem related to using swank, except the swank package is not defined. That also might be caused by a bad and/or old SLIME, that was badly abusing some asdf internals in an incoherent way. Can you try with the latest SLIME?
Note that I am quite angry at the SLIME maintainers because I have tried many times to offer them fixes to swank.asd but they never merged any of my proposed pull requests.
Otherwise, it looks mostly good.
NB: When there is an error from a gcc subprocess, you don't seem to be capturing the output, which goes directly to fd 1 / fd 2 of the process, as inherited by the subprocess. Maybe you can fix that in cl-test-grid?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The idea is not to confront bad ideas but to come up with good ideas. Otherwise, your enemies define the game and you are the loyal opposition. — Terence McKenna
On Sun, Dec 25, 2016 at 7:22 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
It is the same system.
When previous result was CRASH and new one is FAIL, it might be the same error. But when the previous was OK and new is FAIL, it's more suspicious.
For example: (LOAD exscribe OK) vs (LOAD exscribe FAIL) QUICKLISP-CLIENT:SYSTEM-NOT-FOUND : System "fare-scripts/rescript" not found
26.12.2016, 02:36, "Faré" fahree@gmail.com:
On Sun, Dec 25, 2016 at 4:08 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-52.html
It's not looking too bad, but there are a lot of new failures with the latest sbcl, where some dll is not found. Can that be explained by your running on a different setup where some libraries are missing, or is that something I should investigate?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Language is froth on the surface of thought. — John McCarthyte
OK, so apparently: * make-operation: You need an updated iolib for further tests as this causes a lot of errors :-( * make-operation: eco, prove need to use make-operation (sent bug reports). Many systems use prove. https://github.com/eudoxia0/eco/issues/1 https://github.com/fukamachi/prove/issues/35 * the uffi-tests bug is probably due to the update in cffi — dunno whether it's addressed upstream or not. If not, it needs be reported. Another package complains about an old uffi, so, maybe try to update uffi? * the failures to locate some .so's might or might not be due to the CFFI update. * make-operation: cl-protobufs had the bug, it was fixed already, but not yet in ql; no system in ql uses it so no need to update for now but if you do we can check that nothing else breaks. * make-operation: error in lambda-reader-8bit is my fault. Fixed. * Warning in uiop is my fault. Fixed.
PS: For redirecting the output of subprocesses, you can't just redirect a lisp stream; the Lisp process itself must be started with its outputs properly redirected. You can start the building Lisp process with e.g. (uiop:run-program (lisp-invocation:lisp-invocation ...) :output my-logfile-pathname :error-output :output :input nil)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Resentment is like taking poison and waiting for the other person to die. — Malachy McCourt
On Mon, Dec 26, 2016 at 3:02 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Results are coming, these lisps are ready:
ccl-1.10-r16196-f96-linux-x86 cmu-snapshot-2016-12__21b_unicode_-linux-x86 sbcl-1.3.12-linux-x86The following report is the part of the diff including only results where new version fails: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-54.html
As we can see, other systems than asdf-systems-connections fails with the " OPERATION instances must only be created through MAKE-OPERATION." too. This error constitures the majority of failures.
To make it easier seeing other errors, the next report filters out the " OPERATION instances must only be created through MAKE-OPERATION." and leaves only other errors: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-55.html
Notable are the cl-python failure, the "Unknown CFFI type (:STRUCT TUNION1)" error, the "Component CLSQL-UFFI-SYSTEM::UFFI does not match version 2.0, required by #<SYSTEM "clsql-uffi">"
Best regards,
- Anton
26.12.2016, 11:57, "Anton Vodonosov" avodonosov@yandex.ru:
Tests are running (wht updated slime, cffi, asdf-systems-connections)
26.12.2016, 08:22, "Faré" fahree@gmail.com:
I see no unexplained failure in Anton's previous test run, but it's possible that the explained failures are hiding further failures down the line.
Anton: can you re-run with an updated asdf-systems-connections AND an updated SLIME?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Have the courage to take your own thoughts seriously, for they will shape you. — Albert Einstein
On Mon, Dec 26, 2016 at 12:00 AM, Faré fahree@gmail.com wrote:
I see a lot of failures on ECL that seem related to using swank, except the swank package is not defined. That also might be caused by a bad and/or old SLIME, that was badly abusing some asdf internals in an incoherent way. Can you try with the latest SLIME?
Note that I am quite angry at the SLIME maintainers because I have tried many times to offer them fixes to swank.asd but they never merged any of my proposed pull requests.
Otherwise, it looks mostly good.
NB: When there is an error from a gcc subprocess, you don't seem to be capturing the output, which goes directly to fd 1 / fd 2 of the process, as inherited by the subprocess. Maybe you can fix that in cl-test-grid?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The idea is not to confront bad ideas but to come up with good ideas. Otherwise, your enemies define the game and you are the loyal opposition. — Terence McKenna
On Sun, Dec 25, 2016 at 7:22 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
It is the same system.
When previous result was CRASH and new one is FAIL, it might be the same error. But when the previous was OK and new is FAIL, it's more suspicious.
For example: (LOAD exscribe OK) vs (LOAD exscribe FAIL) QUICKLISP-CLIENT:SYSTEM-NOT-FOUND : System "fare-scripts/rescript" not found
26.12.2016, 02:36, "Faré" fahree@gmail.com:
On Sun, Dec 25, 2016 at 4:08 PM, Anton Vodonosov avodonosov@yandex.ru wrote: > https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-52.html
It's not looking too bad, but there are a lot of new failures with the latest sbcl, where some dll is not found. Can that be explained by your running on a different setup where some libraries are missing, or is that something I should investigate?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Language is froth on the surface of thought. — John McCarthyte
Sorry, didn't have time to re-run with updated libraries yet - plan to do it in coming days.
27.12.2016, 01:34, "Faré" fahree@gmail.com:
OK, so apparently:
- make-operation: You need an updated iolib for further tests as this
causes a lot of errors :-(
- make-operation: eco, prove need to use make-operation (sent bug
reports). Many systems use prove. https://github.com/eudoxia0/eco/issues/1 https://github.com/fukamachi/prove/issues/35
- the uffi-tests bug is probably due to the update in cffi
Yes, maybe - it didn't fail before we updated cffi
— dunnowhether it's addressed upstream or not. If not, it needs be reported. Another package complains about an old uffi, so, maybe try to update uffi?
- the failures to locate some .so's might or might not be due to the
CFFI update.
- make-operation: cl-protobufs had the bug, it was fixed already, but
not yet in ql; no system in ql uses it so no need to update for now but if you do we can check that nothing else breaks.
- make-operation: error in lambda-reader-8bit is my fault. Fixed.
- Warning in uiop is my fault. Fixed.
PS: For redirecting the output of subprocesses, you can't just redirect a lisp stream; the Lisp process itself must be started with its outputs properly redirected. You can start the building Lisp process with e.g. (uiop:run-program (lisp-invocation:lisp-invocation ...) :output my-logfile-pathname :error-output :output :input nil)
I doubt I will do it soon: I need process ID of the child process, uiop:run-program doesn't support this. Also I'm not sure passing output file will work reliably on all platforms.
On Wed, Dec 28, 2016 at 11:31 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Sorry, didn't have time to re-run with updated libraries yet - plan to do it in coming days.
PS: For redirecting the output of subprocesses, you can't just redirect a lisp stream; the Lisp process itself must be started with its outputs properly redirected. You can start the building Lisp process with e.g. (uiop:run-program (lisp-invocation:lisp-invocation ...) :output my-logfile-pathname :error-output :output :input nil)
I doubt I will do it soon: I need process ID of the child process, uiop:run-program doesn't support this. Also I'm not sure passing output file will work reliably on all platforms.
You're in luck: ASDF 3.2.0's new uiop:launch-program supports running asynchronously and getting the process ID — at least if you run on SBCL and other good implementations.
And you only need that on the master Lisp that launches the other subprocesses, so it doesn't have to work on all platforms.
NB: If you're not using it yet, you might be interested in the lisp-invocation library.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If this country is worth saving, it's worth saving at a profit. — H. L. Hunt This country can only be saved if it can be saved at a profit. — Patri Friedman
29.12.2016, 07:43, "Faré" fahree@gmail.com:
On Wed, Dec 28, 2016 at 11:31 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
Sorry, didn't have time to re-run with updated libraries yet - plan to do it in coming days.
PS: For redirecting the output of subprocesses, you can't just redirect a lisp stream; the Lisp process itself must be started with its outputs properly redirected. You can start the building Lisp process with e.g. (uiop:run-program (lisp-invocation:lisp-invocation ...) :output my-logfile-pathname :error-output :output :input nil)
I doubt I will do it soon: I need process ID of the child process, uiop:run-program doesn't support this. Also I'm not sure passing output file will work reliably on all platforms.
You're in luck: ASDF 3.2.0's new uiop:launch-program supports running asynchronously and getting the process ID — at least if you run on SBCL and other good implementations.
Cool. (I use CCL - is it supported?).
And you only need that on the master Lisp that launches the other subprocesses, so it doesn't have to work on all platforms.
Yes. CCL on various OSes is needed, do you think it will work? Also, it's desirable the target file to be appended, not overwriten. Is that possible currently?
NB: If you're not using it yet, you might be interested in the lisp-invocation library.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If this country is worth saving, it's worth saving at a profit. — H. L. Hunt This country can only be saved if it can be saved at a profit. — Patri Friedman
On Wed, Dec 28, 2016 at 11:50 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
You're in luck: ASDF 3.2.0's new uiop:launch-program supports running asynchronously and getting the process ID — at least if you run on SBCL and other good implementations.
Cool. (I use CCL - is it supported?).
Yes, CCL is supported. Mind that CCL's background thread will read from stdin in competition with any interactive subprocess you run, though, unless you use my single-threaded-ccl to refrain from running that thread (at which point you have to manually flush stdout and stderr).
And you only need that on the master Lisp that launches the other subprocesses, so it doesn't have to work on all platforms.
Yes. CCL on various OSes is needed, do you think it will work? Also, it's desirable the target file to be appended, not overwriten. Is that possible currently?
I believe that :append is indeed possible with CCL and launch-program, but you'd have to double-check.
NB: If you're not using it yet, you might be interested in the lisp-invocation library.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When a man says money can do anything, that settles it: he hasn't got any. — Edgar Watson Howe
29.12.2016, 08:03, "Faré" fahree@gmail.com:
On Wed, Dec 28, 2016 at 11:50 PM, Anton Vodonosov avodonosov@yandex.ru wrote:
You're in luck: ASDF 3.2.0's new uiop:launch-program supports running asynchronously and getting the process ID — at least if you run on SBCL and other good implementations.
Cool. (I use CCL - is it supported?).
Yes, CCL is supported. Mind that CCL's background thread will read from stdin in competition with any interactive subprocess you run, though, unless you use my single-threaded-ccl to refrain from running that thread (at which point you have to manually flush stdout and stderr).
And you only need that on the master Lisp that launches the other subprocesses, so it doesn't have to work on all platforms.
Yes. CCL on various OSes is needed, do you think it will work? Also, it's desirable the target file to be appended, not overwriten. Is that possible currently?
I believe that :append is indeed possible with CCL and launch-program, but you'd have to double-check.
OK, thanks.
NB: If you're not using it yet, you might be interested in the lisp-invocation library.
Yes, the library is interesting, similar to what I do.
I have finally restarted the tests, with latest ASDF/UIOP (git commit dee8b12) and other libraries updated.
27.12.2016, 01:34, "Faré" fahree@gmail.com:
OK, so apparently:
- make-operation: You need an updated iolib for further tests as this
causes a lot of errors :-(
- make-operation: eco, prove need to use make-operation (sent bug
reports). Many systems use prove. https://github.com/eudoxia0/eco/issues/1 https://github.com/fukamachi/prove/issues/35
- the uffi-tests bug is probably due to the update in cffi — dunno
whether it's addressed upstream or not. If not, it needs be reported. Another package complains about an old uffi, so, maybe try to update uffi?
It happened because when I checkout cffi to quicklisp/local-projects, the local-projects/cffi/uffi-compat/uffi.asd was used instead of the "real" UFFI. Fixed that now.
- the failures to locate some .so's might or might not be due to the
CFFI update.
- make-operation: cl-protobufs had the bug, it was fixed already, but
not yet in ql; no system in ql uses it so no need to update for now but if you do we can check that nothing else breaks.
- make-operation: error in lambda-reader-8bit is my fault. Fixed.
- Warning in uiop is my fault. Fixed.
Current results: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-56.html This reports includes only the subset of full diff where new version has failures.
The lisps completed so far: ccl-1.10-r16196-f96-linux-x86 ccl-1.11-r16635-f96-linux-x86 clisp-2.49-unix-x86 cmu-snapshot-2016-12__21b_unicode_-linux-x86 ecl-16.1.2-unknown-linux-x86-bytecode ecl-16.1.2-unknown-linux-x86-lisp-to-c sbcl-1.3.12-linux-x86
If speak about SBCL results in this report, where previous test has CRASH and new one has ffi/ffi-grovel FAIL - it's an improvement, because the new version seem to better catch errors of running external programs.
Why there are so many strange errors on ECL - I can't say now, deeper analysis is needed. Both tests were run on the same machine.
Overall, the results look good. Robert, shall we release now?
1- For ECL, it looks like you may have kept old fasls from a run with a previous version of asdf. Is that correct? That could explain some confusion with escape-command.
2- For those CFFI failures, I'd like to see the logs for the stdout. See previous message on redirecting output, using launch-program if needs be.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reevaluate your ends periodically — if some of them or in contradiction with reality or with each other, abandon or amend them without mercy — and those you keep, pursue without any apology.
On Thu, Jan 5, 2017 at 5:37 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
Current results: https://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-56.html This reports includes only the subset of full diff where new version has failures.
The lisps completed so far: ccl-1.10-r16196-f96-linux-x86 ccl-1.11-r16635-f96-linux-x86 clisp-2.49-unix-x86 cmu-snapshot-2016-12__21b_unicode_-linux-x86 ecl-16.1.2-unknown-linux-x86-bytecode ecl-16.1.2-unknown-linux-x86-lisp-to-c sbcl-1.3.12-linux-x86
If speak about SBCL results in this report, where previous test has CRASH and new one has ffi/ffi-grovel FAIL
- it's an improvement, because the new version seem to better catch
errors of running external programs.
Why there are so many strange errors on ECL - I can't say now, deeper analysis is needed. Both tests were run on the same machine.
-
Anton Vodonosov -
Faré