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