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
_______________________________________________
V3dot10 mailing list
[email protected]
http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
