Hi All,
I'm very sorry to report that my recent changes (adding CompiledCode and CompiledBlock to the CompiledMethod hierarchy in anticipation of full blocks, and merging ContextPart and MethodContext and renaming them as Context, to eliminate obsolete block and closer implementations) has broken the update process. I do not believe there is an easy fix as i think the issues are to do with the citations that exist on the stack while the update proceeds (the progress indicators). There is a clumsy work-around that appears reliable. The pauses between loads get rid of the progress indication activations and hence avoid trying to upgrade running processes through these kernel changes. Open the trunk repository from your Monticello Browser. Locate the update package (the penultimate entry in the list of packages). Load (or merge) update-eem.400.mcm. Load (or merge) update-eem.403.mcm. Load (or merge) update-eem.406.mcm. Save your image. Local the Kernel package. Load Kernel-eem.1078. Save your image. Update I'm so sorry. Eliot |
Hi Eliot, this remind me recent problems when we wanted to upgrade the SystemProgressMorph itselfhttp://lists.squeakfoundation.org/pipermail/squeak-dev/2016-August/191722.html I didn't look at the problem, but maybe an option is tp detach the Context* classes from the SystemDictionary in some preamble so that they are immune to any refactoring while still in use... Nicolas 2017-03-31 4:32 GMT+02:00 Eliot Miranda <[hidden email]>:
|
In reply to this post by Eliot Miranda-2
When I try to load update-eem.400.mcm, I am getting an error,
"CompiledMethod cannot be changed." It's while loading Kernel-eem.10651... On Thu, Mar 30, 2017 at 9:32 PM, Eliot Miranda <[hidden email]> wrote: > Hi All, > > I'm very sorry to report that my recent changes (adding CompiledCode and > CompiledBlock to the CompiledMethod hierarchy in anticipation of full > blocks, and merging ContextPart and MethodContext and renaming them as > Context, to eliminate obsolete block and closer implementations) has broken > the update process. I do not believe there is an easy fix as i think the > issues are to do with the citations that exist on the stack while the update > proceeds (the progress indicators). > > There is a clumsy work-around that appears reliable. The pauses between > loads get rid of the progress indication activations and hence avoid trying > to upgrade running processes through these kernel changes. > > Open the trunk repository from your Monticello Browser. > Locate the update package (the penultimate entry in the list of packages). > Load (or merge) update-eem.400.mcm. > Load (or merge) update-eem.403.mcm. > Load (or merge) update-eem.406.mcm. Save your image. > Local the Kernel package. > Load Kernel-eem.1078. Save your image. > Update > > I'm so sorry. > Eliot > > > |
I'd like to make a contribution to Squeak, but I'm stuck dead in the
water; can't update. Would someone who has gotten past this please upload a new clean trunk image to our ftp site? Eliot? Thanks. On Tue, Apr 4, 2017 at 2:31 PM, Chris Muller <[hidden email]> wrote: > When I try to load update-eem.400.mcm, I am getting an error, > "CompiledMethod cannot be changed." > > It's while loading Kernel-eem.10651... > > On Thu, Mar 30, 2017 at 9:32 PM, Eliot Miranda <[hidden email]> wrote: >> Hi All, >> >> I'm very sorry to report that my recent changes (adding CompiledCode and >> CompiledBlock to the CompiledMethod hierarchy in anticipation of full >> blocks, and merging ContextPart and MethodContext and renaming them as >> Context, to eliminate obsolete block and closer implementations) has broken >> the update process. I do not believe there is an easy fix as i think the >> issues are to do with the citations that exist on the stack while the update >> proceeds (the progress indicators). >> >> There is a clumsy work-around that appears reliable. The pauses between >> loads get rid of the progress indication activations and hence avoid trying >> to upgrade running processes through these kernel changes. >> >> Open the trunk repository from your Monticello Browser. >> Locate the update package (the penultimate entry in the list of packages). >> Load (or merge) update-eem.400.mcm. >> Load (or merge) update-eem.403.mcm. >> Load (or merge) update-eem.406.mcm. Save your image. >> Local the Kernel package. >> Load Kernel-eem.1078. Save your image. >> Update >> >> I'm so sorry. >> Eliot >> >> >> |
In reply to this post by Chris Muller-3
What does the following expression print before you try to merge (you must
merge if you already have the changes in your image)? ((MCMcmUpdater registry at: 'http://source.squeak.org/trunk') at: 'update') lastUpdateMap associations Levete On Tue, 4 Apr 2017, Chris Muller wrote: > When I try to load update-eem.400.mcm, I am getting an error, > "CompiledMethod cannot be changed." > > It's while loading Kernel-eem.10651... > > On Thu, Mar 30, 2017 at 9:32 PM, Eliot Miranda <[hidden email]> wrote: >> Hi All, >> >> I'm very sorry to report that my recent changes (adding CompiledCode and >> CompiledBlock to the CompiledMethod hierarchy in anticipation of full >> blocks, and merging ContextPart and MethodContext and renaming them as >> Context, to eliminate obsolete block and closer implementations) has broken >> the update process. I do not believe there is an easy fix as i think the >> issues are to do with the citations that exist on the stack while the update >> proceeds (the progress indicators). >> >> There is a clumsy work-around that appears reliable. The pauses between >> loads get rid of the progress indication activations and hence avoid trying >> to upgrade running processes through these kernel changes. >> >> Open the trunk repository from your Monticello Browser. >> Locate the update package (the penultimate entry in the list of packages). >> Load (or merge) update-eem.400.mcm. >> Load (or merge) update-eem.403.mcm. >> Load (or merge) update-eem.406.mcm. Save your image. >> Local the Kernel package. >> Load Kernel-eem.1078. Save your image. >> Update >> >> I'm so sorry. >> Eliot >> >> >> |
It's already at '401'...
{'http://source.squeak.org/trunk'->401} On Tue, Apr 4, 2017 at 3:05 PM, Levente Uzonyi <[hidden email]> wrote: > What does the following expression print before you try to merge (you must > merge if you already have the changes in your image)? > > ((MCMcmUpdater registry at: 'http://source.squeak.org/trunk') at: 'update') > lastUpdateMap associations > > Levete > > > On Tue, 4 Apr 2017, Chris Muller wrote: > >> When I try to load update-eem.400.mcm, I am getting an error, >> "CompiledMethod cannot be changed." >> >> It's while loading Kernel-eem.10651... >> >> On Thu, Mar 30, 2017 at 9:32 PM, Eliot Miranda <[hidden email]> >> wrote: >>> >>> Hi All, >>> >>> I'm very sorry to report that my recent changes (adding CompiledCode >>> and >>> CompiledBlock to the CompiledMethod hierarchy in anticipation of full >>> blocks, and merging ContextPart and MethodContext and renaming them as >>> Context, to eliminate obsolete block and closer implementations) has >>> broken >>> the update process. I do not believe there is an easy fix as i think the >>> issues are to do with the citations that exist on the stack while the >>> update >>> proceeds (the progress indicators). >>> >>> There is a clumsy work-around that appears reliable. The pauses between >>> loads get rid of the progress indication activations and hence avoid >>> trying >>> to upgrade running processes through these kernel changes. >>> >>> Open the trunk repository from your Monticello Browser. >>> Locate the update package (the penultimate entry in the list of >>> packages). >>> Load (or merge) update-eem.400.mcm. >>> Load (or merge) update-eem.403.mcm. >>> Load (or merge) update-eem.406.mcm. Save your image. >>> Local the Kernel package. >>> Load Kernel-eem.1078. Save your image. >>> Update >>> >>> I'm so sorry. >>> Eliot >>> >>> >>> > |
In reply to this post by Chris Muller-3
update-eem.400.mcm may be going back too far, I think I got past the
problem by starting with update-eem.403. Basically, if you can get up to the update-eem.406.mcm level, then manually load Kernel-eem.1078, you should be back in business. But we do need to get the update stream fixed. We have a couple of ideas bouncing around in emails, but as far as I know we don't yet have a working solution. Dave > When I try to load update-eem.400.mcm, I am getting an error, > "CompiledMethod cannot be changed." > > It's while loading Kernel-eem.10651... > > On Thu, Mar 30, 2017 at 9:32 PM, Eliot Miranda <[hidden email]> > wrote: >> Hi All, >> >> I'm very sorry to report that my recent changes (adding CompiledCode >> and >> CompiledBlock to the CompiledMethod hierarchy in anticipation of full >> blocks, and merging ContextPart and MethodContext and renaming them as >> Context, to eliminate obsolete block and closer implementations) has >> broken >> the update process. I do not believe there is an easy fix as i think >> the >> issues are to do with the citations that exist on the stack while the >> update >> proceeds (the progress indicators). >> >> There is a clumsy work-around that appears reliable. The pauses between >> loads get rid of the progress indication activations and hence avoid >> trying >> to upgrade running processes through these kernel changes. >> >> Open the trunk repository from your Monticello Browser. >> Locate the update package (the penultimate entry in the list of >> packages). >> Load (or merge) update-eem.400.mcm. >> Load (or merge) update-eem.403.mcm. >> Load (or merge) update-eem.406.mcm. Save your image. >> Local the Kernel package. >> Load Kernel-eem.1078. Save your image. >> Update >> >> I'm so sorry. >> Eliot >> >> >> > > |
That appears to have worked.
Thank you Dave and Levente! On Tue, Apr 4, 2017 at 3:11 PM, David T. Lewis <[hidden email]> wrote: > update-eem.400.mcm may be going back too far, I think I got past the > problem by starting with update-eem.403. Basically, if you can get up to > the update-eem.406.mcm level, then manually load Kernel-eem.1078, you > should be back in business. > > But we do need to get the update stream fixed. We have a couple of ideas > bouncing around in emails, but as far as I know we don't yet have a > working solution. > > Dave > > >> When I try to load update-eem.400.mcm, I am getting an error, >> "CompiledMethod cannot be changed." >> >> It's while loading Kernel-eem.10651... >> >> On Thu, Mar 30, 2017 at 9:32 PM, Eliot Miranda <[hidden email]> >> wrote: >>> Hi All, >>> >>> I'm very sorry to report that my recent changes (adding CompiledCode >>> and >>> CompiledBlock to the CompiledMethod hierarchy in anticipation of full >>> blocks, and merging ContextPart and MethodContext and renaming them as >>> Context, to eliminate obsolete block and closer implementations) has >>> broken >>> the update process. I do not believe there is an easy fix as i think >>> the >>> issues are to do with the citations that exist on the stack while the >>> update >>> proceeds (the progress indicators). >>> >>> There is a clumsy work-around that appears reliable. The pauses between >>> loads get rid of the progress indication activations and hence avoid >>> trying >>> to upgrade running processes through these kernel changes. >>> >>> Open the trunk repository from your Monticello Browser. >>> Locate the update package (the penultimate entry in the list of >>> packages). >>> Load (or merge) update-eem.400.mcm. >>> Load (or merge) update-eem.403.mcm. >>> Load (or merge) update-eem.406.mcm. Save your image. >>> Local the Kernel package. >>> Load Kernel-eem.1078. Save your image. >>> Update >>> >>> I'm so sorry. >>> Eliot >>> >>> >>> >> >> > > > |
In reply to this post by David T. Lewis
> But we do need to get the update stream fixed. We have a couple of ideas
> bouncing around in emails, but as far as I know we don't yet have a > working solution. What about hard-coding Eliots "clumsy workaround" solution into MCMcmUpdater? |
In reply to this post by David T. Lewis
Specifically, Nicolas made a suggestion here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193908.html And Eliot suggested (sorry I don't have the link) the idea of making the update stream smart enough to restart the update process at certain marked points. I looked at the updater a bit last weekend, and I'm not sure that the "restart the update process" approach will actually handle this problem (though I would be happy to be wrong). So maybe Nicolas' idea will work out? Quoting from his earlier message: >> maybe an option is to detach the Context* classes from the >> SystemDictionary in some preamble so that they are immune >> to any refactoring while still in use... Dave > update-eem.400.mcm may be going back too far, I think I got past the > problem by starting with update-eem.403. Basically, if you can get up to > the update-eem.406.mcm level, then manually load Kernel-eem.1078, you > should be back in business. > > But we do need to get the update stream fixed. We have a couple of ideas > bouncing around in emails, but as far as I know we don't yet have a > working solution. > > Dave > > >> When I try to load update-eem.400.mcm, I am getting an error, >> "CompiledMethod cannot be changed." >> >> It's while loading Kernel-eem.10651... >> >> On Thu, Mar 30, 2017 at 9:32 PM, Eliot Miranda <[hidden email]> >> wrote: >>> Hi All, >>> >>> I'm very sorry to report that my recent changes (adding >>> CompiledCode >>> and >>> CompiledBlock to the CompiledMethod hierarchy in anticipation of full >>> blocks, and merging ContextPart and MethodContext and renaming them as >>> Context, to eliminate obsolete block and closer implementations) has >>> broken >>> the update process. I do not believe there is an easy fix as i think >>> the >>> issues are to do with the citations that exist on the stack while the >>> update >>> proceeds (the progress indicators). >>> >>> There is a clumsy work-around that appears reliable. The pauses >>> between >>> loads get rid of the progress indication activations and hence avoid >>> trying >>> to upgrade running processes through these kernel changes. >>> >>> Open the trunk repository from your Monticello Browser. >>> Locate the update package (the penultimate entry in the list of >>> packages). >>> Load (or merge) update-eem.400.mcm. >>> Load (or merge) update-eem.403.mcm. >>> Load (or merge) update-eem.406.mcm. Save your image. >>> Local the Kernel package. >>> Load Kernel-eem.1078. Save your image. >>> Update >>> >>> I'm so sorry. >>> Eliot >>> >>> >>> >> >> > > |
Hi David,
On Tue, Apr 4, 2017 at 1:23 PM, David T. Lewis <[hidden email]> wrote: Specifically, Nicolas made a suggestion here: Not possible. With an exception system in the image it is vital that messages be sent to contexts. But I think we can do one of two things to lessen the impact: One thing is that right now on most of our work machines, which means most of the machines upon which we do our updating, the compilation part of updating is really fast, so reporting progress isn't probably very important here. In fact what we could do is only report progress graphically while downloading packages. That way much of the graphics subsystem and complex exception notification part of the progress notification would not be active when compiling and installing the package. If we did this I don't think my "be able to mark an update as requiring a restart of the update system" suggestion would be necessary at all. We could put in a hack such that if any of a small number of packages were being updated, the update process would be updated automatically, say Kernel, System, Graphics. But this is a real hack. Personally I like the idea of only updating progress while downloading files, and then during installation updating progress only between package installs. As I discussed (alas off list) a better solution may to allow an update map to specify that the update process should be restarted, so that all active process state is discarded at some point during an update. Of course these ideas need to be tested in the context of the 400 through 408 updates. Am I right to think that if one has an image at a specific update and then loads a much newer version of a package (i.e. MonticelloConfigurations) that the update will never revert, right? Or is merge a preference (or should it be)?
_,,,^..^,,,_ best, Eliot |
On Tue, Apr 04, 2017 at 02:22:07PM -0700, Eliot Miranda wrote:
> Hi David, > > On Tue, Apr 4, 2017 at 1:23 PM, David T. Lewis <[hidden email]> wrote: > > > Specifically, Nicolas made a suggestion here: > > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017- > > March/193908.html > > > > And Eliot suggested (sorry I don't have the link) the idea of making the > > update stream smart enough to restart the update process at certain marked > > points. > > > > I looked at the updater a bit last weekend, and I'm not sure that the > > "restart the update process" approach will actually handle this problem > > (though I would be happy to be wrong). So maybe Nicolas' idea will work > > out? Quoting from his earlier message: > > > > >> maybe an option is to detach the Context* classes from the > > >> SystemDictionary in some preamble so that they are immune > > >> to any refactoring while still in use... > > > > Not possible. With an exception system in the image it is vital that > messages be sent to contexts. Ok. > > But I think we can do one of two things to lessen the impact: > > One thing is that right now on most of our work machines, which means most > of the machines upon which we do our updating, the compilation part of > updating is really fast, so reporting progress isn't probably very > important here. In fact what we could do is only report progress > graphically while downloading packages. That way much of the graphics > subsystem and complex exception notification part of the progress > notification would not be active when compiling and installing the package. > If we did this I don't think my "be able to mark an update as requiring a > restart of the update system" suggestion would be necessary at all. > > We could put in a hack such that if any of a small number of packages were > being updated, the update process would be updated automatically, say > Kernel, System, Graphics. But this is a real hack. > > Personally I like the idea of only updating progress while downloading > files, and then during installation updating progress only between package > installs. Sounds good to me, we just need someone to make it happen :-) > > As I discussed (alas off list) a better solution may to allow an update map > to specify that the update process should be restarted, so that all active > process state is discarded at some point during an update. That sounded like a simple solution to me, but after looking at the update process from within a debugger, I do not know how to make it work. > > Of course these ideas need to be tested in the context of the 400 through > 408 updates. Am I right to think that if one has an image at a specific > update and then loads a much newer version of a package (i.e. > MonticelloConfigurations) that the update will never revert, right? Or is > merge a preference (or should it be)? > I don't know, but I believe that it is the case that if someone can come up with a way to make MonticelloConfigurations work with any of the ideas described above, then that newer version of MonticelloConfigurations could be patched into an earlier update map such that the trunk update stream would start working again. Dave |
In reply to this post by Eliot Miranda-2
On Tue, Apr 4, 2017 at 11:22 PM, Eliot Miranda <[hidden email]> wrote:
Yes, by default the updater will not load/merge a package if it is already in the ancestry.
Loading can be forced by disabling the upgradeIsMerge preference. - Bert - |
In reply to this post by David T. Lewis
On Wed, Apr 5, 2017 at 3:49 AM, David T. Lewis <[hidden email]> wrote:
I tried that, see MonticelloConfigurations-bf.152 in inbox. Update still crashes after 406 when loading Kernel-eem.1078. - Bert - |
It seems that some people have managed to work around the issues of
the broken update and now have an updated image. Is it possible such a fully updated image and changes file for the meantime in http://files.squeak.org/6.0alpha/ ? --Hannes On 4/5/17, Bert Freudenberg <[hidden email]> wrote: > On Wed, Apr 5, 2017 at 3:49 AM, David T. Lewis <[hidden email]> wrote: > >> >> > Personally I like the idea of only updating progress while downloading >> > files, and then during installation updating progress only between >> package >> > installs. >> >> Sounds good to me, we just need someone to make it happen :-) >> > > I tried that, see MonticelloConfigurations-bf.152 in inbox. Update still > crashes after 406 when loading Kernel-eem.1078. > > - Bert - > |
On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel <[hidden email]> wrote: It seems that some people have managed to work around the issues of No. It's easy enough to follow Eliots instructions to get past the bump, but let's fix it properly. We can't leave the update stream broken. - Bert - |
*Not* easy.
You were lucky applying the instructions. The first time I did it I had a walkback. The second time starting with http://files.squeak.org/6.0alpha/Squeak6.0alpha-17086-32bit/ the process stalls while applying 'Installing Kernel-eem.1083'. On 4/5/17, Bert Freudenberg <[hidden email]> wrote: > On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel <[hidden email]> wrote: > >> It seems that some people have managed to work around the issues of >> the broken update and now have an updated image. >> >> Is it possible such a fully updated image and changes file for the >> meantime in >> http://files.squeak.org/6.0alpha/ ? > > > No. It's easy enough to follow Eliots instructions to get past the bump, > but let's fix it properly. We can't leave the update stream broken. > > - Bert - > |
That's a very valuable data point. It means Eliot's reasoning is incomplete.
- Bert - PS: I have no time to work on this anymore today. On Wed, Apr 5, 2017 at 5:21 PM, H. Hirzel <[hidden email]> wrote: *Not* easy. |
In reply to this post by Hannes Hirzel
It's because you have to update your image till 399.mcm first. I presume
you just skipped that and loaded 400.mcm right into that image. Levente On Wed, 5 Apr 2017, H. Hirzel wrote: > *Not* easy. > > You were lucky applying the instructions. > > The first time I did it I had a walkback. > > The second time starting with > http://files.squeak.org/6.0alpha/Squeak6.0alpha-17086-32bit/ > the process stalls while applying 'Installing Kernel-eem.1083'. > > On 4/5/17, Bert Freudenberg <[hidden email]> wrote: >> On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel <[hidden email]> wrote: >> >>> It seems that some people have managed to work around the issues of >>> the broken update and now have an updated image. >>> >>> Is it possible such a fully updated image and changes file for the >>> meantime in >>> http://files.squeak.org/6.0alpha/ ? >> >> >> No. It's easy enough to follow Eliots instructions to get past the bump, >> but let's fix it properly. We can't leave the update stream broken. >> >> - Bert - >> |
On 4/5/17, Levente Uzonyi <[hidden email]> wrote:
> It's because you have to update your image till 399.mcm first. I presume > you just skipped that and loaded 400.mcm right into that image. Thank you, Levent. And how to I update 17086 to 399.mcm only? The screen shot shows the situation *not* doing this before loading 400.mcm --Hannes > Levente > > On Wed, 5 Apr 2017, H. Hirzel wrote: > >> *Not* easy. >> >> You were lucky applying the instructions. >> >> The first time I did it I had a walkback. >> >> The second time starting with >> http://files.squeak.org/6.0alpha/Squeak6.0alpha-17086-32bit/ >> the process stalls while applying 'Installing Kernel-eem.1083'. >> >> On 4/5/17, Bert Freudenberg <[hidden email]> wrote: >>> On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel <[hidden email]> >>> wrote: >>> >>>> It seems that some people have managed to work around the issues of >>>> the broken update and now have an updated image. >>>> >>>> Is it possible such a fully updated image and changes file for the >>>> meantime in >>>> http://files.squeak.org/6.0alpha/ ? >>> >>> >>> No. It's easy enough to follow Eliots instructions to get past the bump, >>> but let's fix it properly. We can't leave the update stream broken. >>> >>> - Bert - >>> > > Squeak6.0a_17086_updateing_Screenshot_2017-04-05.png (329K) Download Attachment |
Free forum by Nabble | Edit this page |