<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="">In case this means something to someone, running Update Squeak a second time on the already updated to 17158 image, results in update-eem.413.mcm downloading and doing: <div class=""><div class="">========== Compiler-eem.341 ==========</div><div class=""><br class=""></div><div class="">Add the refactored encoder-specific method generator. This one moves generation from MethodNode to BytecodeEncoder and subclasses, and hence allows easier bytecode set selection, or at least far more sends to self than to encoder. Add the MethodNode>>primitive accessor it requires.</div><div class=""><br class=""></div><div class="">========== Update completed: 17158 -> 17158 ==========</div><div class=""><br class=""></div><div class="">Ken G. Brown</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Apr 8, 2017, at 18:22, Ken G. Brown <<a href="mailto:kbrown@mac.com" class="">kbrown@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div 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 class=""><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></div><br class=""></div></blockquote></div><br class=""></div></body></html>