On Tue, Apr 04, 2017 at 02:22:07PM -0700, Eliot Miranda wrote:
Hi David,
On Tue, Apr 4, 2017 at 1:23 PM, David T. Lewis lewis@mail.msen.com wrote:
Specifically, Nicolas made a suggestion here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2017- March/193908.html
And Eliot suggested (sorry I don't have the link) the idea of making the update stream smart enough to restart the update process at certain marked points.
I looked at the updater a bit last weekend, and I'm not sure that the "restart the update process" approach will actually handle this problem (though I would be happy to be wrong). So maybe Nicolas' idea will work out? Quoting from his earlier message:
maybe an option is to detach the Context* classes from the SystemDictionary in some preamble so that they are immune to any refactoring while still in use...
Not possible. With an exception system in the image it is vital that messages be sent to contexts.
Ok.
But I think we can do one of two things to lessen the impact:
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.
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.
Personally I like the idea of only updating progress while downloading files, and then during installation updating progress only between package installs.
Sounds good to me, we just need someone to make it happen :-)
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.
That sounded like a simple solution to me, but after looking at the update process from within a debugger, I do not know how to make it work.
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)?
I don't know, but I believe that it is the case that if someone can come up with a way to make MonticelloConfigurations work with any of the ideas described above, then that newer version of MonticelloConfigurations could be patched into an earlier update map such that the trunk update stream would start working again.
Dave