Folks -
Just as a warning, something went wrong in the last round of updates I posted and I'm trying to understand what happened. I recommend you stay away from updating until I send an "all clear" message.
Cheers, - Andreas
Folks -
We're all clear now. The problem with trunk updating was caused by Monticello (more precisely Monticello-rej.309) which attempted to make MC loading atomic but in the process introduced some serious breakage in MC. In short, what the changes did was to first compile new methods and classes and defer installation the newly compiled methods until later. That sounds good at first but only to the point where you realize that methods often need to be recompiled in the process of class definition changes.
In this case, we had various methods in subclasses of CharacterScanner which were updated at the same time as a new variable was added in CharacterScanner (pendingKernX). The process involved compiling some methods with the *old* CharacterScanner definition and some methods with the *new* CharacterScanner definition (depending on whether the method was compiled before or after CharacterScanner's redefinition). As a consequence, when the methods were installed (some of which referred to the old, and some of which referred to the new layout) everything crashed and burned.
I have added a workaround in the form of an extra loading pass in MC that first loads class definitions and then the rest. This gets us past the hurdle but is probably not a proper long-term solution. Any ideas on how to address this issue would be greatly appreciated. At this point I'm leaning towards getting rid of MC's dependency driven load process and replace it with a declarative version that is explicit about what it does (i.e., adding/removing categories, adding/redefining/removing classes, adding/redefining/removing traits, adding/redefining/removing methods etc.) since the current MC version also has the problem that removals now again happen before additions which is yet another problem.
Cheers, - Andreas
Andreas Raab wrote:
Folks -
Just as a warning, something went wrong in the last round of updates I posted and I'm trying to understand what happened. I recommend you stay away from updating until I send an "all clear" message.
Cheers,
- Andreas
On 31.08.2009, at 05:56, Andreas Raab wrote:
Folks -
We're all clear now. The problem with trunk updating was caused by Monticello (more precisely Monticello-rej.309) which attempted to make MC loading atomic but in the process introduced some serious breakage in MC.
Uh, I wasn't even aware our MC version did this. The same version by Ralph introduced the bug that not all files are shown in the repository browser.
I found a little bit of discussion at
http://lists.squeakfoundation.org/pipermail/v3dot10/2007-March/000370.html
Glad this kind of discussion would happen on squeak-dev now.
In short, what the changes did was to first compile new methods and classes and defer installation the newly compiled methods until later. That sounds good at first but only to the point where you realize that methods often need to be recompiled in the process of class definition changes.
In this case, we had various methods in subclasses of CharacterScanner which were updated at the same time as a new variable was added in CharacterScanner (pendingKernX). The process involved compiling some methods with the *old* CharacterScanner definition and some methods with the *new* CharacterScanner definition (depending on whether the method was compiled before or after CharacterScanner's redefinition). As a consequence, when the methods were installed (some of which referred to the old, and some of which referred to the new layout) everything crashed and burned.
I have added a workaround in the form of an extra loading pass in MC that first loads class definitions and then the rest. This gets us past the hurdle but is probably not a proper long-term solution. Any ideas on how to address this issue would be greatly appreciated. At this point I'm leaning towards getting rid of MC's dependency driven load process and replace it with a declarative version that is explicit about what it does (i.e., adding/removing categories, adding/redefining/removing classes, adding/redefining/removing traits, adding/redefining/removing methods etc.) since the current MC version also has the problem that removals now again happen before additions which is yet another problem.
Cheers,
- Andreas
I think the SystemEditor in the latest Monticello does pretty much do this. Before patching up our old version we should switch to that one.
- Bert -
Not all :=) , but I enjoying this.
As Ferrari yesterday in Belgium, Squeak could beat his forks now.
Keep the very good job.
Edgar
Edgar,
just did a clean update from scratch (based on the first trunk image published by andreas).
Alex
On Mon, Aug 31, 2009 at 11:17 AM, Edgar J. De Cleene < edgardec2001@yahoo.com.ar> wrote:
Not all :=) , but I enjoying this.
As Ferrari yesterday in Belgium, Squeak could beat his forks now.
Keep the very good job.
Edgar
On 8/31/09 6:44 AM, "Alexander Lazarević" laza@blobworks.com wrote:
Edgar,
just did a clean update from scratch (based on the first trunk image published by andreas).
Alex
You mean do it all again from 7159 start image ?
It's a long way, but if works...
Edgar
On 31.08.2009, at 12:11, Edgar J. De Cleene wrote:
On 8/31/09 6:44 AM, "Alexander Lazarević" laza@blobworks.com wrote:
Edgar,
just did a clean update from scratch (based on the first trunk image published by andreas).
Alex
You mean do it all again from 7159 start image ?
It’s a long way, but if works...
No. Just load the latest TrueType version from trunk before updating.
I'll add a config map so this should work automatically ...
- Bert -
On 31.08.2009, at 12:18, Bert Freudenberg wrote:
On 31.08.2009, at 12:11, Edgar J. De Cleene wrote:
On 8/31/09 6:44 AM, "Alexander Lazarević" laza@blobworks.com wrote:
Edgar,
just did a clean update from scratch (based on the first trunk image published by andreas).
Alex
You mean do it all again from 7159 start image ?
It’s a long way, but if works...
No. Just load the latest TrueType version from trunk before updating.
I'll add a config map so this should work automatically ...
- Bert -
I had to replace the ar.13 config map with bf.13. It has the same versions but moves the TrueType package further up to be loaded earlier.
With that, updating worked fine for me (I had the same error as Edgar before).
- Bert -
On 8/31/09 7:29 AM, "Bert Freudenberg" bert@freudenbergs.de wrote:
I had to replace the ar.13 config map with bf.13. It has the same versions but moves the TrueType package further up to be loaded earlier.
With that, updating worked fine for me (I had the same error as Edgar before).
- Bert -
Amazing. Now update complete and works.
Viele Danke
Edgar
This was just to share with you what easily worked for me, not to exclude more sophisticated or general solutions! :)
Alex
2009/8/31 Edgar J. De Cleene edgardec2001@yahoo.com.ar
On 8/31/09 6:44 AM, "Alexander Lazarević" laza@blobworks.com wrote:
Edgar,
just did a clean update from scratch (based on the first trunk image published by andreas).
Alex
You mean do it all again from 7159 start image ?
It’s a long way, but if works...
Edgar
On Aug 31, 2009, at 3:17 AM, Edgar J. De Cleene wrote:
<Picture 1.jpg>
Edgar, thanks for the picture. It reminded me of a question I've been wanting to ask for while. Does anyone know how revive a morph after an error leaves it with the redbox and yellow x? Last time this happened to me, I couldn't even locate the code responsible for handling this error state and drawing the redbox with yellow x
David
David Farber wrote:
Edgar, thanks for the picture. It reminded me of a question I've been wanting to ask for while. Does anyone know how revive a morph after an error leaves it with the redbox and yellow x? Last time this happened to me, I couldn't even locate the code responsible for handling this error state and drawing the redbox with yellow x
Look at the senders of #errorOnDraw to find the places that deal with it. The short version is that the system catches errors in drawOn: methods and then walks the stack trying to turn off drawing for the morph in question. You can re-enable drawing by getting the handles on the crossed-out morph, and from the debug halo choose "start drawing again".
Cheers, - Andreas
Thanks!
David
On Aug 31, 2009, at 7:53 PM, Andreas Raab wrote:
David Farber wrote:
Edgar, thanks for the picture. It reminded me of a question I've been wanting to ask for while. Does anyone know how revive a morph after an error leaves it with the redbox and yellow x? Last time this happened to me, I couldn't even locate the code responsible for handling this error state and drawing the redbox with yellow x
Look at the senders of #errorOnDraw to find the places that deal with it. The short version is that the system catches errors in drawOn: methods and then walks the stack trying to turn off drawing for the morph in question. You can re-enable drawing by getting the handles on the crossed-out morph, and from the debug halo choose "start drawing again".
Cheers,
- Andreas
Polymorph install out of the box from Universes.
I don't know what exactly you did, but, holy sh*t...
My squeak trunk image, now flies. It's incredible fast opening menus and browsing.
What the...
El dom, 30-08-2009 a las 20:56 -0700, Andreas Raab escribió:
Folks -
We're all clear now. The problem with trunk updating was caused by Monticello (more precisely Monticello-rej.309) which attempted to make MC loading atomic but in the process introduced some serious breakage in MC. In short, what the changes did was to first compile new methods and classes and defer installation the newly compiled methods until later. That sounds good at first but only to the point where you realize that methods often need to be recompiled in the process of class definition changes.
In this case, we had various methods in subclasses of CharacterScanner which were updated at the same time as a new variable was added in CharacterScanner (pendingKernX). The process involved compiling some methods with the *old* CharacterScanner definition and some methods with the *new* CharacterScanner definition (depending on whether the method was compiled before or after CharacterScanner's redefinition). As a consequence, when the methods were installed (some of which referred to the old, and some of which referred to the new layout) everything crashed and burned.
I have added a workaround in the form of an extra loading pass in MC that first loads class definitions and then the rest. This gets us past the hurdle but is probably not a proper long-term solution. Any ideas on how to address this issue would be greatly appreciated. At this point I'm leaning towards getting rid of MC's dependency driven load process and replace it with a declarative version that is explicit about what it does (i.e., adding/removing categories, adding/redefining/removing classes, adding/redefining/removing traits, adding/redefining/removing methods etc.) since the current MC version also has the problem that removals now again happen before additions which is yet another problem.
Cheers,
- Andreas
Andreas Raab wrote:
Folks -
Just as a warning, something went wrong in the last round of updates I posted and I'm trying to understand what happened. I recommend you stay away from updating until I send an "all clear" message.
Cheers,
- Andreas
On Sun, Aug 30, 2009 at 8:56 PM, Andreas Raab andreas.raab@gmx.de wrote:
Folks -
We're all clear now. The problem with trunk updating was caused by Monticello (more precisely Monticello-rej.309) which attempted to make MC loading atomic but in the process introduced some serious breakage in MC. In short, what the changes did was to first compile new methods and classes and defer installation the newly compiled methods until later. That sounds good at first but only to the point where you realize that methods often need to be recompiled in the process of class definition changes.
In this case, we had various methods in subclasses of CharacterScanner which were updated at the same time as a new variable was added in CharacterScanner (pendingKernX). The process involved compiling some methods with the *old* CharacterScanner definition and some methods with the *new* CharacterScanner definition (depending on whether the method was compiled before or after CharacterScanner's redefinition). As a consequence, when the methods were installed (some of which referred to the old, and some of which referred to the new layout) everything crashed and burned.
I have added a workaround in the form of an extra loading pass in MC that first loads class definitions and then the rest. This gets us past the hurdle but is probably not a proper long-term solution. Any ideas on how to address this issue would be greatly appreciated. At this point I'm leaning towards getting rid of MC's dependency driven load process and replace it with a declarative version that is explicit about what it does (i.e., adding/removing categories, adding/redefining/removing classes, adding/redefining/removing traits, adding/redefining/removing methods etc.) since the current MC version also has the problem that removals now again happen before additions which is yet another problem.
If one doesn't have a truly atomic install then it seems to me that the safest order is as follows:
1. make a pass that adds instance variables & class variables, leaving any to-be-deleted instance & class variables in place 2. compile and install added methods (this still isn't safe since one may add a method that overrides a method in a superclass, but its a reasonable default) 3. compile and install modified methods; these can rely on instance variables and new methods having been added (pace the aforementioned override gotcha) 4. remove methods 5. delete instance & class variables
If you want to do a real atomic install you have to - create a duplicate class hierarchy of all classes with any modification, only sharing methods on classes whose shape doesn't change between the actual class and the shadow class, and recompiling methods on classes whose shape changes - collect all the instances of all the classes - do a mass become that replaces the classes with their shadows and updates instances in one go
Which ever approach one takes, a safer order or a truly atomic install, I think the right approach is a plan/execute one (a.k.a. compile) where the various updates are created as a sequence of operation objects before being run together in some context, instead of interpreting.
Presumably (Hi Colin,) the MC2.0 atomic install works somewhat like this. The question is therefore whether one should try and extract that from MC2 or move to MC2 adding backward compatibility to load MC1.5 format packages.
Cheers,
- Andreas
Andreas Raab wrote:
Folks -
Just as a warning, something went wrong in the last round of updates I posted and I'm trying to understand what happened. I recommend you stay away from updating until I send an "all clear" message.
Cheers,
- Andreas
On 31.08.2009, at 21:58, Eliot Miranda wrote:
On Sun, Aug 30, 2009 at 8:56 PM, Andreas Raab andreas.raab@gmx.de wrote: Folks -
We're all clear now. The problem with trunk updating was caused by Monticello (more precisely Monticello-rej.309) which attempted to make MC loading atomic but in the process introduced some serious breakage in MC. In short, what the changes did was to first compile new methods and classes and defer installation the newly compiled methods until later. That sounds good at first but only to the point where you realize that methods often need to be recompiled in the process of class definition changes.
In this case, we had various methods in subclasses of CharacterScanner which were updated at the same time as a new variable was added in CharacterScanner (pendingKernX). The process involved compiling some methods with the *old* CharacterScanner definition and some methods with the *new* CharacterScanner definition (depending on whether the method was compiled before or after CharacterScanner's redefinition). As a consequence, when the methods were installed (some of which referred to the old, and some of which referred to the new layout) everything crashed and burned.
I have added a workaround in the form of an extra loading pass in MC that first loads class definitions and then the rest. This gets us past the hurdle but is probably not a proper long-term solution. Any ideas on how to address this issue would be greatly appreciated. At this point I'm leaning towards getting rid of MC's dependency driven load process and replace it with a declarative version that is explicit about what it does (i.e., adding/removing categories, adding/redefining/removing classes, adding/redefining/removing traits, adding/redefining/removing methods etc.) since the current MC version also has the problem that removals now again happen before additions which is yet another problem.
If one doesn't have a truly atomic install then it seems to me that the safest order is as follows:
- make a pass that adds instance variables & class variables,
leaving any to-be-deleted instance & class variables in place 2. compile and install added methods (this still isn't safe since one may add a method that overrides a method in a superclass, but its a reasonable default) 3. compile and install modified methods; these can rely on instance variables and new methods having been added (pace the aforementioned override gotcha) 4. remove methods 5. delete instance & class variables
If you want to do a real atomic install you have to
- create a duplicate class hierarchy of all classes with any
modification, only sharing methods on classes whose shape doesn't change between the actual class and the shadow class, and recompiling methods on classes whose shape changes
- collect all the instances of all the classes
- do a mass become that replaces the classes with their shadows and
updates instances in one go
Which ever approach one takes, a safer order or a truly atomic install, I think the right approach is a plan/execute one (a.k.a. compile) where the various updates are created as a sequence of operation objects before being run together in some context, instead of interpreting.
Presumably (Hi Colin,) the MC2.0 atomic install works somewhat like this. The question is therefore whether one should try and extract that from MC2 or move to MC2 adding backward compatibility to load MC1.5 format packages.
I don't think MC1.5 changed the package format - did it? But it uses the same SystemEditor as MC2. Which supposedly gets all this right.
- Bert -
On 31-Aug-09, at 12:58 PM, Eliot Miranda wrote:
Which ever approach one takes, a safer order or a truly atomic install, I think the right approach is a plan/execute one (a.k.a. compile) where the various updates are created as a sequence of operation objects before being run together in some context, instead of interpreting.
Presumably (Hi Colin,) the MC2.0 atomic install works somewhat like this. The question is therefore whether one should try and extract that from MC2 or move to MC2 adding backward compatibility to load MC1.5 format packages.
Yes, SystemEditor does work like this.
The idea is that you make your changes using protocol-compatible proxies for the actual classes, called editors. The editors record the changes then when the transaction is committed, build new classes, (re)compile methods and migrate instances. If all goes without incident, it's all installed with a mass become.
There's no need to extract SystemEditor from MC2 - it's a separate project already in use in a couple of other places.
As far as moving to MC2 goes, I do think we should do that eventually. It's not quite there yet, though. The 2.0.x releases had some logistical issues which made them awkward for collaborative development. I'm currently at work on Monticello 2.1, which will solve these problems and lay the groundwork for continued evolution.
Colin
squeak-dev@lists.squeakfoundation.org