Re: [OMPI devel] ORTE registry patch

This patch finally make it's way back into the trunk. I had to modify it to fit again into the source, but hopefully I manage to do it right. I did some testing and it seems to not harm anything. I split it up in several commits, in order to have a clean submission with one commit related

Re: [OMPI devel] [OMPI svn] svn:open-mpi r14923

George I believe that such non-professional comments do not belong in a code base that will be distributed to the public. I have removed this one - kindly refrain from them in the future. I remind you that the decision to use dynamic memory was made in an ORTE design meeting here at LANL three

Re: [OMPI devel] ORTE registry patch

On 6/6/07 9:21 AM, "Tim Prins" wrote: > Actually, the tests are quite painful to run, since there are things in > there that aren't real tests (such as spin, no-op, loob-child, etc) and > I really don't know what the expected output should be. Actually, they are tests - you

Re: [OMPI devel] ORTE registry patch

Actually, the tests are quite painful to run, since there are things in there that aren't real tests (such as spin, no-op, loob-child, etc) and I really don't know what the expected output should be. Anyways, I have made my way through these things, and I could not see any failures. This

Re: [OMPI devel] [OMPI svn] svn:open-mpi r14897

Yup, thanks. Brian On Jun 6, 2007, at 2:27 AM, Bert Wesarg wrote: +#ifdef HAVE_REGEXEC +args_count = opal_argv_count(options_data[i].compiler_args); +for (j = 0 ; j < args_count ; ++j) { +if (0 != regcomp(, options_data[i].compiler_args [j], REG_NOSUB)) { +

Re: [OMPI devel] ORTE registry patch

Sigh...is it really so much to ask that we at least run the tests in orte/test/system and orte/test/mpi using both mpirun and singleton (where appropriate) instead of just relying on "well I ran hello_world"? That is all I have ever asked, yet it seems to be viewed as a huge impediment. Is it

Re: [OMPI devel] ORTE registry patch

I hate to go back to this, but... The original commits also included changes to gpr_replica_dict_fn.c (r14331 and r14336). This change shows some performance improvement for me (about %8 on mpi hello, 123 nodes, 4ppn), and cleans up some ugliness in the gpr. Again, this is a algorithmic

Re: [OMPI devel] jnysal-openib-wireup branch

Ok -- so did you want to go ahead and make these changes, or did you want me to do it? Either way, I'd be in favor of all this stuff coming to the trunk in the Very Near Future. :-) On Jun 6, 2007, at 7:02 AM, Nysal Jan wrote: Hi Jeff, 1. The logic for if_exclude was not correct. I

Re: [OMPI devel] jnysal-openib-wireup branch

Hi Jeff, 1. The logic for if_exclude was not correct. I committed a fix for it. https://svn.open-mpi.org/trac/ompi/changeset/14748 Thanks 2. I'm a bit confused on a) how the new MCA params mca_num_hcas and map_num_procs_per_hca are supposed to be used and b) what their default values

Re: [OMPI devel] [OMPI svn] svn:open-mpi r14897

> +#ifdef HAVE_REGEXEC > +args_count = opal_argv_count(options_data[i].compiler_args); > +for (j = 0 ; j < args_count ; ++j) { > +if (0 != regcomp(, options_data[i].compiler_args[j], > REG_NOSUB)) { > +return -1; > +} > + > +if