a wrinkle in on-demand behavior transfer

Markus Gaelli gaelli at emergent.de
Sun Jul 4 09:01:37 UTC 2004


Hi Craig,

> 	I got pretty far doing this. New classes were installed and 
> initialized
> properly, as a side-effect of transferring method literals. Super-sends
> and underrides were handled properly, and transfer loops were avoided.
> But I hadn't considered that the possibility of needing an override
> before the need for it is detected. In this case, one of the 
> application
> classes had an implementation of >>name in the kitchen-sink system, and
> an application object in the minimal system sent that message. The
> receiver happily ran Object>>name instead of the override; the minimal
> system had no way of knowing that it should have installed the
> overriding method first.
I guess that you have to store also the absence of an overwritten 
method.
So even if the new class Foo is already present in the system, but 
"name" is called the first time on an object of it,
you look up name on the kitchen sink image, as you did not flag it as 
absent yet. As in your example it is there, you just load it,
if it had not been there, you flag it as "definitely not here" in the 
method-dic of the class Foo, and are faster the next time -
I think it should not hurt too much, if you let the method lookup find 
a "definitely not here" vs. a "not here". ;-)

Makes sense?

Cheers,

Markus

>
> 	This problem seems unsolvable in general (at least, without perfect
> type inference, which I am not interested in pursuing). Left unchecked,
> it could yield highly subtle errors, and so renders any session
> untrustable. So, I've changed my approach to an even more brute-force
> one. I'm running the kitchen-sink snapshot in the simulator, and
> reporting every simulated send, after the entry point, to another copy
> of the kitchen-sink snapshot which is running normally. That snapshot,
> in turn, will make sure that the involved method is installed in the
> minimal snapshot.
>
> 	I appreciate any suggestions or comments. Well, apart from "this is 
> all
> nuts"; I've already thought of that one. :)
>
>
> 	thanks,
>
> -C
>
> --
> Craig Latta
> improvisational musical informaticist
> craig at netjam.org
> www.netjam.org
> [|] Proceed for Truth!
>
>




More information about the Squeak-dev mailing list