On Apr 21, 2011, at 8:21 PM, Paul H. Hargrove wrote:
> I saw the "extra bonus points" proposal for svn-style "mpirun help command",
> and I interpreted it to be slightly different from what I had in mind. What
> I indented by my suggestion was regrouping the existing 200+ line
> alphabetical-b
On 4/21/2011 4:41 PM, Jeff Squyres wrote:
Additionally implement --help=[topic] to give more info on related groups of
options.
I think that fits in my "extra bonus points" proposal. Meaning: I agree that
it would be great, but I, sadly, do not have time to do it.
I saw the "extra bonus p
On Apr 21, 2011, at 7:17 PM, Paul H. Hargrove wrote:
> To address "The --help output needs to be made (much) better" I'd like to
> suggest that --help and -h each give the same BRIEF summary of under 24-lines
> of 80-column text.
Agreed.
> Additionally implement --help=[topic] to give more i
Yes, this is probably better.
I took a *quick* glance through the 232-line output before I sent this and
probably made a bad assumption that some of them could go away.
But definitely some of the old affinity options should become deprecated. That
part of the proposal still stands.
On Apr 21,
To address "The --help output needs to be made (much) better" I'd like
to suggest that --help and -h each give the same BRIEF summary of under
24-lines of 80-column text. Additionally implement --help=[topic] to
give more info on related groups of options. Of course, -h and --help
would list
Might help if you were to list those CLI params you believe to be removable
and/or those you propose to deprecate.
Just a quick glance: I don't see any options that are defunct, though we could
argue about how many people use them. So perhaps what we discussed - having a
short response for -h t
WHAT: Deprecate a bunch of old mpirun CLI parameters, remove *most*
"single dash" long mpirun options, make "mpirun --help" much
more user friendly
WHY: `mpirun --help` is currently 232 lines of output. *Ouch*
Additionally, the Josh/Terry/Jeff affinity re-work will end up
cr
