<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-04-08 14:09 GMT+02:00 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Sat, Apr 08, 2017 at 01:59:34PM +0200, Nicolas Cellier wrote:<br>
> Ah, but now that I've put a<br>
>     (selector == #unwindTo: and: [ self name = 'Context']) ifTrue:[self<br>
> halt: 'debug me'].<br>
> I can't reproduce the problem related to removal of Context methods!!!<br>
><br>
> Instead, I've got the 'Merging Kernel-eem.1078' window with all the<br>
> MethodContext->Context renaming in conflict<br>
> I already reported that in another thread where I told that the upgrade<br>
> went "smoothly" for both my 32 & 64 bits images.<br>
> I don't know if it's related to package cache, or .mcd, or ???<br>
><br>
> It might also be that package ancestry is not correct du to overwriting of<br>
> some packages, otherwise we should not get a merge window, but well...<br>
><br>
> Ah, but now I think I understand: it's just because I have pending changes<br>
> in Kernel due to the addition of halt: above (same for my images which<br>
> usually have some unpublished experiments).<br>
> We then trigger a merge rather than a load. And the merge sees conflict<br>
> probably because of broken ancestry (the GUID are not corresponding), but<br>
> once resolved manually, it processes smoothly without removing Context<br>
> methods...<br>
><br>
> I can't instrument code that easily... This will have to wait for another<br>
> time slot :(<br>
><br>
<br>
</span>Nicolas,<br>
<br>
Thanks very much for working on this and for posting your results so far.<br>
This is not an easy problem to solve.<br>
<br>
Dave<br>
<br>
<br></blockquote><div>Hi Dave,<br></div><div>don't worry, real show stopper obstacles are rare, the rest of them make the game more fun ;)<br></div><div>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.<br><br></div><div>It's in MCDiffyVersion load -> MCVersionLoader load -> MCPackageLoader load.<br><br></div><div>There's a bunch of removals, starting with:<br><br>an OrderedCollection(a MCMethodDefinition(MethodContext>>unwindTo:)<br>a MCMethodDefinition(MethodContext>>tryPrimitiveFor:receiver:args:)<br>a MCMethodDefinition(MethodContext>>tryNamedPrimitiveIn:for:withArgs:)<br>a MCMethodDefinition(MethodContext>>top)<br>a MCMethodDefinition(MethodContext>>terminateTo:) ...<br><br></div><div>So yes, this mcd is going to shoot the update process.<br>Why is it different from the load or merge triggered manually?<br></div><div>Can't we avoid all the method removals and keep only the class removal?<br><br></div><div>I can try this snippet in the MCPackageLoader to reject some superfluous method removals:<br><br>|  removedClasses |<br>removedClasses := (removals select: #isClassDefinition) collect: #actualClass.<br>removedClasses addAll: (removedClasses collect: #class).<br>removals := removals reject: [:e | e isMethodDefinition and: [removedClasses includes: e actualClass]]<br><br></div><div>Is it OK as a general change in MC?<br><br></div><div>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...<br><br></div><div>So two more hacks might be necessary:<br><br>[Smalltalk globals at: #MethodContext put: Context copy] on: AttemptToWriteReadOnlyGlobal do: [:exc | exc resume: true].<br><br>ContextPart instVarAt: 6 put: (ContextPart subclasses select: [:e | e superclass = ContextPart]).<br><br></div><div>Finally, with the 2nd hack, maybe I don't need to forget the superfluous method removals.<br></div><div>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<br></div><div>Not sure if it is really necessary...<br><br></div><div>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.<br><br></div><div>...snip...<br></div><div>UndefinedObject>>handleSignal:<br></div><div>Context(nil)>>handleSignal:<br>Context(nil)>>handleSignal:<br>Context(nil)>>handleSignal:<br>Context(nil)>>handleSignal:<br><br></div><div>I will retry with Bert's hack.<br></div><div>This update hickup is a tough one.<br></div></div></div></div>