There's yet another possibility, in a preamble:
- clone the old SystemProgressMorph class,
- mutate all instances to the clone class

Don't use class rename and class removal, because the system will do too
much clean up.
instead hack at a lower level

2016-08-23 4:03 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:

> On Mon, Aug 22, 2016 at 02:36:09PM +0200, Bert Freudenberg wrote:
> > Seen it, discussed with Marcel but we don't have a good idea yet how to
> > work around it.
> >
> > The only thing I can think of is to walk up the sender chain and restart
> > some context above the one referencing the old instance layout. Maybe an
> > exception handler in the updater that restarts updating in this specific
> > case?
> >
> > - Bert -
> >
>
> I don't see a good place to put an exception handler, at least not without
> making things even more complicated than they already are.
>
> It looks like the the direct reference to instance var 'bars' is where we
> encounter the problem. Presumably the old code in a block is refering to
> an ivar slot in SystemProgressMorph that used to point to the 'vars' array,
> but that is now pointing to the 'font' ivar.
>
> And indeed I see now that Marcel found and fixed this issue in
> Morphic-mt.1198,
> so that accessor methods will now be used instead of direct references to
> the variables.
>
> But we still have the problem of a SystemProgressMorph evaluating an older
> block that was created with an earlier version of the
> SystemProgressMorph>>position:label:min:max: method, so the update stream
> processing still fails if the update processing was started before
> Morphic-mt.1198 was loaded.
>
> A partial workaround is to modify #position:label:min:max: to use an
> accessor
> for 'bars' prior to starting the update processing. This prevents the error
> condition that we are discussing here, but unfortunately it also results
> in a couple of merge dialogs for the modified methods, so the update still
> requires manual intervention.
>
> Dave
>
>
> >
> > On Sun, Aug 21, 2016 at 10:55 PM, Levente Uzonyi <leves at caesar.elte.hu>
> > wrote:
> >
> > >
> > > Same here. I think the code changes during the update and the old code
> on
> > > the stack causes the problem.
> > >
> > > Levente
> > >
> > >
> > > On Sun, 21 Aug 2016, Chris Muller wrote:
> > >
> > >
> > >> I've definitely experienced the exact same problem, and got around it
> > >> the same way, restarting the method and proceeding.  Very strange.
> > >>
> > >>
> > >> On Sun, Aug 21, 2016 at 3:13 PM, David T. Lewis <lewis at mail.msen.com>
> > >> wrote:
> > >>
> > >>>
> > >>> Moving from vm-dev to squeak-dev because it is a trunk update stream
> > >>> question.
> > >>> Follow ups to squeak-dev please.
> > >>>
> > >>> Does anyone recognize this problem?
> > >>>
> > >>> We have an issue in trunk update processing that prevents a full
> update
> > >>> without manual intervention. This does not affect the 5.1 release,
> but
> > >>> it would be good to fix it so that the update from 5.0 to 5.1 can be
> > >>> reproduced in a continuous integration test.
> > >>>
> > >>> To reproduce: Start with Squeak5.0-15113.image, set the update URL
> > >>> preference
> > >>> to http://source.squeak.org/trunk, and do an "update from server".
> > >>>
> > >>> The error first appears when beginning to process the
> update-mt.378.mcm
> > >>> update map. The problem is related to updating the progress bar with
> > >>> ProgressInitiationException.
> > >>>
> > >>> When the failure occurs, the debugger (see attached image) seems to
> > >>> show an array access being interpreted as if the array was an
> instance
> > >>> of StrikeFont. Per Nicolas' note below, it may be related to showing
> > >>> the progress bar while updating it.
> > >>>
> > >>> I can restart the update process from the debugger from
> > >>> SystemProgressMorph>>position:label:min:max: in the stack frame,
> and the
> > >>> update proceeds. The error happens several more times, then at some
> point
> > >>> it seems to go away, so apparently the problem was fixed at some
> later
> > >>> point in the update stream.
> > >>>
> > >>> Does anyone recognize this problem? Can we work around it by
> changing one
> > >>> or more of the update maps?
> > >>>
> > >>> Thanks,
> > >>> Dave
> > >>>
> > >>>
> > >>> On Fri, Aug 19, 2016 at 10:30:30PM +0200, Nicolas Cellier wrote:
> > >>>
> > >>>>
> > >>>> yes, this is a problem I encountered both in 32 and 64 bits squeak
> while
> > >>>> updating.
> > >>>>
> > >>>> I think it's related to showing the progress bar while updating the
> > >>>> progress bar. It's a Squeak trunk update problem, not a VM problem.
> > >>>>
> > >>>> If some class layout change, but some block is still active (yeah,
> did
> > >>>> you
> > >>>> see how many blocks we traverse just to change display of a bar...),
> > >>>> then
> > >>>> the old block has invalid inst var offsets (offsets to the old
> object
> > >>>> that
> > >>>> now has become a new object with new layout).
> > >>>>
> > >>>> In an interactive image, just close the debugger and relaunch the
> > >>>> update.
> > >>>> In an headless automated process, well... We should have fixed the
> > >>>> update
> > >>>> or start from a newer artifact...
> > >>>>
> > >>>> 2016-08-19 21:32 GMT+02:00 tim Rowledge <tim at rowledge.org>:
> > >>>>
> > >>>>>
> > >>>>> I just tried running the vmmaker-build script on my iMac with
> weirdly
> > >>>>> bad
> > >>>>> results.
> > >>>>>
> > >>>>> The vm it downloads is the CogSpur.app-16.18.3692 version. Whilst
> > >>>>> trying
> > >>>>> to do the update part of the process I had several *very* odd
> failures
> > >>>>> where an object in a block was mistaken for nil during a message
> send.
> > >>>>> For
> > >>>>> example in a progress bar update (which I can???t provide a log for
> > >>>>> since the
> > >>>>> log got overwritten later) a line
> > >>>>> (bars at: index)
> > >>>>> lead to a nil is not indexable halt. Yet in inspecting the prior
> > >>>>> stackframe the bars object was a perfectly normal array of progress
> > >>>>> bars. A
> > >>>>> similar but not identical problem happened during another attempt.
> > >>>>>
> > >>>>> Attempting to filein the BuildSqueakSpurTrunkVMMaker.st file failed
> > >>>>> when
> > >>>>> the vm exploded with no visible log.
> > >>>>>
> > >>>>> Now I???m attempting to repeat that with a new 5.1rc1 vm & already
> up
> > >>>>> to
> > >>>>> date 5.1rc1 image. Which has sorta-worked, in a rather odd manner.
> It
> > >>>>> got
> > >>>>> to the final save and quit but when I start the supposedly prepared
> > >>>>> image
> > >>>>> there is a problem with it trying to filein that file. I can???t
> tell
> > >>>>> right
> > >>>>> now if it relates to the manual filein I started or if something
> got
> > >>>>> added
> > >>>>> as a deferred action? Or maybe it???s a side-effect of the filein
> > >>>>> having a
> > >>>>> save & quit? Not come across this before.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> So far as I can tell it did complete the filein, so maybe all is
> well.
> > >>>>>
> > >>>>>
> > >>>
> > >>
>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160823/4db889e9/attachment.htm