Mantis - Squeak
Viewing Issue Advanced Details
6241 Monticello major always 02-27-07 17:54 10-03-09 19:34
assigned 3.9  
0006241: Atomic loading
MC loads methods one at a time, loading one before it compiles the next. Packages that change the compiler (or MC) or classes that they use often do not load. Programmers can edit change sets to make sure that methods get changed in the right order, but there is no way to control the order of loading methods in a MC package. This is one of the disadvantages of MC relative to change sets.

This attachment implements atomic loading. It adds a class called MethodAddition that represents a method in its various stages of being added. First, it gets compiled. Once all methods have been compiled, the PackageLoader will install all of them in their classes. There is one method in PackageLoader that does this; it uses OrderedCollection>>do: and a few methods from CompiledMethod, but otherwise doesn't depend on anything. Finally, all the methods signal that they have been updated, so that tools can update their views.

I have not yet implemented atomic unload. I'll do it when I need it. Let me know if you need it.

-Ralph Johnson
related to 0007017closed Keith_Hodges Sometimes Classes are not recompiled when instance variables change 
 Monticello-rej.309.mcz [^] (199,039 bytes) 02-27-07 17:54
 Foo-lr.1.mcz [^] (957 bytes) 03-01-07 08:17
 Foo-lr.2.mcz [^] (1,029 bytes) 03-01-07 08:18 [^] (1,033 bytes) 03-09-07 08:05

03-01-07 08:16   
I tried you enhancement and see no big improvement, after all I would certainly not call it atomic. To reproduce load Foo-lr.1.mcz and then Foo-lr.2.mcz.
03-09-07 08:09   
This Monticello can not load mcm, see the attached

Additionally it harvests none of the Impara fixes like:
- ignore the order of class variables
- loading FFI external structures
- ui fixes
-- bring the tree for dependent packages back
-- provide more progres information
-- don't scale the toolbar then resizing the monticello browser
05-10-07 18:41   
The problem that ranggli reports is different from the one I tried to solve.

His test case has a local variable named foo, and then he tries to define an instance variable named foo and then change the local variable name to be something else. However, it results in an inconsistent intermediate state. First, you have to rename the local variable and then you have to redefine the class. A changefile can handle this because it can ensure that the changes are done in that order. MC will usually not do it right, and my version of MC is certain to not do it right because it always compiles class definitions before method definitions. To do this, you need two different changes. This proves that you cannot always merge MC files to produce a working MC file.

A change is a program transformation, not a set of methods. Composing transformations is not the same thing as taking the union of the method changes.

So, my conclusion is that my enhancement is an improvement, and that renggli's test case is not appropriate for Monticello.
05-10-07 19:08   
As pointed out several times, Monticello 2 has atomic loading and handles the test of Lukas just fine. All that had to be done is porting the class builder from Monticello 2 to Monticello 1.

There are also some nice papers of the VW guys (Elliot and the gang) about atomic loading in VW with parcels.

05-10-07 19:16   
The problem I report is a common problem when keeping up-to-date with ongoing development. I know of at least a handful cases where this unintentionally happened in the context of big industrial and open-source projects.

What I criticize on the proposed change is that the name is misleading. It is not atomic, because it still compiles incrementally. If the loader would be really atomic, then the order of changes wouldn't matter as everything would be there in one single uninterruptible shot: class addition/removal/recompilation, method addition/removal/recompilation, object migration, etc. The atomic loader of Colin Putney does exactly this and it doesn't fail with my test.

The signalling of the changes at the end and the way the change-logging is handled looks suspicious to break things. I am missing the tests showing that it actually does what you advertise.
05-15-07 20:22   
"fix begin"
Installer mantis bug: 6241 fix: 'Foo-lr.1.mcz'.
Installer mantis bug: 6241 fix: 'Foo-lr.2.mcz'.
"fix end"
06-29-07 07:51   
Update on status: I have added an MCPackageLoader2 to the version hosted at [^]

This loader uses the SystemEditor from MC2 and is therefore truely atomic!

However it appears that this use of SystemEditor has progressed further than the MC2 team have, and so SystemEditor has yet to be tested. So the down side being that the final step of committing the change to the system crashes the image.
06-29-07 07:55   
Keith, you are the man!

If you need any help for testing or bug-fixing, please send a mail to me.
06-07-08 02:50   
I have tried the test case again with Monticello.impl-kph.515 and it passes!
10-26-08 02:04   
Atomic loading/unloading is working with MC1.6 (for non traits and tweak users)