Broken trunk update and workaround

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

Broken trunk update and workaround

Eliot Miranda-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Nicolas Cellier
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.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]>:
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






Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Chris Muller-3
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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Chris Muller-3
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
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Levente Uzonyi
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
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Chris Muller-3
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
>>>
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

David T. Lewis
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
>>
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Chris Muller-3
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
>>>
>>>
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Chris Muller-3
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?

Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

David T. Lewis
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
>>>
>>>
>>>
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Eliot Miranda-2
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.  

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 <[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
>>>
>>>
>>>
>>
>>
>
>






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Bert Freudenberg
In reply to this post by Eliot Miranda-2
On Tue, Apr 4, 2017 at 11:22 PM, Eliot Miranda <[hidden email]> 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 -


Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Bert Freudenberg
In reply to this post by David T. Lewis
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 - 


Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Hannes Hirzel
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 -
>

Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Bert Freudenberg
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 -



Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Hannes Hirzel
*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 -
>

Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Bert Freudenberg
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.

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




Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Levente Uzonyi
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 -
>>

Reply | Threaded
Open this post in threaded view
|

Re: Broken trunk update and workaround

Hannes Hirzel
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
12