I'm usually not in favor of such commits. They are very development
specific, and to be honest very user specific. I use valgrind on a
regular basis, but that's not a reason to commit my changes into the
trunk. However, I think it can be interesting to allow us to prepend
something to the c
Hi all -
A couple of weeks ago, I committed some changes to the trunk that greatly
reduced the size of the shared memory file for small numbers of processes.
I haven't heard any complaints (the non-blocking send/receive issue is at
proc counts greater than the size this patch affected). Anyon
Brian,
The way the resize was done, led to unexpected behaviors. It was not
possible to know what the result of the resize was ... might be
smaller or bigger depending on the value on the stack at the call). I
commit a fix this morning. Let's wait few days before moving the 2
commits into
Hi,
this mail starts like all the others before ;):
I'm glad to announce a first working version of btl/tcp
with both, IPv4 and IPv6 support.
adi@ipc654:~/ompi/trunk/test$ ruby ringtest.rb
Loaded suite ringtest
Started
0: sending message (0) to 1
1: got message (1) from 0, sending to 2
2: got m
That's fine with me too. I only entered this because we needed something to
help check memory corruption on the backend, and not every environment will
support the xterm approach (especially around here). I was of two minds
about it, but needed something in the code that could be moved from compute
Nope.
On Oct 11, 2006, at 2:09 PM, Brian W. Barrett wrote:
Hi all -
A couple of weeks ago, I committed some changes to the trunk that
greatly
reduced the size of the shared memory file for small numbers of
processes.
I haven't heard any complaints (the non-blocking send/receive issue
is
