[squeak-dev] Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)
marcel.taeumel at hpi.de
Fri Dec 15 08:15:14 UTC 2017
looks good. :) Thanks!
Am 15.12.2017 04:00:51 schrieb David T. Lewis <lewis at mail.msen.com>:
Much better, thanks :-)
After moving the EmergencyRecoveryRequested recursion guard reset from
#finalExitActions: to #enter:revert:saveForRevert: the Morphic and ST80
dependencies are gone. The end result is a total of three changed methods
in Project, plus the new EmergencyRecoveryRequested class variable.
Since they are no longer needed, I moved the Morphic and ST80 parts from
inbox to treated inbox. All of the remaining changes are in the inbox
To summarize the changes: The original behavior of seaching for a parent
MVCProject or MorphicProject to host the emergency evaluator works as
originally designed. If no project is found, then search for any suitable
project elsewhere in the project hierarchy. If that is not found then
fall back on the traditional emergency evaluator. If error handling fails
in the project for emergency evaluation, the also fall back on the
traditional emergency evaluator.
I expect this to work with other kinds of Project such as SqueakShellProject
or EtoysProject, although I have not tested these so well.
On Thu, Dec 14, 2017 at 12:50:06PM -0500, David T. Lewis wrote:
> Hi Marcel,
> Oh - now I understand what you mean (d'oh!). You are right. I will follow
> up on your suggestion of putting it in #enter:revert:saveForRevert: (but
> maybe not today).
> > Hi Dave,
> > #finalExitActions: should not contain such critical code. That's what I
> > meant. :) I see it more like a "Template Method" that does nothing serious
> > by default.
> > Maybe we could reset????EmergencyRecoveryRequested in
> > #enter:revert:saveForRevert: so that #finalExitActions: becomes free
> > again. :-)
> > Best,
> > Marcel
> > Am 14.12.2017 14:49:21 schrieb David T. Lewis :
> > Hi Marcel,
> > On Thu, Dec 14, 2017 at 10:18:33AM +0100, Marcel Taeumel wrote:
> >> Hi Davis,
> >> I finally looked at your changes. :) So far, they are reasonable.
> >> However, the mere wish for not just entering parent projects for
> >> recovery but any other introduces a complexity that I am not really
> >> happy with. The class var EmergencyRecoveryRequested requires you to:
> >> - take care of the code for
> >> set/clear??EmergencyRecoveryRequested??across multiple methods
> > Did I make a mistake (again!?!) in these updates? There should be only two
> > references to EmergencyRecoveryRequested in the image. These are:
> > Project>>enterForEmergencyRecovery
> > Project>>finalExitActions:
> >> - makes the super call in #finalExitActions: mandatory, which is
> >> dangerous in my opinion and easy to miss in new kinds of projects
> >> The whole reason for this change is that we think that programmers are
> >> not able to establish a safety net of different parent projects on their
> >> own. Yet, we should rather pre-configure parent projects for the next
> >> release so that nobody has to worry. Maybe the SqueakShell at its root
> >> project.
> >> So, overall, this is a -1 from me here. Sorry.??
> > OK, thanks for reviewing :-)
> > It was an interesting exercise to figure out how to make this work. I may
> > play with the idea some more in my own image.
> >> Here is another take on #tryOtherProjectForRecovery: ??What about
> >> creating a new project of a different kind? Or re-ordering existing
> >> projects as parents? Nevertheless, I think that we should just
> >> pre-configure parent projects.
> > This hard part is to find something that does not add additional
> > complexity
> > to the emergency mechanism. I would be nervous about trying to create a
> > new
> > project or reoorder the existing hierarchy, but if someone can find a way
> > to
> > do it, that would be good.
> > I do like the idea of having a SqueakShell as the root project, so that
> > might
> > be a good thing to try. For myself, I am more comfortable dropping into
> > MVC in
> > case of an error, but that may be only because I am already familiar with
> > the
> > debugger in MVC. In the general case, dropping into a SqueakShell might be
> > better, I'm not sure.
> > Thanks,
> > Dave
> >> Best,
> >> Marcel
> >> Am 13.12.2017 22:28:05 schrieb David T. Lewis :
> >> On Tue, Dec 12, 2017 at 10:42:54PM -0500, David T. Lewis wrote:
> >> > On Mon, Dec 11, 2017 at 08:38:51AM -0500, David T. Lewis wrote:
> >> > > I think that it wlll work with the most recent versions of
> >> Morphic-dtl.1376,
> >> > > ST80-dtl.233, and System-dtl.983 in the inbox.
> >> > >
> >> > > I'll check it later tonight to make sure.
> >> >
> >> > Unfortunately I am not able to test the sound service, because I do
> >> not
> >> > have sound output on the cog/spur VMs on my Linux computer. Maybe
> >> someone
> >> > else can double check to make sure that #letTheMusicPlay still works.
> >> I
> >> > think I have it right, but I can't verify it on my PC.
> >> >
> >> > I am attaching a change set with the lastest version of the changes,
> >> which
> >> > may be more convenient that loading the MCZs from the inbox.
> >> >
> >> > Dave
> >> >
> >> If no objections, I will merge this into trunk in another day or so.
> >> Dave
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev