<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On macOS Sierra 10.12.5 Beta (16F43c), successfully ran through Update Squeak to 17158 without errors on fresh image Squeak6.0alpha-17086-64bit.zip, downloaded from <a href="http://files.squeak.org/6.0alpha/Squeak6.0alpha-17086-64bit/" class="">http://files.squeak.org/6.0alpha/Squeak6.0alpha-17086-64bit/</a> running on <div class="">on opensmalltalk-vm CocoaFast.app from cog_macos64x64_squeak.cog.spur_201701281910.tar from <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/releases" class="">https://github.com/OpenSmalltalk/opensmalltalk-vm/releases</a><div class=""><br class=""></div><div class="">Yay guys!…</div><div class=""><br class=""></div><div class="">Ken G. Brown<br class=""><div class=""><br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 8, 2017, at 12:24, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" class="">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2017-04-08 18:48 GMT+02:00 Eliot Miranda <span dir="ltr" class=""><<a href="mailto:eliot.miranda@gmail.com" target="_blank" class="">eliot.miranda@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Hi Nicolas,<div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="h5">On Sat, Apr 8, 2017 at 8:56 AM, Nicolas Cellier <span dir="ltr" class=""><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank" class="">nicolas.cellier.aka.nice@<wbr class="">gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class=""><div class="m_3761912030440890523gmail-h5"><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2017-04-08 17:29 GMT+02:00 Nicolas Cellier <span dir="ltr" class=""><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank" class="">nicolas.cellier.aka.nice@gmai<wbr class="">l.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class=""><div class="m_3761912030440890523gmail-m_-369529493314121979h5"><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2017-04-08 17:14 GMT+02:00 Nicolas Cellier <span dir="ltr" class=""><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank" class="">nicolas.cellier.aka.nice@gmai<wbr class="">l.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="m_3761912030440890523gmail-m_-369529493314121979m_6639933746201803836h5">2017-04-08 14:09 GMT+02:00 David T. Lewis <span dir="ltr" class=""><<a href="mailto:lewis@mail.msen.com" target="_blank" class="">lewis@mail.msen.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="m_3761912030440890523gmail-m_-369529493314121979m_6639933746201803836m_5224169405675442072gmail-">On Sat, Apr 08, 2017 at 01:59:34PM +0200, Nicolas Cellier wrote:<br class="">
> Ah, but now that I've put a<br class="">
> (selector == #unwindTo: and: [ self name = 'Context']) ifTrue:[self<br class="">
> halt: 'debug me'].<br class="">
> I can't reproduce the problem related to removal of Context methods!!!<br class="">
><br class="">
> Instead, I've got the 'Merging Kernel-eem.1078' window with all the<br class="">
> MethodContext->Context renaming in conflict<br class="">
> I already reported that in another thread where I told that the upgrade<br class="">
> went "smoothly" for both my 32 & 64 bits images.<br class="">
> I don't know if it's related to package cache, or .mcd, or ???<br class="">
><br class="">
> It might also be that package ancestry is not correct du to overwriting of<br class="">
> some packages, otherwise we should not get a merge window, but well...<br class="">
><br class="">
> Ah, but now I think I understand: it's just because I have pending changes<br class="">
> in Kernel due to the addition of halt: above (same for my images which<br class="">
> usually have some unpublished experiments).<br class="">
> We then trigger a merge rather than a load. And the merge sees conflict<br class="">
> probably because of broken ancestry (the GUID are not corresponding), but<br class="">
> once resolved manually, it processes smoothly without removing Context<br class="">
> methods...<br class="">
><br class="">
> I can't instrument code that easily... This will have to wait for another<br class="">
> time slot :(<br class="">
><br class="">
<br class="">
</span>Nicolas,<br class="">
<br class="">
Thanks very much for working on this and for posting your results so far.<br class="">
This is not an easy problem to solve.<br class="">
<br class="">
Dave<br class="">
<br class="">
<br class=""></blockquote></div></div><div class="">Hi Dave,<br class=""></div><div class="">don't worry, real show stopper obstacles are rare, the rest of them make the game more fun ;)<br class=""></div><div class="">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 class=""><br class=""></div><div class="">It's in MCDiffyVersion load -> MCVersionLoader load -> MCPackageLoader load.<br class=""><br class=""></div><div class="">There's a bunch of removals, starting with:<br class=""><br class="">an OrderedCollection(a MCMethodDefinition(MethodConte<wbr class="">xt>>unwindTo:)<br class="">a MCMethodDefinition(MethodConte<wbr class="">xt>>tryPrimitiveFor:receiver:a<wbr class="">rgs:)<br class="">a MCMethodDefinition(MethodConte<wbr class="">xt>>tryNamedPrimitiveIn:for:wi<wbr class="">thArgs:)<br class="">a MCMethodDefinition(MethodConte<wbr class="">xt>>top)<br class="">a MCMethodDefinition(MethodConte<wbr class="">xt>>terminateTo:) ...<br class=""><br class=""></div><div class="">So yes, this mcd is going to shoot the update process.<br class="">Why is it different from the load or merge triggered manually?<br class=""></div><div class="">Can't we avoid all the method removals and keep only the class removal?<br class=""><br class=""></div><div class="">I can try this snippet in the MCPackageLoader to reject some superfluous method removals:<br class=""><br class="">| removedClasses |<br class="">removedClasses := (removals select: #isClassDefinition) collect: #actualClass.<br class="">removedClasses addAll: (removedClasses collect: #class).<br class="">removals := removals reject: [:e | e isMethodDefinition and: [removedClasses includes: e actualClass]]<br class=""><br class=""></div><div class="">Is it OK as a general change in MC?<br class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">So two more hacks might be necessary:<br class=""><br class="">[Smalltalk globals at: #MethodContext put: Context copy] on: AttemptToWriteReadOnlyGlobal do: [:exc | exc resume: true].<br class=""><br class="">ContextPart instVarAt: 6 put: (ContextPart subclasses select: [:e | e superclass = ContextPart]).<br class=""><br class=""></div><div class="">Finally, with the 2nd hack, maybe I don't need to forget the superfluous method removals.<br class=""></div><div class="">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 class=""></div><div class="">Not sure if it is really necessary...<br class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">...snip...<br class=""></div><div class="">UndefinedObject>>handleSignal:<br class=""></div><div class="">Context(nil)>>handleSignal:<br class="">Context(nil)>>handleSignal:<br class="">Context(nil)>>handleSignal:<br class="">Context(nil)>>handleSignal:<br class=""><br class=""></div><div class="">I will retry with Bert's hack.<br class=""></div><div class="">This update hickup is a tough one.<br class=""></div></div></div></div>
</blockquote></div><br class=""></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 class=""></div><div class="gmail_extra">Undeclared shouldn't auto-clean as long as obsolete block pointing to MethodContext are still on the stack.<br class=""></div><div class="gmail_extra">I'm going to try this.<br class=""></div></div>
</blockquote></div><br class=""></div></div></div><div class="gmail_extra">Ah yes, this time it worked for me.<br class=""></div><div class="gmail_extra">Someone want to try and confirm?</div></div></blockquote><div class=""><br class=""></div></div></div><div class="">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:</div><div class=""><br class=""></div><div class=""><div class="">DoIt</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>Smalltalk globals unbind: #MethodContext.</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>[Undeclared at: #MethodContext put: Context copy]</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>on: AttemptToWriteReadOnlyGlobal</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>do: [:t1 | t1 resume: true].</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>^ ContextPart</div><span class=""><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>instVarAt: 6</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>put: (ContextPart subclasses</div></span><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>select: [:t1 | t1 superclass = ContextPart])</div></div><div class=""><br class=""></div><div class="">The instVarAt: 6 put: fails because COntextPart is Undeclared and nil. So better to write it as</div><div class=""><br class=""></div><div class=""><div class="">DoIt</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>Smalltalk globals unbind: #MethodContext.</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>[Undeclared at: #MethodContext put: Context copy]</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>on: AttemptToWriteReadOnlyGlobal</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>do: [:t1 | t1 resume: true].</div><div class=""><span style="white-space:pre-wrap" class=""> </span>ContextPart ifNil: [^self].</div><span style="white-space:pre-wrap" class=""> </span>ContextPart isBehavior ifFalse: [^self].<div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>^ ContextPart</div><span class=""><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>instVarAt: 6</div><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>put: (ContextPart subclasses</div></span><div class=""><span class="m_3761912030440890523gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>select: [:t1 | t1 superclass = ContextPart])</div></div></div><br class=""><br clear="all" class=""><div class=""><br class=""></div><div class="">(And anyone else hitting this just use "return entered value" with nil or self to proceed.</div><div class=""><br class=""></div><div class="m_3761912030440890523gmail_signature"><div dir="ltr" class=""><div class=""><span style="font-size:small;border-collapse:separate" class=""><div class="">_,,,^..^,,,_<br class=""></div><div class="">best, Eliot</div></span></div></div></div>
</div></div>
<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">Hi Eliot, good idea, that should be fixed now. <br class=""></div></div><br class=""></div></div>
<br class=""></div></blockquote></div><br class=""></div></div></div></div></body></html>