On Aug 13, 2011, at 11:28 PM, Jed Brown wrote: > On Sat, Aug 13, 2011 at 23:09, Barry Smith <bsmith at mcs.anl.gov> wrote: > Not sure it is really a viewer? It is an AMS published memory (bunch of > fields) for the object, not sure if it makes sense to consider that a > subclass of PetscViewer > > In the viewer/monitor case, some of those fields are stack, not heap. They > may be computed and thrown away. This makes them different in that in > addition to being read-only, they can only be accessed at the moment they are > published. Is this somehow not a relevant distinction?
Well, you are argeeing with me. Publishing an object with AMS is different than viewing them and so AMS publishing is not a subclass of PetscViewer it is a separate thing. > > > > that has the object, name, type, and help string for every piece of > > information being exposed? > > Yes, I think the only thing missing is the "help string" for each field. > For example currently it is > > ierr = > AMS_Memory_add_field(obj->amem,"its",&ksp->its,1,AMS_INT,AMS_READ,AMS_COMMON,AMS_REDUCT_UNDEF);CHKERRQ(ierr); > > "its" is the help string. We could have a convention that the string is done > as "variablename: useful message" for example "its: the number of iterations > the Krylov solver is currently at" then the GUI can process it anyway it > wants. > > Might be better to change the API now to distinguish the name and the help > string just like for options? You mean "change the AMS API"? Godzooks you are asking too much :-( Reason, this information has to be propagated through all the AMS code which scares me too much to consider. Barry
