I have found the problem which led to packages needing a recompile if
instance vars are changed significantly. This was leading to image crashes when upgrading the dev-image package universes. Recent Omnibrowser changes provided a perfect test scenario. This was our big showstopper bug! cheers Keith ========= The following is for documentation of the loading process and is a very good reason why SystemEditor is much better solution. The loading process. [preloadOver:] When loading classes, first of all MC removes all class extenstions for a class and its subclasses, and saves them for later. This avoids problems later in the load (see **). Then MC attempts to change the class to a union of the old and new class definitions in order that as many methods as possible, old and new will compile. This change prompts a recompile of the class. Old methods which happen to use new inst var names for temp's will fail to recompile with Syntax Errors. At this stage such SyntaxErrors being resumable are ignored. For each method being added the obsolete method (if there is one) is removed. [*] part of the show-stopping bug was caused by failing to remove the obsolete methods at this point. This would cause the next next class recompile to fail due to undeclared items in the obsolete methods When loading methods, each method being added is compiled ready to be added later. This compilation may fail if the unioned-class definition failed to compile earlier hence the importance of *. [removal] Methods that are no longer needed are removed. If the method is an '-override' the old method is found and reinstated. [install] Loading Classes: The class is then changed to the required definition. If this changes the definition then a recompile will occur again. Methods which are not for this class definition and refer to removed instVars will fail to recompile at this point. [this used to include obsolete methods which were not being removed as indicated above*] [**] NOTE: At this point class extensions from other packages will fail to recompile if they are accessing inst vars directly, and those instvars have been removed. The solution is to to remove extensions first until such time as they will recompile or become superseded by a new method Loading Methods: if the previous compilation failed, it will be retried in the context of the new class definition. The compiled method is added to the class and logged to changes [ postinstall ] Loading Classes: Class extensions that were removed to begin with are re-compiled and installed. Classes effected are recompiled (not sure why this is necessary but it is!). Loading Methods: FFI field definitions are loaded (first) and #initialize is run (last) [ postLoad ] Loading Classes: Restored class extension methods have their observers notified. Loading Methods: Methods have their observers notified. |
Very cool Keith. Does it also fix the problem with method categories?
I would then be able to build the new squeak-dev beta on top of it. 2007/10/2, Keith Hodges <[hidden email]>: > I have found the problem which led to packages needing a recompile if > instance vars are changed significantly. This was leading to image > crashes when upgrading the dev-image package universes. Recent > Omnibrowser changes provided a perfect test scenario. > > This was our big showstopper bug! > > cheers > > Keith > > ========= > The following is for documentation of the loading process and is a very > good reason why SystemEditor is much better solution. > > The loading process. > > [preloadOver:] > > When loading classes, first of all MC removes all class extenstions for > a class and its subclasses, and saves them for later. This avoids > problems later in the load (see **). > > Then MC attempts to change the class to a union of the old and new > class definitions in order that as many methods as possible, old and > new will compile. This change prompts a recompile of the class. > > Old methods which happen to use new inst var names for temp's will fail > to recompile with Syntax Errors. At this stage such SyntaxErrors being > resumable are ignored. > > For each method being added the obsolete method (if there is one) is > removed. > > [*] part of the show-stopping bug was caused by failing to remove the > obsolete methods at this point. This would cause the next next class > recompile to fail due to undeclared items in the obsolete methods > > When loading methods, each method being added is compiled ready to be > added later. This compilation may fail if the unioned-class definition > failed to compile earlier hence the importance of *. > > [removal] > > Methods that are no longer needed are removed. If the method is an > '-override' the old method is found and reinstated. > > [install] > > Loading Classes: The class is then changed to the required definition. > If this changes the definition then a recompile will occur again. > Methods which are not for this class definition and refer to removed > instVars will fail to recompile at this point. [this used to include > obsolete methods which were not being removed as indicated above*] > > [**] NOTE: At this point class extensions from other packages will fail > to recompile if they are accessing inst vars directly, and those > instvars have been removed. > > The solution is to to remove extensions first until such time as they > will recompile or become superseded by a new method > > Loading Methods: if the previous compilation failed, it will be retried > in the context of the new class definition. The compiled method is added > to the class and logged to changes > > [ postinstall ] > > Loading Classes: Class extensions that were removed to begin with are > re-compiled and installed. Classes effected are recompiled (not sure why > this is necessary but it is!). > > Loading Methods: FFI field definitions are loaded (first) and > #initialize is run (last) > > [ postLoad ] > > Loading Classes: > Restored class extension methods have their observers notified. > > Loading Methods: > Methods have their observers notified. > > -- Damien Cassou |
Free forum by Nabble | Edit this page |