Yes, now that seems to be fixed, but I had to put that header in two another
files:
ompi/tools/ompi-server/ompi-server.c
ompi/tools/ompi-probe/ompi-probe.c
Now the trunk version is up and running :-).
Thanks,
Caciano Machado
On Wed, Apr 29, 2009 at 12:24 AM, Rainer Keller wrote:
> Caciano,
>
Let's let the #include changes settle down a bit and then let's get
Greg's stuff in. Then let's let that settle, and then we'll branch
for 1.5.
On Apr 28, 2009, at 10:32 PM, Rainer Keller wrote:
Hello all,
as You may have noticed, the two patches for header cleanup have been
committed (SV
Rainer --
Can you explain this a little more:
In ompi/mpi/c/ header files are moved up into the actual c-file,
where necessary (these are the only additional #include),
otherwise it is only deletions of #include (apart from the above
additions required due to notifier...)
It looks l
No offense, but I would like some better evidence that the new changes
are more complete than this last round. It was disturbing to find that
the changes were not in fact ready to come into the trunk - as Rainer
noted, he had to include a separate commit that actually broke the
system becau
Hi Jeff,
sure like to try to explain the matters.
The script check_unnecessary_headers.sh is not smart at all.
It checks whether a header, if known, is required due to some content.
It does not know about hierarchies of include files, or convenience headers
such as bindings.h and would delete the
On Wed, Apr 29, 2009 at 7:16 AM, Rainer Keller wrote:
> Hi Jeff,
> sure like to try to explain the matters.
> The script check_unnecessary_headers.sh is not smart at all.
> It checks whether a header, if known, is required due to some content.
> It does not know about hierarchies of include files
On Apr 29, 2009, at 9:33 AM, Ralph Castain wrote:
My personal opinion however is, that every header and every source
file should
be self contained:
It should include all the headers with symbols it needs, no less, and
certainly not more ;-)
That's an unusual coding style - we could debate th
To Whom This May Concern:
I originally sent this to the users list, but realizing now that this might
be more appropriate for the developer's list as it is dealing with issues
internal to the openmpi library (sorry for the dual distribution). Please
start with second email first.
Thanks,
Brian B
Hi,
I'm currently working in an environment where I cannot use SSH to launch child
processes. Instead, the process with rank 0 skips the ssh_child function in
plm_rsh_module.c and the child processes are all started at the same time on
different machines. Coordination is done with static jobid
On Apr 25, 2009, at 8:33 AM, Ralf Wildenhues wrote:
I hardly know scons. What's cool about it that autotools don't have?
This is worthy of its own thread, so I re-subjected the mail.
I worked up a prototype usage of scons in OMPI a few years ago. It
was actually fully functional -- it b
On Wed, Apr 29, 2009 at 12:38 PM, Jerry Ye wrote:
> I’m currently working in an environment where I cannot use SSH to launch
> child processes. Instead, the process with rank 0 skips the ssh_child
> function in plm_rsh_module.c and the child processes are all started at the
> same time on differe
On Apr 29, 2009, at 1:38 PM, Jerry Ye wrote:
I’m currently working in an environment where I cannot use SSH to
launch child processes. Instead, the process with rank 0 skips the
ssh_child function in plm_rsh_module.c and the child processes are
all started at the same time on different mac
It actually turned out to be something on my end. The modification actually
works. :-)
As Rayson guessed, I am using Hadoop. I actually didn't know that OpenMPI was
integrated with Torque but we're moving away from using Torque. In terms of
making the code public, I'll have to double check,
On Apr 29, 2009, at 3:02 PM, Jerry Ye wrote:
It actually turned out to be something on my end. The modification
actually works. :-)
Excellent.
As Rayson guessed, I am using Hadoop. I actually didn’t know that
OpenMPI was integrated with Torque but we’re moving away from using
Torque.
Actually, I think your program is erroneous -- it looks like you're
using number of bytes for the sizes[] array when it really should be
using number of elements. Specifically, it should be:
sizes[0] = (int) sizeof(tstruct.one);
sizes[1] = 1;
sizes[2] = 1;
sizes[3] = 1;
Sinc
Hi Jeff,
That definetly worked for me. Thanks so much for you help.
Purify did find some other UMR (unitialize memory read) errors though,
but they don't seem to be negativley impacting my application right
now. Nonetheless, I'll post them later today in case anyone is
interested in them
On Apr 29, 2009, at 5:03 PM, Brian Blank wrote:
Purify did find some other UMR (unitialize memory read) errors
though, but they don't seem to be negativley impacting my
application right now. Nonetheless, I'll post them later today in
case anyone is interested in them.
Might as well; we'
17 matches
Mail list logo
