<br><br><div class="gmail_quote">On Mon, Mar 2, 2009 at 1:48 PM, Stephen Pair <span dir="ltr"><<a href="mailto:stephen@pairhome.net">stephen@pairhome.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="Wj3C7c"><div class="gmail_quote">On Mon, Mar 2, 2009 at 12:38 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote">On Sun, Mar 1, 2009 at 9:20 PM, Craig Latta <span dir="ltr"><<a href="mailto:craig@netjam.org" target="_blank">craig@netjam.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[snip]<div><br>
As for whether to produce an object memory statically and then set it running, or transform an object memory which is always running... I think the resulting memory will need to load modules live anyway, so one might as well do all the transformations that way. Perhaps this is simply an aesthetic choice.</div>
</blockquote>
<div><br></div><div>Surely repeatability mandates that one roduce an object memory statically and then set it running? Because of things like delays the always running memory is almost never in a predictable state, so one always ends up with different bits even if they represent the same functionality.</div>
<div><br></div><font color="#888888"><div>E.</div><div></div></font></div>
</blockquote></div><br></div></div><div>Maybe you could get the repeatability with a process that is roughly:</div><div><br></div><div>a) write the spec for the capability of the image (a method that exercises everything you want to be able to do)</div>
<div>b) use the class/method copying & DNU trickery and do the runtime analysis to figure out the classes and methods needed to support that capability</div><div>c) do something a little more surgical to build a new image by copying over the behaviors and methods, but construct the processes and stacks more deliberately (so you aren't so tied to the running image's state)</div>
<div><br></div><div>I'd think in this way you could do something that was reproducible to the extent that resulting image was only dependent on the running image for its behaviors and other necessary objects (various singletons and whatnot), but otherwise not affected by various processes and random other things that might be in that image. Once you had (b) and (c) mostly ironed out, it would be a process of refining the specification in (a) to get to a suitable minimal image.</div>
</blockquote><div><br></div><div>Agreed. The nice thing is being able to run a) in the IDE so that when something is missing it manifests as an Undeclared or an MNU. </div><div><br></div><div>One thing is ensuring that when simulating objects like nil, true and false behave as they will in the result, not as defined in the host image. One thing one could do is arrange that the compiler for MObject uses instances of MSymbol for all code under MObject. Then e.g. a doesNotUnderstand: handler on SmallInteger, UndefinedObject, Boolean et al might be able to forward things correctly and arrange that the simulation was more accurate.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div>
<div><br></div><font color="#888888"><div>- Stephen</div>
</font><br><br>
<br></blockquote></div><br>