It looks like Dresden took my config/ompi_contrib.m4 file from the
htor-nbc tree and made some updates.
I like the idea of having ompi_info show the contributed packages and
their versions, but just like the rest of the tree, it has to be done
in a modular fashion. As it stands, in the vt-
George,
It looks like we should be checking ~/.svk/local not ~/.svk.
Does that do the trick?
~/.svk/local maps to the default "//" depot (created by "svk
depotmap --init") which I guess does not need to be setup
for all SVK users:
$ svk depotmap --list
Depot Path
Ethan,
I think I understand what the problem is. We should check for 2
files: ~/.svk and ~/.svk/local. If they both exist then we can use
the "svn info" command. If ~/.svk/local is missing then svk will ask
the user if it's ok to create it.
With both ~/.svk and ~/.svk existing I finally g
Ethan,
Looks like you have a really old version of svk. Here is the
information about mine:
svk --version
This is svk, version v2.0.2 (using Subversion bindings 1.4.5)
And here is what's happens when I "svk info" on a non svk path.
svk info unstable/ompi-trunk
Repository /Users/bosilca/.svk
George,
For me, SVK says the below on a non-SVK path (then it
immediately exits):
$ svk info /tmp
path /tmp is not a checkout path.
$ svk --version
This is svk, version 1.07.
What is the prompt that SVK gives you?
-Ethan
On Fri, Oct/26/2007 02:36:50PM, George Bosilca wrote:
> Ethan,
Ethan,
It only solve half the problem. I do have some svk based directories
on my system ... but not all my Open MPI checkouts are svk based. So,
it still deadlock for me.
george.
On Oct 26, 2007, at 2:33 PM, Ethan Mallove wrote:
Whoa! My apologies. I saw the same behavior when I did:
Whoa! My apologies. I saw the same behavior when I did:
$ rm -rf ~/.svk
I think if we check the existence of $HOME/.svk before doing
any svk commands then we should be okay. I did that in
r16586. Does it work for you now?
-Ethan
On Fri, Oct/26/2007 02:02:42PM, George Bosilca wrote:
> This p
Hi Brian,
Some good news and bad news. According to the information provided
on http://www.open-mpi.org/faq/?category=running,
I have enabled X11Forward on all remote nodes, and
added the path to mpirun, which is "/usr/local/bin", on all node, and
"xhost +" on my localhost, and
set the D
This patch break the autogen.sh in the case svk is available on the
node. I try it on MAC OS X as well as Linux boxes, and svk info will
try to create the svk if the project is not svk based. In fact it ask
the user if he want to create the svk stuff, but the output is hidden
by the autogen
George --
Can you send me a writeup on how this stuff works? I can add it to
the FAQ.
Thanks!
On Oct 26, 2007, at 12:36 PM, bosi...@osl.iu.edu wrote:
Author: bosilca
Date: 2007-10-26 12:36:51 EDT (Fri, 26 Oct 2007)
New Revision: 16584
URL: https://svn.open-mpi.org/trac/ompi/changeset/165
XGrid does not forward X11 credentials, so you would have to setup an
X11 environment by yourself. Using ssh or a local starter does
forward X11 credentials, which is why it works in that case.
Brian
On Oct 25, 2007, at 10:23 PM, Jinhui Qin wrote:
Hi Brian,
I got another problem in run
Hi Brian,
I got another problem in running an MPI job through XGrid. During the
execution of this MPI job it will call Xlib functions (i.e. XOpenDisplay())
to open an X window. The XOpenDisplay() function call failed (return
"null"), it can not open a display no matter how many processors that
12 matches
Mail list logo
