February 2014 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] Question on ticket 377
by Junchao Zhang 26 Feb '14

26 Feb '14

I read the document again and found sentences like " This routine returns MPI_SUCCESS on success and returns MPI_T_ERR_INVALID_NAME if name does not match the name of any control variable provided by the implementation *at the time of the call*". So I think it is clear we should always return INVALID_* for inactive vars. Forgive me for the oversight. --Junchao Zhang On Thu, Feb 20, 2014 at 6:10 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Hi, > From the agenda, it seems all tickets for voting at the March meeting > are tools. > I have a question about ticket 377<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/377>, > which adds an error code "MPI_T_ERR_INVALID_NAME -- The variable or > category name is invalid". Remember we also use the word in the other case > like "The variable index is invalid". So, what is the meaning of invalid > in these two cases? > I raise this question because in the text we have "When a variable > becomes inactive, e.g., through dynamic unloading, accessing its value > should return a corresponding error code." Then, what operations are > thought as "accessing its values". Instead of *var_read, can I get_info of > an inactive variable? The answer will affect the definition of "invalid" in > cases above. So, I think we'd better clarify that. > > --Junchao Zhang >

1 0

Question on ticket 377
by Junchao Zhang 20 Feb '14

20 Feb '14

Hi, From the agenda, it seems all tickets for voting at the March meeting are tools. I have a question about ticket 377<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/377>, which adds an error code "MPI_T_ERR_INVALID_NAME -- The variable or category name is invalid". Remember we also use the word in the other case like "The variable index is invalid". So, what is the meaning of invalid in these two cases? I raise this question because in the text we have "When a variable becomes inactive, e.g., through dynamic unloading, accessing its value should return a corresponding error code." Then, what operations are thought as "accessing its values". Instead of *var_read, can I get_info of an inactive variable? The answer will affect the definition of "invalid" in cases above. So, I think we'd better clarify that. --Junchao Zhang

1 0

Re: [mpiwg-tools] No meeting today?
by Kathryn Mohror 20 Feb '14

20 Feb '14

Sorry all. I have been sick this week and am starting to be among the living again. I apologize for not passing the call responsibilities onto someone else. Kathryn On Feb 20, 2014, at 8:09 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > John, Dave, and I showed up on the webex this morning, but no one else did. > > So we decided to cancel the meeting. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

No meeting today?
by Jeff Squyres (jsquyres) 20 Feb '14

20 Feb '14

John, Dave, and I showed up on the webex this morning, but no one else did. So we decided to cancel the meeting. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-tools] ticket 405: MPI_CHAR as string
by Kathryn Mohror 15 Feb '14

15 Feb '14

Thanks again for the feedback. I have incorporated it and attached the latest version. Kathryn On Feb 15, 2014, at 4:47 AM, Marc-Andre Hermanns <m.a.hermanns(a)grs-sim.de> wrote: > +1 > > I under stand the null-terminating character as "the character doing the > null termination". As only the null character can do that, the text is > clearer now. > > Cheers, > Marc-Andre > > On 15.02.14 13:42, Jeff Squyres (jsquyres) wrote: >> Sorry -- nit-picking on my own text: >> >> ----- >> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC must be large enough to include any valid value, including its null-terminating character. The contents of returned MPI_CHAR arrays are only defined from index 0 through the location of the first null-terminating character. >> ----- >> >> In the 2nd and 3rd sentence, we refer to the "null-terminating character". Is that correct? Isn't it just a "null character"? >> >> We use "null-terminated character array" in the first sentence, and that seems fine. But "null-terminated character" means "a character terminated by a null", which doesn't seem to make sense. >> >> In 14.3.3 ("Convention for Returning Strings"), we refer to the "null terminator" and "terminating null character"). >> >> I therefore think we should slightly change the last 2 sentences to: >> >> ----- >> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC must be large enough to include any valid value, including its ***terminating null*** character. The contents of returned MPI_CHAR arrays are only defined from index 0 through the location of the first ***null*** character. >> ----- >> >> >> >> >> On Feb 14, 2014, at 6:16 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote: >> >>> Thanks for the feedback. I have attached a new draft for this ticket and incorporated your changes. Please give me any additional comments by the start of business Monday. >>> >>> Kathryn >>> >>> On Feb 14, 2014, at 7:23 AM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: >>> >>>> +1 to almost everything that Jeff said. My only quibble would be to change the last sentence in his text from: >>>> >>>> The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character. >>>> >>>> To: >>>> >>>> The contents of returned MPI_CHAR ***arrays*** are only defined from index 0 through the location of the first null-terminating character. >>>> >>>> -Dave >>>> >>>> On Feb 14, 2014, at 7:27 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >>>> >>>>> Here's the new text: >>>>> >>>>> ----- >>>>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e. a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC will include the null-terminating character. The value returned in count must be large enough to contain any valid value for the given variable. Arrays of type MPI_CHAR are only valid to the first null character. >>>>> ----- >>>>> >>>>> There's a missing "," after "i.e." -- it should be "i.e.," >>>>> >>>>> I'd make some other minor changes: >>>>> >>>>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC ***must be large enough to include any valid value, including its null-terminating character.*** ***The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character.*** >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Feb 13, 2014, at 3:24 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Please have a look at this since we have to decide if it's ready for a reading, and submit it to the forum for review on Monday if we do. >>>>>> >>>>>> Kathryn >>>>>> >>>>>> On Feb 7, 2014, at 1:05 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> As we discussed in our call, I have drafted new text for ticket 405 which clarifies our intent for the MPI_CHAR datatype to represent strings in the tools interface. Please take a look at the red text for ticket 405 in the attached document and send your comments. >>>>>>> >>>>>>> Kathryn >>>>>>> >>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>>>>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <tools-3.pdf>_______________________________________________ >>>>>>> mpiwg-tools mailing list >>>>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>>>>> >>>>>> _________________________________________________________________ >>>>>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>>>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-tools mailing list >>>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>>>> >>>>> >>>>> -- >>>>> Jeff Squyres >>>>> jsquyres(a)cisco.com >>>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>> >>>>> _______________________________________________ >>>>> mpiwg-tools mailing list >>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >>> _________________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >>> >>> >>> >>> >>> >>> >>> >>> >>> <tools-3.pdf>_______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> > > -- > Marc-Andre Hermanns > German Research School for > Simulation Sciences GmbH > c/o Laboratory for Parallel Programming > 52062 Aachen | Germany > > Tel +49 241 80 99753 > Fax +49 241 80 6 99753 > Web www.grs-sim.de > > Members: Forschungszentrum Jülich GmbH | RWTH Aachen University > Registered in the commercial register of the local court of > Düren (Amtsgericht Düren) under registration number HRB 5268 > Registered office: Jülich > Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] ticket 405: MPI_CHAR as string
by Marc-Andre Hermanns 15 Feb '14

15 Feb '14

+1 I under stand the null-terminating character as "the character doing the null termination". As only the null character can do that, the text is clearer now. Cheers, Marc-Andre On 15.02.14 13:42, Jeff Squyres (jsquyres) wrote: > Sorry -- nit-picking on my own text: > > ----- > The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC must be large enough to include any valid value, including its null-terminating character. The contents of returned MPI_CHAR arrays are only defined from index 0 through the location of the first null-terminating character. > ----- > > In the 2nd and 3rd sentence, we refer to the "null-terminating character". Is that correct? Isn't it just a "null character"? > > We use "null-terminated character array" in the first sentence, and that seems fine. But "null-terminated character" means "a character terminated by a null", which doesn't seem to make sense. > > In 14.3.3 ("Convention for Returning Strings"), we refer to the "null terminator" and "terminating null character"). > > I therefore think we should slightly change the last 2 sentences to: > > ----- > The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC must be large enough to include any valid value, including its ***terminating null*** character. The contents of returned MPI_CHAR arrays are only defined from index 0 through the location of the first ***null*** character. > ----- > > > > > On Feb 14, 2014, at 6:16 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote: > >> Thanks for the feedback. I have attached a new draft for this ticket and incorporated your changes. Please give me any additional comments by the start of business Monday. >> >> Kathryn >> >> On Feb 14, 2014, at 7:23 AM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: >> >>> +1 to almost everything that Jeff said. My only quibble would be to change the last sentence in his text from: >>> >>> The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character. >>> >>> To: >>> >>> The contents of returned MPI_CHAR ***arrays*** are only defined from index 0 through the location of the first null-terminating character. >>> >>> -Dave >>> >>> On Feb 14, 2014, at 7:27 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >>> >>>> Here's the new text: >>>> >>>> ----- >>>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e. a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC will include the null-terminating character. The value returned in count must be large enough to contain any valid value for the given variable. Arrays of type MPI_CHAR are only valid to the first null character. >>>> ----- >>>> >>>> There's a missing "," after "i.e." -- it should be "i.e.," >>>> >>>> I'd make some other minor changes: >>>> >>>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC ***must be large enough to include any valid value, including its null-terminating character.*** ***The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character.*** >>>> >>>> >>>> >>>> >>>> >>>> On Feb 13, 2014, at 3:24 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Please have a look at this since we have to decide if it's ready for a reading, and submit it to the forum for review on Monday if we do. >>>>> >>>>> Kathryn >>>>> >>>>> On Feb 7, 2014, at 1:05 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> As we discussed in our call, I have drafted new text for ticket 405 which clarifies our intent for the MPI_CHAR datatype to represent strings in the tools interface. Please take a look at the red text for ticket 405 in the attached document and send your comments. >>>>>> >>>>>> Kathryn >>>>>> >>>>>> >>>>>> _________________________________________________________________ >>>>>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>>>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> <tools-3.pdf>_______________________________________________ >>>>>> mpiwg-tools mailing list >>>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>>>> >>>>> _________________________________________________________________ >>>>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpiwg-tools mailing list >>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>>> >>>> >>>> -- >>>> Jeff Squyres >>>> jsquyres(a)cisco.com >>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> _________________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> >> >> >> >> <tools-3.pdf>_______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > -- Marc-Andre Hermanns German Research School for Simulation Sciences GmbH c/o Laboratory for Parallel Programming 52062 Aachen | Germany Tel +49 241 80 99753 Fax +49 241 80 6 99753 Web www.grs-sim.de Members: Forschungszentrum Jülich GmbH | RWTH Aachen University Registered in the commercial register of the local court of Düren (Amtsgericht Düren) under registration number HRB 5268 Registered office: Jülich Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt

1 0

Re: [mpiwg-tools] ticket 405: MPI_CHAR as string
by Jeff Squyres (jsquyres) 15 Feb '14

15 Feb '14

Sorry -- nit-picking on my own text: ----- The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC must be large enough to include any valid value, including its null-terminating character. The contents of returned MPI_CHAR arrays are only defined from index 0 through the location of the first null-terminating character. ----- In the 2nd and 3rd sentence, we refer to the "null-terminating character". Is that correct? Isn't it just a "null character"? We use "null-terminated character array" in the first sentence, and that seems fine. But "null-terminated character" means "a character terminated by a null", which doesn't seem to make sense. In 14.3.3 ("Convention for Returning Strings"), we refer to the "null terminator" and "terminating null character"). I therefore think we should slightly change the last 2 sentences to: ----- The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC must be large enough to include any valid value, including its ***terminating null*** character. The contents of returned MPI_CHAR arrays are only defined from index 0 through the location of the first ***null*** character. ----- On Feb 14, 2014, at 6:16 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote: > Thanks for the feedback. I have attached a new draft for this ticket and incorporated your changes. Please give me any additional comments by the start of business Monday. > > Kathryn > > On Feb 14, 2014, at 7:23 AM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > >> +1 to almost everything that Jeff said. My only quibble would be to change the last sentence in his text from: >> >> The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character. >> >> To: >> >> The contents of returned MPI_CHAR ***arrays*** are only defined from index 0 through the location of the first null-terminating character. >> >> -Dave >> >> On Feb 14, 2014, at 7:27 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >>> Here's the new text: >>> >>> ----- >>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e. a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC will include the null-terminating character. The value returned in count must be large enough to contain any valid value for the given variable. Arrays of type MPI_CHAR are only valid to the first null character. >>> ----- >>> >>> There's a missing "," after "i.e." -- it should be "i.e.," >>> >>> I'd make some other minor changes: >>> >>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC ***must be large enough to include any valid value, including its null-terminating character.*** ***The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character.*** >>> >>> >>> >>> >>> >>> On Feb 13, 2014, at 3:24 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: >>> >>>> Hi all, >>>> >>>> Please have a look at this since we have to decide if it's ready for a reading, and submit it to the forum for review on Monday if we do. >>>> >>>> Kathryn >>>> >>>> On Feb 7, 2014, at 1:05 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote: >>>> >>>>> Hi all, >>>>> >>>>> As we discussed in our call, I have drafted new text for ticket 405 which clarifies our intent for the MPI_CHAR datatype to represent strings in the tools interface. Please take a look at the red text for ticket 405 in the attached document and send your comments. >>>>> >>>>> Kathryn >>>>> >>>>> >>>>> _________________________________________________________________ >>>>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> <tools-3.pdf>_______________________________________________ >>>>> mpiwg-tools mailing list >>>>> mpiwg-tools(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>>> >>>> _________________________________________________________________ >>>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > > <tools-3.pdf>_______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-tools] ticket 405: MPI_CHAR as string
by Mohror, Kathryn 14 Feb '14

14 Feb '14

Thanks for the feedback. I have attached a new draft for this ticket and incorporated your changes. Please give me any additional comments by the start of business Monday. Kathryn On Feb 14, 2014, at 7:23 AM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com<mailto:[email protected]>> wrote: +1 to almost everything that Jeff said. My only quibble would be to change the last sentence in his text from: The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character. To: The contents of returned MPI_CHAR ***arrays*** are only defined from index 0 through the location of the first null-terminating character. -Dave On Feb 14, 2014, at 7:27 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com<mailto:[email protected]>> wrote: Here's the new text: ----- The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e. a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC will include the null-terminating character. The value returned in count must be large enough to contain any valid value for the given variable. Arrays of type MPI_CHAR are only valid to the first null character. ----- There's a missing "," after "i.e." -- it should be "i.e.," I'd make some other minor changes: The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC ***must be large enough to include any valid value, including its null-terminating character.*** ***The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character.*** On Feb 13, 2014, at 3:24 PM, Kathryn Mohror <kathryn(a)llnl.gov<mailto:[email protected]>> wrote: Hi all, Please have a look at this since we have to decide if it's ready for a reading, and submit it to the forum for review on Monday if we do. Kathryn On Feb 7, 2014, at 1:05 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov<mailto:[email protected]>> wrote: Hi all, As we discussed in our call, I have drafted new text for ticket 405 which clarifies our intent for the MPI_CHAR datatype to represent strings in the tools interface. Please take a look at the red text for ticket 405 in the attached document and send your comments. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA <tools-3.pdf>_______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] ticket 405: MPI_CHAR as string
by Dave Goodell (dgoodell) 14 Feb '14

14 Feb '14

+1 to almost everything that Jeff said. My only quibble would be to change the last sentence in his text from: The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character. To: The contents of returned MPI_CHAR ***arrays*** are only defined from index 0 through the location of the first null-terminating character. -Dave On Feb 14, 2014, at 7:27 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Here's the new text: > > ----- > The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e. a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC will include the null-terminating character. The value returned in count must be large enough to contain any valid value for the given variable. Arrays of type MPI_CHAR are only valid to the first null character. > ----- > > There's a missing "," after "i.e." -- it should be "i.e.," > > I'd make some other minor changes: > > The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC ***must be large enough to include any valid value, including its null-terminating character.*** ***The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character.*** > > > > > > On Feb 13, 2014, at 3:24 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > >> Hi all, >> >> Please have a look at this since we have to decide if it's ready for a reading, and submit it to the forum for review on Monday if we do. >> >> Kathryn >> >> On Feb 7, 2014, at 1:05 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote: >> >>> Hi all, >>> >>> As we discussed in our call, I have drafted new text for ticket 405 which clarifies our intent for the MPI_CHAR datatype to represent strings in the tools interface. Please take a look at the red text for ticket 405 in the attached document and send your comments. >>> >>> Kathryn >>> >>> >>> _________________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >>> >>> >>> >>> >>> >>> >>> >>> >>> <tools-3.pdf>_______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> _________________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> >> >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] ticket 405: MPI_CHAR as string
by Jeff Squyres (jsquyres) 14 Feb '14

14 Feb '14

Here's the new text: ----- The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e. a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC will include the null-terminating character. The value returned in count must be large enough to contain any valid value for the given variable. Arrays of type MPI_CHAR are only valid to the first null character. ----- There's a missing "," after "i.e." -- it should be "i.e.," I'd make some other minor changes: The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC ***must be large enough to include any valid value, including its null-terminating character.*** ***The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character.*** On Feb 13, 2014, at 3:24 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Hi all, > > Please have a look at this since we have to decide if it's ready for a reading, and submit it to the forum for review on Monday if we do. > > Kathryn > > On Feb 7, 2014, at 1:05 PM, "Mohror, Kathryn" <mohror1(a)llnl.gov> wrote: > >> Hi all, >> >> As we discussed in our call, I have drafted new text for ticket 405 which clarifies our intent for the MPI_CHAR datatype to represent strings in the tools interface. Please take a look at the red text for ticket 405 in the attached document and send your comments. >> >> Kathryn >> >> >> _________________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> >> >> >> >> <tools-3.pdf>_______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > _________________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0