January 2013 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] GIt access
by Guillaume Mercier 10 Jan '13

10 Jan '13

Hi Dave, There you go! Guillaume On 01/10/2013 03:25 PM, Dave Goodell wrote: > Hi Guillaume, > > Can you just send your key to me directly? It's a little easier than getting our IT staff involved to dig your key out of their database. > > Thanks, > -Dave > > On Jan 10, 2013, at 3:58 AM, Guillaume Mercier<mercierg(a)mcs.anl.gov> wrote: > >> Hello, >> >> I don't have access to the writeable clone URL. >> My ssh key can be found on my MCS account. >> >> Regards, >> Guillaume

1 0

Re: [mpich-devel] GIt access
by Dave Goodell 10 Jan '13

10 Jan '13

Hi Guillaume, Can you just send your key to me directly? It's a little easier than getting our IT staff involved to dig your key out of their database. Thanks, -Dave On Jan 10, 2013, at 3:58 AM, Guillaume Mercier <mercierg(a)mcs.anl.gov> wrote: > > Hello, > > I don't have access to the writeable clone URL. > My ssh key can be found on my MCS account. > > Regards, > Guillaume

1 0

GIt access
by Guillaume Mercier 10 Jan '13

10 Jan '13

Hello, I don't have access to the writeable clone URL. My ssh key can be found on my MCS account. Regards, Guillaume

1 0

Re: [mpich-devel] MPICH migration to git
by Dave Goodell 08 Jan '13

08 Jan '13

"dev(a)mpich.org" below should obviously be "devel(a)mpich.org". -Dave On Jan 8, 2013, at 6:20 PM CST, Dave Goodell wrote: > MPICH developers, > > The MPICH project has transitioned from using SVN as our version control system (VCS) to using git instead. Details of the switch are described here: > > http://wiki.mpich.org/mpich/index.php/Git > > Highlights from the document and the transition: > > * Read-only git clones are available at http://git.mpich.org/mpich.git and git://git.mpich.org/mpich.git > * All critical history from SVN has been imported into the git history. > * The SVN server and its associated history are not going away, although it has been made read-only. > > We continue to work through our documentation and automated processes (cron jobs, etc.) to update them to the new system. Our trac instance will transition to understand the new VCS soon, although it currently displays only historical SVN data. > > Please bear with us as we work through this transition period. If you have trouble with the new setup, please contact dev(a)mpich.org or discuss(a)mpich.org for assistance. > > Regards, > The MPICH Team

1 0

MPICH migration to git
by Dave Goodell 08 Jan '13

08 Jan '13

MPICH developers, The MPICH project has transitioned from using SVN as our version control system (VCS) to using git instead. Details of the switch are described here: http://wiki.mpich.org/mpich/index.php/Git Highlights from the document and the transition: * Read-only git clones are available at http://git.mpich.org/mpich.git and git://git.mpich.org/mpich.git * All critical history from SVN has been imported into the git history. * The SVN server and its associated history are not going away, although it has been made read-only. We continue to work through our documentation and automated processes (cron jobs, etc.) to update them to the new system. Our trac instance will transition to understand the new VCS soon, although it currently displays only historical SVN data. Please bear with us as we work through this transition period. If you have trouble with the new setup, please contact dev(a)mpich.org or discuss(a)mpich.org for assistance. Regards, The MPICH Team

1 0

Re: [mpich-devel] helpful preprocessor check for CPU_ZERO and CPU_SET
by Darius Buntinas 04 Jan '13

04 Jan '13

If we are defining __USE_GNU et al. other than in the top-level config file, we need to fix that! -d On Dec 31, 2012, at 2:17 PM, Jeff Hammond wrote: > I don't disagree at all with your reasoning here and would certainly > favor the definition of __USE_GNU at the top level, but that's a much > more invasive change. > > The Linux kernel documentation > http://www.kernel.org/doc/man-pages/online/pages/man3/CPU_SET.3.html > demonstrates the usage that is currently in MPICH as well as in > numerous examples on the Internet... > > Best, > > Jeff > > On Mon, Dec 31, 2012 at 2:12 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> For many cases like this, the best solution is either >> >> Never use any macro that starts with __ (these should be reserved "for the system") >> >> If you must, it needs to be defined early, including *before* any configure tests on capabilities of the headers or the compiler, since these macros (e.g., __USE_GNU etc.) *change* the language that is implemented. It is a serious error to define this within any header file, other than the configuration file (mpichconf.h in our case). >> >> Adding it to any other header file should always be considered a mistake. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> On Dec 31, 2012, at 12:54 PM, Jeff Hammond wrote: >> >>> Having been frustrated in a related development effort because I was >>> unaware that sched.h was previously and indirectly included without >>> the __USE_GNU macro active, thereby preventing me from using CPU_ZERO >>> and CPU_SET, I suggest the inclusion of the following preprocessor >>> macro in MPICH so that it is plainly obvious should this occur in the >>> future due to the prior inclusion of sched.h before the following >>> code, which is actually quite far down in the source. >>> >>> I recognize that this is currently not a problem nor is the code below >>> even active right now, but (1) should it ever be active and (2) some >>> developer includes sched.h without __USE_GNU prior to line 1050 in >>> this file (there are ~10 MPICH internal headers that could cause this >>> right now), there will be a problem that is only detected when e.g. >>> cpi is linked, which is later than one would otherwise prefer. >>> >>> Best, >>> >>> Jeff >>> >>> $ svn diff pm/util/process.c >>> Index: pm/util/process.c >>> =================================================================== >>> --- pm/util/process.c (revision 10808) >>> +++ pm/util/process.c (working copy) >>> @@ -1031,6 +1031,11 @@ >>> #define __USE_GNU >>> #endif >>> #include <sched.h> >>> + >>> +#if !defined(CPU_ZERO) || !defined(CPU_SET) >>> +#error CPU_ZERO and/or CPU_SET were not defined because of prior >>> inclusion of sched.h without __USE_GNU >>> +#endif >>> + >>> /* >>> * Set the processor affinity for the calling process. Normally, this will >>> * be used in the "postfork" routine provided by the process manager, before >>> >>> -- >>> Jeff Hammond >>> Argonne Leadership Computing Facility >>> University of Chicago Computation Institute >>> jhammond(a)alcf.anl.gov / (630) 252-5381 >>> http://www.linkedin.com/in/jeffhammond >>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >> > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by William Gropp 02 Jan '13

02 Jan '13

Yes :) Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Jan 2, 2013, at 9:52 AM, Rob Ross wrote: > Is I/O considered communication :)? -- Rob > > On Dec 27, 2012, at 7:45 PM, William Gropp wrote: > >> We all agree that the language can be tightened up. >> >> The approach taken was to specify what was required (commit for communication) and then point out that one important case where commit is not required is the case of datatype construction. >> >> It is also extraordinarily dangerous to claim to cover all cases in the text - this is almost always doomed to failure. Best is to do what you can and then rely on a consistent reading of the text. Perhaps a better fix is to say that a commit is *only* required for datatypes used in communication. Emphasize that in other cases, such as constructing a datatype, a commit is not required. That is certainly the sense that was intended. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> On Dec 27, 2012, at 2:35 PM, Jeff Hammond wrote: >> >>>> On 12/27/2012 02:05 PM US Central Time, William Gropp wrote: >>>>> The standard is already clear - commit is only required when the >>>>> datatype is used for communication. It is unnecessary for the >>>>> standard to list all cases where commit is not required - it is >>>>> enough to list where commit *is* required, which it does. >>> >>> This is argument of the form "unless something is explicitly >>> prohibited, it is permitted," which is extraordinarily dangerous and >>> inconsistent with a robust standards document. >>> >>>> The way the text is currently written, it says "it is required for case >>>> X and not required for case Y" instead of saying "not required for all >>>> other cases". If the intended behavior is to not throw an error for >>>> non-communication routines, then the one example (of datatype >>>> constructors) should be removed from the standard, or just rewritten as >>>> "other operations such as datatype constructors". >>> >>> Exactly. The sentence "As an argument in datatype constructors, >>> uncommitted and also committed datatypes >>> can be used," should be removed completely or otherwise modified such >>> that there is no potential for it to be misinterpreted as an exclusive >>> list of permitted usage. >>> >>> Jeff >>> >>> -- >>> Jeff Hammond >>> Argonne Leadership Computing Facility >>> University of Chicago Computation Institute >>> jhammond(a)alcf.anl.gov / (630) 252-5381 >>> http://www.linkedin.com/in/jeffhammond >>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >> >

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Rob Ross 02 Jan '13

02 Jan '13

Is I/O considered communication :)? -- Rob On Dec 27, 2012, at 7:45 PM, William Gropp wrote: > We all agree that the language can be tightened up. > > The approach taken was to specify what was required (commit for communication) and then point out that one important case where commit is not required is the case of datatype construction. > > It is also extraordinarily dangerous to claim to cover all cases in the text - this is almost always doomed to failure. Best is to do what you can and then rely on a consistent reading of the text. Perhaps a better fix is to say that a commit is *only* required for datatypes used in communication. Emphasize that in other cases, such as constructing a datatype, a commit is not required. That is certainly the sense that was intended. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Dec 27, 2012, at 2:35 PM, Jeff Hammond wrote: > >>> On 12/27/2012 02:05 PM US Central Time, William Gropp wrote: >>>> The standard is already clear - commit is only required when the >>>> datatype is used for communication. It is unnecessary for the >>>> standard to list all cases where commit is not required - it is >>>> enough to list where commit *is* required, which it does. >> >> This is argument of the form "unless something is explicitly >> prohibited, it is permitted," which is extraordinarily dangerous and >> inconsistent with a robust standards document. >> >>> The way the text is currently written, it says "it is required for case >>> X and not required for case Y" instead of saying "not required for all >>> other cases". If the intended behavior is to not throw an error for >>> non-communication routines, then the one example (of datatype >>> constructors) should be removed from the standard, or just rewritten as >>> "other operations such as datatype constructors". >> >> Exactly. The sentence "As an argument in datatype constructors, >> uncommitted and also committed datatypes >> can be used," should be removed completely or otherwise modified such >> that there is no potential for it to be misinterpreted as an exclusive >> list of permitted usage. >> >> Jeff >> >> -- >> Jeff Hammond >> Argonne Leadership Computing Facility >> University of Chicago Computation Institute >> jhammond(a)alcf.anl.gov / (630) 252-5381 >> http://www.linkedin.com/in/jeffhammond >> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >

1 0