5g$>
>>> — it’s sans-serif and designed for code examples, terminals, etc.
>>>
>>> -Todd
>>>
>>>
>>>> On Sep 6, 2021, at 7:53 AM, Michael Klemm via mpi-forum
>>>> mailto:mpi-forum@lists.mpi-forum.org>>
>>>> w
I would like some feedback on my proposed changes to the appearance of the code
and examples. I’d like to either apply these or delete them soon.
Bill
William Gropp
Director, NCSA
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign
IEEE-CS President-Elect
>
>>> mailto:mpi-forum@lists.mpi-forum.org>>
>>> wrote:
>>>
>>> I am OK with leaving out line numbers in tables. Maybe that will be solved
>>> in the future.
>>>
>>> One comment I had was on the code formatting. While I definitely
Thanks, George. On the line numbering, unfortunately, this is very difficult
to fix (and is a known problem). My proposal instead is to not use the line
numbers in these cases; in the rare cases where we need to identify the
location, we can count rows in the table or otherwise identify the
I agree with Dan that this is a big change from the RCM. Further, the approach
in MPI has always been to encourage the users to make it clear to the vendors
what is acceptable in implementations, especially implementation schedules.
Nothing in the standard prohibits implementors from
My previous email (probably crossing paths with Tony’s reply) addressed most of
this. The one thing that I want to add is that the API choice made in MPI for
the C binding, both in the MPI-1 attribute get functions and here, has nothing
to do with the Fortran binding. These were made to match
To be more specific as to the reason, this is the C idiom - it you pass it as a
pointer to a pointer, you have to cast it as a void pointer to a pointer. If
it is just a void *, C views this as an anonymous pointer, and you can use the
address - as in
int *intp;
MPI_Alloc_mem(1000,
Before submitting a pull request, please remember to run
make checklatex
This should produce no output other than echoing the command that it is
running. Currently, there are a number of problems with the document because
this check was not made. I can correct some as editor; one will be
I think this is an editorial fix, though with chapter committee review.
Bill
William Gropp
Director and Chief Scientist, NCSA
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign
> On Sep 10, 2020, at 9:17 AM, Jeff Squyres (jsquyres) via mpi-forum
> wrote:
>
I have merged the pythonization PR into mpi-4.x . If you have a pending pull
request, please review and address any conflicts or issues.
I will be working on the formatting issues that Rolf has found, but those
should not affect anyone (they will be changes to the macro definitions only).
Bill
To everyone in the MPI Forum, but especially the chairs of the MPI Chapter
Committees,
There are a number of updates that the Forum agreed to apply to the MPI
standard that need to be reviewed and signed off by the chapter committees. The
next group of these are the Fortran style changes,
I too found some of these questions impossible to answer because none of the
available answers was accurate enough, and I gave up rather than provide
misleading results.
I do think that this specific question is almost ok, but I really think that it
is better to address the requirements for
Pavan is correct; the program is buggy. Here’s an example
process 1 process 2
start(recv) /* something causes a delay at process 2 */
start(rsend)
wait(all)
start(recv)
….
In this case, the rsend on process 1 occurs before the recv is
13 matches
Mail list logo
