- Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A
by unknown＠example.com 03 Aug '09

03 Aug '09

Hi Erez, I thought that the first colored sentence "Constants with the type const int may also be implemented as literal integer constants substituted by the preprocessor." allows to implement > #define MPI_ERR_BUFFER 0 Your second topic: I'm not a C const specialist. I filled only in what I got as input from the Forum. If something is really wrong, we should use the errata method as soon as possible. Best regards Rolf On Mon, 3 Aug 2009 17:36:42 +0000 Erez Haba <erezh_at_[hidden]> wrote: > This might be nitpicking but wouldn't that force implementation to >typecast their definition of error codes? For example, > > #define MPI_ERR_BUFFER 0 > > Is not a correct definition with the proposed change, because it is >not typed. Thus, it needs to change to > > #define MPI_ERR_BUFFER (int)0 // you don't really need to define >it as (const int)0 > > as a result the following statement > > short x = MPI_ERR_BUFFER; > > which compiled correctly before, would break with this change. > > > Second comment. > > Adding the 'const' modifier to all types is very confusing imho. I >understand that it meant to make it clear that the values are >constants and should not change, but still is very confusing. > >For example, > > C Type: void * const > MPI_BOTTOM > > This means that the value of MPI_BOTTOM is constant and not the >memory it points to. however at first look you might think that it's >the later. (if it was, it would break any application that uses it >because the API's do not take a pointer to const void) > > In any case implementers should define MPI_BOTTOM as > > #define MPI_BOTTOM (void*)0 > > Rather than > > #define MPI_BOTTOM (void* const)0 > > As the value is constant and you don't need to add the const >modifier. > > > Note that the 'constness' of these values is already stated in the >title of the section '19.1.1 Defined Constants' > > > Except for my comments above, the text formatting looks good to me. >(I abstained at the meeting) > > Just my 2c, > .Erez > > > P.S.it looks odd that the int and void* types have const modifiers >while mpi types do not; like MPI_Datatype. I think that this needs to >be consistent. > > -----Original Message----- >From: mpi-22-bounces_at_[hidden] >[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf >Rabenseifner > Sent: Monday, August 03, 2009 8:50 AM > To: MPI Forum > Subject: [Mpi-22] Borderline ticket #107: Types of predefined >constants in Appendix A > > Dear all, > > ticket 107 was the only passed ticket with more no + abstain + miss > votes > than yes votes. > > MPI-2.1 had only C++ type information in this Appendix. > With this ticket, C and Fortran type information is added > to achieve consistency between all language bindings. > > I've implemented it and > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/107/appLang-… > gives you an impression of the final (uncolored) document. > (The new advices in Section 6.7.2 are not yet implemented). > > I hope you can now live with the result. > > If you would voted now with yes (based on the pdf), > but you haven't voted yes at the meeting, > then a short reply would be fine. > > The same of course if you now disagree with your yes at the meeting. > > Best regards > Rolf > > Dr. Rolf Rabenseifner . . . . . . . . . .. email >rabenseifner_at_[hidden] > 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) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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)

1 0

Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A
by unknown＠example.com 03 Aug '09

03 Aug '09

This might be nitpicking but wouldn't that force implementation to typecast their definition of error codes? For example, #define MPI_ERR_BUFFER 0 Is not a correct definition with the proposed change, because it is not typed. Thus, it needs to change to #define MPI_ERR_BUFFER (int)0 // you don't really need to define it as (const int)0 as a result the following statement short x = MPI_ERR_BUFFER; which compiled correctly before, would break with this change. Second comment. Adding the 'const' modifier to all types is very confusing imho. I understand that it meant to make it clear that the values are constants and should not change, but still is very confusing. For example, C Type: void * const MPI_BOTTOM This means that the value of MPI_BOTTOM is constant and not the memory it points to. however at first look you might think that it's the later. (if it was, it would break any application that uses it because the API's do not take a pointer to const void) In any case implementers should define MPI_BOTTOM as #define MPI_BOTTOM (void*)0 Rather than #define MPI_BOTTOM (void* const)0 As the value is constant and you don't need to add the const modifier. Note that the 'constness' of these values is already stated in the title of the section '19.1.1 Defined Constants' Except for my comments above, the text formatting looks good to me. (I abstained at the meeting) Just my 2c, .Erez P.S.it looks odd that the int and void* types have const modifiers while mpi types do not; like MPI_Datatype. I think that this needs to be consistent. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf Rabenseifner Sent: Monday, August 03, 2009 8:50 AM To: MPI Forum Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A Dear all, ticket 107 was the only passed ticket with more no + abstain + miss votes than yes votes. MPI-2.1 had only C++ type information in this Appendix. With this ticket, C and Fortran type information is added to achieve consistency between all language bindings. I've implemented it and https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/107/appLang-… gives you an impression of the final (uncolored) document. (The new advices in Section 6.7.2 are not yet implemented). I hope you can now live with the result. If you would voted now with yes (based on the pdf), but you haven't voted yes at the meeting, then a short reply would be fine. The same of course if you now disagree with your yes at the meeting. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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) _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Borderline ticket #107: Types of predefined constants in Appendix A
by unknown＠example.com 03 Aug '09

03 Aug '09

Dear all, ticket 107 was the only passed ticket with more no + abstain + miss votes than yes votes. MPI-2.1 had only C++ type information in this Appendix. With this ticket, C and Fortran type information is added to achieve consistency between all language bindings. I've implemented it and https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/107/appLang-… gives you an impression of the final (uncolored) document. (The new advices in Section 6.7.2 are not yet implemented). I hope you can now live with the result. If you would voted now with yes (based on the pdf), but you haven't voted yes at the meeting, then a short reply would be fine. The same of course if you now disagree with your yes at the meeting. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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)

1 0

Re: [Mpi-22] MPI 2.2 Document Update (fwd)
by unknown＠example.com 22 Jul '09

22 Jul '09

I review all of the changes (I've just made a pass). You are correct that the ticket author should review; I didn't make this explicit but included it under the "anyone who is interested". Please make sure that the ticket author agrees with your realization of the ticket. Bill On Jul 22, 2009, at 8:21 AM, Richard Treumann wrote: > Thanks > > I was hoping for something better. > > I made some edits to my chapter. I checked all approved tickets and > what I found matched the spread sheet Bill Gropp provided a while > back. I made edits as called for by the identified tickets. If > somehow I missed one, only the ticket owner has a chance of catching > me out on that. > > Nobody else should have changed my chapter. Obviously I reviewed > each edit as I made the PDF files. I guess that review is basically > automatic. No chapter author will share his PDFs without doing his > own review. > > I attached each pdf file to the ticket that inspired it but I did > not make any additional notice to ticket owners. Since these changes > are each a response to a ticket and the ticket owner is motivated to > get his ticket closed, the onus best falls on the ticket owner. If > the chapter author and a representative ticket owner agree that the > ticket has been fully addressed then who else is logical as a > reviewer? > > It is good that Bill Gropp is able to act broadly as a backup > reviewer so he should be notified. I sent an email saying all my > PDFs as called for by the spread sheet are now attached to > appropriate tickets. > > Making the chapter author rather that the ticket author the key > gatekeeper seems backwards to me. We will close any completed ticket > soon but the chapters will change more times. Shouldn't the > checkpoints of the process link up with the clear state transitions > a ticket can move through? > > Dick > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > <graycol.gif>"Bronis R. de Supinski" ---07/22/2009 08:51:39 > AM------------- Forwarded message ---------- Date: Tue, 23 Jun 2009 > 16:25:37 -0500 > > <ecblank.gif> > From: <ecblank.gif> > "Bronis R. de Supinski" <bronis_at_[hidden]> > <ecblank.gif> > To: <ecblank.gif> > "MPI 2.2" <mpi-22_at_[hidden]> > <ecblank.gif> > Date: <ecblank.gif> > 07/22/2009 08:51 AM > <ecblank.gif> > Subject: <ecblank.gif> > Re: [Mpi-22] MPI 2.2 Document Update (fwd) > <ecblank.gif> > Sent by: <ecblank.gif> > mpi-22-bounces_at_[hidden] > > > > > > ---------- Forwarded message ---------- > Date: Tue, 23 Jun 2009 16:25:37 -0500 > From: William Gropp <wgropp_at_[hidden]> > To: Bronis R. de Supinski <bronis_at_[hidden]> > Cc: "Supalov, Alexander" <alexander.supalov_at_[hidden]>, > Adam Moody <moody20_at_[hidden]>, David George Solt <david.solt_at_[hidden] > >, > Jesper Larsson Traeff <traff_at_[hidden]>, > Rolf Rabenseifner <rabenseifner_at_[hidden]>, > Torsten Hoefler <htor_at_[hidden]>, Jeff Squyres <jsquyres_at_[hidden] > >, > Rajeev Thakur <thakur_at_[hidden]>, George Bosilca <bosilca_at_[hidden] > >, > Richard Graham <rlgraham_at_[hidden]>, Richard Treumann <treumann_at_[hidden] > > > Subject: Re: MPI 2.2 Document Update > > Bronis, > > 1. Number of reviews. This is a different review, so it should be the > chapter author, anyone else who is interested (which should be the > author of a different chapter if the chapter author created the > change, as will be the usual case), and me. Unlike the reviews of the > proposals, this is primarily to ensure that the edits implemented the > change. > > 2. The chapter author is responsible for getting the reviews done. My > reasoning is that the chapter author is responsible for any fixes, so > there's no reason to introduce a third party. > > Bill > > On Jun 23, 2009, at 11:43 AM, Bronis R. de Supinski wrote: > > > > > Bill: > > > > Some general questions: > > > > 1. How many reviews of the PDF are required? Is it 4 again? > > > > 2. Who is responsible for getting the PDF reviews done? The > > chapter author? The ticket owner? > > > > Having the chpater author makes sense to me since they clearly > > know when it is ready. That also allows the owner to be a > > reviewer when the owner and author are different. However, that > > does not really work for the tickets with multiple authors. > > Maybe in that case it makes the most sense for the last author > > to be responsible? Or perhaps this problem makes it most > > reasonable to make the author responsible but to require the > > owner to review the ticket before requesting other reviews > > if the owner is not the author? > > > > Anyway, I am asking because it is not clear to me which tickets > > I am expected to review and I would like someone to poke me on > > the ones that I should review... > > > > Bronis > > > > On Thu, 18 Jun 2009, William Gropp wrote: > > > >> I've made an update as well as fixing the macros. One thing to > >> remember (this is noted in the README-2.2), the "color" macro only > >> applies until the end of the current TeX group - that makes it > pretty > >> painful within a table or other environment. There's really no > easy > >> work around without changing color packages. > >> > >> For creating the PDFs, if you can't easily extract the relevant > >> pages, > >> just post the entire chapter - but in that case, include a comment > >> that indicates which pages have changes. An alternative would be > to > >> use TeX/LaTeX as Knuth intended; there are many tools to select > >> subsets of pages that will work with TeX DVI files, and most of the > >> PDF tricks can be preserved as well. If someone is interested in > >> pursuing that option, let me know. > >> > >> And the Makefile for the Appendix was missing - I've fixed that > now. > >> > >> Bill > >> On Jun 18, 2009, at 10:14 AM, Supalov, Alexander wrote: > >> > >>> Thanks for corrections. Originally I tried to use the change > macros > >>> around the change table lines, but the document would not be built > >>> then. I assumed that the macros might not be functional inside > some > >>> LaTeX entities. This is why I opportunistically surrounded the > whole > >>> tables by macros. > >>> > >>> As to the PDF - change in the tables, especially their removal, > >>> makes all other pages slip. I guess in this case it may be > advisable > >>> to provide a full section chapter. I can cut that out using Adobe > >>> Acrobat, but I'm not sure everyone has access to this fairly > >>> expensive product or its equivalent. Is there a free utility that > >>> can extract indicated pages out of a PDF file? > >>> > >>> I was not able to produce a PDF file for the appendix alone. Maybe > >>> there's some make target for this? > >>> > >>> From: William Gropp [mailto:wgropp_at_[hidden]] > >>> Sent: Thursday, June 18, 2009 4:10 PM > >>> To: Supalov, Alexander > >>> Cc: Adam Moody; David George Solt; Jesper Larsson Traeff; Rolf > >>> Rabenseifner; Torsten Hoefler; Jeff Squyres; Bronis R. de > Supinski; > >>> Rajeev Thakur; George Bosilca; Richard Graham; Richard Treumann > >>> Subject: Re: MPI 2.2 Document Update > >>> > >>> Thanks, Alexander. > >>> > >>> This brings up a few more instructions: > >>> > >>> The PDFs should be of the pages with changes or deletions; to make > >>> it easier on the reviewers, just those pages (and a previous or > >>> following page if the change is at the top or bottom) should be > >>> included. If you can't extract the pages, or there are too many > >>> affected pages, just post the chapter's PDF. > >>> > >>> In looking over Alexander's changes, I realized that I needed to > >>> specify the use of the \MPIupdate macros more precisely. They > >>> should be used around only the change - for example, if the change > >>> is within a table, then only the affected items within the table > >>> should be marked. I've modified some of Alexander's changes to > move > >>> the update macros within the tables. > >>> > >>> This brought up another problem - The color highlighting is > >>> currently overwritten by some of the MPI 2.1 merge/update > macros. I > >>> will modify them so that the proper color is displayed. That may > >>> take a few days. > >>> > >>> Bill > >>> > >>> On Jun 18, 2009, at 5:49 AM, Supalov, Alexander wrote: > >>> > >>>> Dear Bill, > >>>> > >>>> What kind of PDFs should be attached to the tickets to complete > the > >>>> work? Please clarify. > >>>> > >>>> FYI, I've fixed my issues (## 4, 40, 63) in the chap-appLang > taken > >>>> off https:// svn.mpi-forum.org/svn/mpi-forum-docs/trunk/ > MPI-2.2 , > >>>> revision 241. Also added two changeLog references requested by > >>>> Rolf: > >>> > >>> William Gropp > >>> Deputy Director for Research > >>> Institute for Advanced Computing Applications and Technologies > >>> Paul and Cynthia Saylor Professor of Computer Science > >>> University of Illinois Urbana-Champaign > >>> > >>> > >>> > >>> > >>> > --------------------------------------------------------------------- > >>> Intel GmbH > >>> Dornacher Strasse 1 > >>> 85622 Feldkirchen/Muenchen Germany > >>> Sitz der Gesellschaft: Feldkirchen bei Muenchen > >>> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes > Schwaderer > >>> Registergericht: Muenchen HRB 47456 Ust.-IdNr. > >>> VAT Registration No.: DE129385895 > >>> Citibank Frankfurt (BLZ 502 109 00) 600119052 > >>> > >>> This e-mail and any attachments may contain confidential material > >>> for > >>> the sole use of the intended recipient(s). Any review or > >>> distribution > >>> by others is strictly prohibited. If you are not the intended > >>> recipient, please contact the sender and delete all copies. > >> > >> William Gropp > >> Deputy Director for Research > >> Institute for Advanced Computing Applications and Technologies > >> Paul and Cynthia Saylor Professor of Computer Science > >> University of Illinois Urbana-Champaign > >> > >> > >> > >> > >> > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > <ATT00001.txt> William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [Mpi-22] MPI 2.2 Document Update (fwd)
by unknown＠example.com 22 Jul '09

22 Jul '09

Thanks I was hoping for something better. I made some edits to my chapter. I checked all approved tickets and what I found matched the spread sheet Bill Gropp provided a while back. I made edits as called for by the identified tickets. If somehow I missed one, only the ticket owner has a chance of catching me out on that. Nobody else should have changed my chapter. Obviously I reviewed each edit as I made the PDF files. I guess that review is basically automatic. No chapter author will share his PDFs without doing his own review. I attached each pdf file to the ticket that inspired it but I did not make any additional notice to ticket owners. Since these changes are each a response to a ticket and the ticket owner is motivated to get his ticket closed, the onus best falls on the ticket owner. If the chapter author and a representative ticket owner agree that the ticket has been fully addressed then who else is logical as a reviewer? It is good that Bill Gropp is able to act broadly as a backup reviewer so he should be notified. I sent an email saying all my PDFs as called for by the spread sheet are now attached to appropriate tickets. Making the chapter author rather that the ticket author the key gatekeeper seems backwards to me. We will close any completed ticket soon but the chapters will change more times. Shouldn't the checkpoints of the process link up with the clear state transitions a ticket can move through? Dick Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 From: "Bronis R. de Supinski" <bronis_at_[hidden]> To: "MPI 2.2" <mpi-22_at_[hidden]> Date: 07/22/2009 08:51 AM Subject: Re: [Mpi-22] MPI 2.2 Document Update (fwd) Sent by: mpi-22-bounces_at_[hidden] ---------- Forwarded message ---------- Date: Tue, 23 Jun 2009 16:25:37 -0500 From: William Gropp <wgropp_at_[hidden]> To: Bronis R. de Supinski <bronis_at_[hidden]> Cc: "Supalov, Alexander" <alexander.supalov_at_[hidden]>, Adam Moody <moody20_at_[hidden]>, David George Solt <david.solt_at_[hidden]>, Jesper Larsson Traeff <traff_at_[hidden]>, Rolf Rabenseifner <rabenseifner_at_[hidden]>, Torsten Hoefler <htor_at_[hidden]>, Jeff Squyres <jsquyres_at_[hidden]>, Rajeev Thakur <thakur_at_[hidden]>, George Bosilca <bosilca_at_[hidden]>, Richard Graham <rlgraham_at_[hidden]>, Richard Treumann <treumann_at_[hidden]> Subject: Re: MPI 2.2 Document Update Bronis, 1. Number of reviews. This is a different review, so it should be the chapter author, anyone else who is interested (which should be the author of a different chapter if the chapter author created the change, as will be the usual case), and me. Unlike the reviews of the proposals, this is primarily to ensure that the edits implemented the change. 2. The chapter author is responsible for getting the reviews done. My reasoning is that the chapter author is responsible for any fixes, so there's no reason to introduce a third party. Bill On Jun 23, 2009, at 11:43 AM, Bronis R. de Supinski wrote: > > Bill: > > Some general questions: > > 1. How many reviews of the PDF are required? Is it 4 again? > > 2. Who is responsible for getting the PDF reviews done? The > chapter author? The ticket owner? > > Having the chpater author makes sense to me since they clearly > know when it is ready. That also allows the owner to be a > reviewer when the owner and author are different. However, that > does not really work for the tickets with multiple authors. > Maybe in that case it makes the most sense for the last author > to be responsible? Or perhaps this problem makes it most > reasonable to make the author responsible but to require the > owner to review the ticket before requesting other reviews > if the owner is not the author? > > Anyway, I am asking because it is not clear to me which tickets > I am expected to review and I would like someone to poke me on > the ones that I should review... > > Bronis > > On Thu, 18 Jun 2009, William Gropp wrote: > >> I've made an update as well as fixing the macros. One thing to >> remember (this is noted in the README-2.2), the "color" macro only >> applies until the end of the current TeX group - that makes it pretty >> painful within a table or other environment. There's really no easy >> work around without changing color packages. >> >> For creating the PDFs, if you can't easily extract the relevant >> pages, >> just post the entire chapter - but in that case, include a comment >> that indicates which pages have changes. An alternative would be to >> use TeX/LaTeX as Knuth intended; there are many tools to select >> subsets of pages that will work with TeX DVI files, and most of the >> PDF tricks can be preserved as well. If someone is interested in >> pursuing that option, let me know. >> >> And the Makefile for the Appendix was missing - I've fixed that now. >> >> Bill >> On Jun 18, 2009, at 10:14 AM, Supalov, Alexander wrote: >> >>> Thanks for corrections. Originally I tried to use the change macros >>> around the change table lines, but the document would not be built >>> then. I assumed that the macros might not be functional inside some >>> LaTeX entities. This is why I opportunistically surrounded the whole >>> tables by macros. >>> >>> As to the PDF - change in the tables, especially their removal, >>> makes all other pages slip. I guess in this case it may be advisable >>> to provide a full section chapter. I can cut that out using Adobe >>> Acrobat, but I'm not sure everyone has access to this fairly >>> expensive product or its equivalent. Is there a free utility that >>> can extract indicated pages out of a PDF file? >>> >>> I was not able to produce a PDF file for the appendix alone. Maybe >>> there's some make target for this? >>> >>> From: William Gropp [?mailto:wgropp_at_[hidden]] >>> Sent: Thursday, June 18, 2009 4:10 PM >>> To: Supalov, Alexander >>> Cc: Adam Moody; David George Solt; Jesper Larsson Traeff; Rolf >>> Rabenseifner; Torsten Hoefler; Jeff Squyres; Bronis R. de Supinski; >>> Rajeev Thakur; George Bosilca; Richard Graham; Richard Treumann >>> Subject: Re: MPI 2.2 Document Update >>> >>> Thanks, Alexander. >>> >>> This brings up a few more instructions: >>> >>> The PDFs should be of the pages with changes or deletions; to make >>> it easier on the reviewers, just those pages (and a previous or >>> following page if the change is at the top or bottom) should be >>> included. If you can't extract the pages, or there are too many >>> affected pages, just post the chapter's PDF. >>> >>> In looking over Alexander's changes, I realized that I needed to >>> specify the use of the \MPIupdate macros more precisely. They >>> should be used around only the change - for example, if the change >>> is within a table, then only the affected items within the table >>> should be marked. I've modified some of Alexander's changes to move >>> the update macros within the tables. >>> >>> This brought up another problem - The color highlighting is >>> currently overwritten by some of the MPI 2.1 merge/update macros. I >>> will modify them so that the proper color is displayed. That may >>> take a few days. >>> >>> Bill >>> >>> On Jun 18, 2009, at 5:49 AM, Supalov, Alexander wrote: >>> >>>> Dear Bill, >>>> >>>> What kind of PDFs should be attached to the tickets to complete the >>>> work? Please clarify. >>>> >>>> FYI, I've fixed my issues (## 4, 40, 63) in the chap-appLang taken >>>> off https:// svn.mpi-forum.org/svn/mpi-forum-docs/trunk/MPI-2.2 , >>>> revision 241. Also added two changeLog references requested by >>>> Rolf: >>> >>> William Gropp >>> Deputy Director for Research >>> Institute for Advanced Computing Applications and Technologies >>> Paul and Cynthia Saylor Professor of Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> Intel GmbH >>> Dornacher Strasse 1 >>> 85622 Feldkirchen/Muenchen Germany >>> Sitz der Gesellschaft: Feldkirchen bei Muenchen >>> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer >>> Registergericht: Muenchen HRB 47456 Ust.-IdNr. >>> VAT Registration No.: DE129385895 >>> Citibank Frankfurt (BLZ 502 109 00) 600119052 >>> >>> This e-mail and any attachments may contain confidential material >>> for >>> the sole use of the intended recipient(s). Any review or >>> distribution >>> by others is strictly prohibited. If you are not the intended >>> recipient, please contact the sender and delete all copies. >> >> William Gropp >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Re: [Mpi-22] MPI 2.2 Document Update (fwd)
by unknown＠example.com 22 Jul '09

22 Jul '09

---------- Forwarded message ---------- Date: Tue, 23 Jun 2009 16:25:37 -0500 From: William Gropp <wgropp_at_[hidden]> To: Bronis R. de Supinski <bronis_at_[hidden]> Cc: "Supalov, Alexander" <alexander.supalov_at_[hidden]>, Adam Moody <moody20_at_[hidden]>, David George Solt <david.solt_at_[hidden]>, Jesper Larsson Traeff <traff_at_[hidden]>, Rolf Rabenseifner <rabenseifner_at_[hidden]>, Torsten Hoefler <htor_at_[hidden]>, Jeff Squyres <jsquyres_at_[hidden]>, Rajeev Thakur <thakur_at_[hidden]>, George Bosilca <bosilca_at_[hidden]>, Richard Graham <rlgraham_at_[hidden]>, Richard Treumann <treumann_at_[hidden]> Subject: Re: MPI 2.2 Document Update Bronis, 1. Number of reviews. This is a different review, so it should be the chapter author, anyone else who is interested (which should be the author of a different chapter if the chapter author created the change, as will be the usual case), and me. Unlike the reviews of the proposals, this is primarily to ensure that the edits implemented the change. 2. The chapter author is responsible for getting the reviews done. My reasoning is that the chapter author is responsible for any fixes, so there's no reason to introduce a third party. Bill On Jun 23, 2009, at 11:43 AM, Bronis R. de Supinski wrote: > > Bill: > > Some general questions: > > 1. How many reviews of the PDF are required? Is it 4 again? > > 2. Who is responsible for getting the PDF reviews done? The > chapter author? The ticket owner? > > Having the chpater author makes sense to me since they clearly > know when it is ready. That also allows the owner to be a > reviewer when the owner and author are different. However, that > does not really work for the tickets with multiple authors. > Maybe in that case it makes the most sense for the last author > to be responsible? Or perhaps this problem makes it most > reasonable to make the author responsible but to require the > owner to review the ticket before requesting other reviews > if the owner is not the author? > > Anyway, I am asking because it is not clear to me which tickets > I am expected to review and I would like someone to poke me on > the ones that I should review... > > Bronis > > On Thu, 18 Jun 2009, William Gropp wrote: > >> I've made an update as well as fixing the macros. One thing to >> remember (this is noted in the README-2.2), the "color" macro only >> applies until the end of the current TeX group - that makes it pretty >> painful within a table or other environment. There's really no easy >> work around without changing color packages. >> >> For creating the PDFs, if you can't easily extract the relevant >> pages, >> just post the entire chapter - but in that case, include a comment >> that indicates which pages have changes. An alternative would be to >> use TeX/LaTeX as Knuth intended; there are many tools to select >> subsets of pages that will work with TeX DVI files, and most of the >> PDF tricks can be preserved as well. If someone is interested in >> pursuing that option, let me know. >> >> And the Makefile for the Appendix was missing - I've fixed that now. >> >> Bill >> On Jun 18, 2009, at 10:14 AM, Supalov, Alexander wrote: >> >>> Thanks for corrections. Originally I tried to use the change macros >>> around the change table lines, but the document would not be built >>> then. I assumed that the macros might not be functional inside some >>> LaTeX entities. This is why I opportunistically surrounded the whole >>> tables by macros. >>> >>> As to the PDF - change in the tables, especially their removal, >>> makes all other pages slip. I guess in this case it may be advisable >>> to provide a full section chapter. I can cut that out using Adobe >>> Acrobat, but I'm not sure everyone has access to this fairly >>> expensive product or its equivalent. Is there a free utility that >>> can extract indicated pages out of a PDF file? >>> >>> I was not able to produce a PDF file for the appendix alone. Maybe >>> there's some make target for this? >>> >>> From: William Gropp [mailto:wgropp_at_[hidden]] >>> Sent: Thursday, June 18, 2009 4:10 PM >>> To: Supalov, Alexander >>> Cc: Adam Moody; David George Solt; Jesper Larsson Traeff; Rolf >>> Rabenseifner; Torsten Hoefler; Jeff Squyres; Bronis R. de Supinski; >>> Rajeev Thakur; George Bosilca; Richard Graham; Richard Treumann >>> Subject: Re: MPI 2.2 Document Update >>> >>> Thanks, Alexander. >>> >>> This brings up a few more instructions: >>> >>> The PDFs should be of the pages with changes or deletions; to make >>> it easier on the reviewers, just those pages (and a previous or >>> following page if the change is at the top or bottom) should be >>> included. If you can't extract the pages, or there are too many >>> affected pages, just post the chapter's PDF. >>> >>> In looking over Alexander's changes, I realized that I needed to >>> specify the use of the \MPIupdate macros more precisely. They >>> should be used around only the change - for example, if the change >>> is within a table, then only the affected items within the table >>> should be marked. I've modified some of Alexander's changes to move >>> the update macros within the tables. >>> >>> This brought up another problem - The color highlighting is >>> currently overwritten by some of the MPI 2.1 merge/update macros. I >>> will modify them so that the proper color is displayed. That may >>> take a few days. >>> >>> Bill >>> >>> On Jun 18, 2009, at 5:49 AM, Supalov, Alexander wrote: >>> >>>> Dear Bill, >>>> >>>> What kind of PDFs should be attached to the tickets to complete the >>>> work? Please clarify. >>>> >>>> FYI, I've fixed my issues (## 4, 40, 63) in the chap-appLang taken >>>> off https:// svn.mpi-forum.org/svn/mpi-forum-docs/trunk/MPI-2.2 , >>>> revision 241. Also added two changeLog references requested by >>>> Rolf: >>> >>> William Gropp >>> Deputy Director for Research >>> Institute for Advanced Computing Applications and Technologies >>> Paul and Cynthia Saylor Professor of Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> Intel GmbH >>> Dornacher Strasse 1 >>> 85622 Feldkirchen/Muenchen Germany >>> Sitz der Gesellschaft: Feldkirchen bei Muenchen >>> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer >>> Registergericht: Muenchen HRB 47456 Ust.-IdNr. >>> VAT Registration No.: DE129385895 >>> Citibank Frankfurt (BLZ 502 109 00) 600119052 >>> >>> This e-mail and any attachments may contain confidential material >>> for >>> the sole use of the intended recipient(s). Any review or >>> distribution >>> by others is strictly prohibited. If you are not the intended >>> recipient, please contact the sender and delete all copies. >> >> William Gropp >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-22] PDF reviews
by unknown＠example.com 22 Jul '09

22 Jul '09

Dick: I will forward Bill's earlier response to when I asked thes same question. Bronis On Wed, 22 Jul 2009, Richard Treumann wrote: > > Hi Jeff > > > This has probably been covered in the flow of emails but I cannot claim to > have carefully read and absorbed every one > > Please remind me and maybe others > > 1) how someone who has edited a chapter in response to one or more tickets > is to tap appropriate pdf reviewers for each pdf > > 2) how someone is to know if they are on the hook to review a pdf. > > 3) how the chapter author is to know when the pdf reviewers have signed off > > > > Thanks > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > > > From: Jeff Squyres <jsquyres_at_[hidden]> > > To: "MPI 2.2" <mpi-22_at_[hidden]> > > Date: 07/21/2009 05:38 PM > > Subject: [Mpi-22] PDF reviews > > Sent by: mpi-22-bounces_at_[hidden] > > > > > > > Please try to get all your PDF reviews in this week. I've been > delinquent myself -- but I think I think I have all the ones assigned > to me done (please let me know if I've overlooked some PDF's that I'm > supposed to review!). > > Thanks! > > -- > Jeff Squyres > jsquyres_at_[hidden] > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >

1 0

MPI-2.2 votes next week
by unknown＠example.com 22 Jul '09

22 Jul '09

Don't forget that we have a lot of MPI-2.2 second votes next week. Please be sure to read up on the tickets and be comfortable to vote. *Now* is the time to ask if you have questions, comments, or concerns. https://svn.mpi-forum.org/trac/mpi-forum-web/query?status=assigned&status=n… Thanks! -- Jeff Squyres jsquyres_at_[hidden]

1 0

Re: [Mpi-22] PDF reviews
by unknown＠example.com 22 Jul '09

22 Jul '09

Hi Jeff This has probably been covered in the flow of emails but I cannot claim to have carefully read and absorbed every one Please remind me and maybe others 1) how someone who has edited a chapter in response to one or more tickets is to tap appropriate pdf reviewers for each pdf 2) how someone is to know if they are on the hook to review a pdf. 3) how the chapter author is to know when the pdf reviewers have signed off Thanks Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 From: Jeff Squyres <jsquyres_at_[hidden]> To: "MPI 2.2" <mpi-22_at_[hidden]> Date: 07/21/2009 05:38 PM Subject: [Mpi-22] PDF reviews Sent by: mpi-22-bounces_at_[hidden] Please try to get all your PDF reviews in this week. I've been delinquent myself -- but I think I think I have all the ones assigned to me done (please let me know if I've overlooked some PDF's that I'm supposed to review!). Thanks! -- Jeff Squyres jsquyres_at_[hidden] _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

PDF reviews
by unknown＠example.com 21 Jul '09

21 Jul '09

Please try to get all your PDF reviews in this week. I've been delinquent myself -- but I think I think I have all the ones assigned to me done (please let me know if I've overlooked some PDF's that I'm supposed to review!). Thanks! -- Jeff Squyres jsquyres_at_[hidden]

1 0