On Wednesday, 20 March 2013 at 22:46:58 UTC, Lars T. Kyllingstad wrote:
> Sorry for the delay, but I've pushed a new version now.  There are still a few things I haven't done wrt. documentation* and unittests**, but the changes to the API and internals should be in place.

Since (IIRC) all issues regarding incompatibility with std.process have been resolved, how about renaming the module to std.process? This way it'll also be easier to test backwards-compatibility in existing programs.

On Thu, Mar 21, 2013 at 12:08:00PM +0100, Vladimir Panteleev wrote:
> On Wednesday, 20 March 2013 at 22:46:58 UTC, Lars T. Kyllingstad wrote:
> >Sorry for the delay, but I've pushed a new version now.  There are still a few things I haven't done wrt. documentation* and unittests**, but the changes to the API and internals should be in place.
> 
> Since (IIRC) all issues regarding incompatibility with std.process have been resolved, how about renaming the module to std.process? This way it'll also be easier to test backwards-compatibility in existing programs.

+1. I hate std.process2 with a passion. Let's keep it as std.process.


T

-- 
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5

On 03/21/2013 11:35 AM, H. S. Teoh wrote:
> On Thu, Mar 21, 2013 at 12:08:00PM +0100, Vladimir Panteleev wrote:
>> On Wednesday, 20 March 2013 at 22:46:58 UTC, Lars T. Kyllingstad
>> wrote:
>>> Sorry for the delay, but I've pushed a new version now.  There are
>>> still a few things I haven't done wrt. documentation* and
>>> unittests**, but the changes to the API and internals should be in
>>> place.
>>
>> Since (IIRC) all issues regarding incompatibility with std.process
>> have been resolved, how about renaming the module to std.process?
>> This way it'll also be easier to test backwards-compatibility in
>> existing programs.
>
> +1. I hate std.process2 with a passion. Let's keep it as std.process.
>
>
> T
>

++1

No more incrementing names!

On Thursday, 21 March 2013 at 16:37:38 UTC, H. S. Teoh wrote:
> On Thu, Mar 21, 2013 at 12:08:00PM +0100, Vladimir Panteleev wrote:
>> 
>> Since (IIRC) all issues regarding incompatibility with std.process
>> have been resolved, how about renaming the module to std.process?
>> This way it'll also be easier to test backwards-compatibility in
>> existing programs.
>
> +1. I hate std.process2 with a passion. Let's keep it as std.process.

The main reason I created a separate std.process2 was in fact not that I intended to keep it that way, but because I kept getting merge conflicts whenever I merged in Phobos master.

If you all don't mind, I'd like to keep it separate until we are satisfied that the API is stable.

Lars

On Thu, Mar 21, 2013 at 06:32:59PM +0100, Lars T. Kyllingstad wrote:
> On Thursday, 21 March 2013 at 16:37:38 UTC, H. S. Teoh wrote:
> >On Thu, Mar 21, 2013 at 12:08:00PM +0100, Vladimir Panteleev wrote:
> >>Since (IIRC) all issues regarding incompatibility with std.process have been resolved, how about renaming the module to std.process? This way it'll also be easier to test backwards-compatibility in existing programs.
> >
> >+1. I hate std.process2 with a passion. Let's keep it as std.process.
> 
> The main reason I created a separate std.process2 was in fact not that I intended to keep it that way, but because I kept getting merge conflicts whenever I merged in Phobos master.
> 
> If you all don't mind, I'd like to keep it separate until we are satisfied that the API is stable.
[...]

That's fine, as long as it's renamed to std.process once it's merged.


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

On 2013-02-23 12:31, Lars T. Kyllingstad wrote:
> It's been years in the coming, but we finally got it done. :) The upshot
> is that the module has actually seen active use over those years, both
> by yours truly and others, so hopefully the worst wrinkles are already
> ironed out.
>
> Pull request:
> https://github.com/D-Programming-Language/phobos/pull/1151
>
> Code:
> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>
> Documentation:
> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html

I would like a function for getting the current process path, i.e. this:

http://dsource.org/projects/tango/attachment/ticket/1536/process.d

-- 
/Jacob Carlborg

On Mon, 25 Mar 2013 15:17:14 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-23 12:31, Lars T. Kyllingstad wrote:
>> It's been years in the coming, but we finally got it done. :) The upshot
>> is that the module has actually seen active use over those years, both
>> by yours truly and others, so hopefully the worst wrinkles are already
>> ironed out.
>>
>> Pull request:
>> https://github.com/D-Programming-Language/phobos/pull/1151
>>
>> Code:
>> https://github.com/kyllingstad/phobos/blob/std-process2/std/process2.d
>>
>> Documentation:
>> http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process2.html
>
> I would like a function for getting the current process path, i.e. this:
>
> http://dsource.org/projects/tango/attachment/ticket/1536/process.d

This is orthogonal to the replacement of process creation functions, can we add this as an enhancement later?  It definitely is useful, but std.process sucks right now.  I don't want to delay the replacement of existing functions with adding extra features.

-Steve

On 2013-03-25 20:27, Steven Schveighoffer wrote:

> This is orthogonal to the replacement of process creation functions, can
> we add this as an enhancement later?  It definitely is useful, but
> std.process sucks right now.  I don't want to delay the replacement of
> existing functions with adding extra features.

Created a pull request for it:

https://github.com/D-Programming-Language/phobos/pull/1224

-- 
/Jacob Carlborg

On Monday, 25 March 2013 at 21:09:57 UTC, Jacob Carlborg wrote:
> On 2013-03-25 20:27, Steven Schveighoffer wrote:
>
>> This is orthogonal to the replacement of process creation functions, can
>> we add this as an enhancement later?  It definitely is useful, but
>> std.process sucks right now.  I don't want to delay the replacement of
>> existing functions with adding extra features.
>
> Created a pull request for it:
>
> https://github.com/D-Programming-Language/phobos/pull/1224

If this gets added *before* the new std.process, we should at least agree on a consistent naming convention.  The new std.process has @property thisProcessID(), which replaces getpid(), and which is somewhat consistent with std.concurrency.thisTid.  I also think std.file.getcwd() is part of this function family, and that it should be moved to std.process (under a different name).

Personally, I dislike function names that start with "get".

Lars

On 2013-03-26 14:07, Lars T. Kyllingstad wrote:

> If this gets added *before* the new std.process, we should at least
> agree on a consistent naming convention.  The new std.process has
> @property thisProcessID(), which replaces getpid(), and which is
> somewhat consistent with std.concurrency.thisTid.  I also think
> std.file.getcwd() is part of this function family, and that it should be
> moved to std.process (under a different name).
>
> Personally, I dislike function names that start with "get".

so what would you prefer, "thisProcessPath"? Or thisExecutablePath, perhaps?

-- 
/Jacob Carlborg