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

Re: [mpiwg-tools] Ticket 383: Variables with the same name ticket
by Schulz Martin 31 Aug '14

31 Aug '14

Hi Kathryn, The text misses the INOUT/OUT instead of just OUT on page 34, line 10, otherwise this looks good to me. Thanks! Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 8/30/14, 4:44 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >Hi Martin, > >Thanks for the feedback. I incorporated it and attached the new copy. > >Anyone else have comments? > >Thanks! >Kathryn >_________________________________________________________________ >Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >USA > > > > > > >On 8/30/14, 1:22 AM, "Schulz Martin" <schulzm(a)llnl.gov> wrote: > >>Hi Kathryn, all, >> >>Thanks for putting this together. I think, this looks almost right. Just >>the string returns are not quite right, I think. What about adding the >>following: >> >> >>Page 15: >> >> >> >> >> >> >> >> >> If the name of a control variable is the same across connected >>processes, the following OUT parameters must be identical: verbosity, >>datatype, enumtype, desc, desc_len, bind, scope. >>-> >>If the name of a control variable is the same across connected processes, >>the following INOUT/OUT parameters must be identical: verbosity, >>datatype, >>enumtype, desc, desc_len, bind, scope (assuming identical values are >>passed in desc_len). >> >> >> >>Same on page 24: >>If the name and class of a performance variable are the same across >>connected processes, >>the following OUT parameters must be identical: verbosity, varclass, >>datatype, enumtype, >>desc, desc_len, bind, readonly, continuous, atomic. >>-> >> >> >> >> >>If the name and class of a performance variable are the same across >>connected processes, >>the following INOUT/OUT parameters must be identical: verbosity, >>varclass, >>datatype, enumtype, >>desc, desc_len, bind, readonly, continuous, atomic (assuming identical >>values are passed in desc_len). >> >> >>Same on page 34 >> >> >> >> >> >> >> >> >> >> If the name of a category is the same across connected processes, >>the >>following OUT >>parameters must be identical: desc, desc_len. >>-> >>If the name of a category is the same across connected processes, the >>following INOUT/OUT >>parameters must be identical: desc, desc_len (assuming identical values >>are passed in desc_len). >> >> >>Martin >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>________________________________________________________________________ >>Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >>CASC @ Lawrence Livermore National Laboratory, Livermore, USA >> >> >> >> >> >>On 8/29/14, 6:10 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >> >>>Hi all, >>> >>>Here¹s a draft of the tools chapter with changes for ticket #383 based >>>on >>>our last discussion. Let¹s see if we can get this nailed down to read in >>>Japan. >>> >>>Please see the attached, and keep in mind that the due date for ticket >>>announcements is MONDAY! >>> >>>Thanks, >>>Kathryn >>> >>> >>> >>>_________________________________________________________________ >>>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 >

1 0

Re: [mpiwg-tools] Ticket 383: Variables with the same name ticket
by Kathryn Mohror 30 Aug '14

30 Aug '14

Hi Martin, Thanks for the feedback. I incorporated it and attached the new copy. Anyone else have comments? Thanks! Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 8/30/14, 1:22 AM, "Schulz Martin" <schulzm(a)llnl.gov> wrote: >Hi Kathryn, all, > >Thanks for putting this together. I think, this looks almost right. Just >the string returns are not quite right, I think. What about adding the >following: > > >Page 15: > > > > > > > > > If the name of a control variable is the same across connected >processes, the following OUT parameters must be identical: verbosity, >datatype, enumtype, desc, desc_len, bind, scope. >-> >If the name of a control variable is the same across connected processes, >the following INOUT/OUT parameters must be identical: verbosity, datatype, >enumtype, desc, desc_len, bind, scope (assuming identical values are >passed in desc_len). > > > >Same on page 24: >If the name and class of a performance variable are the same across >connected processes, >the following OUT parameters must be identical: verbosity, varclass, >datatype, enumtype, >desc, desc_len, bind, readonly, continuous, atomic. >-> > > > > >If the name and class of a performance variable are the same across >connected processes, >the following INOUT/OUT parameters must be identical: verbosity, varclass, >datatype, enumtype, >desc, desc_len, bind, readonly, continuous, atomic (assuming identical >values are passed in desc_len). > > >Same on page 34 > > > > > > > > > > If the name of a category is the same across connected processes, the >following OUT >parameters must be identical: desc, desc_len. >-> >If the name of a category is the same across connected processes, the >following INOUT/OUT >parameters must be identical: desc, desc_len (assuming identical values >are passed in desc_len). > > >Martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >________________________________________________________________________ >Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ >CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > >On 8/29/14, 6:10 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: > >>Hi all, >> >>Here¹s a draft of the tools chapter with changes for ticket #383 based on >>our last discussion. Let¹s see if we can get this nailed down to read in >>Japan. >> >>Please see the attached, and keep in mind that the due date for ticket >>announcements is MONDAY! >> >>Thanks, >>Kathryn >> >> >> >>_________________________________________________________________ >>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

1 0

Re: [mpiwg-tools] Ticket 383: Variables with the same name ticket
by Schulz Martin 30 Aug '14

30 Aug '14

Hi Kathryn, all, Thanks for putting this together. I think, this looks almost right. Just the string returns are not quite right, I think. What about adding the following: Page 15: If the name of a control variable is the same across connected processes, the following OUT parameters must be identical: verbosity, datatype, enumtype, desc, desc_len, bind, scope. -> If the name of a control variable is the same across connected processes, the following INOUT/OUT parameters must be identical: verbosity, datatype, enumtype, desc, desc_len, bind, scope (assuming identical values are passed in desc_len). Same on page 24: If the name and class of a performance variable are the same across connected processes, the following OUT parameters must be identical: verbosity, varclass, datatype, enumtype, desc, desc_len, bind, readonly, continuous, atomic. -> If the name and class of a performance variable are the same across connected processes, the following INOUT/OUT parameters must be identical: verbosity, varclass, datatype, enumtype, desc, desc_len, bind, readonly, continuous, atomic (assuming identical values are passed in desc_len). Same on page 34 If the name of a category is the same across connected processes, the following OUT parameters must be identical: desc, desc_len. -> If the name of a category is the same across connected processes, the following INOUT/OUT parameters must be identical: desc, desc_len (assuming identical values are passed in desc_len). Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://scalability.llnl.gov/ CASC @ Lawrence Livermore National Laboratory, Livermore, USA On 8/29/14, 6:10 PM, "Kathryn Mohror" <kathryn(a)llnl.gov> wrote: >Hi all, > >Here¹s a draft of the tools chapter with changes for ticket #383 based on >our last discussion. Let¹s see if we can get this nailed down to read in >Japan. > >Please see the attached, and keep in mind that the due date for ticket >announcements is MONDAY! > >Thanks, >Kathryn > > > >_________________________________________________________________ >Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >USA > > > >

1 0

Ticket 383: Variables with the same name ticket
by Kathryn Mohror 29 Aug '14

29 Aug '14

Hi all, Here¹s a draft of the tools chapter with changes for ticket #383 based on our last discussion. Let¹s see if we can get this nailed down to read in Japan. Please see the attached, and keep in mind that the due date for ticket announcements is MONDAY! Thanks, Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
by Kathryn Mohror 26 Aug '14

26 Aug '14

> >> I suppose it doesn¹t change semantics, but possibly implementation of >> tools and MPI libraries. I was under the impression that anything that >> could change how a program that uses MPI is written couldn¹t be ticket >>0. > >Mmm. Ok, fair enough. > >> For my part, I don¹t really think it¹s wrong to not use the same >> convention as the rest of the MPI library for true and false. We don¹t >>use the same string convention, after all. > >Strings are one thing, but booleans are a different (smaller) thing. > >I would think that now is the time to actually nip this inconsistency in >the bud -- *while* people are initially writing all the MPI_T-based >tools, etc. Vs. someone else in the Forum (outside the Tools WG) >noticing the inconsistency, insisting that we fix the inconsistency, and >then we have the problem of lots of existing MPI_T tools that need to be >updated / backwards-compatibility woes. > >It's a small thing; you've convinced me that it should be an errata >ticket (vs. a ticket 0 change). But it's a small/easy one. And now is >the time to do it. Okay, then do we want to try for Japan to introduce it as errata? That would mean we would need to get it finalized by basically this weekend. I think Labor Day is the two week mark for introducing tickets. I would be fine with that, but would need someone else to drive the ticket. I have a busy week this week and wouldn¹t have the time to devote to it. Any volunteers? Kathryn > >-- >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

Why are typedefs (and types in general) in the debug interfaces problematic?
by John DelSignore 18 Aug '14

18 Aug '14

1 0

Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
by Jeff Squyres (jsquyres) 16 Aug '14

16 Aug '14

On Aug 15, 2014, at 11:45 AM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > I suppose it doesn’t change semantics, but possibly implementation of > tools and MPI libraries. I was under the impression that anything that > could change how a program that uses MPI is written couldn’t be ticket 0. Mmm. Ok, fair enough. > For my part, I don’t really think it’s wrong to not use the same > convention as the rest of the MPI library for true and false. We don’t use the same string convention, after all. Strings are one thing, but booleans are a different (smaller) thing. I would think that now is the time to actually nip this inconsistency in the bud -- *while* people are initially writing all the MPI_T-based tools, etc. Vs. someone else in the Forum (outside the Tools WG) noticing the inconsistency, insisting that we fix the inconsistency, and then we have the problem of lots of existing MPI_T tools that need to be updated / backwards-compatibility woes. It's a small thing; you've convinced me that it should be an errata ticket (vs. a ticket 0 change). But it's a small/easy one. And now is the time to do it. -- 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] Too strict for flags in MPI_T_pvar_get_info?
by Kathryn Mohror 15 Aug '14

15 Aug '14

I suppose it doesn’t change semantics, but possibly implementation of tools and MPI libraries. I was under the impression that anything that could change how a program that uses MPI is written couldn’t be ticket 0. For my part, I don’t really think it’s wrong to not use the same convention as the rest of the MPI library for true and false. We don’t use the same string convention, after all. Kathryn _________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA On 8/14/14, 1:11 PM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >How does it change semantics? > >On Aug 14, 2014, at 4:09 PM, Schulz, Martin <schulz6(a)llnl.gov> wrote: > >> I would tend to agree with Kathryn, that this is more than ticket 0, >>since it does change semantics. It seems to me, though, that this is a >>clear bug in the specification and hence errata. >> >> Martin >> >> ________________________________________ >> From: mpiwg-tools [mpiwg-tools-bounces(a)lists.mpi-forum.org] on behalf >>of Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] >> Sent: Thursday, August 14, 2014 12:07 PM >> To: MPI Tool WG >> Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info? >> >> Is >> >> s/0/false/g >> s/1/true/g >> >> (where relevant, of course) >> >> in the Tools chapter more than a ticket-0 change? >> >> >> On Aug 14, 2014, at 2:39 PM, Mohror, Kathryn <mohror1(a)llnl.gov> wrote: >> >>> Hi Jeff, >>> >>> I see your point too. How do you propose to fix it? Make it clearer >>>why we don't follow the same convention? Or change it to follow the >>>rest of the standard? (The latter doesn't seem like ticket 0 to me.) >>> >>> >>> >>> -- Kathryn >>> >>> Sent with Good (www.good.com) >>> >>> >>> -----Original Message----- >>> From: Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] >>> Sent: Thursday, August 14, 2014 10:28 AM Pacific Standard Time >>> To: MPI Tool WG >>> Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info? >>> >>> I think the parts about the C convention/ignoring Fortran is fine. >>> >>> But I think Junchao is raising the small-but-valid point that >>>elsewhere in the doc, we say true/false for such things, but here in >>>the tools chapter, we're saying 1/0. So I'd say that this is a valid >>>"consistency" kind of issue. >>> >>> I'd further opine that this is a ticket 0 kind of change, and the >>>chapter author should just make the change. >>> >>> >>> >>> On Aug 14, 2014, at 1:19 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: >>> >>>> Hi Junchao, >>>> >>>> Thanks as always for your sharp eyes. I think though in this case that >>>> Nathan is correct. Since we only define a C interface for MPI_T and >>>>try to >>>> ignore Fortran altogether, it is okay to use the C convention for >>>>true and >>>> false. >>>> >>>> Kathryn >>>> _________________________________________________________________ >>>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, >>>>CA, >>>> USA >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 8/14/14, 9:49 AM, "Nathan Hjelm" <hjelmn(a)mac.com> wrote: >>>> >>>>> >>>>> On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> >>>>>wrote: >>>>> >>>>> >>>>> >>>>> >>>>> It is a minor issue. In the Standard, the description for >>>>> int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int >>>>> *atomic) >>>>> says: >>>>> Upon return, the argument readonly is set to zero if the variable can >>>>> be written or reset by the user. It is set to >>>>> one if the variable can only be read. >>>>> (Same thing happens to continuous and atomic.) >>>>> >>>>> >>>>> The description mandates an implementation must return 1 as TRUE, >>>>>which >>>>> does not follow C's convention. Other parts of MPI use true/false >>>>>instead >>>>> of 1/0 in description. Section 2.6.3 make it clear that true means >>>>> non-zero. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> How does that not follow C¹s convention? C mandates that the >>>>>evaluation >>>>> of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1. >>>>> Returning 0/1 here makes perfect sense. >>>>> >>>>> >>>>> Other parts of MPI probably use true/false because fortran logicals >>>>>do >>>>> not use 0/1 for false/true. >>>>> >>>>> >>>>> -Nathan Hjelm >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> -- >> 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 > > >-- >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] Too strict for flags in MPI_T_pvar_get_info?
by Jeff Squyres (jsquyres) 14 Aug '14

14 Aug '14

How does it change semantics? On Aug 14, 2014, at 4:09 PM, Schulz, Martin <schulz6(a)llnl.gov> wrote: > I would tend to agree with Kathryn, that this is more than ticket 0, since it does change semantics. It seems to me, though, that this is a clear bug in the specification and hence errata. > > Martin > > ________________________________________ > From: mpiwg-tools [mpiwg-tools-bounces(a)lists.mpi-forum.org] on behalf of Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] > Sent: Thursday, August 14, 2014 12:07 PM > To: MPI Tool WG > Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info? > > Is > > s/0/false/g > s/1/true/g > > (where relevant, of course) > > in the Tools chapter more than a ticket-0 change? > > > On Aug 14, 2014, at 2:39 PM, Mohror, Kathryn <mohror1(a)llnl.gov> wrote: > >> Hi Jeff, >> >> I see your point too. How do you propose to fix it? Make it clearer why we don't follow the same convention? Or change it to follow the rest of the standard? (The latter doesn't seem like ticket 0 to me.) >> >> >> >> -- Kathryn >> >> Sent with Good (www.good.com) >> >> >> -----Original Message----- >> From: Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] >> Sent: Thursday, August 14, 2014 10:28 AM Pacific Standard Time >> To: MPI Tool WG >> Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info? >> >> I think the parts about the C convention/ignoring Fortran is fine. >> >> But I think Junchao is raising the small-but-valid point that elsewhere in the doc, we say true/false for such things, but here in the tools chapter, we're saying 1/0. So I'd say that this is a valid "consistency" kind of issue. >> >> I'd further opine that this is a ticket 0 kind of change, and the chapter author should just make the change. >> >> >> >> On Aug 14, 2014, at 1:19 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: >> >>> Hi Junchao, >>> >>> Thanks as always for your sharp eyes. I think though in this case that >>> Nathan is correct. Since we only define a C interface for MPI_T and try to >>> ignore Fortran altogether, it is okay to use the C convention for true and >>> false. >>> >>> Kathryn >>> _________________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ >>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, >>> USA >>> >>> >>> >>> >>> >>> >>> On 8/14/14, 9:49 AM, "Nathan Hjelm" <hjelmn(a)mac.com> wrote: >>> >>>> >>>> On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: >>>> >>>> >>>> >>>> >>>> It is a minor issue. In the Standard, the description for >>>> int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int >>>> *atomic) >>>> says: >>>> Upon return, the argument readonly is set to zero if the variable can >>>> be written or reset by the user. It is set to >>>> one if the variable can only be read. >>>> (Same thing happens to continuous and atomic.) >>>> >>>> >>>> The description mandates an implementation must return 1 as TRUE, which >>>> does not follow C's convention. Other parts of MPI use true/false instead >>>> of 1/0 in description. Section 2.6.3 make it clear that true means >>>> non-zero. >>>> >>>> >>>> >>>> >>>> >>>> How does that not follow C¹s convention? C mandates that the evaluation >>>> of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1. >>>> Returning 0/1 here makes perfect sense. >>>> >>>> >>>> Other parts of MPI probably use true/false because fortran logicals do >>>> not use 0/1 for false/true. >>>> >>>> >>>> -Nathan Hjelm >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 > > > -- > 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 -- 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] Too strict for flags in MPI_T_pvar_get_info?
by Schulz, Martin 14 Aug '14

14 Aug '14

I would tend to agree with Kathryn, that this is more than ticket 0, since it does change semantics. It seems to me, though, that this is a clear bug in the specification and hence errata. Martin ________________________________________ From: mpiwg-tools [mpiwg-tools-bounces(a)lists.mpi-forum.org] on behalf of Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] Sent: Thursday, August 14, 2014 12:07 PM To: MPI Tool WG Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info? Is s/0/false/g s/1/true/g (where relevant, of course) in the Tools chapter more than a ticket-0 change? On Aug 14, 2014, at 2:39 PM, Mohror, Kathryn <mohror1(a)llnl.gov> wrote: > Hi Jeff, > > I see your point too. How do you propose to fix it? Make it clearer why we don't follow the same convention? Or change it to follow the rest of the standard? (The latter doesn't seem like ticket 0 to me.) > > > > -- Kathryn > > Sent with Good (www.good.com) > > > -----Original Message----- > From: Jeff Squyres (jsquyres) [jsquyres(a)cisco.com] > Sent: Thursday, August 14, 2014 10:28 AM Pacific Standard Time > To: MPI Tool WG > Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info? > > I think the parts about the C convention/ignoring Fortran is fine. > > But I think Junchao is raising the small-but-valid point that elsewhere in the doc, we say true/false for such things, but here in the tools chapter, we're saying 1/0. So I'd say that this is a valid "consistency" kind of issue. > > I'd further opine that this is a ticket 0 kind of change, and the chapter author should just make the change. > > > > On Aug 14, 2014, at 1:19 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > > > Hi Junchao, > > > > Thanks as always for your sharp eyes. I think though in this case that > > Nathan is correct. Since we only define a C interface for MPI_T and try to > > ignore Fortran altogether, it is okay to use the C convention for true and > > false. > > > > Kathryn > > _________________________________________________________________ > > Kathryn Mohror, kathryn(a)llnl.gov, http://scalability.llnl.gov/ > > Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, > > USA > > > > > > > > > > > > > > On 8/14/14, 9:49 AM, "Nathan Hjelm" <hjelmn(a)mac.com> wrote: > > > >> > >> On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > >> > >> > >> > >> > >> It is a minor issue. In the Standard, the description for > >> int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int > >> *atomic) > >> says: > >> Upon return, the argument readonly is set to zero if the variable can > >> be written or reset by the user. It is set to > >> one if the variable can only be read. > >> (Same thing happens to continuous and atomic.) > >> > >> > >> The description mandates an implementation must return 1 as TRUE, which > >> does not follow C's convention. Other parts of MPI use true/false instead > >> of 1/0 in description. Section 2.6.3 make it clear that true means > >> non-zero. > >> > >> > >> > >> > >> > >> How does that not follow C¹s convention? C mandates that the evaluation > >> of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1. > >> Returning 0/1 here makes perfect sense. > >> > >> > >> Other parts of MPI probably use true/false because fortran logicals do > >> not use 0/1 for false/true. > >> > >> > >> -Nathan Hjelm > >> > >> > > > > > > _______________________________________________ > > 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 -- 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