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).

Thanks,
Dave


> 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 <lewis at mail.msen.com>:
> 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
>>
>>
>
>>
>
>
>
>