<div dir="ltr">Hi David,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 4, 2017 at 1:23 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><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">Specifically, Nicolas made a suggestion here:<br>
<br>
<a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193908.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation.<wbr>org/pipermail/squeak-dev/2017-<wbr>March/193908.html</a><br>
<br>
And Eliot suggested (sorry I don't have the link) the idea of making the<br>
update stream smart enough to restart the update process at certain marked<br>
points.<br>
<br>
I looked at the updater a bit last weekend, and I'm not sure that the<br>
"restart the update process" approach will actually handle this problem<br>
(though I would be happy to be wrong). So maybe Nicolas' idea will work<br>
out? Quoting from his earlier message:<br>
<br>
>> maybe an option is to detach the Context* classes from the<br>
<span class="gmail-">>> SystemDictionary in some preamble so that they are immune<br>
>> to any refactoring while still in use...<br></span></blockquote><div><br></div><div>Not possible.  With an exception system in the image it is vital that messages be sent to contexts.  </div><div><br></div><div>But I think we can do one of two things to lessen the impact:</div><div><br></div><div>One thing is that right now on most of our work machines, which means most of the machines upon which we do our updating, the compilation part of updating is really fast, so reporting progress isn't probably very important here.  In fact what we could do is only report progress graphically while downloading packages.  That way much of the graphics subsystem and complex exception notification part of the progress notification would not be active when compiling and installing the package. If we did this I don't think my "be able to mark an update as requiring a restart of the update system" suggestion would be necessary at all.</div><div><br></div><div>We could put in a hack such that if any of a small number of packages were being updated, the update process would be updated automatically, say Kernel, System, Graphics.  But this is a real hack.</div><div><br></div><div>Personally I like the idea of only updating progress while downloading files, and then during installation updating progress only between package installs.</div><div><br></div><div>As I discussed (alas off list) a better solution may to allow an update map to specify that the update process should be restarted, so that all active process state is discarded at some point during an update.</div><div><br></div><div>Of course these ideas need to be tested in the context of the 400 through 408 updates.  Am I right to think that if one has an image at a specific update and then loads a much newer version of a package (i.e. MonticelloConfigurations) that the update will never revert, right?  Or is merge a preference (or should it be)?</div><div><br></div><div><br></div><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="gmail-">
<br>
</span>Dave<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> update-eem.400.mcm may be going back too far, I think I got past the<br>
> problem by starting with update-eem.403. Basically, if you can get up to<br>
> the update-eem.406.mcm level, then manually load Kernel-eem.1078, you<br>
> should be back in business.<br>
><br>
> But we do need to get the update stream fixed. We have a couple of ideas<br>
> bouncing around in emails, but as far as I know we don't yet have a<br>
> working solution.<br>
><br>
> Dave<br>
><br>
><br>
>> When I try to load update-eem.400.mcm, I am getting an error,<br>
>> "CompiledMethod cannot be changed."<br>
>><br>
>> It's while loading Kernel-eem.10651...<br>
>><br>
>> On Thu, Mar 30, 2017 at 9:32 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
>> wrote:<br>
>>> Hi All,<br>
>>><br>
>>>     I'm very sorry to report that my recent changes (adding<br>
>>> CompiledCode<br>
>>> and<br>
>>> CompiledBlock to the CompiledMethod hierarchy in anticipation of full<br>
>>> blocks, and merging ContextPart and MethodContext and renaming them as<br>
>>> Context, to eliminate obsolete block and closer implementations) has<br>
>>> broken<br>
>>> the update process.  I do not believe there is an easy fix as i think<br>
>>> the<br>
>>> issues are to do with the citations that exist on the stack while the<br>
>>> update<br>
>>> proceeds (the progress indicators).<br>
>>><br>
>>> There is a clumsy work-around that appears reliable.  The pauses<br>
>>> between<br>
>>> loads get rid of the progress indication activations and hence avoid<br>
>>> trying<br>
>>> to upgrade running processes through these kernel changes.<br>
>>><br>
>>> Open the trunk repository from your Monticello Browser.<br>
>>> Locate the update package (the penultimate entry in the list of<br>
>>> packages).<br>
>>> Load (or merge) update-eem.400.mcm.<br>
>>> Load (or merge) update-eem.403.mcm.<br>
>>> Load (or merge) update-eem.406.mcm. Save your image.<br>
>>> Local the Kernel package.<br>
>>> Load Kernel-eem.1078. Save your image.<br>
>>> Update<br>
>>><br>
>>> I'm so sorry.<br>
>>> Eliot<br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
><br>
><br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>