Hi Nicolas,

On Sat, Apr 8, 2017 at 8:56 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 2017-04-08 17:29 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com>:
>
>>
>>
>> 2017-04-08 17:14 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>> l.com>:
>>
>>>
>>>
>>> 2017-04-08 14:09 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:
>>>
>>>> On Sat, Apr 08, 2017 at 01:59:34PM +0200, Nicolas Cellier wrote:
>>>> > 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 :(
>>>> >
>>>>
>>>> Nicolas,
>>>>
>>>> Thanks very much for working on this and for posting your results so
>>>> far.
>>>> This is not an easy problem to solve.
>>>>
>>>> Dave
>>>>
>>>>
>>>> Hi Dave,
>>> don't worry, real show stopper obstacles are rare, the rest of them make
>>> the game more fun ;)
>>> So I've put the halt in MethodContext class>>removeSelector:  in a
>>> *Debug protocol so as to keep Kernel clean, and I've now got the stack at
>>> the point of removing what should not be removed.
>>>
>>> It's in MCDiffyVersion load -> MCVersionLoader load -> MCPackageLoader
>>> load.
>>>
>>> There's a bunch of removals, starting with:
>>>
>>> an OrderedCollection(a MCMethodDefinition(MethodContext>>unwindTo:)
>>> a MCMethodDefinition(MethodContext>>tryPrimitiveFor:receiver:args:)
>>> a MCMethodDefinition(MethodContext>>tryNamedPrimitiveIn:for:withArgs:)
>>> a MCMethodDefinition(MethodContext>>top)
>>> a MCMethodDefinition(MethodContext>>terminateTo:) ...
>>>
>>> So yes, this mcd is going to shoot the update process.
>>> Why is it different from the load or merge triggered manually?
>>> Can't we avoid all the method removals and keep only the class removal?
>>>
>>> I can try this snippet in the MCPackageLoader to reject some superfluous
>>> method removals:
>>>
>>> |  removedClasses |
>>> removedClasses := (removals select: #isClassDefinition) collect:
>>> #actualClass.
>>> removedClasses addAll: (removedClasses collect: #class).
>>> removals := removals reject: [:e | e isMethodDefinition and:
>>> [removedClasses includes: e actualClass]]
>>>
>>> Is it OK as a general change in MC?
>>>
>>> Then I'm not sure how it's going to work, because at this stage, Context
>>> is still a subclass of ContextPart as I told before (though it has a
>>> different superclass), and #MethodContext is still pointing to Context, so
>>> removing either one or the other is going to lead to problems again...
>>>
>>> So two more hacks might be necessary:
>>>
>>> [Smalltalk globals at: #MethodContext put: Context copy] on:
>>> AttemptToWriteReadOnlyGlobal do: [:exc | exc resume: true].
>>>
>>> ContextPart instVarAt: 6 put: (ContextPart subclasses select: [:e | e
>>> superclass = ContextPart]).
>>>
>>> Finally, with the 2nd hack, maybe I don't need to forget the superfluous
>>> method removals.
>>> However, it failed when I tried, so I've uploaded a Monticello-nice.667
>>> with the hack, and triggered its download in update-eem.406.mcm
>>> Not sure if it is really necessary...
>>>
>>> Now the update is still failing with an emergency evalutator, and this
>>> time it seems to be related to the progress bar with an obsolete block
>>> still pointing to MethodContext.
>>>
>>> ...snip...
>>> UndefinedObject>>handleSignal:
>>> Context(nil)>>handleSignal:
>>> Context(nil)>>handleSignal:
>>> Context(nil)>>handleSignal:
>>> Context(nil)>>handleSignal:
>>>
>>> I will retry with Bert's hack.
>>> This update hickup is a tough one.
>>>
>>
>> And Bert's hack is not enough. So another possibility would be to move
>> #MethodContext -> Context binding in Undeclared.
>> Undeclared shouldn't auto-clean as long as obsolete block pointing to
>> MethodContext are still on the stack.
>> I'm going to try this.
>>
>
> Ah yes, this time it worked for me.
> Someone want to try and confirm?
>

There is one wrinkle.  When one updates an image that has been manually
updated past Kernel-em.1078 then the preamble script in Squeak-Version
fails:

DoIt
Smalltalk globals unbind: #MethodContext.
[Undeclared at: #MethodContext put: Context copy]
on: AttemptToWriteReadOnlyGlobal
do: [:t1 | t1 resume: true].
^ ContextPart
instVarAt: 6
put: (ContextPart subclasses
select: [:t1 | t1 superclass = ContextPart])

The instVarAt: 6 put: fails because COntextPart is Undeclared and nil.  So
better to write it as

DoIt
Smalltalk globals unbind: #MethodContext.
[Undeclared at: #MethodContext put: Context copy]
on: AttemptToWriteReadOnlyGlobal
do: [:t1 | t1 resume: true].
ContextPart ifNil: [^self].
ContextPart isBehavior ifFalse: [^self].
^ ContextPart
instVarAt: 6
put: (ContextPart subclasses
select: [:t1 | t1 superclass = ContextPart])



(And anyone else hitting this just use "return entered value" with nil or
self to proceed.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170408/31926d58/attachment.html>