On Aug 14, 2011, at 2:58 PM, Jed Brown wrote: > On Sun, Aug 14, 2011 at 13:11, Barry Smith <bsmith at mcs.anl.gov> wrote: > Yes, the publisher is required to insure that all memory references that > they publish as fields remain around as long as the AMS memory exists. > > This is the problem.
"the" problem? I don't see it as a problem at all :-) You seem to want to have a neutral GUI backend that know's nothing about PETSc, it just transfers data and displays it. While those type do have their place I always envisioned also PETSc specific backends that presented the data so, for example, the GUI backend for SNES would know about things in SNES and could display computed quantities specific to SNES. In addition, if there is a "computed" value you want transmitted it can be simply added to the PETSc object (or subclass) and then an AMS field made for it. You are perhaps trying to make the AMS model something it is not, it is called a memory snooper because that is what it is, otherwise we would need to change the name to Memory snooper and other random stuff :-). > There are things that the monitors and viewers compute that are not backed by > memory. We still want to be able to see these when observing a computation. > So we need to somehow communicate information that is only on the stack to a > GUI or database that is monitoring a computation. Since we already want to > transmit options, we could create some similar channel (maybe buffered by > AMS) or we could just call it a viewer and have a way to hook an AMS client > into that viewer (i.e. with a protocol that is not too mismatched).
