<br><br><div class="gmail_quote">On Mon, Mar 2, 2009 at 3:25 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/3/3 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
<div><div><span id="q_11fc993d1c5a641d_1" class="h4">- Show quoted text -</span></div><div class="h5">><br>
><br>
> On Mon, Mar 2, 2009 at 1:48 PM, Stephen Pair <<a href="mailto:stephen@pairhome.net">stephen@pairhome.net</a>> wrote:<br>
>><br>
>> On Mon, Mar 2, 2009 at 12:38 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> On Sun, Mar 1, 2009 at 9:20 PM, Craig Latta <<a href="mailto:craig@netjam.org">craig@netjam.org</a>> wrote:<br>
>>>><br>
>>>> [snip]<br>
>>>> As for whether to produce an object memory statically and then set<br>
>>>> it running, or transform an object memory which is always running... I think<br>
>>>> the resulting memory will need to load modules live anyway, so one might as<br>
>>>> well do all the transformations that way. Perhaps this is simply an<br>
>>>> aesthetic choice.<br>
>>><br>
>>> Surely repeatability mandates that one roduce an object memory statically<br>
>>> and then set it running? Because of things like delays the always running<br>
>>> memory is almost never in a predictable state, so one always ends up with<br>
>>> different bits even if they represent the same functionality.<br>
>>> E.<br>
>><br>
>> Maybe you could get the repeatability with a process that is roughly:<br>
>> a) write the spec for the capability of the image (a method that exercises<br>
>> everything you want to be able to do)<br>
>> b) use the class/method copying & DNU trickery and do the runtime analysis<br>
>> to figure out the classes and methods needed to support that capability<br>
>> c) do something a little more surgical to build a new image by copying<br>
>> over the behaviors and methods, but construct the processes and stacks more<br>
>> deliberately (so you aren't so tied to the running image's state)<br>
>> I'd think in this way you could do something that was reproducible to the<br>
>> extent that resulting image was only dependent on the running image for its<br>
>> behaviors and other necessary objects (various singletons and whatnot), but<br>
>> otherwise not affected by various processes and random other things that<br>
>> might be in that image. Once you had (b) and (c) mostly ironed out, it<br>
>> would be a process of refining the specification in (a) to get to a suitable<br>
>> minimal image.<br>
><br>
> Agreed. The nice thing is being able to run a) in the IDE so that when<br>
> something is missing it manifests as an Undeclared or an MNU.<br>
> One thing is ensuring that when simulating objects like nil, true and false<br>
> behave as they will in the result, not as defined in the host image. One<br>
> thing one could do is arrange that the compiler for MObject uses instances<br>
> of MSymbol for all code under MObject. Then e.g. a doesNotUnderstand:<br>
> handler on SmallInteger, UndefinedObject, Boolean et al might be able to<br>
> forward things correctly and arrange that the simulation was more accurate.<br>
><br>
<br>
</div></div>Thats why i wrote own parser/compiler in Moebius.<br>
It is designed in a way, that a parser & compiler output is under full<br>
control of an object which plays role as environment.<br>
So, you can produce an instance of CompiledMethod as output, or encode<br>
result in machine code, or represent methods as a raw bytes which then<br>
could be put in the image you constructing.<br>
Even nil,true,false singleton values are under control of environment.<br>
<br>
Read more about it here.<br>
<a href="http://code.google.com/p/moebius-st/wiki/Parser" target="_blank">http://code.google.com/p/moebius-st/wiki/Parser</a><br>
<br>
Simulation of SmallInts could be made easy - we could simply make a<br>
class, named BoxedSmallInteger<br>
and use it for representing all literal values in methods. At final<br>
stage of image creating we can unbox them and replace by smallints.</blockquote><div><br></div><div>Cool. So the compiler can avoid using the pushNil, pushFalse and pushTrue bytecodes. It must send some message to coerce every MBoolean result into a host Boolean before doing a conditional jump. It must wrap all MSmallInteger relational primitive invocations with code to coerce the Booleran to the matching MBoolean.</div>
<div><br></div><div>A doesNotUnderstand: will produce an instance of Message and send doesNotUnderstand:, do MObject needs a doesNtUnderstand: handler that sends MSymbol #doesNotUnderstand: with a coercion of the Message to an MMessage. Any other holes that need to be plugged?</div>
<div><br></div><div>Alternatively just create a subclass of InstructionStream and/or ContextPart and interpret all code and have the interpretation manage MObject. That might be slow but easier to get going.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">We're in smalltalk, after all, where such things is possible to do,<br>
unlike many other languages :)</blockquote><div><br></div><div>Right on!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">>><br>
>> - Stephen<br>
<div><div><span id="q_11fc993d1c5a641d_3" class="h4">- Show quoted text -</span></div><div class="h5"><br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br>