[V3dot10] Going to beta ?

[Keith Hodges]

Ralph Johnson wrote:
> My interpretation of "going to beta" means that we stop adding
> features and just fix bugs.  I am in favor.
I would suggest, just fix bugs in the base image, but also be able to 
update to the latest tools, those that are conceptually also beta/final. 
For example SqueakMap has had some GUI updates. In the case of tools it 
should be easier to revert to the original tool if there is a problem 
before going final. I would also like to vote for my improved 
SUnit/TestRunner etc.

Investigating Monticello, in particular 309, I think that there are a 
couple of bugs in there. For example, If you browse a snapshot and 
manually load a method, this calls #load on the MCMethodDefinition. 
Under your atomic loading scheme this only compiles the method it does 
not install it.

I shall spend a couple of more days on monticello to see if I can knock 
it into shape. I need to use it for a porting project before tuesday.

I thought that my first release had your 'atomic loading' code in it. 
Since it didn't I have since been looking at a more comprehensive solution.

I so far I have set up the following sequence, #loadOver: [ #install 
#postinstall ] #postloadOver: , for additions and [ #remove ] 
#postinstall for removals, where the bracketed items are the atomic bits 
that happen 'simultaneously'. Now I just need to work out  what actions 
should best happen at what step.

The TTFCache fix broke on loading because the a new Class definition 
removed a number of Class variables which were then used by the old 
methods, before the new methods get loaded in.

I am attempting to change the class definition first (at #loadOver:) to 
something that represents the union of the old and new definitions, then 
having compiled the new methods. The atomic loading installs the 
compiled methods, and removes the old methods 'atomically'. The class 
definition can then be changed to its final state in postLoadOver.

I like this solution because the #initialize function is will have 
access to both the old and the new class vars  simultaneously (etc) so 
making migrations theoretically possible.

> changes, losing some history.   It would be cool to go back and
> recover that history and put it in the history database.
>
> Even cooler, we could go back and get all the history in Squeak 1 and
> Squeak 2, so we could have a complete history of all code that had
> ever been in the Squeak image.  This would only require changing the
>
and even cooler, you could trawl monticello repositories for yet more 
method history.
> So, here is a summary of my proposal.  I want to know what you think 
> about it!
Sounds great

Keith