reversing fileins (was More Benchmark Results + Problems
with Win32/WinCE VMs)
Glenn Krasner
krasner at objectshare.com
Wed Sep 1 17:45:17 UTC 1999
The VisualWorks parcel load/unload mechanism includes this kind of "version
stack". You may want to check it out by way of example.
glenn
At 01:07 PM 9/1/99 -0400, Norton, Chris wrote:
>Hi Folks.
>
>Regarding reversible fileins, Dan Ingalls [Dan.Ingalls at disney.com] wrote:
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>"First, although, as Dwight points out, a fileIn can have any kind of
>executable code in it, most are pretty well behaved (add/remove methods,
>instVars, classVars, classes), and most of these changes could be reversed
>without a huge amount of bookkeeping. It might be worth doing."
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>Good point! As a person that often uses the filein mechanism, I would
>suggest that "normal" fileins (fileins that don't execute any wild new code)
>are far more prevalent than the latter. I'm not a change set expert, but
>isn't it the case that the executable code performed during the filein
>process is stored in the post script section of the change set? It might be
>easy to mark change sets as "those containing executable code" and "those
>without executable code" by doing a quick parse of the post script section
>of the change set. Having armed the change set browsers with the ability to
>differentiate between the two cases, one could then allow the change sets
>that do not execute wild new code to be removed from the image.
>
>Of course, the process of reverting a change set out of your image would
>require that you have not compressed your sources since the change set was
>filed in. It may also be the case that change sets that remove classes and
>class variables may have to be disallowed from the reversion process. After
>all, what would you initialize the "deleted" class variables to?
>
>This is interesting food for thought (it's lunchtime on the US east coast!).
>
>
>Cheers!
>---==> Chris
>>
>
>
>
More information about the Squeak-dev
mailing list
|