[squeak-dev] Broken trunk update and workaround

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 4 21:22:07 UTC 2017


Hi David,

On Tue, Apr 4, 2017 at 1:23 PM, David T. Lewis <lewis at 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 at gmail.com
> >
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170404/f50fe6c7/attachment.html>


More information about the Squeak-dev mailing list