I ran the tests again on all three platforms.
Linux:
Unexpected test success on ecl-bytecodes (ECL 16.1.2) in this block:
;; forced, it should be later (DBG "Check that force reloading loads again") (setf test-package::*file3* :reset) (load-system 'test-asdf/force :force :all) (assert-compare (>= (get-file-stamp file1) file1-date)) (assert-equal test-package::*file3* t)
I do *not* see this on ECL non-bytecodes. The tests here fail as before.
Windows:
Allegro, ccl, ECL-bytecodes, and SBCL all fail test-force. ECL-bytecodes also fails test-run-program.
These seem to be failing here:
(DBG "Check that require-system of touched .asd will reload the asdf.") (DBG "(That's what it does now, but if it could be fixed that'd be nice.)") (unset-asdf-cache-entry '(locate-system "test-asdf")) (unset-asdf-cache-entry '(find-system "test-asdf")) (unset-asdf-cache-entry '(find-system "test-asdf/force")) (touch-file "test-asdf.asd" :timestamp (+ 10000 (get-file-stamp file1))) (require-system 'test-asdf/force) (assert-equal (asymval :*times-loaded* :test-asdf-system) 2)
Looks like *TIMES-LOADED* is evaluating to 1 instead of 2.
Anyone know why this would have changed?
Mac:
Everything passes.
Thx, r
On 9/12/16 Sep 12 -4:33 PM, Robert Goldman wrote:
I ran the tests again on all three platforms.
....
Windows:
Allegro, ccl, ECL-bytecodes, and SBCL all fail test-force. ECL-bytecodes also fails test-run-program.
These seem to be failing here:
(DBG "Check that require-system of touched .asd will reload the asdf.") (DBG "(That's what it does now, but if it could be fixed that'd be nice.)") (unset-asdf-cache-entry '(locate-system "test-asdf")) (unset-asdf-cache-entry '(find-system "test-asdf")) (unset-asdf-cache-entry '(find-system "test-asdf/force")) (touch-file "test-asdf.asd" :timestamp (+ 10000 (get-file-stamp file1))) (require-system 'test-asdf/force) (assert-equal (asymval :*times-loaded* :test-asdf-system) 2)
Looks like *TIMES-LOADED* is evaluating to 1 instead of 2.
Anyone know why this would have changed?
Looking further, it seems like getting the proper results here relies on TOUCH-FILE (script-support.lisp) which, in turn, relies on being able to invoke "touch" through a shell. So I wonder not so much why this is broken, as why it ever worked. Possibly because I have always run the tests with Cygwin installed.
According to this: http://superuser.com/questions/292630/how-can-i-change-the-timestamp-on-a-fi... it looks like on Windows if we need to set the new time to a particular time, we should use PowerShell, but if we only want to set to the *current* time, we can do it with windows Copy. But... that won't satisfy the ASSERT-EQUAL in TOUCH-FILE.
Fare -- should we be replacing this, on windows, with the windows-native "copy"? Or is there some reason why we must have the ability to set the exact time, instead of simply increasing it to be greater than it was in the past?
thanks, r
On 12 Sep 2016, at 23:33, Robert Goldman rpgoldman@sift.net wrote:
I ran the tests again on all three platforms.
Linux:
I’ve run tests on Linux again, now, too.
Unexpected test success on ecl-bytecodes (ECL 16.1.2) in this block:
;; forced, it should be later (DBG "Check that force reloading loads again") (setf test-package::*file3* :reset) (load-system 'test-asdf/force :force :all) (assert-compare (>= (get-file-stamp file1) file1-date)) (assert-equal test-package::*file3* t)
I do *not* see this on ECL non-bytecodes. The tests here fail as before.
I’ve hit the following regressions, some of which overlap with what you see:
- ECL 16.1.2 and newer fail test3.script in regular mode - ECL 16.1.2 and newer fail test-force.script in ecl_bytescodes mode(+) - SBCL 1.1.13 now fails plenty of tests (11 to be precise). SBCL 1.3.9 and later are fine(++) - MKCL-git(*) now fails test-make-build.script and test-program.script(**)
(+) I don’t typically run such tests. It seems I should. (++) I did not test anything between 1.1.13 and 1.3.9 (*) needs to be very recent (**) that’s what https://github.com/jcbeaudoin/MKCL/issues/9 is about
Elias
On 9/12/16 Sep 12 -6:13 PM, Elias Pipping wrote:
On 12 Sep 2016, at 23:33, Robert Goldman rpgoldman@sift.net wrote:
I ran the tests again on all three platforms.
Linux:
I’ve run tests on Linux again, now, too.
Are you running on head of master from common-lisp.net?
Unexpected test success on ecl-bytecodes (ECL 16.1.2) in this block:
;; forced, it should be later (DBG "Check that force reloading loads again") (setf test-package::*file3* :reset) (load-system 'test-asdf/force :force :all) (assert-compare (>= (get-file-stamp file1) file1-date)) (assert-equal test-package::*file3* t)
I do *not* see this on ECL non-bytecodes. The tests here fail as before.
I’ve hit the following regressions, some of which overlap with what you see:
- ECL 16.1.2 and newer fail test3.script in regular mode
- ECL 16.1.2 and newer fail test-force.script in ecl_bytescodes mode(+)
I believe that this is a non-failure -- previously this was tagged as an expected failure. Looks like Faré has removed that expected failure. Now ecl_bytecodes reports success on both Mac and Linux. This is 16.1.2.
I don't see a failure in test3.script, on either Mac or Linux.
- SBCL 1.1.13 now fails plenty of tests (11 to be precise). SBCL 1.3.9 and later are fine(++)
The last time I checked SBCL 1.3.9 (really a candidate for release), it failed because of some pathname-printing code. Passes for me now on Mac and Linux.
- MKCL-git(*) now fails test-make-build.script and test-program.script(**)
mkcl from git just now doesn't fail any tests for me.
I'd be interested to see what's going wrong in these failures that I cannot see.
(+) I don’t typically run such tests. It seems I should. (++) I did not test anything between 1.1.13 and 1.3.9 (*) needs to be very recent (**) that’s what https://github.com/jcbeaudoin/MKCL/issues/9 is about
Elias
On 13 Sep 2016, at 03:47, Robert Goldman rpgoldman@sift.net wrote:
On 9/12/16 Sep 12 -6:13 PM, Elias Pipping wrote:
On 12 Sep 2016, at 23:33, Robert Goldman rpgoldman@sift.net wrote:
I ran the tests again on all three platforms.
Linux:
I’ve run tests on Linux again, now, too.
Are you running on head of master from common-lisp.net?
Yes. I was testing with 3.1.7.19.
Unexpected test success on ecl-bytecodes (ECL 16.1.2) in this block:
;; forced, it should be later (DBG "Check that force reloading loads again") (setf test-package::*file3* :reset) (load-system 'test-asdf/force :force :all) (assert-compare (>= (get-file-stamp file1) file1-date)) (assert-equal test-package::*file3* t)
I do *not* see this on ECL non-bytecodes. The tests here fail as before.
I’ve hit the following regressions, some of which overlap with what you see:
- ECL 16.1.2 and newer fail test3.script in regular mode
- ECL 16.1.2 and newer fail test-force.script in ecl_bytescodes mode(+)
I believe that this is a non-failure -- previously this was tagged as an expected failure. Looks like Faré has removed that expected failure. Now ecl_bytecodes reports success on both Mac and Linux. This is 16.1.2.
I don't see a failure in test3.script, on either Mac or Linux.
Yikes. Now I cannot reproduce this issue anymore either all of a sudden. No idea what changes since yesterday. Will report back if/when the problem re-occurs.
- SBCL 1.1.13 now fails plenty of tests (11 to be precise). SBCL 1.3.9 and later are fine(++)
The last time I checked SBCL 1.3.9 (really a candidate for release), it failed because of some pathname-printing code. Passes for me now on Mac and Linux.
That was a regression that they fixed prior to the 1.3.9 release, fortunately. I just wanted to point out here that so far rather old sbcl releases worked perfectly well and now they don’t. Might be worth investigating what changed.
- MKCL-git(*) now fails test-make-build.script and test-program.script(**)
mkcl from git just now doesn't fail any tests for me.
Please make sure that you’re on the very latest mkcl (in particular, this will typically require you to pull from github, not the gitlab mirror). Please also make sure to remove any trace of the old installation from your system before installing a new version so that files the were removed are really gone.
Elias
On 9/13/16 Sep 13 -2:50 AM, Elias Pipping wrote:
Yikes. Now I cannot reproduce this issue anymore either all of a sudden. No idea what changes since yesterday. Will report back if/when the problem re-occurs.
One possibility: see if it might be happening only if/only if not run under 'make'. In the past I have found some issues in the tests where we weren't properly cleaning up, and some state slipped from one test run into another.
That's the only thing I can think of right now.
I'm looking at test3.script and to be honest, I'm not sure what it is trying to test. It seems to date back to a time before the tests had descriptive names. It seems to test some combination of feature values, the use of REQUIRE to invoke ASDF's load, but I don't claim to understand it.
Best, r
On 9/13/16 Sep 13 -2:50 AM, Elias Pipping wrote:
- SBCL 1.1.13 now fails plenty of tests (11 to be precise). SBCL 1.3.9 and later are fine(++)
The last time I checked SBCL 1.3.9 (really a candidate for release), it failed because of some pathname-printing code. Passes for me now on Mac and Linux.
That was a regression that they fixed prior to the 1.3.9 release, fortunately. I just wanted to point out here that so far rather old sbcl releases worked perfectly well and now they don’t. Might be worth investigating what changed.
Do you have any error logs you could post? For example to launchpad?
WRT mkcl, I'm going to let this slide. I am already tracking it from git, which I don't do for most other implementations.x I can't afford the complexity of tracking multiple git repositories. According to the page at common-lisp.net, the gitlab repository is the official one, so I will stick to that.
So my understanding of what needs investigation is:
1. What's going on with the new Windows failures.
2. What's going on with the newly introduced issues on older versions of SBCL.
Best, r
I don't currently have access to a Windows development machine or to an old SBCL, so can't help with that.
I violated your moratorium to push a trivial refactoring and docstring cleanup, as suggested by the discussion with Daniel K.
PS: my take from Daniel K's patch is that we need to *eagerly* rather than *lazily* register the preloaded systems as loaded (including action-already-done-p bit) for the sake of already-loaded-systems and the function require-system that depends on it.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Democracy is but government of the busy, by the bully, for the bossy. — Arthur Seldon, "The Dilemma of Democracy"
On 13 Sep 2016, at 15:16, Robert Goldman rpgoldman@sift.net wrote:
On 9/13/16 Sep 13 -2:50 AM, Elias Pipping wrote:
- SBCL 1.1.13 now fails plenty of tests (11 to be precise). SBCL 1.3.9 and later are fine(++)
The last time I checked SBCL 1.3.9 (really a candidate for release), it failed because of some pathname-printing code. Passes for me now on Mac and Linux.
That was a regression that they fixed prior to the 1.3.9 release, fortunately. I just wanted to point out here that so far rather old sbcl releases worked perfectly well and now they don’t. Might be worth investigating what changed.
Do you have any error logs you could post? For example to launchpad?
WRT mkcl, I'm going to let this slide. I am already tracking it from git, which I don't do for most other implementations.x I can't afford the complexity of tracking multiple git repositories. According to the page at common-lisp.net, the gitlab repository is the official one, so I will stick to that.
I think https://common-lisp.net/project/mkcl/ is outdated in that respect.
https://github.com/jcbeaudoin/MKCL
is clearly official. Moreover, JCB indicated to me earlier that
https://github.com/jcbeaudoin/MKCL/issues
is the primary location for bug reports.
So my understanding of what needs investigation is:
What's going on with the new Windows failures.
What's going on with the newly introduced issues on older versions of
SBCL.
It turns out the test3 issue was down to the same problem as the issues with older SBCL releases: I’d run out of space on the machine I was testing on without noticing. So please ignore them entirely. I apologise for the false and confusing reports.
I’ve used this as an occasion to move my testing to another machine as well as make it cleaner and more automatic. The result? I’ve started from the latest git revision of ASDF, which is 7b7b9f0 and ahead of 3.1.7.19 by 3 commits. Consequently, you can find the results of my testing at:
http://139.162.161.212/asdf/3.1.7.19-3-7b7b9f0/status
(Yes, I haven’t bothered with a proper name. Not sure how permanent this all is)
This will tell you that - 2 tests fail on mkcl-1.1.9-154-1e72d5d, as is already known. - 2 tests still fail on the hobbyist edition of lispworks because there’s no way to check if a lispworks installation provides a proper `deliver` function or a dummy (the hobbyistDV edition would pass these tests)
And also that - I hacked around the bogus warning that lispworks 6.1.x gives so that on my machine, it passes all tests (on somebody else’s, it wouldn’t) - Allegro CL is not yet in there because I have yet to find a way to compute a proper version string that takes patches into account. The version I have passes all tests, though.
All the corresponding logs can be found in the parent directory, which is
http://139.162.161.212/asdf/3.1.7.19-3-7b7b9f0/
In summary, on Linux, the MKCL issue that we already know about, is the sole regression for now.
Elias
On Mon, Sep 12, 2016 at 7:13 PM, Elias Pipping pipping.elias@icloud.com wrote:
On 12 Sep 2016, at 23:33, Robert Goldman rpgoldman@sift.net wrote:
I ran the tests again on all three platforms.
Linux:
I’ve run tests on Linux again, now, too.
Unexpected test success on ecl-bytecodes (ECL 16.1.2) in this block:
;; forced, it should be later (DBG "Check that force reloading loads again") (setf test-package::*file3* :reset) (load-system 'test-asdf/force :force :all) (assert-compare (>= (get-file-stamp file1) file1-date)) (assert-equal test-package::*file3* t)
I have the same unexpected success with ecl_bytecodes on Linux x64. Pushed fix.
I do *not* see this on ECL non-bytecodes. The tests here fail as before.
I see all tests passing on the latest ECL 16.1.2 from git ca7f510 on Linux x64, both with and without bytecodes. Native ECL had an intermittent non-reproducible failure in test-bundle making monolithic dlls, though.
I’ve hit the following regressions, some of which overlap with what you see:
- ECL 16.1.2 and newer fail test3.script in regular mode
- ECL 16.1.2 and newer fail test-force.script in ecl_bytescodes mode(+)
- SBCL 1.1.13 now fails plenty of tests (11 to be precise). SBCL 1.3.9 and later are fine(++)
- MKCL-git(*) now fails test-make-build.script and test-program.script(**)
(+) I don’t typically run such tests. It seems I should. (++) I did not test anything between 1.1.13 and 1.3.9 (*) needs to be very recent (**) that’s what https://github.com/jcbeaudoin/MKCL/issues/9 is about
The MKCL failures are expected.
I don't have an old SBCL to test with. Can you send me the failure logs?
PS: as for touch-file, it only modifies the asdf-cache by default; it won't hit the filesystem unless you explicitly use :in-filesystem t.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Endures the belief in Government "our" friend, no reform is possible. Perishes the superstition, only abolition is conceivable.
On 9/12/16 Sep 12 -8:54 PM, Faré wrote:
PS: as for touch-file, it only modifies the asdf-cache by default; it won't hit the filesystem unless you explicitly use :in-filesystem t.
OK, I was confused by the extremely odd conditional in the middle of that function:
See the following:
(unless in-filesystem (error "Y U NO use stamp cache?"))
(line 323 of script-support.lisp)
This is pretty odd, because it's only reachable if.... (NOT IN-FILESYSTEM).
I'm going to kill that UNLESS. I'll put it back if it's useful.
So this means it's still a mystery that I'm getting all these windows failures.
I'd like to see why that's happening before we press on to other issues, since it's definitely a regression.
best, r
On 9/12/16 Sep 12 -9:26 PM, Robert Goldman wrote:
On 9/12/16 Sep 12 -8:54 PM, Faré wrote:
PS: as for touch-file, it only modifies the asdf-cache by default; it won't hit the filesystem unless you explicitly use :in-filesystem t.
OK, I was confused by the extremely odd conditional in the middle of that function:
See the following:
(unless in-filesystem (error "Y U NO use stamp cache?"))(line 323 of script-support.lisp)
This is pretty odd, because it's only reachable if.... (NOT IN-FILESYSTEM).
I'm going to kill that UNLESS. I'll put it back if it's useful.
Actually, the more I look at this, the more odd it seems.
We don't simply use the cache if IN-FILESYSTEM is NIL -- we do it only if IN-FILESYSTEM is NIL and *ASDF-CACHE* is bound (and we check the latter first).
Can't we just branch on IN-FILESYSTEM, and error out if (NOT IN-FILESYSTEM) and *ASDF-CACHE* is NIL? In that case, the programmer has said: "I want to use the cache," and we are quietly ignoring the request and using the filesystem. I'd rather we blow up when we flout the programmer's directive, instead of trying to DWIM it in a weird way.
Is that an acceptable mod? I'm going to push a candidate patch.
Cheers, r
-
Elias Pipping -
Faré -
Robert Goldman