To be honest, I don't care so much today, I'm just fighting so that the
output doesn't get worse. At some point, we do need to figure out a
better way of dealing with error messages, but not today :).
Brian
On 11/2/11 11:53 AM, "Ralph Castain" wrote:
>Hmmmsince it was my bug that surfaced
Hmmmsince it was my bug that surfaced the problem, maybe the best answer is
to just return an error code. I'll slowly work thru the param registrations in
ORTE and make them all check the return code. I'm willing to look at OPAL as I
go, but someone else will have to deal with the OMPI layer
I really don't like our show_help at every level behavior (look at what
happens when MPI_INIT fails, you get a page per process of the same error
message from each level of the call stack). If you want to show_help and
abort on debug, that makes sense. It doesn't make any sense on a
production bu
Brian: you were the one that had an allergic reaction to #1 on the call.
Thoughts?
On Nov 2, 2011, at 1:23 PM, George Bosilca wrote:
> As it has been said, this is not something supposed to make it in a release.
> On the unfortunate case where it does, always having a show_help will ensure
>
As it has been said, this is not something supposed to make it in a release. On
the unfortunate case where it does, always having a show_help will ensure a
quick complaint on one of our mailing lists and increase the probability of a
[very] quick fix.
george.
On Nov 2, 2011, at 06:26 , TERRY
On 11/1/2011 7:48 PM, Jeff Squyres wrote:
So this was slightly different than the opinion that was discussed on the call
today, which was 2. The rationale for #2 was to punish developers, but if such
a bug did make it through to production, users wouldn't be annoyed with
show_help messages