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 itself
http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-August/191722.ht...
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 eliot.miranda@gmail.com:
Hi All,
I'm very sorry to report that my recent changes (adding CompiledCodeand 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
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 eliot.miranda@gmail.com wrote:
Hi All,
I'm very sorry to report that my recent changes (adding CompiledCode andCompiledBlock 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 asqueaker@gmail.com 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 eliot.miranda@gmail.com wrote:
Hi All,
I'm very sorry to report that my recent changes (adding CompiledCode andCompiledBlock 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
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 eliot.miranda@gmail.com wrote:
Hi All,
I'm very sorry to report that my recent changes (adding CompiledCode andCompiledBlock 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%27-%3E401%7D
On Tue, Apr 4, 2017 at 3:05 PM, Levente Uzonyi leves@caesar.elte.hu 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 eliot.miranda@gmail.com wrote:
Hi All,
I'm very sorry to report that my recent changes (adding CompiledCodeand 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
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 eliot.miranda@gmail.com wrote:
Hi All,
I'm very sorry to report that my recent changes (adding CompiledCodeand 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 lewis@mail.msen.com 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 eliot.miranda@gmail.com wrote:
Hi All,
I'm very sorry to report that my recent changes (adding CompiledCodeand 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
Specifically, Nicolas made a suggestion here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193908.htm...
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 eliot.miranda@gmail.com wrote:
Hi All,
I'm very sorry to report that my recent changes (addingCompiledCode 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 lewis@mail.msen.com 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.
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)?
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 <eliot.miranda@gmail.com
wrote:
Hi All,
I'm very sorry to report that my recent changes (addingCompiledCode 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
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 lewis@mail.msen.com 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
On Wed, Apr 5, 2017 at 3:49 AM, David T. Lewis lewis@mail.msen.com 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 -
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 bert@freudenbergs.de wrote:
On Wed, Apr 5, 2017 at 3:49 AM, David T. Lewis lewis@mail.msen.com 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 hannes.hirzel@gmail.com 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 -
*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 bert@freudenbergs.de wrote:
On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel hannes.hirzel@gmail.com 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 hannes.hirzel@gmail.com 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 bert@freudenbergs.de wrote:
On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel hannes.hirzel@gmail.com
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 -
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 bert@freudenbergs.de wrote:
On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel hannes.hirzel@gmail.com 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 leves@caesar.elte.hu 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 bert@freudenbergs.de wrote:
On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel hannes.hirzel@gmail.com 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 -
I started again with a pristine image again from http://files.squeak.org/6.0alpha/Squeak6.0alpha-17086-32bit/
By reading Update stream http://wiki.squeak.org/squeak/3154
I was directed to class MCMcmUpdater
After having a look at the code of this class I did
MCMcmUpdater default lastUpdateMap
and got
a Dictionary('http://source.squeak.org/trunk%27-%3E402 )
Which is more than the 399 you recommend and the 400 Eliot recommends to start with. [1]
Do I need to start with an earlier version? If yes, which one?
--Hannes
[1] Instructions by Eliot M. to do the manual update http://forum.world.st/Broken-trunk-update-and-workaround-td4940633.html (= the start of this thread)
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
On 4/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:
On 4/5/17, Levente Uzonyi leves@caesar.elte.hu 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 bert@freudenbergs.de wrote:
On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel hannes.hirzel@gmail.com 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 -
I've never tried to update an image past 399, but if your image is at 402, then I suggest you load 403, then 406.
Levente
On Wed, 5 Apr 2017, H. Hirzel wrote:
I started again with a pristine image again from http://files.squeak.org/6.0alpha/Squeak6.0alpha-17086-32bit/
By reading Update stream http://wiki.squeak.org/squeak/3154
I was directed to class MCMcmUpdater
After having a look at the code of this class I did
MCMcmUpdater default lastUpdateMapand got
a Dictionary('http://source.squeak.org/trunk%27-%3E402 )
Which is more than the 399 you recommend and the 400 Eliot recommends to start with. [1]
Do I need to start with an earlier version? If yes, which one?
--Hannes
[1] Instructions by Eliot M. to do the manual update http://forum.world.st/Broken-trunk-update-and-workaround-td4940633.html (= the start of this thread)
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
On 4/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:
On 4/5/17, Levente Uzonyi leves@caesar.elte.hu 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 bert@freudenbergs.de wrote:
On Wed, Apr 5, 2017 at 4:55 PM, H. Hirzel hannes.hirzel@gmail.com 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 -
Thank you, Levente, for this valuable hint :-)
This paved the road to sucess!
The following process now has worked for me (adapted from Eliot's instructions)
1) Download http://files.squeak.org/6.0alpha/Squeak6.0alpha-17086-32bit/
2) Verify the last update map loaded by opening a Workspace. Then evaluate MCMcmUpdater default lastUpdateMap This gives me 'http://source.squeak.org/trunk%27-%3E402
3) Open a Monticello Browser and and click on 'http://source.squeak.org/trunk'; click 'Open'
4) Locate the second to last entry called 'update' and there 'update-eem.403.mcm' (see attachment); click on 'Load'
5) Load (or merge) update-eem.406.mcm.
6) Save your image.
7) Locate the Kernel package and click on 'Kernel-eem.1078'; "Load"
8) Save your image.
9) Choose 'Update' from the Squeak menu.
RESULT ------------
As of today this got me to version #17138
--Hannes
Accidentally, my images (both 32 & 64 bits) were at 399.mcm, and the update went smoothly (well except a manual resolution of merge). I'll have to download an older version to see how update fail...
2017-04-05 20:44 GMT+02:00 H. Hirzel hannes.hirzel@gmail.com:
Thank you, Levente, for this valuable hint :-)
This paved the road to sucess!
The following process now has worked for me (adapted from Eliot's instructions)
Download http://files.squeak.org/6.0alpha/Squeak6.0alpha-17086-32bit/
Verify the last update map loaded by opening a Workspace. Then evaluate MCMcmUpdater default lastUpdateMap This gives me 'http://source.squeak.org/trunk%27-%3E402
Open a Monticello Browser and and click on
'http://source.squeak.org/trunk'; click 'Open'
- Locate the second to last entry called 'update' and there
'update-eem.403.mcm' (see attachment); click on 'Load'
Load (or merge) update-eem.406.mcm.
Save your image.
Locate the Kernel package and click on 'Kernel-eem.1078'; "Load"
Save your image.
Choose 'Update' from the Squeak menu.
RESULT
As of today this got me to version #17138
--Hannes
On Wed, Apr 05, 2017 at 04:50:54PM +0200, Bert Freudenberg wrote:
On Wed, Apr 5, 2017 at 3:49 AM, David T. Lewis lewis@mail.msen.com 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.
It does not fix the update stream problem, but reducing the progress bar activity seems to be a good thing in any case.
Dave
On Tue, Apr 4, 2017 at 11:22 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
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?
Yes, by default the updater will not load/merge a package if it is already in the ancestry.
Or is merge a preference (or should it be)?I
Loading can be forced by disabling the upgradeIsMerge preference.
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
David T. Lewis -
Eliot Miranda -
H. Hirzel -
Levente Uzonyi -
Nicolas Cellier