SANO Masatoshi reports that uiop:run-program broke on SBCL/Windows at some point between 3.1.3 and 3.1.5.
Can someone with SBCL and Windows help me debug that? A trace of functions in uiop/run-program and the functions in sb-ext that appear in that file, using ASDF on 3.1.3 and on 3.1.5, on some failed invocation, would help.
A fix before 3.1.6 would be wonderful.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The [classical] liberal, of course, does not deny that there are some superior people — he is not an egalitarian — but he denies that anyone has authority to decide who these superior people are. — F. A. Hayek, "Why I Am Not a Conservative"
Hi,
I tried this expression on sbcl windows x86-64. (uiop/run-program:run-program "c:/windows/system32/tree /?" :output :string) I notice the result changed after commit 94e9f4c0.
on windows platform run-program with :output is :string and :force-shell is T,the result was already broken before the commit. but I didn't notice because I never tried passing :force-shell t. As an uiop user. It is not so hard to avoid the inconvenience,cause :force-shell nil would work like before.
Thanks.
On Thu, Sep 24, 2015 at 8:50 AM, Faré fahree@gmail.com wrote:
SANO Masatoshi reports that uiop:run-program broke on SBCL/Windows at some point between 3.1.3 and 3.1.5.
Can someone with SBCL and Windows help me debug that? A trace of functions in uiop/run-program and the functions in sb-ext that appear in that file, using ASDF on 3.1.3 and on 3.1.5, on some failed invocation, would help.
A fix before 3.1.6 would be wonderful.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The [classical] liberal, of course, does not deny that there are some superior people — he is not an egalitarian — but he denies that anyone has authority to decide who these superior people are. — F. A. Hayek, "Why I Am Not a Conservative"
I see imagine kluge that could make things work under Windows: create a temporary .bat file then execute it with cmd /c foo.bat
Unhappily, I don't have a Windows machine to test on.
Alternatively, fixing SBCL so that :force-shell t works.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A patriot must always be ready to defend his country against his government. — Edward Abbey
On Thu, Sep 24, 2015 at 1:54 AM, SANO Masatoshi snmsts@gmail.com wrote:
Hi,
I tried this expression on sbcl windows x86-64. (uiop/run-program:run-program "c:/windows/system32/tree /?" :output :string) I notice the result changed after commit 94e9f4c0.
on windows platform run-program with :output is :string and :force-shell is T,the result was already broken before the commit. but I didn't notice because I never tried passing :force-shell t. As an uiop user. It is not so hard to avoid the inconvenience,cause :force-shell nil would work like before.
Thanks.
On Thu, Sep 24, 2015 at 8:50 AM, Faré fahree@gmail.com wrote:
SANO Masatoshi reports that uiop:run-program broke on SBCL/Windows at some point between 3.1.3 and 3.1.5.
Can someone with SBCL and Windows help me debug that? A trace of functions in uiop/run-program and the functions in sb-ext that appear in that file, using ASDF on 3.1.3 and on 3.1.5, on some failed invocation, would help.
A fix before 3.1.6 would be wonderful.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The [classical] liberal, of course, does not deny that there are some superior people — he is not an egalitarian — but he denies that anyone has authority to decide who these superior people are. — F. A. Hayek, "Why I Am Not a Conservative"
Will someone please post a launchpad ticket for this? Specifically a launchpad ticket that indicates how to replicate the bug and what the expected and observed behaviors are?
I'll try to test tomorrow, but I don't know what "broken" means in this context. Of course if it means "crashes," that's easy, but if you mean "returns something unexpected," please give more details.
Please also explain how the behavior is expected to vary when :force-shell is T or NIL
Does *every* command crash/fail/do something weird on :force-shell t on windows? And what's the relationship to :output :string?
Is this a problem with the tree command, or every command?
Thanks! R
LAST CALL FOR A BUG REPORT!!!
I do not know enough to replicate this bug report, so cannot debug it.
I need a bug report on launchpad per the following *THIS MORNING* if there's going to be a fix before releasing 3.1.6:
I repeat my earlier email:
Will someone please post a launchpad ticket for this? Specifically a launchpad ticket that indicates EXACTLY how to replicate the bug and what the expected and observed behaviors are?
I'll try to test tomorrow, but I don't know what "broken" means in this context. Of course if it means "crashes," that's easy, but if you mean "returns something unexpected," please give more details.
Please also explain how the behavior is expected to vary when :force-shell is T or NIL
Does *every* command crash/fail/do something weird on :force-shell t on windows? And what's the relationship to :output :string?
Is this a problem with the tree command, or every command?
Oh sorry I did it just now. https://bugs.launchpad.net/asdf/+bug/1501373
On Wed, Sep 30, 2015 at 11:14 PM, Robert Goldman rpgoldman@sift.net wrote:
LAST CALL FOR A BUG REPORT!!!
I do not know enough to replicate this bug report, so cannot debug it.
I need a bug report on launchpad per the following *THIS MORNING* if there's going to be a fix before releasing 3.1.6:
I repeat my earlier email:
Will someone please post a launchpad ticket for this? Specifically a launchpad ticket that indicates EXACTLY how to replicate the bug and what the expected and observed behaviors are?
I'll try to test tomorrow, but I don't know what "broken" means in this context. Of course if it means "crashes," that's easy, but if you mean "returns something unexpected," please give more details.
Please also explain how the behavior is expected to vary when :force-shell is T or NIL
Does *every* command crash/fail/do something weird on :force-shell t on windows? And what's the relationship to :output :string?
Is this a problem with the tree command, or every command?
On 9/23/15 Sep 23 -6:50 PM, Faré wrote:
SANO Masatoshi reports that uiop:run-program broke on SBCL/Windows at some point between 3.1.3 and 3.1.5.
Can someone with SBCL and Windows help me debug that? A trace of functions in uiop/run-program and the functions in sb-ext that appear in that file, using ASDF on 3.1.3 and on 3.1.5, on some failed invocation, would help.
A fix before 3.1.6 would be wonderful.
I have a VM I could test this on, but won't have access to it until Monday.
best, r