Another issues is:
3. is content of info/hints a list of key/value pairs or is
it a structure?
In a list several key/value pairs with the same key are all valid,
in a structure the latest value for a key overwrites the former
ones.
The forum voted for a structure for the SPAWN-info.
The nature of SPAWN-commandline is a list of only-string-values.
> If I have understood the mail correctly, there are
> three proposals for info in the dynamic chapter. These
> are:
>
> 1. The main proposal (discussed at last meeting) based on
> MPI_INFO_CREATE(OUT info)
> MPI_INFO_SET(INOUT info, IN key, IN value)
> MPI_INFO_GET(IN info, IN key, IN valuelen, OUT value, OUT flag)
> MPI_INFO_DUP(IN info, OUT newinfo)
> MPI_INFO_FREE(INOUT info)
>
> "value" is always a string
>
> 2. A proposal from Rolf
> MPI_INFO_CREATE(OUT info)
> MPI_INFO_KEY_STRING(INOUT info, IN key, IN string)
> MPI_INFO_KEY_INT(INOUT info, IN key, IN integer_value)
> MPI_INFO_KEY_FLOAT(INOUT info, IN key, IN float_value)
> MPI_INFO_DUP(IN info, OUT newinfo)
> MPI_INFO_FREE(INOUT info)
>
> "value may be a string, int or float depending on the call
You forgot my line
MPI_INFO_STRING(INOUT info, IN string)
This function adds a string without a key to the info object.
>
> 3. A proposal from Eric/Raja
> MPI_INFO_CREATE(OUT info)
> MPI_INFO_APPEND(INOUT info, IN string)
> MPI_INFO_DUP(IN info, OUT newinfo)
> MPI_INFO_FREE(INOUT info)
>
> "string" is a string of the form "key=value". Parsing
> does not require "%" quoting of the type in the command-line
> proposal, though some work needs to be done to sort out
> "key=value" from "key = value".
>
> ---
>
> Rolf and Raja have suggested that their proposals could be used for
> the command line as well. I'm not sure what is proposed. For Rolf's ,
> it would seem to require special keys "arg1", "arg2", arg3", etc.
No. For this I have proposed the routine
MPI_INFO_STRING(INOUT info, IN string).
And I proposed to have to arguments:
- the commandline-executable (a string)
- The commandline-arguments (a info handle)
> For Raja's perhaps the idea is that for command lines, you don't pass
> key=value pairs, but pass regular strings instead .
>
> While I think it would be nice to be able to handle command lines with
> the same mechanism, both of these seem contrived and not too elegant
> to me. I may have misunderstood something so Raja and Rolf, please
> clarify it necessary.
In the moment all proposals have a lack of elegance:
- argv/argc is terrible for fortran
- the main proposal has the %-algorithm
- my (Rolfs) proposal has to many functions
- Rajas proposal must clarify the space-problem around the equal sign
- and the array-of-string or array-of-array-of-string proposal
has the problem that only one dimension of the 2-dim-array
can be variable in Fortran, i.e. the string length and the number of
arguments must be the same for all spawns in a SPAWN_MULTIPLE.
> My current thinking is that if command_line needs to be changed, we
> should go back to argv, which was originally rejected by the
> committee.
Not good -- see above.
> The new twist is that I do not think we considered doing
> what is done in PVM, which is to separate the command itself (a single
> string) from the argument list. In most cases the arg list would be
> NULL or MPI_FNULL.
Not so bad -- or?
> I've presented in an earlier note an example that
> shows even the 2-d array of strings that would be required for
> SPAWN_MULTIPLE may not be too bad in Fortran.
For the commandline perhaps better than all info/proposals,
but for the info argument very bad due to the arguments above.
----
> The deletion of "value_get" from the list of routines acknowledges
> the fact that the interface would be hairy. I think this tries
> to sweep under the rug a real problem. An implementation will
> internally have to have such functionality in any case - it
> will just be hidden from the user. Also, I disagree that
> it is not necessary. We've found that users often have reasons
> for wanting to deconstruct opaque objects. When the structure
> is so clear (really being part of the definition of the object),
> why hide it? The reason to hide it is that it would be ugly
> to get the information. This tension is a red flag for me.
Yes I agree.
Therefore my proposal to have different routines for different
datatypes is not good. (sprintf() in C and write(string_var,fmt)
in Fortran is good enough to encode integers or floats into a string.)
But if we want to use info objects for the commandline, I think
Rajas proposal combined with my idea to allow list and structure
oriented terms in an info object, is better than the main proposal.
The "key=value" versus "key = value" problem can be solved
by a short advice, that spaces around the "=" are significant.
With all proposed interfaces for the commandline
(except the main proposal with the %-algo.) we have with Fortran
the problem that empty strings cannot be defined.
With Rajas solution, I think we must add the rule that one leading
blank is deleted if there is one.
With all proposed interfaces for the commandline
(except the main proposal with the %-algo.) we have with Fortran
the following problem because empty strings are not allowed:
we cannot distinguish between '' and ' ' or we cannot define '' or
we cannot define ' ' because it is automatically converted to ''.
Rolf
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de