We use it a lot and it is very comfortable and intuitive to view in the GUI
source changes (local vs. repository) on the workspace/file level from
withing IDE.
SlickEdit is widely used and its tight integration with VC tool
On Wed, Feb 18, 2009 at 4:40 PM, Jeff Squyres wrote:
> How important
Hello guys,
We have compilation problem of ompi v1.3 on Itanium ia64 + gcc + rhel 4.7.
It seems that vt_pform_linux.c:46 includes asm/intrinsics.h which is
unavailable on rhel47/ia64 in /usr/include/asm but is a part of
kernel-headers rpm
(in /usr/src/kernels/2.6.9-78.EL-ia64/include/asm-ia64/)
From: Bert Wesarg
Free the memory alocated by the call to asprintf.
Regards,
Bert Wesarg
---
orte/tools/orte-ps/orte-ps.c |1 +
1 file changed, 1 insertion(+)
diff --quilt old/orte/tools/orte-ps/orte-ps.c new/orte/tools/orte-ps/orte-ps.c
--- old/orte/tools/orte-ps/orte-ps.c
+++ new/orte/
From: Bert Wesarg
---
orte/tools/orte-ps/orte-ps.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --quilt old/orte/tools/orte-ps/orte-ps.c new/orte/tools/orte-ps/orte-ps.c
--- old/orte/tools/orte-ps/orte-ps.c
+++ new/orte/tools/orte-ps/orte-ps.c
@@ -392,10 +392,10 @@ static
From: Bert Wesarg
asprintf returns the length of the written header, use this as the length.
Regards,
Bert Wesarg
---
orte/tools/orte-ps/orte-ps.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --quilt old/orte/tools/orte-ps/orte-ps.c new/orte/tools/orte-ps/orte-ps.c
--- old
From: Bert Wesarg
Provide a helper funtion to print a dashed line of variable length and use this
in the pretty_print* functions.
Regards,
Bert Wesarg
---
orte/tools/orte-ps/orte-ps.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --quilt
From: Bert Wesarg
Regards,
Bert Wesarg
---
opal/util/printf.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --quilt old/opal/util/printf.h new/opal/util/printf.h
--- old/opal/util/printf.h
+++ new/opal/util/printf.h
@@ -83,7 +83,7 @@ OPAL_DECLSPEC int opal_vsnprintf(char *
From: Bert Wesarg
The 2 new lines where added to the header length, which looks wrong.
Regards,
Bert Wesarg
---
orte/tools/orte-ps/orte-ps.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --quilt old/orte/tools/orte-ps/orte-ps.c new/orte/tools/orte-ps/orte-ps.c
--- old/orte
Eugene Loh wrote:
Jeff Squyres wrote:
Here's what I typically run to bring down changes from SVN to HG:
# Ensure all the latest hg repo changes are in the working dir
hg up
# Bring in all the SVN changes
svn up
# Refresh the .hgignore file (may change due to the svn up)
./contrib/hg/build-hgig
On Feb 16, 2009, at 9:14 AM, Lisandro Dalcin wrote:
After running my testsuite again and next looking at
"ompi/mpi/c/comm_set_errhandler.c", I noticed that
MPI_Comm_set_errhandler() do return MPI_ERR_COMM when invalid
communicators are passed. IMHO, for the sake of consistency, you
should fix MP
Could this pertain to the other itanium compilation problems that were
discussed (and not yet resolved) earlier?
On Feb 19, 2009, at 3:52 AM, Mike Dubman wrote:
Hello guys,
We have compilation problem of ompi v1.3 on Itanium ia64 + gcc +
rhel 4.7.
It seems that vt_pform_linux.c:46 includ
George -- any thoughts on this one?
On Feb 11, 2009, at 1:01 AM, Mike Dubman wrote:
Hello guys,
I'm running some experimental tcp btl which implements rdma GET
method and advertises it in its flags of the btl API.
The btl`s send() method returns rc=1 to select fast path for PML.
(this opt
On Feb 19, 2009, at 5:39 AM, Terry Dontje wrote:
Eugene Loh wrote:
Jeff Squyres wrote:
Here's what I typically run to bring down changes from SVN to HG:
# Ensure all the latest hg repo changes are in the working dir
hg up
# Bring in all the SVN changes
svn up
# Refresh the .hgignore file (m
Ralph Castain wrote:
On Feb 19, 2009, at 5:39 AM, Terry Dontje wrote:
Eugene Loh wrote:
Jeff Squyres wrote:
Here's what I typically run to bring down changes from SVN to HG:
# Ensure all the latest hg repo changes are in the working dir
hg up
# Bring in all the SVN changes
svn up
# Refresh
On Thu, Feb 19, 2009 at 10:54 AM, Jeff Squyres wrote:
> On Feb 16, 2009, at 9:14 AM, Lisandro Dalcin wrote:
>
>> After running my testsuite again and next looking at
>> "ompi/mpi/c/comm_set_errhandler.c", I noticed that
>> MPI_Comm_set_errhandler() do return MPI_ERR_COMM when invalid
>> communicat
Terry Dontje wrote:
Ralph Castain wrote:
On Feb 19, 2009, at 5:39 AM, Terry Dontje wrote:
Eugene Loh wrote:
Jeff Squyres wrote:
Here's what I typically run to bring down changes from SVN to HG:
# Ensure all the latest hg repo changes are in the working dir
hg up
# Bring in all the SVN c
Eugene Loh wrote:
Terry Dontje wrote:
Ralph Castain wrote:
On Feb 19, 2009, at 5:39 AM, Terry Dontje wrote:
Eugene Loh wrote:
Jeff Squyres wrote:
Here's what I typically run to bring down changes from SVN to HG:
# Ensure all the latest hg repo changes are in the working dir
hg up
# Bri
On Feb 19, 2009, at 10:16 AM, Eugene Loh wrote:
But, I'd like to understand this better. Jeff's e-mail above has an
"hg up" before the "svn up". But, I was trying to organize the
steps in terms of stuff that propagates "from left to right" (from
OMPI central repository out to HG clones) a
I fail to find anything about this on the MPI Standard. For me passing
the NULL error handle to any kind of set handler function should not
be an error. It should means that you prefer to not have any error
handler triggered on the object.
george.
On Feb 19, 2009, at 09:34 , Lisandro Dal
On Feb 19, 2009, at 9:34 AM, Lisandro Dalcin wrote:
I agree that it would be good to have these all be consistent.
Just to be
sure: are you saying you'd prefer MPI_ERR_COMM|FILE|WIN for each of
these
(respectively), vs. all of them returning MPI_ERR_ARG?
Yes, I prefer the MPI_ERR_COMM|FIL
On Feb 19, 2009, at 10:47 AM, George Bosilca wrote:
I fail to find anything about this on the MPI Standard.
MPI doesn't define any errors, does it? :-) I think it falls into
the category of "MPI tells you what to do" and doesn't define what
happens if you don't do that. MPI_*_SET_ERRHAN
I don't see how you reach this conclusion. Based on my reading of the
standard, MPI_ERRHANDLER_NULL is a valid error handler defined as "no"
errorhandler. Kind of similar with MPI_REQUEST_NULL ...
Moreover, I don't agree with some of the other changes, more
specifically with the one related
Okay, thanks for all the feedback. New version is at:
https://svn.open-mpi.org/trac/ompi/wiki/UsingMercurial#Developmentcycle
If everyone is happy with that, I'll remove the old version, along with
the diagram.
Jeff Squyres wrote:
Here's what I typically run to bring down changes from SVN
Hi folks
I have (finally) updated the wiki to include a topic list for this
meeting:
https://svn.open-mpi.org/trac/ompi/wiki/Feb09Meeting
As noted, I expect the meeting will begin with a discussion over a
more complete topic list, and a proposed agenda. I will attempt to
update the wiki
Eugene Loh wrote:
Okay, thanks for all the feedback. New version is at:
https://svn.open-mpi.org/trac/ompi/wiki/UsingMercurial#Developmentcycle
If everyone is happy with that, I'll remove the old version, along
with the diagram.
So I like the new text much better than the old, but I think you
On Feb 19, 2009, at 12:01 PM, George Bosilca wrote:
I don't see how you reach this conclusion. Based on my reading of
the standard, MPI_ERRHANDLER_NULL is a valid error handler defined
as "no" errorhandler. Kind of similar with MPI_REQUEST_NULL ...
It is not valid; MPI specifically defines
On Feb 19, 2009, at 12:14 PM, Eugene Loh wrote:
Okay, thanks for all the feedback. New version is at:
https://svn.open-mpi.org/trac/ompi/wiki/
UsingMercurial#Developmentcycle
If everyone is happy with that, I'll remove the old version, along
with the diagram.
FWIW, I think your text is
Terry Dontje wrote:
Eugene Loh wrote:
Okay, thanks for all the feedback. New version is at:
https://svn.open-mpi.org/trac/ompi/wiki/UsingMercurial#Developmentcycle
If everyone is happy with that, I'll remove the old version, along
with the diagram.
So I like the new text much better than
I think you are all over-engineering what is in truth a very, very
simple procedure I do dozens of times a day...and can best be
"discovered" by simply doing "hg help" or looking at their great
documentation for svn users. ;-)
"svn add" takes as arguments the files that need to be added. I
I also updated the same wiki page with a few google maps:
- One showing the Cisco office general location
- One showing where to turn and the satellite picture of the office
(it's set a little back from the main road)
- One showing klumps of hotels near the Cisco offices
Enjoy.
On Feb 19
After building 1.3, running the example I get this message:
[[55888,1],0]: A high-performance Open MPI point-to-point messaging module
was unable to find any relevant network interfaces:
Module: uDAPL
Host: alpha
Another transport will be used instead, although this may result in
lower perform
On 02/19/09 15:57, Jim Langston wrote:
After building 1.3, running the example I get this message:
[[55888,1],0]: A high-performance Open MPI point-to-point messaging
module
was unable to find any relevant network interfaces:
Module: uDAPL
Host: alpha
Another transport will be used instea
Don Kerr wrote:
On 02/19/09 15:57, Jim Langston wrote:
After building 1.3, running the example I get this message:
[[55888,1],0]: A high-performance Open MPI point-to-point messaging
module
was unable to find any relevant network interfaces:
Module: uDAPL
Host: alpha
Another transport wi
Ralph Castain wrote:
I think you are all over-engineering what is in truth a very, very
simple procedure
Yes, guilty as charged.
I do dozens of times a day...
Aha! Therein lies the difference. I haven't even done this a dozen
times in my lifetime.
and can best be "discovered" by sim
George and I talked about this on the phone at length. More below.
On Feb 19, 2009, at 1:18 PM, Jeff Squyres wrote:
I don't see how you reach this conclusion. Based on my reading of
the standard, MPI_ERRHANDLER_NULL is a valid error handler defined
as "no" errorhandler. Kind of similar wit
On Feb 19, 2009, at 4:30 PM, Jim Langston wrote:
I'm just wondering if I compiled incorrectly, or if the message is
generated because uDAPL is the default
interface (I'm on OpenSolaris), which I'm wondering if I can stop
from being looked at, either by
compiling differently, or from the comm
36 matches
Mail list logo
