[mpiwg-tools] proposed text

[Kathryn Mohror]

I see what you mean, and that helps.

Do you think then, that all instances of the word "string" in this chapter
(or the tools information interface part of the chapter anyway) need to be
changed to "<foo> string"?

Or can we just say that we refer to them as <foo> strings wherever
confusion might arise? (That seems a bit dangerous, I think, because who
knows where confusion could arise for a particular reader?)

Kathryn
_________________________________________________________________
Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
USA






On 11/18/14, 12:41 PM, "Marc-Andre Hermanns" <m.a.hermanns at grs-sim.de>
wrote:

>Hi Kathryn,
>
>if I understood right its a bit of both. We want to indicate that "our"
>strings (or their handling) are different from the rest of the standard,
>hence "MPI_T string" would be a good start. However, as I understand
>Jeff, it implies that "this is how MPI_T handles strings everywhere" and
>if we need some other handling of strings in MPI_T, we are then stuck
>with a name that implies the full scope of MPI_T when it does not
>provide it.
>
>What about "quasi-identical" strings to explicitly name what we want to
>express. Something along the lines of:
>
>Quasi-identical strings in MPI_T are strings that behave as if they are
>generated by a prefix-copy operation from a common source up to the
>length provided locally to the call returning the string.
>
>With something like this, we could then say, "foo" is a quasi-identical
>strings as discussed in 14.3.3, wherever we need it, e.g., for name and
>desc in the respective calls.
>
>What do you think?
>
>Cheers,
>Marc-Andre
>
>On 18.11.14 21:25, Kathryn Mohror wrote:
>> I'm a bit lost on the intended meaning behind the name: <foo> strings.
>> 
>> Do you want <foo> strings to indicate all strings in the MPI tool
>> information interface that are by our definition in 14.3.3 treated
>> differently than in the rest of the standard? And then have a concept of
>> identical <foo> strings and specify what is returned in the user's
>>buffer
>> for identical <foo> strings?
>> 
>> 
>> Or is <foo> strings supposed to only indicate strings that if identical,
>> have a particular defined behavior that determine what is returned into
>> the user's buffer according to our string conventions in 14.3.3?
>> 
>> Thanks,
>> Kathryn
>> 
>>>>> - so up in 14.3.3, have a definition for "<foo> strings" (someone
>>>>>come
>>>>> up
>>>>> with a better name than "<foo>"):
>>>>
>>>> MPI_T strings?
>>>
>>> Mmm.  That would imply that these are the *only* type of strings that
>>>are
>>> used in MPI_T.  That may be true today, but I don't know if we want to
>>>be
>>> locked in to that generalization for forever.
>>>
>>> How about "MPI_T universal strings"?
>>>
>>> -- 
>>> 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
>> 
>> 
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>> 
>
>-- 
>Marc-Andre Hermanns
>Jülich Aachen Research Alliance,
>High Performance Computing (JARA-HPC)
>German Research School for Simulation Sciences GmbH
>
>Schinkelstrasse 2
>52062 Aachen
>Germany
>
>Phone: +49 241 80 99753
>Fax: +49 241 80 6 99753
>www.grs-sim.de/parallel
>email: m.a.hermanns at grs-sim.de
>