Hi,

I decided to take a stab at reviving the new std.process written by Lars T. Kyllingstad and Steven Schveighoffer.

The result is here: https://github.com/alexrp/phobos/tree/new-std-process-update

I decided to extract the work into new commits because rebasing the old branch in Lars's repo was way too cumbersome after so many months (and that branch also had a lot of merge commits). The code is obviously not written by me; all I did was a couple of build and test fixes.

It currently works on 32-bit and 64-bit Linux. It would be great if someone could take it for a spin on OS X, FreeBSD, and Windows to see how it fares there (I'm particularly worried that I may have broken the Windows build).

Lars or Steven, would either of you be willing to go through the review process with this module? I sent the druntime changes upstream a while back, so the Phobos changes are really all that remain in order to have it included.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Thursday, 6 December 2012 at 18:40:57 UTC, Alex Rønne Petersen wrote:
> Hi,
>
> I decided to take a stab at reviving the new std.process written by Lars T. Kyllingstad and Steven Schveighoffer.
>
> The result is here: https://github.com/alexrp/phobos/tree/new-std-process-update
>
> I decided to extract the work into new commits because rebasing the old branch in Lars's repo was way too cumbersome after so many months (and that branch also had a lot of merge commits). The code is obviously not written by me; all I did was a couple of build and test fixes.
>
> It currently works on 32-bit and 64-bit Linux. It would be great if someone could take it for a spin on OS X, FreeBSD, and Windows to see how it fares there (I'm particularly worried that I may have broken the Windows build).
>
> Lars or Steven, would either of you be willing to go through the review process with this module? I sent the druntime changes upstream a while back, so the Phobos changes are really all that remain in order to have it included.

Alex, you rock! You have no idea how happy this makes me. std.process made by Lars and Steven was already awesome. It would be great if you guys work on it together and make it as stable/robust as it should be.

On 2012-12-06 19:40, Alex Rønne Petersen wrote:
> Hi,
>
> I decided to take a stab at reviving the new std.process written by Lars
> T. Kyllingstad and Steven Schveighoffer.
>
> The result is here:
> https://github.com/alexrp/phobos/tree/new-std-process-update
>
> I decided to extract the work into new commits because rebasing the old
> branch in Lars's repo was way too cumbersome after so many months (and
> that branch also had a lot of merge commits). The code is obviously not
> written by me; all I did was a couple of build and test fixes.
>
> It currently works on 32-bit and 64-bit Linux. It would be great if
> someone could take it for a spin on OS X, FreeBSD, and Windows to see
> how it fares there (I'm particularly worried that I may have broken the
> Windows build).

On Mac OS X, move the declaration of "environ" out of the Environment class, it's used by two global functions.

Also, running the unit tests for Phobos, I get this:

http://pastebin.com/GrDrHMxi

I don't know if it has anything to do with the new std.process module or not. This is all for 32bit.

-- 
/Jacob Carlborg

On Thursday, 6 December 2012 at 18:40:57 UTC, Alex Rønne Petersen wrote:
> It currently works on 32-bit and 64-bit Linux. It would be great if someone could take it for a spin on OS X, FreeBSD, and Windows to see how it fares there (I'm particularly worried that I may have broken the Windows build).

How about submitting it as a WIP pull request, so the auto tester picks it up and does the testing for you?

On 06-12-2012 23:25, Jacob Carlborg wrote:
> On 2012-12-06 19:40, Alex Rønne Petersen wrote:
>> Hi,
>>
>> I decided to take a stab at reviving the new std.process written by Lars
>> T. Kyllingstad and Steven Schveighoffer.
>>
>> The result is here:
>> https://github.com/alexrp/phobos/tree/new-std-process-update
>>
>> I decided to extract the work into new commits because rebasing the old
>> branch in Lars's repo was way too cumbersome after so many months (and
>> that branch also had a lot of merge commits). The code is obviously not
>> written by me; all I did was a couple of build and test fixes.
>>
>> It currently works on 32-bit and 64-bit Linux. It would be great if
>> someone could take it for a spin on OS X, FreeBSD, and Windows to see
>> how it fares there (I'm particularly worried that I may have broken the
>> Windows build).
>
> On Mac OS X, move the declaration of "environ" out of the Environment
> class, it's used by two global functions.
>
> Also, running the unit tests for Phobos, I get this:
>
> http://pastebin.com/GrDrHMxi
>
> I don't know if it has anything to do with the new std.process module or
> not. This is all for 32bit.
>

Probably does. I'll look into it, thanks!

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 07-12-2012 00:30, Vladimir Panteleev wrote:
> On Thursday, 6 December 2012 at 18:40:57 UTC, Alex Rønne Petersen wrote:
>> It currently works on 32-bit and 64-bit Linux. It would be great if
>> someone could take it for a spin on OS X, FreeBSD, and Windows to see
>> how it fares there (I'm particularly worried that I may have broken
>> the Windows build).
>
> How about submitting it as a WIP pull request, so the auto tester picks
> it up and does the testing for you?

Good idea, I hadn't even thought of that.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

Am Thu, 06 Dec 2012 19:40:56 +0100
schrieb Alex Rønne Petersen <alex@lycus.org>:


> I decided to extract the work into new commits because rebasing the old branch in Lars's repo was way too cumbersome after so many months (and that branch also had a lot of merge commits). The code is obviously not written by me; all I did was a couple of build and test fixes.

BTW in case you didn't know: The author and committer can be different in git, so you can always do this:

git commit --author="Full Name <email@address.com>"

This will set the author to "Full Name" and the committer to your local account.

On Thursday, 6 December 2012 at 18:40:57 UTC, Alex Rønne Petersen wrote:
> Hi,
>
> I decided to take a stab at reviving the new std.process written by Lars T. Kyllingstad and Steven Schveighoffer.
>
> The result is here: https://github.com/alexrp/phobos/tree/new-std-process-update

https://github.com/alexrp/phobos/blob/new-std-process-update/std/process.d#L417

You need to call toArgz and toStringz before the fork, since either of those can be in TLS. Test with:


string cmd = "echo";
string[] args1 = ["hello"];
string[] args2 = [];

void main()
{
  spawnProcess(cmd, args2);
  spawnProcess(cmd, args1);
  args ~= "World";
  spawnProcess(cmd, args2);
}


I'm not exactly sure what is up, but in one of my projects I had this problem. I solved it by just making all the string[]s into __gshared.

Cheers, Jakob.

On 07-12-2012 14:20, Jakob Bornecrantz wrote:
> On Thursday, 6 December 2012 at 18:40:57 UTC, Alex Rønne Petersen wrote:
>> Hi,
>>
>> I decided to take a stab at reviving the new std.process written by
>> Lars T. Kyllingstad and Steven Schveighoffer.
>>
>> The result is here:
>> https://github.com/alexrp/phobos/tree/new-std-process-update
>
> https://github.com/alexrp/phobos/blob/new-std-process-update/std/process.d#L417
>
>
> You need to call toArgz and toStringz before the fork, since either of
> those can be in TLS. Test with:
>
>
> string cmd = "echo";
> string[] args1 = ["hello"];
> string[] args2 = [];
>
> void main()
> {
>    spawnProcess(cmd, args2);
>    spawnProcess(cmd, args1);
>    args ~= "World";
>    spawnProcess(cmd, args2);
> }
>
>
> I'm not exactly sure what is up, but in one of my projects I had this
> problem. I solved it by just making all the string[]s into __gshared.
>
> Cheers, Jakob.

Thanks, fixed.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 12/6/12, Alex Rønne Petersen <alex@lycus.org> wrote:
> (I'm particularly worried that I may have broken the
> Windows build).

Does anyone know the URL of the original repository? Some symbols are missing, but I don't think it's Alex'es fault.