[ANN] Monticllo Update

Dear All,

Latest merged-Monticello in http://www.squeaksource.com/mc loads into 3.9.
I will generate the changeset/patch for loading into 3.8/3.7 tomorrow.

This latest version includes refactored and better psuedo-atomic loading.

The good news: It successfully loaded the TTFSpeedUpFix code, which
previously would freeze.

The hard part about this fix is that loading the package changes the
instance variables of a class while it is being used. To solve this,
before the load, I change the class defn to the union of the before and
after class defnitions. I then compile the methods in the context of
this class. Then methods are added and removed in a tight loop, and
finally the class definition is changed to the final requested state,
after initialization.

This means that theoretically perhaps everything is now loadable, i.e.
it should be possible to load any package, given a couple of simple
precautions.

The not so good news (hence the precautions): It still doesnt pass
Lukas'  nasty test. His test has a variable named foo, which in the
first case is block argument name, and in the second is an instance var.
Thus adding the class defn, with the inst var prior to the new methods
causes the old method to raise a syntax error.

This is only a problem if you happen to pick a new instVar name, the
same as one already used in another context. I.e. it is easily worked
around when the problem is found.

The code around the install process has been cleaned up, and hopefully
speeded up. The error handlers have been removed to outside of the
loops, into #protectedLoad, whch calls a cleaner and more easily
understood #basicLoad. All loads have been refactored to go through
#basicLoad, which means that in order to plug in a new atomic-loading
scheme in the future, it only has fix #basicLoad.

The out of order loading handles the case where a package pulls a
superclass out form under a subclass. If you reload the superclass it
will be relinked. Various scenarios have been tested, but it is a tricky
problem.

There are lots of new features on the drawing board, but I am going to
add them as needed...

best regards

Keith

---
Release Notes May 2007 - kph

MCDefinition - psuedo-instVars
Now has a properties interface to enable future enhancements that may
need to extend MCDefiniton with further instVars without breaking
exisitng mcz's which contain a binary snapshot, and so are dependent
upon the exisitng instVar layout. See MCDefinition-#properties
This is used to add the psuedo--instVar-#because.

MCWorkingCopyBrowser
'inspect working copy' is now 'explore working copy'

Bug: resizing the button bar, you cant make it smaller again.

Added MCCommonRepositoryInspector as an abstract superclass of
MCRepositoryInspector and MCFileRepositoryInspector.

Added a menu to the Version list in the above UI tools, moved the less
common actions from the button bar into this menu. #adopt, #diff (copy All?)

Added code for deleting repositories from directories and ftp
repositories. UI is currently disabled in
MCCommonRepositoryInspector-#isVersionDeleteable because it isnt
necessarily a great idea.

In general packageInfo only provides info about the loaded classes and
methods. Monticello extends PackageInfo with
#orphanedClassesAsDefinitions and #orphanedMethodsAsDefinitions The
updated packageInfo is optional.

ToDo: renaming a category has to do the classes in the orphanage too.

Changed the #dependencyWarning to reflect the new workflow.

Updated the use of Error handling to create orphans to use an explicit
OrphanedNotification, raised via MCDefinition-#orphanedBecause:. This
means that only known errors create orphans at present, and you get to
see other errors.

Added MCPackageLoader installOne: for individual loading.

When an orphan is created its definition,is told why. This is kept in
the #because pseudo-instVar

MCPackageLoader
For consistency loading, and unloading always uses the same load process
in #basicLoad. Callers can decide for themselves whether and when they
want to include the orphanage if they call #installOrphanage, before
calling #load. Much cleaner code.

Now shows 'Unloading...' for package removal, even though technically
its an Installation of removals. It used to say 'Installing...' which
was quirky but acceptable when unloading was rarely used.

Saving a package snapshot excludes any MCUnlinkedClassDefinitions from
the orphanage.

Removing an unlinked class removes any MCUnlinkedClassDefinitions from
the orphanage, or anyother definitions with that className (there
shouldnt be any other type).

Added MCMethodInitializeDefintion, MCExternalMethodDefinition and
MCMethodSpecialDefiniton and the factory method that instanciates the
correct subclass of MCMethodDefiniton.

Changed loadOver to preloadOver so that previous MC would be able to
load this MC.

Successfully loaded TTFSpeedUpFix.

Failed to load Lukas' heineous test case!

-----

Hi Keith -

Nice to see you taking on all of this. I'm personally very interested in
these improvements and (as soon as I find a bit of time) have a look at
them for integrating this version into Croquet. Two notes though:

The most complex issue that I have found in doing this is when you move
iVars up the class hierarchy. It is simple to do manually:

Object subclass: #Foo
        instanceVariableNames: ''
        ...

Foo subclass: #Bar
        instanceVariableNames: 'mumble'
        ...

and then (and this is where order is important):

Foo subclass: #Bar
        instanceVariableNames: ''

Object subclass: #Foo
        instanceVariableNames: 'mumble'

As far as I know this will explode pretty much everywhere and we may
have to add a specific exception to catch the problem (it is not that
the system can't survive the duplicate ivar temporarily it's just that
this is really really really a bad thing to do).

In any case, I think that if you can do *that* correctly you're ready to
take on everything else too ;-) Contrary to which ...

> The not so good news (hence the precautions): It still doesnt pass
> Lukas'  nasty test. His test has a variable named foo, which in the
> first case is block argument name, and in the second is an instance var.
> Thus adding the class defn, with the inst var prior to the new methods
> causes the old method to raise a syntax error.

... this problem really shouldn't cause a syntax error any more than
other shadowed variables. Non-interactive compilation has always allowed
this to go through so raising a syntax error seems inconsistent with,
say, adding an ivar in the browser which is shadowed by a temp which
doesn't raise a syntax error either.

Cheers,
   - Andreas