On Aug 14, 2011, at 12:15 PM, Jed Brown wrote: > On Sun, Aug 14, 2011 at 12:05, Barry Smith <bsmith at mcs.anl.gov> wrote: > 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. > > 1. I thought AMS was normally allowed to look at it later (because it > returned a memory reference).
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. > By what mechanism does AMS become synchronous (because it must if you publish > a stack variable which will only be valid instantaneously). It doesn't, you don't publish stuff on the stack. There is no such concept. > > 2. We could create an "AMS" viewer that, instead of actually reading the > published values with a separate process, printed it (or wrote to a file). Yes > > I need to go use AMS for something so that I can have an intelligent > discussion about its implementation/capability. > > 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. > > Alternative rationale: AMS does not have a big network of dependencies yet so > now is the best time to make it just how we eventually want it. Getting hands > dirty in AMS (although this may be a somewhat superficial change) would be > useful for me anyway. Valid point. Before doing that I think we need to toughen up the test suite a bit, the tests are a bit too much like "examples" and not enough "automatic tests". Barry
