Ah, but now that I've put a
    (selector == #unwindTo: and: [ self name = 'Context']) ifTrue:[self
halt: 'debug me'].
I can't reproduce the problem related to removal of Context methods!!!

Instead, I've got the 'Merging Kernel-eem.1078' window with all the
MethodContext->Context renaming in conflict
I already reported that in another thread where I told that the upgrade
went "smoothly" for both my 32 & 64 bits images.
I don't know if it's related to package cache, or .mcd, or ???

It might also be that package ancestry is not correct du to overwriting of
some packages, otherwise we should not get a merge window, but well...

Ah, but now I think I understand: it's just because I have pending changes
in Kernel due to the addition of halt: above (same for my images which
usually have some unpublished experiments).
We then trigger a merge rather than a load. And the merge sees conflict
probably because of broken ancestry (the GUID are not corresponding), but
once resolved manually, it processes smoothly without removing Context
methods...

I can't instrument code that easily... This will have to wait for another
time slot :(

2017-04-08 10:47 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> My finding today is that ContextPart still have a subclass named Context
> after update 406.
>
> ContextPart allSubclasses collect: #superclass.
> -> an OrderedCollection(ContextPart InstructionStream)
>
> So I will put a conditional breakpoint in removeSelector: to identify the
> path that remove the selector and re-launch the update
>
> 2017-04-08 0:45 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>> Ah no, the binding #MethodContext=>Context is still in the Smalltalk
>> globals declarations (and bindings) after update 406.
>> It's not at all in Undeclared. Why is that? Oh, no, it's the
>> bootstrapContext method:
>>
>>     Smalltalk at: #MethodContext ifAbsentPut: [Smalltalk classNamed:
>> #Context].
>>
>> And there are still plenty references to this binding at this stage.
>>
>> So why loading Kernel-eem.1078 manually doesn't do any arm, while loading
>> update-eem.407.mcm does?
>> This time it'll be for tomorrow
>>
>>
>> 2017-04-08 0:21 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>> l.com>:
>>
>>> Ah, but thanks to my previous WeakIdentityDictionary changes, Undeclared
>>> holds weakly to its binding.
>>> And after update 406, the references to MethodContext have already
>>> vanished.
>>> So maybe a simple garbageCollect might help update 407 to proceed
>>> without any problem?
>>>
>>> I've just tried that in a package above Kernel in the configuration
>>> map....
>>> But it does not seems to work. I'll see tomorrow.
>>>
>>> 2017-04-07 23:07 GMT+02:00 Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com>:
>>>
>>>> Hi,
>>>> I tried updating a relatively recent image from:
>>>>
>>>> http://files.squeak.org/6.0alpha/Squeak6.0alpha-16548-32bit/
>>>>
>>>> What happens to me is an unhandled exception MNU Context>>terminateTo:
>>>> during update 407.
>>>>
>>>> Update 407 is loading Kernel.eem.1078 which is storing the new Kernel
>>>> classes (Context rather than MethodContext)
>>>>
>>>> Last change written in the change log is:
>>>>
>>>>     Context removeSelector: #terminateTo:
>>>>
>>>> Oh, but there's no such instruction in Kernel-eem.1078...
>>>> So what happens exactly which told the image to remove some just
>>>> installed Context methods???
>>>>
>>>> What happens before that is the boostrapContext in Kernel-eem.1077
>>>> preamble
>>>>
>>>>     Smalltalk renameClassNamed: #MethodContext as: #Context
>>>>
>>>> And what happens when we rename is in Environment>>renameClass:from:to:
>>>>
>>>>     oldBinding := self declarationOf: oldName.
>>>>     declarations removeKey: oldName.
>>>>     self binding: oldBinding removedFrom: self.
>>>>     " re-route now undeclared oldBinding "
>>>>     oldBinding value: aClass.
>>>>
>>>> That means that we have an Undeclared #MethodeContext => Context.
>>>>
>>>> And what happens when we ask to remove MethodContext class?
>>>> We start removing Context!!!
>>>>
>>>> So what might be necessary is to purgeUndeclared in Kernel-eem.1078
>>>> preamble.
>>>> And it will work if and only if we removed all MethodContext references.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170408/a33421b3/attachment.html>