Sorry it took so long for a reply; Ralph and I were working on this
code much of the day in an attempt to have it all complete / tidied up
for the teleconf tomorrow.
On May 12, 2008, at 10:04 AM, Josh Hursey wrote:
>> Er, no. I thought the group had agreed to the main idea last Tuesday
>> (framework for filtering output). We were racing against the time-
>> to-
>> branch clock and didn't take the time for an RFC after we agreed on
>> the design. Do we need to?
>
> I don't think so. But I'd just kinda like a more formal description of
> what this fix is and it's implications on how the developers are
> expected to use it going forward since this is altering the coding
> standards.
Fair enough, will do.
Since this one was kinda weird, do you want an after-the-fact RFC, or
a page on the wiki? I'm partial to the latter; it'll be more durable.
>> The side effect of eliminating duplicate error messages is new / was
>> not discussed last Tuesday -- I can put out an RFC for that if you'd
>> like, but the benefit is so obvious that I didn't think it would be
>> controversial.
>
> Don't get me wrong, I'm not arguing the benefit just that I'd like to
> know what is expected of me as a developer after this change.
That's perfectly reasonable. In short: s/opal_show_help/
orte_show_help/ in the ORTE and OMPI layers, and you're done (which we
already did throughout the code base). Use orte_show_help in the ORTE
and OMPI layers in the future. I think this information should go on
the wiki.
Finally, per a conversation that I had with Terry earlier today, I
added a new MCA parameter that will turn off the show_help message
aggregation. It defaults to aggregation enabled, but you can disable
it with:
... --mca orte_base_help_aggregation 0 ...
This will show *all* show_help messages, regardless of duplication.
Terry was worried that aggregating the same (filename, tuple) messages
may actually mask different errors because we allow %s expansion in
the message.
Re-examining George's mail in this thread, I think he may have had
similar concerns, but I didn't grok that at the time.
--
Jeff Squyres
Cisco Systems
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}