Spoon July 2004

spoon@lists.squeakfoundation.org

1 participants
3 discussions

re: a wrinkle in on-demand behavior transfer
by Craig Latta 04 Jul '04

04 Jul '04

Oh, but this won't help in the case where the classes involved are already present on both sides from the beginning of the session. Hmm, time for bed. :) -C -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org [|] Proceed for Truth!

1 0

re: a wrinkle in on-demand behavior transfer
by Craig Latta 04 Jul '04

04 Jul '04

Ned Konz and Russell Penney on the Squeak list suggested installing a loader method for each selector in a class when it is defined in the target system. Of course it seems obvious now. :) Thanks guys! (The loader methods which don't end up getting run can easily be removed later.) -C -- Craig Latta improvisational musical informaticist craig(a)netjam.org www.netjam.org [|] Proceed for Truth!

1 0

a wrinkle in on-demand behavior transfer
by Craig Latta 04 Jul '04

04 Jul '04

Hi-- So I've been using on-demand behavior transfer to pull into a minimal snapshot just what's required to run a particular application from a kitchen-sink snapshot (with a bunch of prerequisites from various authors). I ran into a situation that made me realize that my approach wasn't accurate enough. What I had been doing was responding to each message not understood by installing a "loader" method [(RemoteMessageDispatcher class)>>loadAndResend and friends]. When run, the loader method fetches the appropriate method from the kitchen-sink system (using a special network client), then resends the message which originally wasn't understood. The whole process gets kicked off by a loader method that represents an entry point for the application in the kitchen-sink system. 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. 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(a)netjam.org www.netjam.org [|] Proceed for Truth!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Spoon July 2004