Hi all -
Per the RFC I sent out last week, I've implemented a revised behavior
of the memory hooks for high speed networks. It's a bit different
than the RFC proposed, but still very minor and fairly straight foward.
The default is to build ptmalloc2 support, but as an almost complete
st
Hi again.
Sorry for the late response - I was on vacation.
The signature for the PVFS_sys_create function has indeed changed as of
version 2.7.0.
As far as I can tell, this is a minor change.
Cheers!
~Joe
> -- Forwarded message --
> From: Jeff Squyres
> To: Open MPI Developer
Okay, it's fixed now in r18629
On 6/9/08 3:23 PM, "Ralph H Castain" wrote:
> Visibility issue - fix coming in a minute...
>
>
> On 6/9/08 3:10 PM, "Ralph H Castain" wrote:
>
>> Interesting - it compiles for me under three different environments.
>>
>> Let me check - perhaps something isn't
Visibility issue - fix coming in a minute...
On 6/9/08 3:10 PM, "Ralph H Castain" wrote:
> Interesting - it compiles for me under three different environments.
>
> Let me check - perhaps something isn't getting committed properly
>
>
> On 6/9/08 3:07 PM, "Aurélien Bouteiller" wrote:
>
>> T
Interesting - it compiles for me under three different environments.
Let me check - perhaps something isn't getting committed properly
On 6/9/08 3:07 PM, "Aurélien Bouteiller" wrote:
> This commit looks like it does not compile.
> orterun.o: In function `orterun':
> ../../../../trunk/orte/tool
This commit looks like it does not compile.
orterun.o: In function `orterun':
../../../../trunk/orte/tools/orterun/orterun.c:525: undefined
reference to `orte_totalview_init_before_spawn'
orterun.o: In function `job_completed':
../../../../trunk/orte/tools/orterun/orterun.c:603: undefined
ref
On Jun 9, 2008, at 11:50 AM, Jeff Squyres wrote:
Please search through the archives of this list; as Brian mentioned,
this topic has come up several times before. It's fairly boring to
keep repeating the same arguments; we have lots of *new* things to
argue about these days. ;-)
Unfortunate
George --
I think the following sentence is pretty clear:
"This field may be updated only by the functions in Section 3.7.5
which return multiple statuses."
The intent is that you should get the error value back from the return
value of the function, not the status. You only need this fie
Rainer,
The snippet from the MPICH2 is irrelevant to the current discussion.
It only concern set empty status. A quick grep in the MPICH2 source
code (find . -name "*.[ch]" -exec grep -Hn MPI_ERROR {} \;) shows that
they ALWAYS set the MPI_ERROR field in the status if they detect
somethin
Hi,
that's one of the mysteries of the MPI-1 standard.
Nevertheless, we should be std. conforming. Therefore, I included the comment
and omitted the setting of .MPI_ERROR.
MPIch2 does not for the same reasons. Therefore I would say the tests are
wrong.
With best regards,
Rainer
PS: e.g. from
10 matches
Mail list logo
