Re^4: Parallelization of heterogenous (runs itself Fortran executables) code

[Dominus]

The docs do not say anything about getopts() return value, and indeed experimental evidence is that it can't be relied upon for failure checking.

It is very strange that the manual does not mention the return value of getopts(), but it does in fact return true on success and false on failure, and has done so since perl 4.0.

I would like to see the "experiments" that you tried. The source code is quite clear:

sub getopts ($;$) {
    my ($argumentative, $hash) = @_;
    ... 
    # no "return" anywhere...
    ...
    $errs == 0;
}

So it seems to me that what we have here is a documentation failure.

Addendum: Every Getopt::Std test suite ever distributed Perl, going back to 5.004_04, tests for this behavior. So now I would really like to see your experiments.

[blazar]

Addendum: Every Getopt::Std test suite ever distributed Perl, going back to 5.004_04, tests for this behavior. So now I would really like to see your experiments.

I personally believe that you're right. More precisely, you're obviously right. Anyway I probably just tried to add an unknown switch to a cmd line that worked:

C:\temp>runn.pl -q
Unknown option: q
Usage: C:\temp\runn.pl [-n N] [-r] [-v] command arg1 arg2...
Run command arg1, command arg2, etc., concurrently.
Run no more than N processes simultaneously (default 1)
    -r: run commands in random order instead of specified order (unimp
+l.)
    -v: verbose mode

C:\temp>runn.pl -n 2 dir *.txt *.pl -q
exec: No such file or directory at C:\temp\runn.pl line 27.
exec: No such file or directory at C:\temp\runn.pl line 27.
exec: No such file or directory at C:\temp\runn.pl line 27.

IPB that the latter should exit early printing the usage screen too.

[Dominus]

I suppose it could do that, but the implementation is a bit difficult. The only way I can think of to do it reliably is to have the parent open a pipe to the child so that the child can communicate back the errno from the failed exec.

And I would need to go over every possible value of errno and decide which ones warranted an early exit and which ones didn't. It seems like a complicated issue.

Anyway, it's definitely a feature I haven't needed yet. A few years back I did a review of a couple of dozen programs I'd written and put in my ~/bin directory, and the overwhelming majority of them were over-featurized, not under-featurized. I learned that I had wasted a lot of work on features I didn't need. So these days I try to leave out as many features as possible until I'm sure I need them.

The original version of this program left -v unimplemented, but I kept wishing for it, so eventually I put it in. The original version of this program left -r unimplemented, but I haven't yet wished for it, so I haven't put it in yet. Win!

It occurs to me now that if I did decide that I wanted the -r option, the right way to get it would be to write a separate shuffle utility that shuffles its arguments and prints them in random order. Then instead of runN -r ... I could runN `shuffle ...`. Win!

Similarly, it has occurred to me more than once that the program completely fails to report the exit status of the subprocesses. Your suggestion is part of that. But I haven't needed to find out the exit status of the subprocesses, so I haven't tried to fix that.

[blazar]

So these days I try to leave out as many features as possible until I'm sure I need them.

I personally believe that's the discipline people call YAGNI.