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

[Rolf Rabenseifner]

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

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)