Hi,
> -Original Message-
> From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org]
On
> Behalf Of Ralph Castain
> Sent: Wednesday, March 19, 2008 3:19 AM
> To: Open MPI Developers
> Subject: Re: [OMPI devel] rankfile questions
>
> Not trying to pile on here...but I do have a
Yes, you're right -- we should have reviewed this code 2 weeks ago
when you asked. Sorry about that. :-\
Per adding lots of affinity code in ompi_mpi_init.c: perhaps those
code belongs down in the paffinity (or rmaps?) base. It doesn't have
to become part of any specific paffinity compon
I re-merged down to the libevent-merge branch (to include r17872) and
a new tarball has been uploaded to http://www.open-mpi.org/~jsquyres/unofficial/
On Mar 18, 2008, at 10:11 PM, George Bosilca wrote:
Commit 17872 is the one you're looking for.
https://svn.open-mpi.org/trac/ompi/changese
Hi all -
Now that Libtool 2.2 has gone stable (2.0 was skipped entirely), it
probably makes sense to update the version of Libtool used to build the
nightly tarball and releases for the trunk (and eventually v1.3) from the
nightly snapshot we have been using to the stable LT 2.2 release.
I'v
Should we wait for the next LT point release? I see a fair amount of
activity on the bugs-libtool list; I think they're planning a new
release within the next few weeks.
(I think we will want to go to the LT point release when it comes out;
I don't really have strong feelings about going t
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.
Brian
On Wed, 19 Mar 2008, Jeff Squyres wro
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 somethin
Thanks a lot Jeff and Josh.
Seems it will be quite an interesting task to implement a separate btl for
xensocket (xs) or anything related to migration. I plan to stick to initial
design for the time which seems ugly but simple and quite efficient (at the
moment). I have bundled xs with tcp btl
