On Nov 2, 2006, at 6:11 PM, Ethan Mallove wrote:
./configure --with-lib-mpi=blah; gmake
Right. I left out the ';'. It still errors out. It works
if I trim the leading/trailing quote(s).
Right, sorry -- you don't need the quotes if you're not in functlet
args. In this case, if you add quot
On Fri, Nov/03/2006 08:03:04AM, Jeff Squyres wrote:
> On Nov 2, 2006, at 6:11 PM, Ethan Mallove wrote:
>
> >> ./configure --with-lib-mpi=blah; gmake
> >
> > Right. I left out the ';'. It still errors out. It works
> > if I trim the leading/trailing quote(s).
>
> Right, sorry -- you don't need the
On Nov 3, 2006, at 9:46 AM, Ethan Mallove wrote:
So just to confirm -- this works:
command = ./configure --with-mpi-dir=&test_prefix(); gmake
Right?
Right. I still like doing trim_quotes before returning, so
that we're more forgiving in allowing ''both'' of these:
shell_build_command = conf
I see some failures from LANL and IU/thor that *look* like the tests
were aborted before they completed (e.g., "rm -rf" of the scratch dir
while MTT was running).
Can someone from both organizations confirm that these are bogus
results?
Begin forwarded message:
From: mtt-resu...@osl.i
IU/Thor Short Story:
-
The IU/thor tests are borked because of the scheduler. Ignore these
results for now.
IU/Thor Longer Story:
-
SLURM is setup to kill any job that's 'idle' for more than N min,
where N is kinda small. We are compiling, but SLURM is
On Nov 3, 2006, at 11:30 AM, James W. Barker wrote:
I believe I replied to Ethan, $NODES and $NODELIST appear to be the
only environmental variables associated with BProc. I can't send
you the
I think that went to mtt-users, but then I asked for information
about these variables (i.e., w
Cool. Thanks for the info!
On Nov 3, 2006, at 11:31 AM, Josh Hursey wrote:
IU/Thor Short Story:
-
The IU/thor tests are borked because of the scheduler. Ignore these
results for now.
IU/Thor Longer Story:
-
SLURM is setup to kill any job that's 'idle'
Should we have a "testing" flag to MTT such that you can flag your
results as potentially not valuable? I.e., something like:
shell$ mtt --im-just-testing ...
We'd still put your results in the database (so you can verify
connectivity and all that), but flag them as "just testing my MTT
On Fri, Nov/03/2006 09:54:06AM, Jeff Squyres wrote:
> On Nov 3, 2006, at 9:46 AM, Ethan Mallove wrote:
>
> >> So just to confirm -- this works:
> >>
> >> command = ./configure --with-mpi-dir=&test_prefix(); gmake
> >>
> >> Right?
> >
> > Right. I still like doing trim_quotes before returning, so
>
That would be a good flag to have.
Also, is there someway we can after-the-fact, mark a set of results as invalid?
Say, when we have a hardware fault on a cluster that causes some tests
to fail...
On 11/3/06, Jeff Squyres wrote:
Should we have a "testing" flag to MTT such that you can flag you
On Nov 3, 2006, at 12:11 PM, Tim Mattox wrote:
That would be a good flag to have.
K. I'll file a feature enhancement. This is probably an MTT 2.0
thing, because it's a whole lot easier with the new schema.
Also, is there someway we can after-the-fact, mark a set of results
as invalid?
On Nov 3, 2006, at 12:08 PM, Ethan Mallove wrote:
Point taken about being literal. My thinking is that most
will be only guessing about the quoting mechanism of
funclets (as I was for a bit), and there would never be a
real case for sending '"cmd"' to exec().
How about a doc fix then?
I'm not
The patch was for DoCommand.pm which wouldn't affect @foo@,
right? (Isn't @foo@ dealt with in Run.pm?) I would revise
the patch to only chop the trailing '"' only if there is a
leading '"'. So we only remove quotes that wrap the whole
command.
+++ lib/MTT/DoCommand.pm(working copy)
+
I have an INI File that looks something like what is enclose at the
end of this message.
So I have multiple MPI Details sections. It seems like only the first
one is running. Do I have to list them out somewhere?
As a side question:
Instead of using multiple MPI Details sections, if I use a
No, @foo@ is evaluated when shell_command is evaluated. So it would
have it's " chopped before it was folded into shell_command,
resulting in a the following:
./configure CFLAGS=-g -O
which would be wrong.
I admit to not having looked closely at your patch; would it handle
this scenario
15 matches
Mail list logo
