Re: [OMPI devel] Libtool for 1.3 / trunk builds

[Ralf Wildenhues]

* Jeff Squyres wrote on Wed, Mar 19, 2008 at 09:07:39PM CET:
> On Mar 19, 2008, at 4:05 PM, Brian W. Barrett wrote:
> 
> > True - I have no objection to waiting for 2.2.1 or 1.3 to be branched,
> > whichever comes first.  The main point is that under no circumstance
> > should 1.3 be shipped with the same 2.1a pre-release as 1.2 uses --  
> > it's time to migrate to something stable.
> 
> Cool; I think we're agreed.  Just for simplicity; let's do whatever  
> comes first: LT hits 2.2.1 (or 2.2.2?  I don't know their numbering  
> scheme) or we branch for v1.3.

2.2.2 will be next.  Current development happens on the 2.3 branch as
well as the 2.2.1 branch, but since we chose both to remain identical
until 2.2.2 was done we haven't branched branch-2-2 yet.

FWIW, here's the general numbering scheme explained:


Cheers,
Ralf

[OMPI devel] Proc modex change

[Brian W. Barrett]

Hi all -

Does anyone know why we go through the modex receive and for the local 
process in ompi_proc_get_info()?  It doesn't seem like it's necessary, and 
it causes some problems on platforms that don't implement the modex (since 
it zeros out useful information determined during the init step).  If no 
one has any objections, I'd like to commit the attached patch that fixes 
that problem.



Thanks,

BrianIndex: ompi/proc/proc.c
===
--- ompi/proc/proc.c	(revision 17898)
+++ ompi/proc/proc.c	(working copy)
@@ -192,6 +192,11 @@
 size_t datalen;
 orte_vpid_t nodeid;
 
+/* Don't reset the information determined about the current
+   process during the init step.  Saves time and problems if
+   modex is unimplemented */
+if (ompi_proc_local() == proc) continue;
+
 if (OPAL_EQUAL != orte_util_compare_name_fields(ORTE_NS_CMP_JOBID,
  &ompi_proc_local_proc->proc_name,
  &proc->proc_name)) {

[OMPI devel] RFC: Removal of orte_sys_info structure

[Ralph H Castain]

WHAT: Remove the orte_sys_info structure from the system

WHY: Outside of the nodeid and nodename fields, the fields do not appear to
be used anywhere. However, they occupy (albeit small) space, and every proc
expends some effort filling them in.

WHERE: removal of the orte/runtime/orte_sys.[hc] files, and remove the
include file entries in orte_init/finalize. The nodeid and nodename
discovery code would go into the ess/base std_{app,orted} functions.

TIMEOUT: COB, Mon, Mar 24

DESCRIPTION:

Finding and setting the nodeid and nodename is a system-dependent procedure,
so it makes no sense to penalize every proc to use the default method and
then have the enviro-specific ess module "overwrite" the result.

The other fields do not appear to be used anywhere, so it makes no sense to
occupy the (albeit small) memory space for nothing, nor to take time (again,
albeit small) doing system calls to populate the unused fields.


IF SOMEONE IS ACTUALLY USING THOSE FIELDS, OR INTENDS TO, PLEASE SPEAK UP

Thanks
Ralph

Re: [OMPI devel] Switching away from SVN?

[Roland Dreier]

 has some interesting
info about svn->git conversions (and svn vs. next-gen distibuted
systems in general).

Also, out of curiousity I tried doing

git-svn clone --stdlayout http://svn.open-mpi.org/svn/ompi/

and it seemed to work fine (git-svn is part of the main git
distribution).  The only obvious thing missing is that you would
probably want to set up an author file for a real conversion, so that
you get real names instead of just "jsquyres".  It took a while to
run, mostly because it has to grab each svn changeset one by one.

The interesting thing is that a checkout of the current ompi tree
seems to be about 37 MB, while .git directory of my repository, which
has the entire history of all branches of the svn repository plus
1.6MB of svn metadata is 36 MB.  And git can do fun stuff like

git diff v1.1..v1.2

in half a second (it generates a 274858 line diff).  It can generate
the full 116320 line (11164 commit) log of the trunk in .3 seconds.

Jeff, if you want to see the repository, it is in

/data/home/roland/ompi.git

Feel free to make it available however you want (it's your data of course).

 - R.