in reply to Re^2: Parallelization of heterogenous (runs itself Fortran executables) code
in thread Parallelization of heterogenous (runs itself Fortran executables) code

Ok, you are mjd so I shouldn't probably "dare" to comment, but...

use Getopt::Std;

[download]

I personally believe that since we recommend newbies and more expert programmers altogether to always use strict and warnings, and this is a nice little utility likely to be picked up as an example, it would be a good thing if it had

use strict;
use warnings;

[download]

at the top. So to build a better future for our children...

Also,

use List::Util 'shuffle';

[download]

would implement the -r switch straight ahead.

getopts('r:n:v', \%opt) or usage();

[download]

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. Suitable hooks are provided instead, although admittedly I don't like the interface. (Suitably named subs in main::)

sub usage {
  print STDERR "Usage: $0 [-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
";
  exit 1;

[download]

Any good reason for basically reimplementing die? Incidentally, I would have used a here-doc instead. Personally, I like to implement a USAGE sub like thus:

sub USAGE () {
    my $name=basename $0;  # File::Basename's
    <<".EOT";
Usage: $name [args]
[actual usage here]
.EOT
}

[download]

So if the user explicitly asks for help, then I print to STDOUT and exit regularly, for in that case I wouldn't consider the program termination to be "abnormal". Else, I regularly die USAGE.

Replies are listed 'Best First'.
Re^4: Parallelization of heterogenous (runs itself Fortran executables) code
by Dominus (Parson) on Nov 21, 2007 at 22:00 UTC
    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;
}

    [download]
    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.

    --
    Mark Dominus
    Perl Paraphernalia

[reply]
[d/l]
      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.

      [download]

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

[reply]
[d/l]
        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.

        --
        Mark Dominus
        Perl Paraphernalia

[reply]
Re^4: Parallelization of heterogenous (runs itself Fortran executables) code
by Dominus (Parson) on Nov 21, 2007 at 21:54 UTC
    Also, use List::Util 'shuffle'; would implement the -r switch straight ahead.
    Sure, but if nobody uses the feature, my implementation is better.

    --
    Mark Dominus
    Perl Paraphernalia

[reply]
Re^4: Parallelization of heterogenous (runs itself Fortran executables) code
by Dominus (Parson) on Nov 23, 2007 at 15:08 UTC
[reply]

In Section Seekers of Perl Wisdom