Re: trying some ASuDF tests on Windows (was: Re: [asdf-devel] Volunteer for LispWorks testing?)
Fare wrote:
The test-bundle.script output suggests that, on Windows, there might be a bug in ccl:fasl-concatenate. Please create a reduced test, and open a bug against CCL if that is indeed the case, using http://trac.clozure.com/ccl/newticket
Ok, I went ahead and opened a CCL bug, which was (almost immediately) reported as fixed in the subversion trunk and the ticket (#1109) was closed. Then I built a CCL from the trunk (which is 1.10-dev), and indeed this failure goes away when using 1.10-dev. See the results in the 2013-09-05 folder in the link below.
The test-multiple.script failure reveals an error in run-program, that looks like it does a (cons "cmd" argument) instead of a (list "cmd" argument). Same failure in test-run-program.script.
I tried changing the code in uiop/run-program.lisp from:
#+clozure (cons "cmd" (strcat "/c" command))
to
#+clozure (list "cmd" (strcat "/c" command))
but still get some failures in test-run-program.script. Maybe they are different failures. See results below.
https://www.dropbox.com/sh/jc2cqwpkp06dupm/1FZ_YlVvVW/cl/tests/asdf/output
By the way, the run-program tests seem to use the command "ln" for testing -- this command isn't there by default on Windows, is it?
The issue with ";" vs. ":" for path separator I'm not sure exactly where to fix, so I leave that alone for the time being (anyone else care to jump on it?) --- apparently that's not CCL-specific, but a general Windows asdf testing issue?
On Wed, Sep 4, 2013 at 5:07 PM, Robert P. Goldman rpgoldman@sift.infowrote:
Dave Cooper wrote:
Hi Robert,
[also cc'ing this to asdf-devel in case anyone else has feedback]
Ok, shifting gears a little bit here first...
I'm trying a few test runs of the ASDF test suite on Windows. Platforms on Windows which I have available to test right now are: Allegro CL (several variations), and CCL.
To prepare to run the tests on Windows, I installed cygwin and cygwin's make. Then to run the tests, I do (for lack of having this more automated so far):
set ASDF_TEST_LISPS appropriately.
Edit run-tests.sh to point to appropriate Lisp executables.
You actually shouldn't need to do that -- there is one environment variable for each of the executables, and you can set those, if the default values don't work for you.
3 Invoke "make test-all-no-upgrade" from the cygwin command shell.
Let's try CCL first. Here are the outputs:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/-vvd5gFwTk/cl/tests/asdf/output/2...
Summary: 42 out of 47 pass (5 failures).
I can try to dive into these further, but I thought I would post the results here first in case anything is obvious to anyone.
Incidentally, I have been running ASDF in production with Allegro CL for some time now (including asdf:monolithic-fasl-op) and it has been working well. There are some startup glitches for running ASDF tests on Windows/Allegro right now. After the CCL issue is resolved I will return to trying to get the tests to run for Allegro on Windows.
That would be great.
By the way, the bundle tests aren't working for me on a couple of other lisps.
cheers, r
Ok, I went ahead and opened a CCL bug, which was (almost immediately) reported as fixed in the subversion trunk and the ticket (#1109) was closed. Then I built a CCL from the trunk (which is 1.10-dev), and indeed this failure goes away when using 1.10-dev. See the results in the 2013-09-05 folder in the link below.
Wonderful. Stellar support from the CCL team, as always.
The test-multiple.script failure reveals an error in run-program, that looks like it does a (cons "cmd" argument) instead of a (list "cmd" argument). Same failure in test-run-program.script.
Yeah, this code was obviously never tested on Windows since I last changed it in the hopes of adapting to the latest CCL run-program bug fix.
Please try again with the attached patch (totally untested, since I don't have Windows).
The issue with ";" vs. ":" for path separator I'm not sure exactly where to fix, so I leave that alone for the time being (anyone else care to jump on it?) --- apparently that's not CCL-specific, but a general Windows asdf testing issue?
I pushed an update to these two tests. Please pull and try again.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Certainly the game is rigged. Don't let that stop you; if you don't bet, you can't win. — Robert Heinlein, "Time Enough For Love"
[if this starts to be off-topic for the openmcl-devel list please don't hesitate to ask me to take it off the cc list]
On Thu, Sep 5, 2013 at 6:29 PM, Faré fahree@gmail.com wrote:
Please try again with the attached patch (totally untested, since I don't have Windows).
The issue with ";" vs. ":" for path separator I'm not sure exactly where
to
fix, so I leave that alone for the time being (anyone else care to jump
on
it?) --- apparently that's not CCL-specific, but a general Windows asdf testing issue?
I pushed an update to these two tests. Please pull and try again.
Ok I ran the tests with the rp.diff patch applied and the updates pulled in.
With these changes, we are down to 3 failures: test-multiple.script, test-run-program.script, test-utilities.script.
It looks like the test-multiple.script failure might be because "ln" is not a known command on Windows.
test-run-program.script looks like it's giving Error Code 1 for the command "echo ok 1" which as far as I know should work.
I'm not sure what is going wrong with test-utilities.script.
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
On Thu, Sep 5, 2013 at 7:10 PM, Dave Cooper david.cooper@genworks.com wrote:
[if this starts to be off-topic for the openmcl-devel list please don't hesitate to ask me to take it off the cc list]
Well, it's about getting ccl's run-program to do something useful on Windows, so it's possibly on-topic there.
The issue with ";" vs. ":" for path separator I'm not sure exactly where to fix
I pushed yet another update for these two tests.
test-run-program.script looks like it's giving Error Code 1 for the command "echo ok 1" which as far as I know should work.
Yup, there is one layer of quoting too much, trying to execute a command echo" "ok" "1
Please try again with this updated patch (relative to master HEAD).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The rule is, jam to-morrow and jam yesterday, but never jam today. — Lewis Carroll
On Thu, Sep 5, 2013 at 8:07 PM, Faré fahree@gmail.com wrote:
Please try again with this updated patch (relative to master HEAD).
Now down to 2 failures: test-multiple.script, test-run-program.script
This link has been updated with the results:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
Now down to 2 failures: test-multiple.script, test-run-program.script
This link has been updated with the results:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
OK, getting there. Please pull and try again.
I'm disabling the test in test-multiple that uses ln -s on Windows. Apparently, CCL opens the symlink in a way that accesses the meta data rather than follows the link.
I'm disabling one run-program test on Windows for ./good-shell-command, let's see if other tests pass.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To make war requires the will to act. But to be at war, it suffices to suffer the aggression. Refusing to fight will not bring you peace.
OK, getting there. Please pull and try again.
Still two tests failing. Link updated again with the results:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
On Thu, Sep 5, 2013 at 8:51 PM, Dave Cooper david.cooper@genworks.com wrote:
OK, getting there. Please pull and try again.
Still two tests failing. Link updated again with the results:
Making progress. And again! And again! And again! http://www.youtube.com/watch?v=9VDvgL58h_Y
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Computer programming is omnipotence without omniscience." — Prospero, as cited by Eliezer Yudkowsky
On Thu, Sep 5, 2013 at 9:16 PM, Faré fahree@gmail.com wrote:
Making progress. And again! And again! And again!
Very funny.
With the latest pull, there is only one test failing, one for run-program.
Here is the updated link with results:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
Also (for my own production purposes) I made a local change to make it prepend ("cmd" "/c" ...) for Clozure/Windows when the command is given as a list instead of a string. I'll send that separately as a patch for your consideration. But this patch doesn't fix the one remaining test failure; that is something different.
Testing echo ok 1 via run-program as a list TEST ABORTED: These two expressions fail comparison with EQUAL: '("ok 1") evaluates to ("ok 1") (RUN-PROGRAM '("echo" "ok" "1") :OUTPUT :LINES) evaluates to ("ok 1 ")
So somehow when using Windows, we get an extra space at the end? Madness!
Well, I'm outta here. You get to frob the tests until they pass. You're a big boy and you understand those things as well as I do. Now, where's the booze?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Young man, in mathematics you don't understand things, you just get used to them. — John von Neumann (1903-1957)
On Thu, Sep 5, 2013 at 10:49 PM, Dave Cooper david.cooper@genworks.com wrote:
On Thu, Sep 5, 2013 at 9:16 PM, Faré fahree@gmail.com wrote:
Making progress. And again! And again! And again! http://www.youtube.com/watch?v=9VDvgL58h_Y
Very funny.
With the latest pull, there is only one test failing, one for run-program.
Here is the updated link with results:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
Also (for my own production purposes) I made a local change to make it prepend ("cmd" "/c" ...) for Clozure/Windows when the command is given as a list instead of a string. I'll send that separately as a patch for your consideration. But this patch doesn't fix the one remaining test failure; that is something different.
-- 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
Dave Cooper wrote:
Also (for my own production purposes) I made a local change to make it prepend ("cmd" "/c" ...) for Clozure/Windows when the command is given as a list instead of a string. I'll send that separately as a patch for your consideration. But this patch doesn't fix the one remaining test failure; that is something different.
Can you explain this a little for someone who is not wise in the ways of the Windows?
Isn't "cmd" the equivalent of the shell on windows? If so, aren't we turning RUN-PROGRAM into RUN-SHELL-COMMAND behind the user's back?
Maybe I'm off base....
thanks, r
On Fri, Sep 6, 2013 at 9:47 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Dave Cooper wrote:
Also (for my own production purposes) I made a local change to make it prepend ("cmd" "/c" ...) for Clozure/Windows when the command is given as a list instead of a string. I'll send that separately as a patch for your consideration. But this patch doesn't fix the one remaining test failure; that is something different.
Can you explain this a little for someone who is not wise in the ways of the Windows?
Isn't "cmd" the equivalent of the shell on windows? If so, aren't we turning RUN-PROGRAM into RUN-SHELL-COMMAND behind the user's back?
Indeed, and that's why I'd like not to do it unless strictly necessary. I don't remember why I did it on allegro — that's probably a mistake; I probably did it because otherwise there might be no searching through $PATH. How does the test work on Allegro if you remove the prepending of cmd /c ?
Robert: on Windows, the legacy interface is to pass a string to the program, to be interpreted as multiple arguments by the program itself, which it typically does through the standard C++ library, but might not. However, for backward compatibility reason, the command interpreter doesn't use said library, but interprets the line its own way, which may or may not (hopefully will) lead to the same behavior on properly escaped command lines such as the Lisp implementation will issue.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org That man who dares to waste one hour of time, has not discovered the value of life. — Charles Darwin
On Fri, Sep 6, 2013 at 9:57 PM, Faré fahree@gmail.com wrote:
How does the test work on Allegro if you remove the prepending of cmd /c ?
I will check into this and report back...
On Sat, Sep 7, 2013 at 10:29 AM, Dave Cooper david.cooper@genworks.com wrote:
On Fri, Sep 6, 2013 at 9:57 PM, Faré fahree@gmail.com wrote:
How does the test work on Allegro if you remove the prepending of cmd /c ?
I will check into this and report back...
Ideally there would a test that includes all printable ASCII characters and ensures that quoting works alright, with either a list or string argument (beware quoting when generating the string).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org — Why are you buying this gun? — Why are you asking this question? — It's the law. — I need a gun because people vote laws like that.
On Thu, Sep 5, 2013 at 10:49 PM, Dave Cooper david.cooper@genworks.comwrote:
Also (for my own production purposes) I made a local change to make it prepend ("cmd" "/c" ...) for Clozure/Windows when the command is given as a list instead of a string. I'll send that separately as a patch for your consideration. But this patch doesn't fix the one remaining test failure; that is something different.
Here is the patch to make it prepend ("cmd" "/c") for uiop:run-program for Clozure/Windows list commands, which seems to be the prudent thing to do for Clozure/Windows. The patch is relative to current master HEAD.
Again this does not fix the one outstanding test failure; that is still outstanding in case the spirit moves anyone to look at that before I have a chance to do so. Latest test results continue to be here:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
For the record, I'm not going to apply this patch or anything. I'll let the maintainer decide.
Also, the "ok 1 " might be a bug in CCL if CCL is the one adding a space after the last argument. I'm not going to do any debugging to confirm or infirm. I'll only actively fix bugs I introduced on platforms I can use. Good luck.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Never underestimate the power of human stupidity. — Robert A. Heinlein
On Thu, Sep 5, 2013 at 11:08 PM, Genworks Support support@genworks.com wrote:
On Thu, Sep 5, 2013 at 10:49 PM, Dave Cooper david.cooper@genworks.com wrote:
Also (for my own production purposes) I made a local change to make it prepend ("cmd" "/c" ...) for Clozure/Windows when the command is given as a list instead of a string. I'll send that separately as a patch for your consideration. But this patch doesn't fix the one remaining test failure; that is something different.
Here is the patch to make it prepend ("cmd" "/c") for uiop:run-program for Clozure/Windows list commands, which seems to be the prudent thing to do for Clozure/Windows. The patch is relative to current master HEAD.
Again this does not fix the one outstanding test failure; that is still outstanding in case the spirit moves anyone to look at that before I have a chance to do so. Latest test results continue to be here:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
-- 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
For the record, I don't mean to be directing these emails personally at* *Faré. They are for whomever the spirit moves on the asdf-devel list (i've changed Faré to be a CC here).
With my patch applied, the only failure now has to do with "awkward legacy output capture via run-shell-command."
As far as I'm concerned that test can be retired at some point anyway (personally I'm only interested in uiop:run-program), so I would be ok with leaving this as-is and moving on.
But as far as I can tell, my patch is needed (relative to current master HEAD) for
(run-program '("echo" "ok" "1"))
even to function in CCL/Win. With my patch applied, there is no failure for the
(run-program '("echo" "ok" "1"))
test -- only for the "awkward legacy output capture via run-shell-command" test.
Anyway I'll wait to hear from the maintainer regarding applying that patch.
Latest test results (again) which show that the only failure is for the awkward legacy output thingie (and yes, it has to do with an extra space printed after the "1").
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
On Thu, Sep 5, 2013 at 11:19 PM, Faré fahree@gmail.com wrote:
For the record, I'm not going to apply this patch or anything. I'll let the maintainer decide.
Also, the "ok 1 " might be a bug in CCL if CCL is the one adding a space after the last argument. I'm not going to do any debugging to confirm or infirm. I'll only actively fix bugs I introduced on platforms I can use. Good luck.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Never underestimate the power of human stupidity. — Robert A. Heinlein
On Thu, Sep 5, 2013 at 11:08 PM, Genworks Support support@genworks.com wrote:
On Thu, Sep 5, 2013 at 10:49 PM, Dave Cooper david.cooper@genworks.com wrote:
Also (for my own production purposes) I made a local change to make it prepend ("cmd" "/c" ...) for Clozure/Windows when the command is given
as a
list instead of a string. I'll send that separately as a patch for your consideration. But this patch doesn't fix the one remaining test
failure;
that is something different.
Here is the patch to make it prepend ("cmd" "/c") for uiop:run-program
for
Clozure/Windows list commands, which seems to be the prudent thing to do
for
Clozure/Windows. The patch is relative to current master HEAD.
Again this does not fix the one outstanding test failure; that is still outstanding in case the spirit moves anyone to look at that before I
have a
chance to do so. Latest test results continue to be here:
https://www.dropbox.com/sh/jc2cqwpkp06dupm/G3xWZXMC6b/cl/tests/asdf/output/2...
-- 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 Thu, Sep 5, 2013 at 11:48 PM, Genworks Support support@genworks.com wrote:
For the record, I don't mean to be directing these emails personally at Faré. They are for whomever the spirit moves on the asdf-devel list (i've changed Faré to be a CC here).
I didn't suppose you were, but I wanted to make it clear I am not going to put the energy I used to, or to take responsibility for getting patches applied, even though I may help when for whatever reason I feel concerned. IOW, I'm not a maintainer anymore.
With my patch applied, the only failure now has to do with "awkward legacy output capture via run-shell-command."
Looking at the log with emacs, that's the extra space bug again.
You may want to open a bug against CCL for the extra space: the problem is in the (when strings ...) condition in ccl::make-windows-command-line which should be (when (rest strings) ...) or something.
* (make-windows-command-line '("echo" "ok" "1")) "echo ok 1 " ;; instead of "echo ok 1"
That said, you will probably face many more failures with this file. Have you tried the test suite with SBCL for Windows?
It's OK to #+conditionalize a few annoying tests when implementations fail, though of course we'd ideally get the bugs fixed in the implementations.
But as far as I can tell, my patch is needed (relative to current master HEAD) for test
If that's the patch that always adds cmd /c, I think it is a bad idea, because that's probably not transparent with respect to some special characters interpreted magically by cmd.exe. If someone wants to invoke cmd, he can pass a string to run-program.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A word for the epoch of free software and universal publishing: voluntocracy n 1. governance by those who do the work. 2. the volunteers who do the work. — Aubrey Jaffer, http://swissnet.ai.mit.edu/~jaffer/
-
Dave Cooper -
Faré -
Genworks Support -
Robert P. Goldman