Yes. Eric's proposal solves the quoting issues because the "string"
given is only one key=value pair. The only limitation is that the key
cannot have the '=' character in it. I find this a minor restriction,
especially when compared to the % hack. Note that both key and value
can have spaces, and the value can have as many '='s as needed (only the
1st '=' delimits key and value). So this works:
String_append(&string, "my key = my value=with=equals");
where the key is "my key " and the value is " my value=with=equals".
> I think that proposal would be almost as complicated
> as the current quoting mechanism.
It's simpler to understand, except for the need to create and destroy
objects (one disadvantage mentioned about the spawn counter proposal for
example). But that need is there anyway since the "info/hints" object
was voted in. So for spawn "multiple", one creates N objects, spawns,
then destroys them all. Not simpler than array of strings mind you, but
then again... (throw hands up in the air)
> I'm not sure what the advantages are vs. a char** approach:
For the case of the "multiple" spawns, it would mean char *** or a 3-d
array of characters in Fortran. Pick your poison! :-)
> for those of you who weren't at the meeting...) makes use
> of the fact that we have key/value pairs, and doesn't
> rely on *any* parsing.
The only parsing in Eric's proposal is: strchr(string, '=');
That's hardly a big deal in MPI implementations. :-)
I got a feeling at the meeting that some people like the idea of
on-the-fly parsing of the info object, storing it in a structure of
flags internally, instead of a list/array of strings. But the minute
it's merged with the I/O hints, we have a problem with orthogonality.
It means that the same key cannot be used interchangeably in spawn and
I/O, since when the object is being built, you don't know if it is to be
used with spawn or with I/O. That forces the set of keys to be unique
(flat) across both functionalities; not elegant nor expandable. If on
the other hand there is no "info" or "hints" object, it's just a list of
strings and it can be used interchangeably (portable object). The
(really minimal) parsing has to be done inside the spawn or I/O call
since that's the only place where MPI knows the context in which to
interpret these strings.
I don't like the solution of using argc/argv for C and something
different for F77 because it's a departure from the "keep the API the
same" position. In the name of language interoperability, we already
made handles be integers to accomodate Fortran. Punting on it here
would be inconsistent. Among all imperfect solutions on the table, my
preference is still:
1- old proposal: all are strings, with ugly % for infrequent corner cases
(255-char f77 limit is set aside just like the 6-char function-name
limit was dismissed in MPI-1; plus I remember Marc saying he didn't
care about it (right Marc?), so why are we 'solving' this issue for
IBM since it doesn't seem to be considered as a problem?)
2- single string object used interchangeably (Eric's proposal)
> We could do the same for info (a but clumsy, because it
> really *is* key/value pairs, not strings)
Bill, this is like saying that foo.c is not an ASCII file or that
stdin/out are not streams of characters. :-)
> Finally, we have to make progress. Let's keep that
> in mind as we discuss new proposals.
Sure, just accept my approach and we're done! :-) :-) :-)
Seriously though, it isn't a show-stopper at the end of day. I thought
it would be easy to clean this up. If not, so be it.
--Raja
-=-
Raja Daoud Hewlett-Packard Co.
raja@rsn.hp.com Convex Division