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