[squeak-dev] re: execution-driven imprinting (was "Context status 2015-01-16")

Craig Latta craig at netjam.org
Wed Jan 21 10:44:03 UTC 2015


Hi Nicolas--

> In this scheme, something is striking me. Some images share some code
> (classes, compiledMethods). But what about code mutations/updates?

     That's doable. A target system can record what it has received, and
from where. Through a continuous or periodic remote-messaging connection
to a providing system (not necessarily the original one), or by
subscribing to update broadcasts from a repository that a providing
system updates, the target system can stay up to date.

> Without such mutations, is it still Smalltalk?

     I think it would be, but we don't have to give them up so it's only
a philosophical point.

> With active imprinting, such mutations might not be obvious to
> propagate (for example a subclass now overrides a message of super)

     I think a target system could arrange to receive notifications
about absolutely every change which might effect the code it has, and
discard the ones it deems irrelevant.

> ...you import class builder and compiler in the target; for what
> purpose? Is the target going to change a class locally?

     No, those were just examples of rather complex and interconnected
frameworks which are tricky to transfer via source code recompilation.
They made good demonstrations of the execution-driven imprinting
technique. One big feature is that the person doing the transfer doesn't
need to understand anything about the code being transferred, and the
technique works without modification no matter what the code is.

> What if it then imports incompatible methods from the provider?

     The imprinting mechanism doesn't transfer incompatible methods. It
supports a negotiation between the systems involved, though, to make the
targets compatible before transferring a method, if the person operating
the system approves.

> Maybe the scheme is more interesting for deployment of static code,
> but I'm curious to know if live updates would ever still be
> possible...

     Yes indeed! I wouldn't be as interested in it if they weren't. This
is meant to bring a fully-functional livecoding system, like we're all
used to having, to distributed situations.


     thanks,

-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)



More information about the Squeak-dev mailing list