MC15 nasty bugs strike 1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

MC15 nasty bugs strike 1

keith1y
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.

Reply | Threaded
Open this post in threaded view
|

Re: MC15 nasty bugs strike 1

Damien Cassou-3
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

Reply | Threaded
Open this post in threaded view
|

Re: MC15 nasty bugs strike 1

keith1y
Damien Cassou wrote:
> 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.
>  
hehe, that will be strike 2

Keith