<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Nicolas,</div><div><br>On Apr 8, 2017, at 8:56 AM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-04-08 17:29 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-04-08 17:14 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@<wbr>gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_6639933746201803836h5">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="m_6639933746201803836m_5224169405675442072gmail-">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></div><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(MethodConte<wbr>xt>>unwindTo:)<br>a MCMethodDefinition(MethodConte<wbr>xt>>tryPrimitiveFor:receiver:<wbr>args:)<br>a MCMethodDefinition(MethodConte<wbr>xt>>tryNamedPrimitiveIn:for:wi<wbr>thArgs:)<br>a MCMethodDefinition(MethodConte<wbr>xt>>top)<br>a MCMethodDefinition(MethodConte<wbr>xt>>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>
</blockquote></div><br></div></div></div><div class="gmail_extra">And Bert's hack is not enough. So another possibility would be to move #MethodContext -> Context binding in Undeclared.<br></div><div class="gmail_extra">Undeclared shouldn't auto-clean as long as obsolete block pointing to MethodContext are still on the stack.<br></div><div class="gmail_extra">I'm going to try this.<br></div></div>
</blockquote></div><br></div><div class="gmail_extra">Ah yes, this time it worked for me.<br></div><div class="gmail_extra">Someone want to try and confirm?</div></div></div></blockquote><br><div><span style="background-color: rgba(255, 255, 255, 0);">I just updated a 64-bit image from 16987 to 17157 so I think you have it fixed. Brilliant!</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">How do we capture your insights in the code? I'll try and read the thread and the code and see that comments in the code capture things. But not today; it's raining and we're going to the beach :-). (Muir beach and the Pelican In are fun in the rain too).<br><br>_,,,^..^,,,_ (phone)</span></div></body></html>