[Mpi-forum] Ticket 265 - Re: Changelog question

Fab Tillier ftillier at microsoft.com
Mon Apr 25 19:54:19 CDT 2011


The changelog has been condensed as you suggested, and Jeff kindly built and attached a new PDF to the ticket.

-Fab

Rolf Rabenseifner wrote on Mon, 25 Apr 2011 at 04:55:36

> Jeff  and Fab,
> 
> I would say that the content is fine, but it would also be as
> same as good when you combine and shorten some entries, to reduce
> the total number to 2 entries, and I would add a simple sentence
> about compatibility in the last one:
> 
> 2. Sections 2.5.8, 3.2.2, 3.3 on pages 16, 29, 31, Sections 4.1.5,
> 4.1.7, 4.1.8, 4.1.11, 5.9.2 on pages 97, 99, 101, 105, 172, Section 12.3
> on page 412, and Appendix A.1.1 on page 545. New inquiry functions,
> MPI_TYPE_SIZE_X, MPI_TYPE_GET_EXTENT_X, MPI_TYPE_GET_TRUE_EXTENT_X, and
> MPI_GET_ELEMENTS_X, return their results as an MPI_Count value, which is
> a new type large enough to represent element counts in memory, file
> views, etc. A new function, MPI_STATUS_SET_ELEMENTS_X, modifies the
> opaque part of MPI_STATUS so that a call to MPI_GET_ELEMENTS_X returns
> the provided MPI_Count value.
> 
> 3. Sections 3.2.5, 4.1.5, 4.1.11, 4.2 on pages 34, 97, 105, and 127. The
> functions MPI_GET_COUNT, MPI_TYPE_SIZE, MPI_GET_ELEMENTS, and
> MPI_PACK_SIZE  are now defined to set the count, resp. size parameter to
> MPI_UNDEFINED when that parameter would overflows. In all other MPI-2.2
> routines, the type and semantics of the count arguments are kept
> unchanged, i.e., int or INTEGER.
> 
> -----
> With this all locations are mentioned, all new functionality is mentioned,
> and that's what is needed for both users and implementors.
> Details can be taken from the cited sections.
> 
> I'm sorry for the late answer - first I've overseen the mail
> (therefore I now added "Ticket 265" in the Subject)
> - and second, I'm still on Easter break.
> 
> Best regards
> Rolf
> 
> ----- Original Message -----
>> From: "Jeff Squyres" <jsquyres at cisco.com>
>> To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
>> Sent: Friday, April 22, 2011 5:11:26 PM
>> Subject: Re: [Mpi-forum] Changelog question
>> Rolf -- How's this? (see attached; the rendered text didn't
>> copy-n-paste well into a plain-text email)
>> 
>> I honestly don't have too much of an opinion here -- Fab and I put
>> together what we think Rolf wanted, but it *does* seem like a little
>> overkill.
>> 
>> The only think I have a slight reservation about is that this sets a
>> high bar for all other MPI-3 proposals -- e.g., will the one-sided
>> chapter need to have changelog entries for every new function (because
>> they're interleaved; it's not like NBC or MPI_T that just added whole
>> new sections).
>> 
>> Or should we have a single new changelog entry, perhaps with a table
>> or list of all the new functions?
>> 
>> (I see that Rolf made 13 new changelog entries for the Fortran 08 stuff
>> -- https://svn.mpi-forum.org/trac/mpi-forum-web/raw-
>> attachment/ticket/229/mpi-report-F2008-2011-04-21-reviewdoc.pdf)
>> 
>> 
>> 
>> 
>> On Apr 21, 2011, at 7:15 AM, Rolf Rabenseifner wrote:
>> 
>>> Yes, of course, but I thought that the MPI_Count
>>> ticket has only about 6 new routines, similar to the
>>> two entries 17 and 18 on MPI-2.2 pages 594 and 595
>>> about the MPI_DIST_GRAPH_... routines.
>>> 
>>> If a whole new main chapter is added, then
>>> typically only one ticket is added,
>>> without mentioning 20 routines.
>> 
>> --
>> Jeff Squyres
>> jsquyres at cisco.com
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>




More information about the mpi-forum mailing list