Re: [OMPI devel] === CREATE FAILURE (trunk) ===
The build machine at IU was running out of disk space. I'm not 100% sure that this is the underlying error, but I'm going to kick off another build and see if we get the same dist error. If so, I'll dig more. On Feb 7, 2010, at 9:13 PM, MPI Team wrote: > > ERROR: Command returned a non-zero exist status (trunk): >make distcheck > > Start time: Sun Feb 7 21:00:06 EST 2010 > End time: Sun Feb 7 21:13:33 EST 2010 > > === > [... previous lines snipped ...] > CC opal_convertor_raw.lo > CC opal_copy_functions.lo > CC opal_copy_functions_heterogeneous.lo > CC opal_datatype_add.lo > CC opal_datatype_clone.lo > CC opal_datatype_copy.lo > CC opal_datatype_create.lo > CC opal_datatype_create_contiguous.lo > CC opal_datatype_destroy.lo > CC opal_datatype_dump.lo > CC opal_datatype_fake_stack.lo > CC opal_datatype_get_count.lo > CC opal_datatype_module.lo > CC opal_datatype_optimize.lo > CC opal_datatype_pack.lo > CC opal_datatype_position.lo > CC opal_datatype_resize.lo > CC opal_datatype_unpack.lo > CCLD libdatatype.la > make[3]: Leaving directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/datatype' > Making all in etc > make[3]: Entering directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/etc' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/etc' > Making all in event > make[3]: Entering directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event' > Making all in compat > make[4]: Entering directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event/compat' > Making all in sys > make[5]: Entering directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event/compat/sys' > make[5]: Nothing to be done for `all'. > make[5]: Leaving directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event/compat/sys' > make[5]: Entering directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event/compat' > make[5]: Nothing to be done for `all-am'. > make[5]: Leaving directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event/compat' > make[4]: Leaving directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event/compat' > make[4]: Entering directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event' > CC event.lo > CC log.lo > CC evutil.lo > ../../../opal/event/evutil.c:201:2: #error "I don't know how to parse 64-bit > integers." > make[4]: *** [evutil.lo] Error 1 > make[4]: Leaving directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal/event' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build/opal' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r22568/ompi/openmpi-1.7a1r22568/_build' > make: *** [distcheck] Error 1 > === > > Your friendly daemon, > Cyrador > ___ > testing mailing list > test...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/testing > -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] Create success (r1.7a1r22577)
Yay. :-) On Feb 8, 2010, at 4:28 PM, MPI Team wrote: > Creating nightly snapshot SVN tarball was a success. > > Snapshot: 1.7a1r22577 > Start time: Mon Feb 8 15:56:14 EST 2010 > End time: Mon Feb 8 16:28:48 EST 2010 > > Your friendly daemon, > Cyrador > ___ > testing mailing list > test...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/testing > -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] New feature for SVN commit messages
It looks like this is fixed now. Let us know if you see any other issues with it. -- Josh On Feb 5, 2010, at 11:10 AM, Jeff Squyres wrote: IU has been having some problems with this -- let me ping the admin and see what happened (I also saw your commit go by and noticed that no CMR ticket was created). On Feb 5, 2010, at 10:48 AM, Joshua Hursey wrote: Is this functionality still working? I added 'cmr:v1.5.1' to r22564 and it did not create a ticket. I noticed a few of the tickets manually created yesterday also cited this problem. -- Josh On Feb 3, 2010, at 8:23 AM, Jeff Squyres wrote: A little while ago, IU added the feature of automatically creating CMRs from SVN commits when you add tokens like this in your commit message: svn ci -m "This fixes ...foo... cmr:v1.4.2" IU just extended this feature by allowing you to specify a reviewer, thusly: svn ci -m "This fixes ...foo... cmr:v1.4.2:reviewer=jsquyres" You must specify a valid Trac ID. If you do this, the ticket will be assigned to that ID, meaning that they'll get an email with the ticket and a request to review it. More description is here: https://svn.open-mpi.org/trac/ompi/wiki/TracSVNCommitMessages Enjoy! -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco.com - http://www.cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] RFC: s/ENABLE_MPI_THREADS/ENABLE_THREAD_SAFETY/g
How about --enable-mpi-threads ==> --enable-multi-threads ENABLE_MPI_THREADS ==>ENABLE_MULTI_THREADS Essentially, s/mpi/multi/ig. This gives us "progress thread" support and "multi thread" support. Similar, but different. Another possibility instead of "mpi" could be "concurrent". On Jan 28, 2010, at 9:24 PM, Barrett, Brian W wrote: > Jeff - > > I think the idea is ok, but I think the name needs some thought. There's > currently two ways to have the lower layers be thread safe -- enabling MPI > threads or progress threads. The two can be done independently -- you can > disable MPI threads and still enable thread support by enabling progress > threads. > > So either that behavior would need to change or we need a better name (in my > opinion...). > > Brian > > On Jan 28, 2010, at 8:53 PM, Jeff Squyres wrote: > > > WHAT: Rename --enable-mpi-threads and ENABLE_MPI_THREADS to > > --enable-thread-safety and ENABLE_THREAD_SAFETY, respectively > > (--enable-mpi-threads will be maintained as a synonym to > > --enable-thread-safety for backwards compat, of course). > > > > WHY: Other projects are starting to use ORTE and OPAL without OMPI. The > > fact that thread safety in OPAL and ORTE requires a configure switch with > > "mpi" in the name is very non-intuitive. > > > > WHERE: A bunch of places in the code; see attached patch. > > > > WHEN: Next Friday COB > > > > TIMEOUT: COB, Friday, Feb 5, 2010 > > > > > > > > More details: > > > > Cisco is starting to investigate using ORTE and OPAL in various threading > > scenarios -- without the OMPI layer. The fact that you need to enable > > thread safety in ORTE/OPAL with a configure switch that has the word "mpi" > > in it is extremely counter-intuitive (it bit some of our engineers very > > badly, and they were mighty annoyed!!). > > > > Since this functionality actually has nothing to do with MPI (it's actually > > the other way around -- MPI_THREAD_MULTIPLE needs this functionality), we > > really should rename this switch and the corresponding AC_DEFINE -- I > > suggest: > > > > --enable|disable-thread-safety > > ENABLE_THREAD_SAFETY > > > > Of course, we need to keep the configure switch > > "--enable|disable-mpi-threads" for backwards compatibility, so that can be > > a synonym to --enable-thread-safety. > > > > See the attached patch (the biggest change is in > > opal/config/opal_config_threads.m4). If there are no objections, I'll > > commit this next Friday COB. > > > > -- > > Jeff Squyres > > jsquy...@cisco.com > > ___ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > -- > Brian W. Barrett > Dept. 1423: Scalable System Software > Sandia National Laboratories > > > > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] RFC: s/ENABLE_MPI_THREADS/ENABLE_THREAD_SAFETY/g
Well, does --disable-multi-threads disable progress threads? And do you want to disable thread support in ORTE because you don't want MPI_THREAD_MULTIPLE? Perhaps a third option is a rational way to go? Brain On Feb 8, 2010, at 6:54 PM, Jeff Squyres wrote: > How about > > --enable-mpi-threads ==> --enable-multi-threads >ENABLE_MPI_THREADS ==>ENABLE_MULTI_THREADS > > Essentially, s/mpi/multi/ig. This gives us "progress thread" support and > "multi thread" support. Similar, but different. > > Another possibility instead of "mpi" could be "concurrent". > > > > On Jan 28, 2010, at 9:24 PM, Barrett, Brian W wrote: > >> Jeff - >> >> I think the idea is ok, but I think the name needs some thought. There's >> currently two ways to have the lower layers be thread safe -- enabling MPI >> threads or progress threads. The two can be done independently -- you can >> disable MPI threads and still enable thread support by enabling progress >> threads. >> >> So either that behavior would need to change or we need a better name (in my >> opinion...). >> >> Brian >> >> On Jan 28, 2010, at 8:53 PM, Jeff Squyres wrote: >> >>> WHAT: Rename --enable-mpi-threads and ENABLE_MPI_THREADS to >>> --enable-thread-safety and ENABLE_THREAD_SAFETY, respectively >>> (--enable-mpi-threads will be maintained as a synonym to >>> --enable-thread-safety for backwards compat, of course). >>> >>> WHY: Other projects are starting to use ORTE and OPAL without OMPI. The >>> fact that thread safety in OPAL and ORTE requires a configure switch with >>> "mpi" in the name is very non-intuitive. >>> >>> WHERE: A bunch of places in the code; see attached patch. >>> >>> WHEN: Next Friday COB >>> >>> TIMEOUT: COB, Friday, Feb 5, 2010 >>> >>> >>> >>> More details: >>> >>> Cisco is starting to investigate using ORTE and OPAL in various threading >>> scenarios -- without the OMPI layer. The fact that you need to enable >>> thread safety in ORTE/OPAL with a configure switch that has the word "mpi" >>> in it is extremely counter-intuitive (it bit some of our engineers very >>> badly, and they were mighty annoyed!!). >>> >>> Since this functionality actually has nothing to do with MPI (it's actually >>> the other way around -- MPI_THREAD_MULTIPLE needs this functionality), we >>> really should rename this switch and the corresponding AC_DEFINE -- I >>> suggest: >>> >>> --enable|disable-thread-safety >>> ENABLE_THREAD_SAFETY >>> >>> Of course, we need to keep the configure switch >>> "--enable|disable-mpi-threads" for backwards compatibility, so that can be >>> a synonym to --enable-thread-safety. >>> >>> See the attached patch (the biggest change is in >>> opal/config/opal_config_threads.m4). If there are no objections, I'll >>> commit this next Friday COB. >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> ___ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> -- >> Brian W. Barrett >> Dept. 1423: Scalable System Software >> Sandia National Laboratories >> >> >> >> >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > > > -- > Jeff Squyres > jsquy...@cisco.com > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories
