On Nov 19, 2007, at 6:56 AM, Pavel Shamis (Pasha) wrote:
- Cisco
- Voltaire
- LLNL
- OGC (Chelsio)
- ?ORNL?
- ?Sun?
Please add Mellanox to the list too ...
Oops! That was clearly a typo/oversight, sorry...
--
Jeff Squyres
Cisco Systems
Yo Galen
I'm not aware of any continuing discussion to totally remove the process
name from ORTE - I believe we coalesced to redefining how the jobid was
established to a procedure that doesn't require a name server. This hasn't
come over to the trunk yet, but will in the next couple of months.
I guess I don't see why this is an opal_cmd_line_parse() problem.
If you invoke executables through system(), then a shell is used and
quoting is necessary to preserve the individual string tokens (i.e.,
"my beloved string" would be passed to the application as one argv
token, without the
Unfortunately, it -is- a significant problem when passing the params on to
the orteds, as Tim has eloquently pointed out in his original posting. I
guess I don't see why it would be a significant problem to just have
opal_cmd_line_parse do the "right thing" - if a string param is quoted, then
just
On Nov 19, 2007, at 10:01 AM, Ralph H Castain wrote:
Unfortunately, it -is- a significant problem when passing the params
on to
the orteds, as Tim has eloquently pointed out in his original
posting. I
guess I don't see why it would be a significant problem to just have
opal_cmd_line_parse
Hmmm...okay, I get the message: if it is going to be fixed, then I have to
fix it on my end. ;-) Which means it ain't happening anytime soon, so Tim P
is the one left in the lurch.
Sorry Tim! Perhaps you can come up with a compromise that re-enables what
you want to do.
Ralph
On 11/19/07 8:11
On Nov 19, 2007, at 10:15 AM, Ralph H Castain wrote:
Hmmm...okay, I get the message: if it is going to be fixed, then I
have to
fix it on my end. ;-) Which means it ain't happening anytime soon,
so Tim P
is the one left in the lurch.
Sorry Tim! Perhaps you can come up with a compromise
On 11/19/07 8:19 AM, "Jeff Squyres" wrote:
> On Nov 19, 2007, at 10:15 AM, Ralph H Castain wrote:
>
>> Hmmm...okay, I get the message: if it is going to be fixed, then I
>> have to
>> fix it on my end. ;-) Which means it ain't happening anytime soon,
>> so Tim P
>> is the
I am off all next week, but I will try to call in anyway..
- Galen
On 11/19/07 10:09 AM, "Don Kerr" wrote:
> Sun would like to be represented at this meeting. Mon 10AM might be a
> problem for Sun, any of the other times are good.
>
> -DON
>
> Jeff Squyres wrote:
>
>>
On Fri, Nov 16, 2007 at 11:36:39AM -0800, Jeff Squyres wrote:
> 1. Mon, 26 Nov, 10am US East, 7am US Pacific, 5pm Israel
> 2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel
> 3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel
> 4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel
Friday -- right, duh. My bad. So with everyone's replies so far, I
think we're down to:
2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel
3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel
4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel
If we get no more requirements,
Jeff Squyres wrote:
Friday -- right, duh. My bad. So with everyone's replies so far, I
think we're down to:
2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel
3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel
4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel
3 or 4
This patch will fix the problem -- the OMPI_VAR_SCOPE stuff didn't
make it over to the v1.2 branch:
Index: config/ompi_config_asm.m4
===
--- config/ompi_config_asm.m4 (revision 16740)
+++ config/ompi_config_asm.m4 (working
13 matches
Mail list logo