On Aug 12, 2009, at 3:09 PM, John DelSignore wrote:

...

It strikes me that TVT/Allinea might have experience in this area (general name/type/value registration).

Sorry, I couldn't attend the concall, so I'm not sure I follow 100% what you are trying to accomplish.

Representing a type is not too complicated, but that depends on the language (C, C++, Fortran, etc) and the kind of type (e.g., integer, float, complex, aggregate, array, pointer, reference, etc.). Generally, debug information schemes like STABS and DWARF (which are commonly used on most Unix systems), allow the compiler and language to name the type, and provide the properties of the type. For example, "int" in C may be the same kind of type as "INTEGER*4" in Fortran: e.g., a 4-byte signed integer.

The general idea here was that the proposal was seeking to have a registration system that MPI implementations could register a variety of run-time tunable parameters and run-time available information values -- we talked about this on a con call when the Forum was meeting in Chicago. We continued the discussion the other day, but it devolved into "we need lots of different types" / "do the types need to match the MPI datatypes" / "do we need to MPI_SEND/MPI_RECV these values around" / "what about complex types?" / etc. I suggested that the proposal authors should look to other sources for inspiration rather than re-invent the wheel (if possible) because this problem space shares many similarities with other systems. For example, CORBA-like systems have long since "solved" the serialization/ de-serialization issue (ser/de-ser is a different problem, but it shares many similar characteristics). And debuggers already have a system for identifying types of symbols in executables, printing and assigning the correct types to them interactively at run-time, etc. At their heart, these systems are just mappings of names to meta types (like type, value, etc.). I'm just suggesting that we look to others to see if there's knowledge / techniques that might be useful to re- use here rather than make it up anew, possibly ignoring some hard-won knowledge that others have gleaned from doing similar / analogous systems. Hopefully that rambling made sense... -- Jeff Squyres [email protected]