2017-04-08 18:48 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:

> Hi Nicolas,
>
> On Sat, Apr 8, 2017 at 8:56 AM, Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com> wrote:
>
>>
>>
>> 2017-04-08 17:29 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>> l.com>:
>>
>>>
>>>
>>> 2017-04-08 17:14 GMT+02:00 Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.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
>
>
>
Hi Eliot, good idea, that should be fixed now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170408/6b5726b4/attachment.html>