Here is a patch to add the allegro 8-bit character executables to the test cases in run-tests.sh.
Also here is an updated version of my little "run" script (which is to be used in the parent of the asdf/ directory) which now automatically sets the executables based on the running OS.
I'm still having intermittent failures of test-encodings.script on mlisp8.exe, and test-stamp-propogation.script on alisp8.exe. These may be spurious failures because when I run them with a clean build/ directory, they seem to pass. If I can get them to fail reliably I will report it otherwise I don't want to hold up the release because of this.
Best Regards
Dave
Let's go Tigers!
On Thu, Oct 17, 2013 at 4:59 PM, Dave Cooper david.cooper@genworks.comwrote:
On Thu, Oct 17, 2013 at 4:41 PM, Faré fahree@gmail.com wrote:
Do you have a transcript for the remaining failure with test-encodings on mlisp8 or such?
I don't. I re-ran the tests a few times and could not reproduce the failure. I'll run everything from the top with a fresh build/ directory a bit later, with your test-utilities.script workaround, and see if any of the failures pop up again.
Patch applied and pushed.
If/when you get an intermittent failure, can you grab the error output? Is it "just" a case of polluted fasl cache between alisp and alisp8?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Knowing that 95% of what journalists write and say about topics you know well is grossly incorrect, how can you trust what they say or write on other topics?
On Thu, Oct 17, 2013 at 11:39 PM, Dave Cooper david.cooper@genworks.com wrote:
Here is a patch to add the allegro 8-bit character executables to the test cases in run-tests.sh.
Also here is an updated version of my little "run" script (which is to be used in the parent of the asdf/ directory) which now automatically sets the executables based on the running OS.
I'm still having intermittent failures of test-encodings.script on mlisp8.exe, and test-stamp-propogation.script on alisp8.exe. These may be spurious failures because when I run them with a clean build/ directory, they seem to pass. If I can get them to fail reliably I will report it otherwise I don't want to hold up the release because of this.
On Fri, Oct 18, 2013 at 12:16 AM, Faré fahree@gmail.com wrote:
If/when you get an intermittent failure, can you grab the error output? Is it "just" a case of polluted fasl cache between alisp and alisp8?
I didn't succeed in getting any more yet.
But I did get a stamp-propagation-test failure on SBCL/Linux (attached).
There is also a test-multiple failure in there, but that's because I am running Linux in a mounted VM guest filesystem which doesn't allow symbolic linking (it comes back with "Read-only Filesystem" when you try to make a symbolic link in an OS terminal shell). I wonder if this test can query the OS somehow to see if the current filesystem allows symbolic links, and don't try to make them if not.
Also attached is a patch which makes the output *.text files in build/results/ be os-specific, to allow for running the tests in the same asdf/ directory mounted across multiple machines.
There are other outputs (e.g. fasl cache directories) which I feel also ought to be named in an os-specific manner, to support running the tests from a common directory across all machines. But the bootstrapping issues involved with that are a bit beyond obvious to me at first glance --- presumably some of these names would have to be determined in script-support.lisp, before asdf is loaded with its "detect-os" etc. goodness. So I guess a subset of that functionality would have to be copied into script-support.lisp.
1- these tests really aren't geared to be run concurrently by two (or more) implementations at once. Some tests, such as the stamp propagation test or the other that failed, do various side-effects to the filesystem, to check how asdf responds to them. Therefore, until this is fixed, it does not necessarily make sense to try to distinguish multiple systems that share the same results directory at once, etc.
2- Yes, there is a bootstrap problem with putting things in implementation dependent directories before the UIOP support for that has been loaded. That's why I don't try, and there are parts of the system that use cruder techniques.
3- Resolving all these issues is not impossible, but doing it right, especially without massive inefficiency or unmaintainability, is more work than I'm willing to put at present.
Therefore, I don't feel your patch as is is ready for inclusion — much more work needed.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If it's not worth doing right, it's not worth doing. — Scott McKay
On Fri, Oct 18, 2013 at 1:41 AM, Dave Cooper david.cooper@genworks.com wrote:
On Fri, Oct 18, 2013 at 12:16 AM, Faré fahree@gmail.com wrote:
If/when you get an intermittent failure, can you grab the error output? Is it "just" a case of polluted fasl cache between alisp and alisp8?
I didn't succeed in getting any more yet.
But I did get a stamp-propagation-test failure on SBCL/Linux (attached).
There is also a test-multiple failure in there, but that's because I am running Linux in a mounted VM guest filesystem which doesn't allow symbolic linking (it comes back with "Read-only Filesystem" when you try to make a symbolic link in an OS terminal shell). I wonder if this test can query the OS somehow to see if the current filesystem allows symbolic links, and don't try to make them if not.
Also attached is a patch which makes the output *.text files in build/results/ be os-specific, to allow for running the tests in the same asdf/ directory mounted across multiple machines.
There are other outputs (e.g. fasl cache directories) which I feel also ought to be named in an os-specific manner, to support running the tests from a common directory across all machines. But the bootstrapping issues involved with that are a bit beyond obvious to me at first glance --- presumably some of these names would have to be determined in script-support.lisp, before asdf is loaded with its "detect-os" etc. goodness. So I guess a subset of that functionality would have to be copied into script-support.lisp.
-- My Best,
Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype)
Therefore, I don't feel your patch as is is ready for inclusion — much more work needed.
Fine.
So I update my toplevel "run" script (attached) to make a separate asdf/ directory for each OS, thereby keeping things entirely partitioned but allowing to run the same toplevel script everywhere.
This "run" script does an
rsync -aL --delete
in order to clone the asdf/ directory to the os-specific one, so it has the effect of starting with a fresh asdf directory every time (i.e. with the build/ directory cleared out).
Also attached is another patch which protects the test-multiple.script from failure when the filesystem does not support symbolic links (e.g. in a virtualbox guest folder shared from the virtualbox host). This patch also adds the ability to set an ALLEGRO_NOISY environment variable so that Allegro on Windows will pop up the consoles (useful for cases when there are failures and you need to be able to capture the output).
I am reliably replicating test-encoding.script failures now with alisp8 and mlisp8 on Windows and Linux. I will send that output separately.
I am also still getting intermittent test-stamp-propagation failures, but these seem to be more rare since I am starting with clean asdf directory for each set of test runs. But the next time I do get one I will provide the output.
So I update my toplevel "run" script (attached) to make a separate asdf/ directory for each OS, thereby keeping things entirely partitioned but allowing to run the same toplevel script everywhere.
This "run" script does an
rsync -aL --delete
in order to clone the asdf/ directory to the os-specific one, so it has the effect of starting with a fresh asdf directory every time (i.e. with the build/ directory cleared out).
Yup, I fear that's the safe way to go, for now.
Also attached is another patch which protects the test-multiple.script from failure when the filesystem does not support symbolic links (e.g. in a virtualbox guest folder shared from the virtualbox host). This patch also adds the ability to set an ALLEGRO_NOISY environment variable so that Allegro on Windows will pop up the consoles (useful for cases when there are failures and you need to be able to capture the output).
Applied, with trivial cleanups.
I am reliably replicating test-encoding.script failures now with alisp8 and mlisp8 on Windows and Linux. I will send that output separately.
I am also still getting intermittent test-stamp-propagation failures, but these seem to be more rare since I am starting with clean asdf directory for each set of test runs. But the next time I do get one I will provide the output.
Excellent. I'm looking forward to fixing those intermittent failures.
Duane Rettig replied about char-code-limit; it's a known issue and not a bug, but a arguably justified design choice. Allegro has a excl:real-char-code-limit variable (as opposed to the more rigid char-code-limit constant) for these situations. I patched our tests already.
Regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "'Need' now means wanting someone else's money. 'Greed' means wanting to keep your own. 'Compassion' is when a politician arranges the transfer." — Joseph Sobran
On Fri, Oct 18, 2013 at 4:02 PM, Faré fahree@gmail.com wrote:
I am reliably replicating test-encoding.script failures now with alisp8
and
mlisp8 on Windows and Linux. I will send that output separately.
Here is a patch (with respect to d20ea551c018c46439874f6911e4522289c1196a which you just pushed) which should take care of the test-encodings.script failures. The issue in my case was that I was running tests for alisp followed by alisp8. The asdf/build/fasls/alisp/asdf.fasl was being created originally by alisp, then loaded unmodified by alisp8. Because the pushnew of the :asdf-unicode onto *features* was being hard-coded into that fasl by alisp at compile time, this feature was coming into the system when asdf.fasl was being loaded into alisp8. So alisp8 ended up incorrectly thinking that it had :asdf-unicode, which caused test-encodings.script to become confused.
Same deal with mlisp/mlisp8.
Of course when I ran a fresh test only with alisp8, this problem was not presenting.
One might argue that the fasls for alisp and alisp8 (similarly mlisp and mlisp8) should be separated. And in full ASDF of course this is done already with the implementation-identifier --- so one would never have noticed the issue in day-to-day operational use of ASDF.
But separating the fasls between mlisp/mlisp8 and alisp/alisp8 should not be necessary; in Allegro you are supposed to be able to compile a fasl with alisp (mlisp) and load it with alisp8 (mlisp8), and vice-versa. It's specifically designed to be able to do this. So even though ASDF normally separates its fasls in production use, I still think code should be written so as not to violate the expected ability to compile interchangeably like this (note that it's also supported to compile a fasl with mlisp and load it with alisp (but not the other way around) --- but that's a different issue entirely).
I am also still getting intermittent test-stamp-propagation failures, but
these seem to be more rare since I am starting with clean asdf directory
for
each set of test runs. But the next time I do get one I will provide the output.
Excellent. I'm looking forward to fixing those intermittent failures.
This has not popped up again. All 15 tests in the attached "run" script now run to completion with no failures. So I'm going to leave it be for right now...
My Best,
Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699
On Fri, Oct 18, 2013 at 5:01 PM, Dave Cooper david.cooper@genworks.com wrote:
On Fri, Oct 18, 2013 at 4:02 PM, Faré fahree@gmail.com wrote:
I am reliably replicating test-encoding.script failures now with alisp8 and mlisp8 on Windows and Linux. I will send that output separately.
Here is a patch (with respect to d20ea551c018c46439874f6911e4522289c1196a which you just pushed) which should take care of the test-encodings.script failures. The issue in my case was that I was running tests for alisp followed by alisp8. The asdf/build/fasls/alisp/asdf.fasl was being created originally by alisp, then loaded unmodified by alisp8. Because the pushnew of the :asdf-unicode onto *features* was being hard-coded into that fasl by alisp at compile time, this feature was coming into the system when asdf.fasl was being loaded into alisp8. So alisp8 ended up incorrectly thinking that it had :asdf-unicode, which caused test-encodings.script to become confused.
Same deal with mlisp/mlisp8.
OK, I pushed something along the same idea, except also patching uiop/stream.lisp to match the behavior.
But separating the fasls between mlisp/mlisp8 and alisp/alisp8 should not be necessary; in Allegro you are supposed to be able to compile a fasl with alisp (mlisp) and load it with alisp8 (mlisp8), and vice-versa.
I'm curious about what happens to string with non-latin1 characters in them: do they cause the loading to abort, or are they interned as string with different lengths depending on the unicode support? (Similarly for latin1 strings that are malformed as utf-8.)
I am also still getting intermittent test-stamp-propagation failures,
This has not popped up again.
I'll ascribe that to interferences between multiple implementations formerly sharing the same directory simultaneously, then (assuming they used to).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If mice were the ultimate input device, humans would be born with one arm and three fingers.
On Fri, Oct 18, 2013 at 6:11 PM, Faré fahree@gmail.com wrote:
I'm curious about what happens to string with non-latin1 characters in them: do they cause the loading to abort, or are they interned as string with different lengths depending on the unicode support? (Similarly for latin1 strings that are malformed as utf-8.)
For attached file unicode.lisp:
on Linux:
In mlisp: ======= cl-user> (excl:locale-external-format excl:*locale*) #<external-format :utf8 [(crlf-base-ef :utf8)] @ #x2013f322> cl-user> (load (compile-file "/tmp/unicode.lisp")) ;;; Compiling file /tmp/unicode.lisp ;;; Writing fasl file /tmp/unicode.fasl ;;; Fasl write complete ; Fast loading /tmp/unicode.fasl t cl-user> *ch-string* "选项" cl-user> (aref *ch-string* 0) #\选 cl-user> (aref *ch-string* 1) #\项 cl-user> (char-code (aref *ch-string* 0)) 36873 cl-user> (char-code (aref *ch-string* 1)) 39033 cl-user>
then in alisp8: ============ CL-USER> (excl:locale-external-format excl:*locale*) #<EXTERNAL-FORMAT :LATIN1 [(CRLF-BASE-EF :LATIN1)] @ #x20094152> CL-USER> (load "/tmp/unicode.fasl") ; Fast loading /tmp/unicode.fasl T CL-USER> *ch-string* "??" CL-USER> (aref *ch-string* 0) #? CL-USER> (aref *ch-string* 1) #? CL-USER> (char-code (aref *ch-string* 0)) 63 CL-USER> (char-code (aref *ch-string* 1)) 63 CL-USER> (char-code (aref *ch-string* 2)) ; Evaluation aborted on #<TYPE-ERROR @ #x224ad05a>. CL-USER> (load (compile-file "/tmp/unicode.lisp")) ;;; Compiling file /tmp/unicode.lisp ;;; Writing fasl file /tmp/unicode.fasl ;;; Fasl write complete ; Fast loading /tmp/unicode.fasl T CL-USER> *ch-string* "选项" CL-USER> (aref *ch-string* 0) #\é CL-USER> (aref *ch-string* 1) #%null CL-USER> (aref *ch-string* 2) #%tab CL-USER> (aref *ch-string* 3) #\é CL-USER> (aref *ch-string* 4) #\¡ CL-USER> (aref *ch-string* 5) #\¹ CL-USER> (aref *ch-string* 6) ; Evaluation aborted on #<TYPE-ERROR @ #x220d29f2>. CL-USER> (char-code (aref *ch-string* 0)) 233 CL-USER> (char-code (aref *ch-string* 1)) 128 CL-USER> (char-code (aref *ch-string* 2)) 137 CL-USER> (char-code (aref *ch-string* 3)) 233 CL-USER> (char-code (aref *ch-string* 4)) 161 CL-USER> (char-code (aref *ch-string* 5)) 185
On Windows:
in mlisp: =======
cl-user> (excl:locale-external-format excl:*locale*) #<external-format :|1252| ['(:e-crlf :1252-base)] @ #x202bda2a> cl-user> (load (compile-file "~/genworks/tmp/unicode.lisp" :external-format :utf-8)) ;;; Compiling file C:\Users\dcooper8\genworks\tmp\unicode.lisp ;;; Writing fasl file C:\Users\dcooper8\genworks\tmp\unicode.fasl ;;; Fasl write complete ; Fast loading C:\Users\dcooper8\genworks\tmp\unicode.fasl t
;;; ;;; ;;; ;; The rest is the same as Linux -- but note that on Windows you have to ;; say (compile-file ... :external-format :utf-8), because the default ;; external-format is '(:e-crlf :1252-base) while on Linux it's already ;; (crlf-base-ef :utf8) (at least in my locale). ;;
I'm not sure how to make a latin1 string which is malformed as utf-8.
For attached file unicode.lisp [...]
So allegro stores the strings in utf-8 (as confirmed by looking at a trivial fasl), and when a non-latin1 (or cp1252) character is interned from the fasl in a 8-bit variant, it becomes #?. That makes sense.
I'm not sure how to make a latin1 string which is malformed as utf-8.
You just did.
echo 选项 | recode u8..l1 | recode u8..u2 recode: Invalid input in step `UTF-8..ISO-10646-UCS-2'
Thanks a lot! This closes this investigation of strings in allegro. Can you test that the latest checkout passes the test on mlisp8?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The difference between a programmer and a user, is that the programmer knows there is no difference between using and programming. — Faré
On Sat, Oct 19, 2013 at 11:51 AM, Faré fahree@gmail.com wrote:
Can you test that the latest checkout passes the test on mlisp8?
test-force.script appears to be failing on all platforms (e.g. see attached).
If i run interactively I get "Y U NO use stamp cache" (I'm sure you know it already):
bob:~ dcooper8$ cd genworks/cl/tests/asdf/asdf-macos/test bob:test dcooper8$ /Users/dcooper8/genworks/cl-engines/ccl-mac-1.9/dx86cl64 --no-init --quiet Welcome to Clozure Common Lisp Version 1.9-r15759 (DarwinX8664)! ? '(#.(load "script-support.lisp") #.(asdf-test::da) #.(load-asdf) #.(frob-packages) #.(load "test-force.script"))
;Loading #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/build/fasls/ccl/asdf.dx64fsl"...Configuring ASDF Enabling debugging Being a bit verbose Comparing directories *TEST-DIRECTORY* and X both evaluate to same path: #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/test/" Frob packages ;Loading #P"test-force.script"... ;Loading #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/test/test-force.asd"... ;Loading #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/build/fasls/ccl-1.9-f96-macosx-x64/asdf/test/file1.dx64fsl"...
Error: Y U NO use stamp cache? While executing: TOUCH-FILE, in process listener(1). Type :POP to abort, :R for a list of available restarts. Type :? for other options.
1 >
On Sat, Oct 19, 2013 at 12:16 PM, Dave Cooper david.cooper@genworks.comwrote:
On Sat, Oct 19, 2013 at 11:51 AM, Faré fahree@gmail.com wrote:
Can you test that the latest checkout passes the test on mlisp8?
test-force.script appears to be failing on all platforms (e.g. see attached).
-- My Best,
Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699
On Sat, Oct 19, 2013 at 12:16 PM, Dave Cooper david.cooper@genworks.com wrote:
Can you test that the latest checkout passes the test on mlisp8?
Actually, that would have been "check that mlisp8 passes with a asdf.fasl produced by mlisp", and conversely.
test-force.script appears to be failing on all platforms (e.g. see attached).
Your attachment shows ccl failing on a test that I have disabled some time ago, and failure in test-force.
#-(and clozure os-windows) ;; http://trac.clozure.com/ccl/ticket/1118 (assert-equal '(:ok 1) (run-program '("echo" ":ok 1") :output :forms))
If i run interactively I get "Y U NO use stamp cache" (I'm sure you know it already):
Oops, I should update the instructions on how to reproduce bugs at the REPL, by including a with-asdf-cache in them. I have no time to do that now, but maybe you do.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org As for poverty, no one need be ashamed to admit it: the real shame is in not taking practical measures to escape from it. — Perikles
On Sat, Oct 19, 2013 at 12:26 PM, Faré fahree@gmail.com wrote:
test-force.script appears to be failing on all platforms (e.g. see attached).
Your attachment shows ccl failing on a test that I have disabled some time ago, and failure in test-force.
No, it doesn't. The only failing test in there is the test-force one.
But, it's very strange. I didn't change anything, started the tests again fresh, and all passing now (including running the alisp before alisp8 and mlisp before mlisp8, so that the latters are using the asdf.fasl's from the formers).
Possibly something was in a weird state with my filesystem or clocks (clocks seem fine)? I ran this stuff in a completely fresh directory (not under Dropbox --- i've wised up about trying to put under Dropbox folders which have a lot of automatic creations/deletions going on - Dropbox has epileptic fits with those). Anyway I'll create another completely fresh folder with a fresh git clone, and run them all one more time for good measure.
Oops, I should update the instructions on how to reproduce bugs at the REPL, by including a with-asdf-cache in them. I have no time to do that now, but maybe you do.
Ok, I'll look at it.
Your attachment shows ccl failing on a test that I have disabled some time ago, and failure in test-force.
No, it doesn't. The only failing test in there is the test-force one.
My apologies, I was looking at a same-named older log.
Weird, it works for me on Linux.
But, it's very strange. I didn't change anything, started the tests again fresh, and all passing now (including running the alisp before alisp8 and mlisp before mlisp8, so that the latters are using the asdf.fasl's from the formers).
Possibly something was in a weird state with my filesystem or clocks (clocks seem fine)? I ran this stuff in a completely fresh directory (not under Dropbox --- i've wised up about trying to put under Dropbox folders which have a lot of automatic creations/deletions going on - Dropbox has epileptic fits with those). Anyway I'll create another completely fresh folder with a fresh git clone, and run them all one more time for good measure.
If I hadn't long ago added this asdf-cache with file dates being modified in the cache rather than on the filesystem, I'd say a bug with test-force might be a symptom of clock skew or something.
Now, it's possible that the test is failing to touch files in the cache the same way that they are used in the test, because of all the pathname normalizations that may happen, but that the discrepancy somehow only shows up on Windows. Ahem. Maybe I could normalize this cache by using the namestring or native-namestring as the key, instead of the pathname object? Probably.
OK, done, please try again (sigh).
Oops, I should update the instructions on how to reproduce bugs at the REPL, by including a with-asdf-cache in them. I have no time to do that now, but maybe you do.
Ok, I'll look at it.
Thanks. I pushed that together with other modifications.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Politics" is made up of two words, "Poli", which is Greek for "many", and "tics", which are blood sucking insects. — Gore Vidal
On Sat, Oct 19, 2013 at 2:34 PM, Faré fahree@gmail.com wrote:
Now, it's possible that the test is failing to touch files in the cache the same way that they are used in the test, because of all the pathname normalizations that may happen, but that the discrepancy somehow only shows up on Windows.
The failure was happening on MacOS, Linux, and Windows --- not just on Windows.
Ahem. Maybe I could normalize this cache by using the namestring or native-namestring as the key, instead of the pathname object? Probably.
OK, done, please try again (sigh).
Starting from a fresh git clone of asdf (which was reliably producing the problem previously), now we don't get any failures with test-force.script on any platforms.
But I am still getting stamp-propagation failures on Windows with mlisp after having run mlisp8 (and I think it would also fail if running mlisp8 after mlisp). I will send the console output from that separately. I suspect this is indeed an issue with files left over after the run of mlisp polluting the mlisp8 run. I'll confirm that by clearing build/ before each run and see if the failures still occur.
Regarding the touching of files: does the below transcript look correct? (this is on CCL/Mac, and look at the bottom where i check the file-stamp after having done the touch-file):
bash-3.2$ /Users/dcooper8/genworks/cl-engines/ccl-mac-1.9/dx86cl64 --no-init --quiet Welcome to Clozure Common Lisp Version 1.9-r15759 (DarwinX8664)! ? (load "script-support.lisp") #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/test/script-support.lisp" ? (asdf-test::da) #<Package "ASDF-TEST"> ? (load-asdf) ;Loading #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/build/fasls/ccl/asdf.dx64fsl"...Configuring ASDF Enabling debugging Being a bit verbose Comparing directories *TEST-DIRECTORY* and X both evaluate to same path: #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/test/" T ? (frob-packages) Frob packages T ? (load-system 'test-force) ;Loading #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/test/test-force.asd"... ;Loading #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/build/fasls/ccl-1.9-f96-macosx-x64/asdf/test/file1.dx64fsl"... T ? (defparameter file1 (test-fasl "file1")) FILE1 ? (defparameter file1-date (file-write-date file1)) FILE1-DATE ? (defparameter date1 (- file1-date 600)) DATE1 ? (defparameter date2 (- file1-date 300)) DATE2 ? file1 #P"/Users/dcooper8/genworks/cl/tests/asdf/asdf-macos/build/fasls/ccl-1.9-f96-macosx-x64/asdf/test/file1.dx64fsl" ? file1-date 3591196920 ? (file-write-date "test-force.asd") 3591196848 ? (get-file-stamp "test-force.asd") 3591196848 ? (asdf/cache:with-asdf-cache () (get-file-stamp "test-force.asd")) 3591196848 ? date1 3591196320 ? (asdf/cache:with-asdf-cache () (touch-file "test-force.asd" :timestamp date1)) 3591196320 ? (asdf/cache:with-asdf-cache () (get-file-stamp "test-force.asd")) 3591196848 ?
But I am still getting stamp-propagation failures on Windows with mlisp
after having run mlisp8 (and I think it would also fail if running mlisp8 after mlisp). I will send the console output from that separately.
Said console output is attached.
I suspect this is indeed an issue with files left over after the run of mlisp polluting the mlisp8 run. I'll confirm that by clearing build/ before each run and see if the failures still occur.
Doing this now and will report...
But I am still getting stamp-propagation failures on Windows with mlisp after having run mlisp8 (and I think it would also fail if running mlisp8 after mlisp). I will send the console output from that separately.
That makes sense: the test includes a test of the time propagation bug for the native defsystem, and then the lack of output-translations on said native defsystem will cause issues.
Maybe we should just disable the native test for now. It's not testing ASDF itself, anyway.
If you have time, you can add a clearing of the fasls in the native defsystem test. And with even more time, transform the test so that in the ASDF case, it touches or deletes files in the asdf timestamp cache rather than do it in the filesystem (the trick obviously won't work for the native defsystem test).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The American Republic will endure, until politicians realize they can bribe the people with their own money. — Alexis de Tocqueville
On Sat, Oct 19, 2013 at 3:34 PM, Faré fahree@gmail.com wrote:
But I am still getting stamp-propagation failures on Windows with mlisp after having run mlisp8 (and I think it would also fail if running
mlisp8
after mlisp). I will send the console output from that separately.
That makes sense: the test includes a test of the time propagation bug for the native defsystem, and then the lack of output-translations on said native defsystem will cause issues.
Maybe we should just disable the native test for now. It's not testing ASDF itself, anyway.
If you have time, you can add a clearing of the fasls in the native defsystem test.
Ok here's a patch for that.
It seems to fix things for allegro/Windows, but now it reared its head again on sbcl/Windows.
The failure is always the same:
These two expressions fail comparison with EQUAL: (ASDF-TEST::SANITIZE-LOG (ASDF-TEST::RELOAD ASDF/DEFSYSTEM:DEFSYSTEM)) evaluates to ((:COMPILING :SYSTEM)) (QUOTE ((:COMPILING :SYSTEM) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2))) evaluates to ((:COMPILING :SYSTEM) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2))
A couple of things I cannot figure out:
1. How on earth does the following work on Windows without throwing an error:
(uiop:run-program `("touch" ,(native-namestring filename)) :output t :error-output t)
as far as I know there is no "touch" command on Windows, and when I try this at the command line I get "starting shell command resulted in error..."
2. By the way, for the ASDF tests, am I clearing the correct fasl files?
And with even more time, transform the test so that in the ASDF case,
it touches or deletes files in the asdf timestamp cache rather than do it in the filesystem (the trick obviously won't work for the native defsystem test).
I'm fairly sure I would screw things up if I tried that with my current level of understanding...
On Sat, Oct 19, 2013 at 5:33 PM, Dave Cooper david.cooper@genworks.comwrote:
Ok here's a patch for that.
It seems to fix things for allegro/Windows, but now it reared its head again on sbcl/Windows.
Welp, it just happened again on alisp -- and that was in a clean build/ directory before any other tests had run (alisp was the first in the list).
I'm pretty sure these test-stamp-propagation failures are only happening on Windows now.
More curious than ever now about how we think we're doing "touch" on Windows...
I committed a variant of your patch. See 3.0.2.30.
Can you send a failure log?
Touch is not part of Windows, but it's probably part of either cygwin or msys or whichever add-on you run the test scripts with.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Yield to temptation; it may never pass your way again. — Robert Heinlein, "Time Enough For Love"
On Sat, Oct 19, 2013 at 5:39 PM, Dave Cooper david.cooper@genworks.com wrote:
On Sat, Oct 19, 2013 at 5:33 PM, Dave Cooper david.cooper@genworks.com wrote:
Ok here's a patch for that.
It seems to fix things for allegro/Windows, but now it reared its head again on sbcl/Windows.
Welp, it just happened again on alisp -- and that was in a clean build/ directory before any other tests had run (alisp was the first in the list).
I'm pretty sure these test-stamp-propagation failures are only happening on Windows now.
More curious than ever now about how we think we're doing "touch" on Windows...
On Sat, Oct 19, 2013 at 7:43 PM, Faré fahree@gmail.com wrote:
I committed a variant of your patch. See 3.0.2.30.
With this pulled, test-stamp-propagation started failing even more reliably (on Windows only), usually on the first or second lisp being run.
I remembered reading somewhere (I think some things Gary Byers was saying on openmcl-devel) that Windows does not always have particularly fine-grained timing facilities. So I thought maybe 2 seconds sleep was not enough to wait before touching files, and increased that to 5 seconds for Windows, as reflected in the attached patch.
With this change, I ran test-stamp-propagation on all the platforms three times through, all passing.
For good measure I also bumped the sleep for non-os-windows to 3 seconds from 2.
Maybe it's not necessary to clear the build/ directory before each set of tests anymore. I'll play with that a little bit.
Touch is not part of Windows, but it's probably part of either cygwin
or msys or whichever add-on you run the test scripts with.
Oh ya. It does work when the lisp is invoked from cygwin. So touch is not assumed to be there in normal asdf, only during the tests, right? Then no prob.
OK, so I've patched test-stamp-propagation so it will use the timestamp cache when available. This should make the test more deterministic on all platforms when using ASDF. I left your increased sleep delay for other defsystems and/or ASDF with cache disabled (or old ASDF without cache).
The complexity of ASDF and its test suite is a testament to the horror of portability in CL. That ASDF and its test suite are possible at all is a testament to the compatibility between the many maintained CL implementations across many operating systems.
Do all tests pass now on all platforms including Windows? Is there any obstacle to release left?
PS: someone ought to examine the stamp propagation failure on ABCL and XCL (that share a lot of their runtime). But not me.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I used to like the government, but that was before it got big and popular.
On Sat, Oct 19, 2013 at 10:51 PM, Dave Cooper david.cooper@genworks.com wrote:
On Sat, Oct 19, 2013 at 7:43 PM, Faré fahree@gmail.com wrote:
I committed a variant of your patch. See 3.0.2.30.
With this pulled, test-stamp-propagation started failing even more reliably (on Windows only), usually on the first or second lisp being run.
I remembered reading somewhere (I think some things Gary Byers was saying on openmcl-devel) that Windows does not always have particularly fine-grained timing facilities. So I thought maybe 2 seconds sleep was not enough to wait before touching files, and increased that to 5 seconds for Windows, as reflected in the attached patch.
With this change, I ran test-stamp-propagation on all the platforms three times through, all passing.
For good measure I also bumped the sleep for non-os-windows to 3 seconds from 2.
Maybe it's not necessary to clear the build/ directory before each set of tests anymore. I'll play with that a little bit.
Touch is not part of Windows, but it's probably part of either cygwin or msys or whichever add-on you run the test scripts with.
Oh ya. It does work when the lisp is invoked from cygwin. So touch is not assumed to be there in normal asdf, only during the tests, right? Then no prob.
-- My Best,
Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype)
Oops, I should update the instructions on how to reproduce bugs at the
REPL, by including a with-asdf-cache in them. I have no time to do that now, but maybe you do.
Ok, I'll look at it.
Please see attached.
-
Dave Cooper -
Faré -
Genworks Support