[mpiwg-tools] Ticket #383 -- Final text?

[Kathryn Mohror]

Okay, here’s another try. Please let me know if this is now correct.  (Sorry
for the delay ― I am at IPDPS and the wifi is not so good)

Kathryn

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

From:  <Schulz>, Martin <schulz6 at llnl.gov>
Reply-To:  "mpiwg-tools at lists.mpi-forum.org"
<mpiwg-tools at lists.mpi-forum.org>
Date:  Monday, May 19, 2014 at 9:37 AM
To:  "'mpiwg-tools at lists.mpi-forum.org'" <mpiwg-tools at lists.mpi-forum.org>,
"'<mpiwg-tools at lists.mpi-forum.org>'" <mpiwg-tools at lists.mpi-forum.org>
Subject:  Re: [mpiwg-tools] Ticket #383 -- Final text?

Re: [mpiwg-tools] Ticket #383 -- Final text?
Either option is fine with me - I can see the argument either way

Martin



Sent with Good (www.good.com)


-----Original Message-----
From: Jeff Squyres (jsquyres) [jsquyres at cisco.com]
Sent: Monday, May 19, 2014 09:25 AM Pacific Standard Time
To: 
Subject: Re: [mpiwg-tools] Ticket #383 -- Final text?


Good point.  I like INOUT, but wont' fight too hard if people want to drop
it.

On May 19, 2014, at 12:08 PM, "Schulz, Martin" <schulz6 at llnl.gov>
 wrote:

> Looks mostly good to me, but length arguments are INOUT, so that may be
confusing - perhaps just drop the IN?
>
> Martin
>
>
>
> Sent with Good (www.good.com)
>
>
> -----Original Message-----
> From: Kathryn Mohror [kathryn at llnl.gov]
> Sent: Monday, May 19, 2014 08:31 AM Pacific Standard Time
> To: Bronis R. de Supinski; mpiwg-tools at lists.mpi-forum.org
> Subject: Re: [mpiwg-tools] Ticket #383 -- Final text?
>
> Jeff,
>
> Is this what you want for the text, attached?
>
> Kathryn
> _________________________________________________________________
> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
> USA
>
>
>
>
>
>
> On 5/19/14, 8:03 AM, "Bronis R. de Supinski" <bronis at llnl.gov> wrote:
>
> >
> >"sufficiently long enough" is redundant; "sufficiently long"
> >is sufficient.
> >
> >On Mon, 19 May 2014, Jeff Squyres (jsquyres) wrote:
> >
> >> On May 18, 2014, at 2:35 AM, Martin Schulz <schulzm at llnl.gov> wrote:
> >>
> >>> Hi Kathryn, all,
> >>>
> >>> A few comments:
> >>> - "Adhere to the same definition from the MPI implementation.² - not
> >>>sure
> >>> what we meant with this anymore. Perhaps we should just drop this part.
> >>
> >> What I meant by that is that each MPI implementation will create a
> >>definition for each cvar/pvar/etc.  The implementation must adhere to
> >>that same definition in all connected processes.  I.e., it can't change
> >>the definition of exactly what that variable is in different processes
> >>(e.g., bytes_in = bytes received from TCP in one process, but bytes
> >>received across shared memory in another process).
> >>
> >>> - "OUT index values² is not correct, since index values are IN
> >>>parameters
> >>> to the get_info calls. Perhaps just drop OUT?
> >>
> >> Good catch; missed that.  Yes, this whole clause can go.
> >>
> >>> - The mandate of equal OUT/INPUT values is also not quite right - for
> >>>the
> >>> strings, it¹s OK to return substrings of the size argument is too
> >>>small. I
> >>> know that¹s a technicality, but I am not sure if this causes problems
> >>> later down the road.
> >>
> >> Mmm.  Good point.  So the current text is:
> >>
> >> * Return the same INOUT and OUT values from the relevant
> >>MPI_T_*_GET_INFO function.
> >>
> >> (I took the liberty of dropping the index value clause)
> >>
> >> I notice that we actually return 3 kinds of things from GET_INFO
> >>functions: integers/enums, strings, and MPI handles (i.e.,
> >>MPI_Datatype).  So how about this:
> >>
> >> * Return the same INOUT and OUT integer and enum values from the
> >>relevant MPI_T_*_GET_INFO function.
> >> * If sufficiently long enough string length IN parameters are supplied,
> >>return the same string OUT parameters from the relevant MPI_T_*_GET_INFO
> >>function.
> >> * Return a handle to an equivalent MPI object from the relevant
> >>MPI_T_*_GET_INFO function.
> >>
> >>
> >>
> >> --
> >> 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


--
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20140519/bcd18890/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tools-3.pdf
Type: application/pdf
Size: 326967 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20140519/bcd18890/attachment-0001.pdf>