On 2013-02-26 17:45, Steven Schveighoffer wrote:

> without extra allocation.  However, we have two conflicting parts to
> spawnProcess that would be optional -- the variadic arg list, and the
> optional redirected handles and configuration.
>
> We could just go full-bore variadic...

I'm thinking named parameters, unfortunately we don't have that :(

-- 
/Jacob Carlborg

On Tue, Feb 26, 2013 at 09:07:06PM +0100, Jacob Carlborg wrote:
> On 2013-02-26 17:45, Steven Schveighoffer wrote:
> 
> >without extra allocation.  However, we have two conflicting parts to spawnProcess that would be optional -- the variadic arg list, and the optional redirected handles and configuration.
> >
> >We could just go full-bore variadic...
> 
> I'm thinking named parameters, unfortunately we don't have that :(
[...]

Y'know, it would be nice if AA literal syntax could be used for that purpose, if the compiler could be made aware of its meaning so that no actual allocation is done at runtime.

But maybe it's a bit too late for that.


T

-- 
PNP = Plug 'N' Pray

On 2/26/2013 12:31 AM, Lee Braiden wrote:
> If it was, and there were unit tests as part of releases (or even commits
> to master, say), then this problem of RDMD breakage wouldn't happen.


That's a different issue. The issue I was talking about was working D code no longer compiling due to library changes.

On 2013-02-26 21:29, H. S. Teoh wrote:

> Y'know, it would be nice if AA literal syntax could be used for that
> purpose, if the compiler could be made aware of its meaning so that no
> actual allocation is done at runtime.
>
> But maybe it's a bit too late for that.

I had this idea that could be used for named parameters:

http://forum.dlang.org/thread/kfbnuc$1cro$1@digitalmars.com

-- 
/Jacob Carlborg

Mini thing: Redirect.none is not documented

On Tuesday, 26 February 2013 at 18:48:08 UTC, Jonathan M Davis wrote:
> On Tuesday, February 26, 2013 09:02:11 Steven Schveighoffer wrote:
>> On one hand, I think the correct behavior is to return null, and let the
>> program deal with checking the error, or use get if they have a default.
>> If we throw an exception, people will end up catching the exception in
>> order to avoid an unintended error. Exceptions are not good for flow
>> control, they are for exceptional situations that you didn't plan for.
>
> I think that it's far more correct to say that exceptions are for situations
> where it's reasonable for code to assume that something's the case when it
> might not be or when it's impossible for it to check. For instance, it's much
> cleaner to write a parser if the parser in general assumes that operations
> will succeed and throws when they don't. Then only a small part of the parser
> needs to worry about handling error cases. Or an example of when it would be
> impossible to check would be with file operations. You can (and should) check
> beforehand that the file exists, but there's no way to guarantee that the file
> will still exist when you actually operate on it (e.g. another process could
> delete it out from under you), so the file functions have to throw when the file
> isn't there anymore or you don't have permissions or whatever.
>

That is best explanation I've read on the subject. I'm dead serious.

> If you have to keep checking return values for functions, then you should
> probably be using exceptions. The place to avoid exceptions is when the odds
> of an operation succeeding are low (or at least that there's a fairly good
> chance that it'll fail), because then it really is just becoming flow control.
> But I actually think that pushing for exceptions to be for "exceptional
> situations" is harmful, as that leads to people not using them, and the code
> ends up checking return values when it would be much cleaner if it didn't have
> to. Of course, there are plenty of people who are quite poor at that balance
> and end up over-using exceptions as well, so striking a good balance can be
> hard.
>

I want to add a point that you don't address here : it is easy to forgot to check return value. For instance, how much C code don't check the return value of printf ? I'd be surprised if it is even 1% . When you don't, and things fail, you program is in undefined state and start doing crap. As exception are costly only when the are thrown, it don't make any sense to not use them for speed, as doing crap very fast is rarely a goal that people want to achieve.

On Sunday, March 03, 2013 12:11:16 deadalnix wrote:
> On Tuesday, 26 February 2013 at 18:48:08 UTC, Jonathan M Davis
> > I think that it's far more correct to say that exceptions are
> > for situations
> > where it's reasonable for code to assume that something's the
> > case when it
> > might not be or when it's impossible for it to check. For
> > instance, it's much
> > cleaner to write a parser if the parser in general assumes that
> > operations
> > will succeed and throws when they don't. Then only a small part
> > of the parser
> > needs to worry about handling error cases. Or an example of
> > when it would be
> > impossible to check would be with file operations. You can (and
> > should) check
> > beforehand that the file exists, but there's no way to
> > guarantee that the file
> > will still exist when you actually operate on it (e.g. another
> > process could
> > delete it out from under you), so the file functions have to
> > throw when the file
> > isn't there anymore or you don't have permissions or whatever.
> 
> That is best explanation I've read on the subject. I'm dead serious.

Well, if you have to debate exceptions and/or explain them enough times, you start coming up with better explanations, or you never get anywhere, and the whole "exceptional circumstances" bit is just way too vague, and everyone interprets it differently. And too often, I've argued exceptions with someone who basically agreed with my opinion, but we both sucked at explaining what we meant, so we ended up arguing until we understood that. It's definitely one of those cases where examples make things clearer, and if you can distill what the examples have in common, well then you get an explanation like what I gave.


> I want to add a point that you don't address here : it is easy to forgot to check return value. For instance, how much C code don't check the return value of printf ? I'd be surprised if it is even 1% . When you don't, and things fail, you program is in undefined state and start doing crap.

Definitely, that is one of the reasons that error codes are generally horrible.

> As exception are costly only when the
> are thrown, it don't make any sense to not use them for speed, as
> doing crap very fast is rarely a goal that people want to achieve.

The place that it makes sense to not use them when speed is a concern is when they're going to be thrown often or when the code in question simply cannot afford the extra time that that the exception costs even in the rare situations where one actually gets thrown (which is the sort of situation that games might run into given their insane performance constraints but most everything else won't). Also, I don't believe that the cost of try-catch blocks is actually zero (though it _is_ relatively low), even when no exceptions are thrown because of stuff that must be done in case an exception is thrown, but it's definitely true that in most cases, not using exceptions because of performance concerns is a mistake, and if your code is really going to be throwing exceptions enough that it would be a performance concern, then using an exception doesn't make sense anyway. That's back to using exceptions as flow control.

- Jonathan M Davis

On Sunday, 3 March 2013 at 11:00:52 UTC, Sönke Ludwig wrote:
> Mini thing: Redirect.none is not documented

Ok, thanks!

On Monday, 4 March 2013 at 06:51:15 UTC, Lars T. Kyllingstad wrote:
> On Sunday, 3 March 2013 at 11:00:52 UTC, Sönke Ludwig wrote:
>> Mini thing: Redirect.none is not documented
>
> Ok, thanks!

I ended up simply removing it.  There is no point in calling pipeProcess without any redirection at all.

Lars

On Saturday, 23 February 2013 at 11:31:21 UTC, 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

Ok, a new version is up.  I think I have adressed the concerns that were brought up earlier, but please speak up if I've missed something that we agreed on.

A special thanks to Vladimir P. for pointing out an egregious flaw in the original design.

Lars