On Mar 10, 2011, at 21:54 , Ralph Castain wrote: > Future developers? Code? What are you talking about??? > > This isn't in the code base, nor is it "code" - it is config options in the > private platform files for configuring clusters of contributors. We -never- > review what is in that area, leaving it up to their respective owners. The > contents of that area have no impact on anyone other than their owners. > > In some cases, like this one, the platform file may reflect uses outside of > the main code base. Nobody has to explain them to anyone. > > Eventually, when my other uses catch up, I will indeed remove it. Shouldn't > be much longer as I'm close to completing the integration of my branches back > to the trunk, but (frankly) that's my concern, not yours.
Obviously! george. > On Mar 10, 2011, at 7:16 PM, Eugene Loh wrote: > >> No big deal one way or the other. It's a symbolic gesture against bit rot, >> I suppose. The fact is that there are different pieces of the code base >> that move forward while vestiges of old stuff get left behind elsewhere. At >> first, it's easier to leave that stuff in. With time, the history gets >> forgotten and there gets left more and more mysterious stuff that future >> developers have to figure out. >> >> Let's say there's code that doesn't do anything. One can ask, "Why not just >> leave it in?" Or, one can ask, "Why not just strip it out?" >> >> This particular case (*.conf enable_progress) is minor. Either way, things >> are fine. My concern is more around the accumulation of many such instances. >> >> Ralph Castain wrote: >> >>> On Mar 10, 2011, at 5:54 PM, Eugene Loh wrote: >>> >>>> Ralph Castain wrote: >>>> >>>>> Just stale code that doesn't hurt anything >>>>> >>>> Okay, so it'd be all right to remove those lines. Right? >>>> >>> They are in my platform files - why are they a concern? >>> >>> Just asking - we don't normally worry about people's platform files. I >>> would rather not have to go thru everyone's files and review what they have >>> there. >>> >>>>> - frankly, I wouldn't look at platform files to try to get a handle on >>>>> such things as they tend to fall out of date unless someone needs to >>>>> change it. >>>>> >>>>> We always hard-code progress threads to off because the code isn't thread >>>>> safe in key areas involving the event library, for one. >>>>> >>>>> On Mar 10, 2011, at 3:43 PM, Eugene Loh wrote: >>>>> >>>>>> In the trunk, we hardwire progress threads to be off. E.g., >>>>>> >>>>>> % grep progress configure.ac >>>>>> # Hardwire all progress threads to be off >>>>>> enable_progress_threads="no" >>>>>> [Hardcode the ORTE progress thread to be off]) >>>>>> [Hardcode the OMPI progress thread to be off]) >>>>>> >>>>>> So, how do I understand the following? >>>>>> >>>>>> % grep enable_progress contrib/platform/*/*.conf >>>>>> contrib/platform/cisco/linux-static.conf:orte_enable_progress_threads = 1 >>>>>> contrib/platform/cisco/macosx-dynamic.conf:orte_enable_progress_threads >>>>>> = 1 >>>>>> contrib/platform/openrcm/debug.conf:orte_enable_progress_threads = 1 >>>>>> % grep enable_progress contrib/platform/*/*/*.conf >>>>>> contrib/platform/cisco/ebuild/hlfr.conf:orte_enable_progress_threads = 1 >>>>>> contrib/platform/cisco/ebuild/ludd.conf:orte_enable_progress_threads = 1 >>>>>> contrib/platform/cisco/ebuild/native.conf:orte_enable_progress_threads = >>>>>> 1 >>>>>> >>>>>> These seem to try to turn progress threads on. Ugly, but not a problem? >>>>>> >> _______________________________________________ >> 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 George Bosilca Research Assistant Professor Innovative Computing Laboratory Department of Electrical Engineering and Computer Science University of Tennessee, Knoxville http://web.eecs.utk.edu/~bosilca/
