[mpiwg-tools] working group depository

[Kathryn Mohror]

>
>> I would suggest making the first sentence include enumerations and
>>categories:
>> 
>> Enumerations, variables, and categories with the same name in connectedŠ
>
>I thought about that.  But then you get into an ambiguity: is that
>sentence saying that if an enumeration and a variable have the same name,
>they must obey the same semantics (which wouldn't make sense)?
>
>Hence, I just listed variables first, and then said "the others also must
>obey these semantics...".

Ah, I see what you were doing there. It makes sense now.

>
>...although I see that my sentence after the itemized list induces this
>same ambiguity.  Drat.  See below.
>
>> We also might need to explicitly state the full names of the GET_INFO
>>routines instead of using a star.
>
>That was exactly what I was trying *not* to do, because then you get in
>the game of a) listing all the function names, and b) matching them to
>their respective word ("enumerations", "variables", and "categories").

I wasn¹t sure if ³standardeze² allowed for wildcards which is why I said
that. I think it¹s clear, but wasn¹t sure if it was formal enough. The
only place I see wildcard notation is in the tools chapter table of
constants and in 6.1 for MPI_Comm_*

>
>> Do you intend to keep the table we made of the parameters?
>
>I did not intend to, no.

AFTER I WORKED SO HARD ON IT? :-)
>
>Slightly new suggestion:
>
>-----
>Variables with the same name in connected processes are required to:
>
>* Adhere to the same definition from the MPI implementation
>* Exhibit the same behavioral semantics
>* Return the same INOUT and OUT values from the relevant
>  MPI_T_*_GET_INFO function, with the exception that OUT index values
>  may differ between different processes
>
>Similarly, enumerations and categories in connected processes must also
>obey the above restrictions.
>
>Advice to implementors. The intent of these requirements is to enforce
>consistent meanings of variables, categories, and enumerations across
>connected processes.  For example, variables describing the number of
>packets sent across different network device types should have different
>names to reflect their potentially different meanings. (End of advice to
>implementors.)
>-----

I¹m good with this. The only thing I think is weird is the wildcard in the
last bullet there, because there is only one relevant GET_INFO routine for
variables. It makes sense after I read the next sentence I suppose, but
not before. Of course, now that I say that, when I¹m reading this I don¹t
necessarily know there is only one GET_INFO routine for variables because
I haven¹t gotten to that part yetŠ

Kathryn

>
>-- 
>Jeff Squyres
>jsquyres at cisco.com
>For corporate legal information go to:
>http://www.cisco.com/web/about/doing_business/legal/cri/
>
>_______________________________________________
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools