Ok; thanks for the explanation.
On Jul 20, 2007, at 6:44 PM, Aurelien Bouteiller wrote:
I know. This is the reason it was missing in the first commit.
The problem is that because we wanted to make as little changes as
possible to the original trunk, we designed the framework as a "PML"
instead
I know. This is the reason it was missing in the first commit.
The problem is that because we wanted to make as little changes as
possible to the original trunk, we designed the framework as a "PML"
instead of a new framework (at the mca level). For that reason the
autogen/configure mechanism
This looks like an improper commit; static-components.h should never
be committed to SVN (it's a generated file), and it should not be in
a component directory.
Is there a reason this was added?
On Jul 20, 2007, at 6:24 PM, boute...@osl.iu.edu wrote:
Author: bouteill
Date: 2007-07-20 18:2
It is probably easiest / best to completely remove your prior
installation and then install again.
FWIW: I typically install my development copies of OMPI into a tree
that has nothing else so that I can easily "rm -rf $ompi" and "make
install" to guarantee that I get a clean install.
On
Ralph H Castain wrote:
This change has finally been merged into the trunk as r15517. It will
unfortunately require an autogen (sorry).
Please let me know if you encounter any problems. As noted in the commit, I
tried to catch all the places that required change, but cannot guarantee
that I got a
I think I've found a problem that is causing at least some of my runs of
the MT tests to abort or hang. The issue is that in the OB1 request
structure there is a req_send_range_lock that is never initialized with
the appropriate (pthread_)mutex_init call. I've put in the following
patch (give
Thanks - makes sense! Appreciate the explanation - should have looked more
closely that early in the morning before asking. Definitely a "2-cups of
coffee" question... :-)
On 7/20/07 9:15 AM, "George Bosilca" wrote:
> The problem started with the compiler complaining about using a non
> initial
I need to correct myself on something here...see below.
On 7/20/07 8:31 AM, "Ralph Castain" wrote:
>
>
>
> On 7/20/07 8:13 AM, "rolf.vandeva...@sun.com"
> wrote:
>
>>
>> Greetings:
>> Ralph brings up some good points here.I have a few thoughts/experiences.
>> First, I like the way thi
The problem started with the compiler complaining about using a non
initialized variable. When I looked into the code, I just planned to
initialize it with some default value to make the compiler stop
complaining. But then I realize that all the ifs between the moment
where this buffer get
On 7/20/07 8:13 AM, "rolf.vandeva...@sun.com"
wrote:
>
> Greetings:
> Ralph brings up some good points here.I have a few thoughts/experiences.
> First, I like the way things are behaving now. In fact, I take full
> advantage
> of the fact the different aliases for a node are treated as d
Greetings:
Ralph brings up some good points here.I have a few thoughts/experiences.
First, I like the way things are behaving now. In fact, I take full
advantage
of the fact the different aliases for a node are treated as different nodes
to do some scalability testing. It is in this way t
Yo all
A recent email thread on the devel list involved (in part) the question of
hostname resolution. [Note: I have a fix for the localhost problem described
in that thread - just need to chase down a memory corruption problem, so it
won't come into the trunk until next week]
This is a problem t
My apologies - I intended to address this solely to George and missed that
it replied to the list. Too early in the morning...
On 7/20/07 5:32 AM, "Ralph Castain" wrote:
> I guess I really don't understand this change. How is it better that I
> *always* malloc a buffer that I might never use, j
I guess I really don't understand this change. How is it better that I
*always* malloc a buffer that I might never use, just so I can *always*
release it - versus *only* malloc'ing and releasing a buffer when I know I
need it??
I don't really care, but this seems kinda wasteful and I would like to
14 matches
Mail list logo
