On Mar 30, 2009, at 12:05 PM, Jeff Squyres wrote:
But don't we need the whole area to be zero filled?
It will be zero-filled on demand using the lseek/touch method.
However, the OS may not reserve space for the skipped pages or disk
blocks. Thus one could still get out of memory or file
On Mar 31, 2009, at 11:00 AM, Jeff Squyres wrote:
On Mar 31, 2009, at 3:45 AM, Sylvain Jeaugey wrote:
Sorry to continue off-topic but going to System V shm would be for me
like going back in the past.
System V shared memory used to be the main way to do shared memory on
MPICH and from my (li
On Apr 1, 2009, at 4:29 PM, Jeff Squyres wrote:
Should the same fixes be applied to type_create_keyval_f.c and
win_create_keyval_f.c?
Good question. I'll have a look at them.
Iain
On Apr 1, 2009, at 4:58 PM, Iain Bason wrote:
On Apr 1, 2009, at 4:29 PM, Jeff Squyres wrote:
Should the same fixes be applied to type_create_keyval_f.c and
win_create_keyval_f.c?
Good question. I'll have a look at them.
It looks as though those have the same problem. I will wr
On Jun 2, 2009, at 10:24 AM, Rainer Keller wrote:
no, that's not an issue. The comment is correct: For any Fortran
integer*kind
we need to have _some_ C-representation as well, otherwise we
disregard the
type (tm), see e.g. the old and resolved ticket #1094.
The representation chosen is se
On Jun 3, 2009, at 1:30 PM, Ralph Castain wrote:
I'm not entirely sure what comment is being discussed.
Jeff said:
I see the following comment:
** The fortran integer is dismissed here, since there is no
** platform known to me, were fortran and C-integer do not match
You can tell the int
Jeff Squyres wrote:
Thanks for looking into this, David.
So if I understand that correctly, it means you have to assign all
literals in your fortran program with a "_16" suffix. I don't know if
that's standard Fortran or not.
Yes, it is.
Iain
Ralph Castain wrote:
I'm sorry, but this change is incorrect.
If you look in orte/mca/ess/base/ess_base_std_orted.c, you will see
that -all- orteds, regardless of how they are launched, open and
select the PLM.
I believe you are mistaken. Look in plm_base_launch_support.c:
/* Th
Ralph Castain wrote:
Yes, but look at orte/mca/plm/rsh/plm_rsh_module.c:
/* ensure that only the ssh plm is selected on the remote daemon */
var = mca_base_param_environ_variable("plm", NULL, NULL);
opal_setenv(var, "rsh", true, &env);
free(var);
This is done in "ssh_chi
(Thanks, Nick, for explaining that kind values are compiler-dependent. I
was too lazy to do that.)
Jeff Squyres wrote:
Given that I'll inevitably get the language wrong, can someone suggest
proper verbiage for this statement in the OMPI README:
- MPI_REAL16 and MPI_COMPLEX32 are only supporte
On Jun 23, 2009, at 7:17 PM, Ralph Castain wrote:
Not any more, when using regex - the only message that comes back is
one/node telling the HNP that the procs have been launched. These
messages flow along the route, not direct to the HNP - assuming you
use the static port option.
Is ther
On Jun 25, 2009, at 11:10 AM, Ralph Castain wrote:
They do flow along the route at all times. However, without static
ports the orted has to start by directly connecting to the HNP and
sending the orted's contact info to the HNP.
This is the part I don't understand. Why can't they send th
On Jul 21, 2009, at 6:31 PM, Ralph Castain wrote:
This commit appears to have broken the build system for Mac OSX.
Could you please fix it - since it only supports Solaris and Linux,
how about setting it so it continues to work in other environments??
That was the intent of the configure.m
On Jul 21, 2009, at 6:34 PM, Jeff Squyres wrote:
I'm quite confused about what this component did to the base
functions. I haven't had a chance to digest it properly, but it
"feels wrong"... Iain -- can you please explain the workings of
this component and its interactions with the base?
On Jul 21, 2009, at 6:34 PM, Jeff Squyres wrote:
Also, it seems broken:
[15:31] svbu-mpi:~/svn/ompi4 % ompi_info | grep installd
--
Sorry! You were supposed to get help about:
developer warning: field too long
But I co
On Jul 21, 2009, at 7:35 PM, Jeff Squyres wrote:
However, I see that autodetect configure.m4 is checking
$backtrace_installdirs_happy -- which seems like a no-no. The
ordering of framework / component configure.m4 scripts is not
guaranteed, so it's not a good idea to check the output of a
On Jul 21, 2009, at 7:50 PM, Jeff Squyres wrote:
If you have an immediate fix for this, that would be great --
otherwise, please back this commit out (I said in my previous mail
that I would back it out, but I had assumed that you were gone for
the day. If you're around, please make the c
On Jul 21, 2009, at 7:50 PM, Jeff Squyres wrote:
On Jul 21, 2009, at 7:46 PM, Iain Bason wrote:
> The help file should have been found. This is on Linux RHEL4,
but I
> doubt it's a Linux-version-specific issue...
Could you send me your configure options, and your OPAL_XXX
On Jul 21, 2009, at 7:48 PM, Jeff Squyres wrote:
Arrgh!! Even with .ompi_ignore, everything is broken on OS X and
Linux (perhaps this is what Ralph was referring to -- not a compile
time problem?):
-
$ mpicc -g -Isrc -c -o libmpitest.o libmpitest.c
Cannot open configuration file ${d
On Jul 22, 2009, at 10:55 AM, Brian W. Barrett wrote:
The current autodetect implementation seems like the wrong approach
to me. I'm rather unhappy the base functionality was hacked up like
it was without any advanced notice or questions about original
design intent. We seem to have a set
On Jul 23, 2009, at 5:53 PM, Jeff Squyres wrote:
We have talked many times about doing proper versioning for
OMPI's .so libraries (e.g., libmpi.so -- *not* our component DSOs).
Forgive me if this has been hashed out, but won't you run into trouble
by not versioning the components? What ha
WHAT: Enhance the orte_forward_job_control MCA flag by:
1. Forwarding signals to descendants of launched processes; and
2. Forwarding signals received before process launch time.
(The orte_forward_job_control flag arranges for SIGTSTP and SIGCONT to
be forwarded. This allows a resource mana
x27;s criteria below.
--td
Ralph Castain wrote:
I don't have any issue with this so long as (a) it is -only- active
when someone sets a specific MCA param requesting it, and (b) that
flag is -not- set by default.
On Jan 4, 2010, at 11:50 AM, Iain Bason wrote:
WHAT: E
On Mar 3, 2010, at 1:24 PM, Jeff Squyres wrote:
> I'm not sure I agree with change #1. I understand in principle why the
> change was made, but I'm uncomfortable with:
>
> 1. The individual entries now behave like pseudo-regexp's rather that strict
> matching. We used strict matching before
On Mar 3, 2010, at 3:04 PM, Jeff Squyres wrote:
>
> Mmmm... good point. I was thinking specifically of the if_in|exclude
> behavior in the openib BTL. That uses strcmp, not strncmp. Here's a
> complete list:
>
> ompi_info --param all all --parsable | grep include | grep :value:
> mca:opal:
25 matches
Mail list logo
