On Sunday, 24 February 2013 at 18:56:39 UTC, jerro wrote:
>> To me, "asynchronous" implies that something is going on in the background that will produce a result in the future.  That is not what happens here.
>>
>> I agree that nonBlockingWait() is less than ideal, though, mainly because it is an oxymoron. :)  I considered "status", "isAlive", etc., but I think it is important to emphasise the fact that if the process *has* terminated, nonBlockingWait() has the same, perhaps non-obvious, effects as wait():
>>
>> On POSIX, it makes the OS clean up after the process.
>> On Windows, it closes the process handle.
>> On all platforms, it invalidates the processID and osHandle properties of the Pid object.
>>
>> If you or anyone else have a better suggestion, I'm all ears.
>>
>> Lars
>
> Maybe tryWait?

I like it. :)

Lars

On Sun, Feb 24, 2013 at 10:05:01AM +0200, Andrei Alexandrescu wrote:
> On 2/24/13 6:26 AM, Andrej Mitrovic wrote:
> >Phobos modules which already use std.process would have to be changed to directly import std.process1 or std.process2.
> 
> This is problematic as has been discussed. I think we could address immediate needs by attaching an attribute to import, e.g.:
> 
> @"v2.070+" import std.process;

Better yet, @">v.2070". So that later on it can be extended to @">v2.070 <v2.084", etc.. But I don't know if it's a good idea to push it that far...


> or similar. By default code would import the old library.
[...]

Alternatively, use a version identifier:

	version = newStdProcess;
	import std.process;	// get new version
	-----
	//version = newStdProcess;
	import std.process;	// get old version

Then once the old version has gone through the deprecation cycle and is kicked out, the new code can just ignore version=newStdProcess and always import the new version, and existing user code needs no changes.


T

-- 
Why ask rhetorical questions? -- JC

On Sun, 24 Feb 2013 19:42:23 +0100, Lars T. Kyllingstad wrote:
>>>> http://www.kyllingen.net/code/std-process2/phobos-prerelease/
std_process2.html
>>>>
>>>>
>>> Ok, a new version with non-blocking wait is up.
>>
>> asyncWait would be less verbose :)
> 
> To me, "asynchronous" implies that something is going on in the background that will produce a result in the future.  That is not what happens here.
> 
> I agree that nonBlockingWait() is less than ideal, though, mainly
> because it is an oxymoron. :)  I considered "status", "isAlive", etc.,
> but I think it is important to emphasise the fact that if the process
> *has* terminated, nonBlockingWait() has the same, perhaps non-obvious,
> effects as wait():

I think something like getExitStatus() or checkExitStatus() makes more sense in terms of what the function actually does.  The only problem is that you lose the connection with wait().  wait is poorly named anyway though, it's only good because it's the traditional name.  A combo like waitForExitStatus() and checkForExitStatus() would probably make more sense.

Although I guess we're getting into java-style names, rather than C-style names ;)


-- 
Lee

On Sunday, 24 February 2013 at 19:45:26 UTC, H. S. Teoh wrote:
>
> Alternatively, use a version identifier:
>
> 	version = newStdProcess;
> 	import std.process;	// get new version
> 	-----
> 	//version = newStdProcess;
> 	import std.process;	// get old version
>
> Then once the old version has gone through the deprecation cycle and is
> kicked out, the new code can just ignore version=newStdProcess and
> always import the new version, and existing user code needs no changes.
>

Would work just fine, *if* versions propogated across modules, which they do not. (And doing so creates new problems discussed to death and beyond in times past.)  But maybe you meant setting it at the command-line, which to be honest, was my first thought as well. The ensuing discussion baffles me.

How about this as a suggestion, even though I know it will never happen.

Release A:
 - New process module is available as 'future.process'
 - Old module remains available as 'std.process' but with a pragma(msg) warning users that it will go away next release. (It'd be even better to have a pragma(warn), actually.)
 - Old module is duplicated as 'past.process'

Release B:
 - New module is now 'std.process', but with a pragma(msg) reminding users to update code if they haven't already
 - Old module remains at 'past.process'

Release C:
 - New module remains at 'std.process' now with no special messages.
 - Old module remains at 'past.process' for the last time.

Ta, fricking, da.
We should have started a procedure like this ages ago for Phobos additions and rewrites. Not everyone is in a position to comfortably use pre-release compilers, so testing new code from git head is not an option for them. Further, this gives old code three whole releases before it's forced to update; that ought to be enough legacy support.

Legacy support is the devil.

On Sunday, 24 February 2013 at 14:44:51 UTC, Steven Schveighoffer wrote:
> On Sun, 24 Feb 2013 08:03:24 -0500, Jonas Drewsen <jdrewsen@nospam.com> wrote:
>
>>
>> 1, What about support for nonblocking wait(). It would be very nice not to block the main thread if you really don't care about waiting for the sub process but just want to be nice and not create zombies.
>
> Non-blocking wait was brought up.  I think we can add it.  It would be non-blocking wait on specific processes though, I think doing a wait for *any* process is a more difficult problem to solve, and is not supported in the current std.process.  It may be something added later.

I saw that you have implemented this now - great!.

>> 2, What about nonblocking read/writes or support for timing out reads/writes at least. On linux you can select() on the file descriptor but that is not supported on windows.
>
> This is not an issue with std.process, but rather with File.  If File doesn't support non-blocking read/write, that is an issue, but we should solve it for all streams, not just pipes.

Since File is just used to wrap the fd created in std.process it is not possible for File to make this non-blocking since windows doesn't have proper support for non-blocking fds that are not sockets e.g. files or pipes. The recommended way to communicate non-blocking between processes this way is to create a named pipe and do waitformultiple objects on that.

/Jonas

On 2/24/13, Chris Nicholson-Sauls <ibisbasenji@gmail.com> wrote:
>   - Old module remains available as 'std.process' but with a
> pragma(msg) warning users that it will go away next release.
> (It'd be even better to have a pragma(warn), actually.)

We have deprecated("message") for that. And it gives the user the option to silence the deprecation message via -d.

On Sunday, 24 February 2013 at 17:41:44 UTC, Lars T. Kyllingstad wrote:
> Ok, a new version with non-blocking wait is up.

1. Can the Firefox example be replaced with something else? Spawning a specific browser to open a webpage is bad practice, and I've noticed in several programs. It would be nice not to perpetuate it any further. There exists a proper way to open an URL in the default browser, already implemented as browse(url) in the current std.process.

2. (Nitpick) The grep example uses a POSIX quoting syntax (single quotes). Would be better to use double quotes, or pass as array to avoid one more needless OS-specific element.

3. The documentation for the "gui" config item seems to be wrong: it prevents the creation of a console, instead of causing it.

4. I see that my command escaping functions have not made it through. I believe the matter has been discussed before, and I thought the consensus was to use them, although it's been a while. The function escapeShellCommand and its callees from the current std.process have the advantages that a) they come with a very thorough unit test, whereas std.process2's Windows escaping code does not have tests at all, and b) they are usable independently, which allows constructing scripts and batch files in D programs.

5. The spawnProcess versions which take a single string command simply call std.string.split on the command. I believe this approach to be fundamentally wrong, as passing an argument in quotes will not work as expected. Furthermore, on Windows (where process arguments are passed as a single string), splitting the string in spawnProcess and then putting it back together in spawnProcessWindows will result in a final command line that is different from the one supplied by the user.

6. What are the reasons why this module can't be integrated with the existing std.process? I've noticed it mentioned a few times but couldn't actually find the reasoning, anyone can post the link?

7. How do I test this with a recent version of Phobos? I'm getting the following runtime exception with the "ls" example:

std.stdio.StdioException@std\stdio.d(2343): Failed to pass stdin stream to child process
----------------
0x0041D504 in char[][] core.sys.windows.stacktrace.StackTrace.trace()
0x0041D38F in core.sys.windows.stacktrace.StackTrace core.sys.windows.stacktrace.StackTrace.__ctor()
0x004124A8 in D3std8process219spawnPАЖПWindowsFNeAyaxAтPvSАД░5┌io4FileАРРАРРEАНр6ConfigZCАНЦ3Pid13prepa┘St┘amFKАР╔kАГ JiJPvZv
0x0040F8AA in @trusted std.process2.Pid std.process2.spawnProcess(immutable(char)[], const(immutable(char)[][]), std.stdio.File, std.stdio.File, std.stdio.File, std.process2.Config)
0x0040A353 in @trusted std.process2.Pid std.process2.spawnProcess(immutable(char)[], std.stdio.File, std.stdio.File, std.stdio.File, std.process2.Config)
0x004020B9 in _Dmain

Do I need a patched snn.lib or something else?

On Sun, 24 Feb 2013 11:43:24 -0800, H. S. Teoh wrote:
> @"v2.070+" import std.process;
> 
> Better yet, @">v.2070". So that later on it can be extended to @">v2.070 <v2.084", etc.. But I don't know if it's a good idea to push it that far...
> 

Now that I think about it more, this is not an import-level issue.  It's a package management/build-tool issue.  If your package manager knows that you depend on phobos >= 2 && phobos <= 3, and can install them in a local build dir, when the global version doesn't match, then all of these problems go away.

You also gain a lot from that: package managers know about inter-package dependencies; much more complex dependencies (even dependencies unknown to the author of a program at the time) can be handled automatically; there's no need to worry about whether std.process is version 1 or 2, or even if it's the one that originally came with phobos2, etc.


-- 
Lee

On 2/24/13, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
> a) they come with a very thorough unit test

Unfortunately those unittests are never being run in the Phobos
test-suite and as a result a regression was missed (which was fixed by
now):
http://d.puremagic.com/issues/show_bug.cgi?id=9309

The report for the unittests: http://d.puremagic.com/issues/show_bug.cgi?id=9310

On Sun, 24 Feb 2013 16:04:43 -0500, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> On Sunday, 24 February 2013 at 17:41:44 UTC, Lars T. Kyllingstad wrote:
>> Ok, a new version with non-blocking wait is up.
>
> 3. The documentation for the "gui" config item seems to be wrong: it prevents the creation of a console, instead of causing it.

It means 'use gui mode' which means, don't create a console.  I don't consider a console window a gui.

> 4. I see that my command escaping functions have not made it through. I believe the matter has been discussed before, and I thought the consensus was to use them, although it's been a while. The function escapeShellCommand and its callees from the current std.process have the advantages that a) they come with a very thorough unit test, whereas std.process2's Windows escaping code does not have tests at all, and b) they are usable independently, which allows constructing scripts and batch files in D programs.

I had also thought we were going to use those (that was the consensus I remember).  It probably was just forgotten.  Lars?

> 6. What are the reasons why this module can't be integrated with the existing std.process? I've noticed it mentioned a few times but couldn't actually find the reasoning, anyone can post the link?

Lars just mentioned his reasons in this thread.  Let me see...

http://forum.dlang.org/post/pnspeckullzedovpvjcx@forum.dlang.org

> 7. How do I test this with a recent version of Phobos? I'm getting the following runtime exception with the "ls" example:
>
> std.stdio.StdioException@std\stdio.d(2343): Failed to pass stdin stream to child process
> ----------------
> 0x0041D504 in char[][] core.sys.windows.stacktrace.StackTrace.trace()
> 0x0041D38F in core.sys.windows.stacktrace.StackTrace core.sys.windows.stacktrace.StackTrace.__ctor()
> 0x004124A8 in D3std8process219spawnPАЖПWindowsFNeAyaxAтPvSАД░5┌io4FileАРРАРРEАНр6ConfigZCАНЦ3Pid13prepa┘St┘amFKАР╔kАГ JiJPvZv
> 0x0040F8AA in @trusted std.process2.Pid std.process2.spawnProcess(immutable(char)[], const(immutable(char)[][]), std.stdio.File, std.stdio.File, std.stdio.File, std.process2.Config)
> 0x0040A353 in @trusted std.process2.Pid std.process2.spawnProcess(immutable(char)[], std.stdio.File, std.stdio.File, std.stdio.File, std.process2.Config)
> 0x004020B9 in _Dmain
>
> Do I need a patched snn.lib or something else?

No, snn.lib included with the compilers for a few versions has been patched.  The exeception you would get would be different, that appears to be coming from std.process, even though the file name seems to be std.stdio.

-Steve