[mpiwg-tools] proposed text

[Marc-Andre Hermanns]

Hi Kathryn,

I think we don't have to search&replace the word string for <foo> string
throughout the chapter. I think we only need to define <foo> string in
14.3.3 and then state for the 6 parameters so far that those are foo
strings.

By and large <foo> strings are just like other C string. We just have
additional requirements to what "identical" means. That is why I came up
with the name: "quasi-identical", because they are not identical in the
normal C string sense (str*cmp). As "quasi-identical" is a new kind of
string, that probably no-one heard in a different context, so has no
preoccupation on what it could mean, a reader should go: "What's that?"
and refer to Section 14.3.3.

What's the groups take on the name "quasi-identical"?

Should we have an "out-of-order" telco tomorrow to discuss this? As we
need to finalize our wording by Monday in order for 383 to be an errata,
I think we need to make progress before the weekend.

Cheers,
Marc-Andre

PS: I know (almost) everyone is at SC, but maybe we can find a time for
a call.

On 18.11.14 22:03, Kathryn Mohror wrote:
> 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
>>
> 
> 
> _______________________________________________
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4842 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20141119/87f7ce8c/attachment-0001.bin>