Hi,

Functions from the old std.process have been marked (in documentation) as "scheduled for deprecation" since April 2013.  I'm not completely clear on the deprecation process we're currently using.  Is it OK to finally add a "deprecated" attribute to them now?  I am currently doing some maintenance work on std.process, and this seems like a good time to do it.

The functions in question are: system(), getpid(), shell(), getenv(), setenv() and unsetenv().  All of these have equivalents among the newer std.process functions, as specified in the deprecation notices.

The exec*() family of functions is also marked as such, but it was agreed(?) in a NG discussion to only deprecate them on Windows, and to move them to a separate module on POSIX:

http://forum.dlang.org/thread/l4nav4$q9r$1@digitalmars.com?page=2#post-l4ph2m:2410t:242:40digitalmars.com

Lars
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 8/6/14, 1:53 PM, Lars Tandle Kyllingstad via phobos wrote:
> The exec*() family of functions is also marked as such, but it was
> agreed(?) in a NG discussion to only deprecate them on Windows, and to
> move them to a separate module on POSIX:
>
> http://forum.dlang.org/thread/l4nav4$q9r$1@digitalmars.com?page=2#post-l4ph2m:2410t:242:40digitalmars.com

For my money I think we should just keep them around. -- Andrei

_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

> Sent: Wednesday, August 06, 2014 at 1:53 PM
> From: "Lars Tandle Kyllingstad via phobos" <phobos@puremagic.com>
> To: "Phobos mailing list" <phobos@puremagic.com>
> Subject: [phobos] std.process deprecations
>
> Hi,
>
> Functions from the old std.process have been marked (in documentation) as "scheduled for deprecation" since April 2013.  I'm not completely clear on the deprecation process we're currently using.  Is it OK to finally add a "deprecated" attribute to them now?  I am currently doing some maintenance work on std.process, and this seems like a good time to do it.
>
> The functions in question are: system(), getpid(), shell(), getenv(),
> setenv() and unsetenv().  All of these have equivalents among the newer
> std.process functions, as specified in the deprecation notices.
>
> The exec*() family of functions is also marked as such, but it was
> agreed(?) in a NG discussion to only deprecate them on Windows, and to
> move them to a separate module on POSIX:
>
> http://forum.dlang.org/thread/l4nav4$q9r$1@digitalmars.com?page=2#post-l4ph2m:2410t:242:40digitalmars.com

We really aren't "scheduling" anything for deprecation anymore, which is probably why I missed those functions and have never actually deprecated them when I last was moving the Phobos deprecations along. Now that deprecated just prints out a message rather than blocking compilation, there's no reason not to just immediately deprecate anything that we want to deprecate. So, if we're going to deprecate them, we should just deprecate them.

If we want to keep them on POSIX but not Windows, then we need to either move them to a new module where they're POSIX-only and deprecate the ones in std.process, or we need to version them out in std.process so that they're deprecated on Windows and not on POSIX.

- Jonathan M Davis
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 06/08/14 23:36, Andrei Alexandrescu wrote:
> On 8/6/14, 1:53 PM, Lars Tandle Kyllingstad via phobos wrote:
>> The exec*() family of functions is also marked as such, but it was
>> agreed(?) in a NG discussion to only deprecate them on Windows, and to
>> move them to a separate module on POSIX:
>>
>> http://forum.dlang.org/thread/l4nav4$q9r$1@digitalmars.com?page=2#post-l4ph2m:2410t:242:40digitalmars.com
>>
>
> For my money I think we should just keep them around. -- Andrei

I think we made a good case for why those functions ought to be deprecated on Windows in that discussion, and while I stand by my arguments, I don't really have anything more to add to re-convince you.

Removing functionality is a drastic step to take, and I won't try to deprecate them unless there is a clear consensus that it is the right thing to do.

Lars
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 07/08/14 01:12, Jonathan M Davis via phobos wrote:
> We really aren't "scheduling" anything for deprecation anymore, which is
> probably why I missed those functions and have never actually deprecated them
> when I last was moving the Phobos deprecations along. Now that deprecated just
> prints out a message rather than blocking compilation, there's no reason not
> to just immediately deprecate anything that we want to deprecate. So, if we're
> going to deprecate them, we should just deprecate them.

Ok, got it.  How long do functions stay deprecated before they're removed, then?

Lars

_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

AFAIK, 2 releases is the rule of thumb. Give or take a release depending on how touchy it is.


On Thu, Aug 7, 2014 at 10:21 AM, Lars Tandle Kyllingstad via phobos < phobos@puremagic.com> wrote:

> On 07/08/14 01:12, Jonathan M Davis via phobos wrote:
>
>> We really aren't "scheduling" anything for deprecation anymore, which is
>> probably why I missed those functions and have never actually deprecated
>> them
>> when I last was moving the Phobos deprecations along. Now that deprecated
>> just
>> prints out a message rather than blocking compilation, there's no reason
>> not
>> to just immediately deprecate anything that we want to deprecate. So, if
>> we're
>> going to deprecate them, we should just deprecate them.
>>
>
> Ok, got it.  How long do functions stay deprecated before they're removed, then?
>
> Lars
>
>
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On 8/7/14, 1:21 AM, Lars Tandle Kyllingstad via phobos wrote:
> I think we made a good case for why those functions ought to be
> deprecated on Windows in that discussion, and while I stand by my
> arguments, I don't really have anything more to add to re-convince you.
>
> Removing functionality is a drastic step to take, and I won't try to
> deprecate them unless there is a clear consensus that it is the right
> thing to do.

I am convinced. I do understand exec* is inefficient on Windows. However, I remember I dealt with an application in which removal of said functionality would force me to essentially paste the source code from std.process into my program. That doesn't seem like progress.

Is there a chance to offer the functionality on Windows in a reasonable way?


Andrei

_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

> Sent: Thursday, August 07, 2014 at 1:21 AM
> From: "Lars Tandle Kyllingstad via phobos" <phobos@puremagic.com>
> To: phobos@puremagic.com
> Subject: Re: [phobos] std.process deprecations
>
> On 07/08/14 01:12, Jonathan M Davis via phobos wrote:
> > We really aren't "scheduling" anything for deprecation anymore, which is probably why I missed those functions and have never actually deprecated them when I last was moving the Phobos deprecations along. Now that deprecated just prints out a message rather than blocking compilation, there's no reason not to just immediately deprecate anything that we want to deprecate. So, if we're going to deprecate them, we should just deprecate them.
>
> Ok, got it.  How long do functions stay deprecated before they're removed, then?

I generally try for one year as deprecated and six months as deprecated but undocumented. Ideally, those dates would be from actual releases, but those have gotten so far apart now that that isn't working so well. So, when something is deprecated, I put a comment like

$(RED Deprecated. Please use $(LREF PointerTarget) instead. This will be
      removed in June 2015.)

or

$(RED Deprecated. Please use $(LREF split) instead. Too frequently,
      $(LREF get) or one of the individual unit getters is used when the
      function that gave the desired behavior was $(LREF total). This
      should make it more explicit and help prevent bugs. This function
      will be removed in June 2015.)

at the top of the ddoc comment for the function, and then around the date given in the comment (June 2015 in this case), the entire ddoc comment gets replaced with something like

// Explicitly undocumented. It will be removed in December 2015.

and then in the date given in that comment, the function would be completely removed.

- Jonathan M Davis
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 07/08/14 16:05, Andrei Alexandrescu wrote:
> On 8/7/14, 1:21 AM, Lars Tandle Kyllingstad via phobos wrote:
>> I think we made a good case for why those functions ought to be
>> deprecated on Windows in that discussion, and while I stand by my
>> arguments, I don't really have anything more to add to re-convince you.
>>
>> Removing functionality is a drastic step to take, and I won't try to
>> deprecate them unless there is a clear consensus that it is the right
>> thing to do.
>
> I am convinced. I do understand exec* is inefficient on Windows.
> However, I remember I dealt with an application in which removal of said
> functionality would force me to essentially paste the source code from
> std.process into my program. That doesn't seem like progress.

Inefficiency was never used as an argument.  The problem is that exec* does different things on Windows and POSIX.  In other words, a D program which uses std.process.exec* will have different observable behaviour on different platforms.  This is what bothers me.

  - On POSIX systems, exec* overwrites the current process
    with a new one.

  - On Windows, exec* spawns a new, independent process and
    exits the current one.

As an example of how this causes different observable behaviour, let us say that program A uses exec* to run program B.  The user starts A from the command line.  The POSIX user will then be returned to the command line when program B has completed, and the exit code he receives is that of program B.  The Windows user will be returned to the command line immediately after the exec* statement has run, and program B will run independently in the background.  Which exit code the user receives is anyone's guess, but it is certainly not from B.


> Is there a chance to offer the functionality on Windows in a reasonable
> way?

Yes or no, depending on how your question is interpreted.

No, it is not possible to make exec* overwrite the current process on Windows.  New processes are always created in isolation.  Not even Microsoft managed to implement exec* properly in their C runtime; their functions fake it with spawn-and-exit, as described above.

But yes, you can make a program that does the same thing yours does now, even if exec* is deprecated on Windows.  The user-side code will be more verbose, but the difference in behaviour will be explicit.

Program using today's std.process.execv():

    execv("prog", ["arg1", "arg2" ]);

Program that behaves in the same manner, after exec* deprecation on Windows:

    auto cmd = [ "prog", "arg1", "arg2" ];
    version (Posix) execv(cmd[0], cmd[1 .. $]);
    else { spawnProcess(cmd); _exit(0); }

Somewhat improved program that appears to behave in almost the same manner on all platforms (assuming there are no other threads running!):

    auto cmd = [ "prog", "arg1", "arg2" ];
    version (Posix) execv(cmd[0], cmd[1 .. $]);
    else _exit(wait(spawnProcess(cmd)));

Lars
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 07/08/14 17:51, Jonathan M Davis via phobos wrote:
>> Sent: Thursday, August 07, 2014 at 1:21 AM
>> From: "Lars Tandle Kyllingstad via phobos" <phobos@puremagic.com>
>> To: phobos@puremagic.com
>> Subject: Re: [phobos] std.process deprecations
>>
>> How long do functions stay deprecated before they're
>> removed, then?
>
> I generally try for one year as deprecated and six months as deprecated but
> undocumented. Ideally, those dates would be from actual releases, but those
> have gotten so far apart now that that isn't working so well. So, when
> something is deprecated, I put a comment like
>
> $(RED Deprecated. Please use $(LREF PointerTarget) instead. This will be
>        removed in June 2015.)

All right, I'll schedule them for removal in August 2015, then.  Pull request coming soon!

Lars
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos