Hi,
I am planning to commit the following patch. Those two progress() calls
are responsible for most of our deep recursion troubles. And I also
think they are completely unnecessary.
diff --git a/ompi/mca/pml/ob1/pml_ob1_recvreq.c
b/ompi/mca/pml/ob1/pml_ob1_recvreq.c
index 5899243..641176e
Hi Ralf,
thanks for the patch. I've added this to the trunk...
Matthias
On Mo, 2008-02-11 at 21:14 +0100, Ralf Wildenhues wrote:
> Hello,
>
> please apply this patch, to make future contrib integration just a tad
> bit easier. I verified that the generated configure script is
> identical,
On Monday 11 February 2008, Josh Hursey wrote:
> I've been noticing another problem with the VT integration. If you do
> a "./configure --enable-contrib-no-build=vt" a subsequent 'make
> distclean' will fail in contrib/vt. The 'make distclean' will succeed
> with VT enabled (default).
>
hm,
The VampirTrace integration is already in the trunk. It should be mentioned as
complete somewhere in the misc section.
Andreas
signature.asc
Description: This is a digitally signed message part.
On Tue, Feb 12, 2008 at 01:08:32PM +0100, Matthias Jurenz wrote:
> Hi Gleb,
>
> that's very strange... cause' the corresponding 'Makefile.in' is
> definitely not empty (checked in to the SVN repository).
Ah, here is the problem. Makefile.in is empty in my tree. I am building
not from SVN
To simplify things, I'm going to start filing tickets for all build
breaks that I find. Here's the latest:
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../opal/include -
I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/
linux/plpa/src/libplpa -I../..
Good points about 'distclean' versus 'clean'. For the make distclean
case then I think it is ok if we fail here since it is not a full
'make dist' that I was working with originally.
Sorry for the distraction.
Cheers,
Josh
On Feb 12, 2008, at 6:52 AM, Andreas Knüpfer wrote:
On Monday 11
I just talked to Jeff about this. The problem was that on Sif we use
--enable-visibility, and apparently the new c++ bindings access
ompi_errhandler_create, which was not OMPI_DECLSPEC'd. Jeff will fix
this soon.
Tim
Jeff Squyres wrote:
I'm a little concerned about the C++ test build
autogen.sh has some deep mojo in it...
Would it be sufficient to just have our autogen.sh recurse down into
your tree? An undocumented feature of our autogen.sh is that you can
have a "autogen.subdirs" file in ompi/contrib/vt with a single line in
it: "vt". This will make our autogen
Ralph --
We talked about this on the OMPI con call today and everyone agrees
that this seems to be a good plan. Just as a safety net: if the merge
goes disastrously wrong and you're unavailable Thu/Fri this week, we
can just back it out and try again later.
Thanks!
On Feb 11, 2008, at
Ew. I've filed a ticket:
https://svn.open-mpi.org/trac/ompi/ticket/1214
On Feb 12, 2008, at 11:27 AM, George Bosilca wrote:
I keep getting some warnings when I compile with gcc-4.2 on MAC OS X.
tools/compwrap/Makefile.am:38: `CXXFLAGS' is a user variable, you
should not override it;
On Feb 12, 2008, at 7:11 AM, Lenny Verkhovsky wrote:
During coding new RMAPS component I found strange behavior of PLPA.
Same
behavior that was described in
http://www.open-mpi.org/community/lists/plpa-users/2007/04/0073.php
I believe that it was fixed in new version of PLPA.
This new
Hi Ralph -
How extensive are the changes involved in removing the GPR? How hard would
it be for someone to maintain an enhanced version of this as an addon or
compile-time optional module? Thanks.
- Doug
On Mon, 11 Feb 2008, Ralph Castain wrote:
> Hello all
>
> Per last week's
Thanks for response, Jeff.
I'll definitely plan an upgrade to the latest LSF release (7.0 update 2),
then. Given the roadmap, I think I'm way better off forging ahead with MPI
on LSF than implementing a separate solution. I didn't really expect
production-ready code at this point. Just
On Feb 12, 2008, at 4:09 PM, ejon wrote:
I'll definitely plan an upgrade to the latest LSF release (7.0
update 2),
then. Given the roadmap, I think I'm way better off forging ahead
with MPI
on LSF than implementing a separate solution. I didn't really expect
production-ready code at this
I see that in the OOB CPC for the openib BTL, when setting up the send
side of the QP, we set the rnr_retry value depending on whether the
remote receive queue is a per-peer or SRQ:
- SRQ: btl_openib_rnr_retry MCA param value
- PP: 0
The rationale given in a comment is that setting the RNR
Hmm; I'm not sure.
distclean will fail in a tarball or SVN checkout if you do --enable-
contrib-no-build=vt. So it's not a developer-only artifact.
I don't know what the Right solution is, though. :-\
On Feb 12, 2008, at 9:22 AM, Josh Hursey wrote:
Good points about 'distclean' versus
Were these supposed to cover the time required for pinning and
unpinning?
Can you explain why you think they're unnecessary?
On Feb 12, 2008, at 5:27 AM, Gleb Natapov wrote:
Hi,
I am planning to commit the following patch. Those two progress()
calls
are responsible for most of our deep
Hi Doug
The changes are rather far-reaching. We essentially revamped the entire RTE
to switch from an event-driven architecture to one based on sequential
logic. This had large benefits, but the GPR was the casualty. Remember, the
aim for the past year has been to create a dedicated "lean, mean
19 matches
Mail list logo
