>
>
> On Mon, Mar 2, 2009 at 1:48 PM, Stephen Pair <
stephen@pairhome.net> wrote:
>>
>> On Mon, Mar 2, 2009 at 12:38 AM, Eliot Miranda <
eliot.miranda@gmail.com>
>> wrote:
>>>
>>>
>>> On Sun, Mar 1, 2009 at 9:20 PM, Craig Latta <
craig@netjam.org> wrote:
>>>>
>>>> [snip]
>>>> 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.
>>>
>>> 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.
>>> E.
>>
>> Maybe you could get the repeatability with a process that is roughly:
>> a) write the spec for the capability of the image (a method that exercises
>> everything you want to be able to do)
>> 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
>> 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)
>> 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.
>
> 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.
> 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.
>