<div class="gmail_quote">On Sun, Aug 14, 2011 at 12:05, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":35">  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.<br></div></blockquote><div><br></div>
<div>1. I thought AMS was normally allowed to look at it later (because it returned a memory reference). By what mechanism does AMS become synchronous (because it must if you publish a stack variable which will only be valid instantaneously).</div>
<div><br></div><div>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).</div><div><br></div><div>I need to go use AMS for something so that I can have an intelligent discussion about its implementation/capability.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":35"><div class="im">
</div>   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.</div></blockquote></div>
<br><div>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.</div>