<body><div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
Yeah, this would not happen if you only use the owner projects ... hmm ... We might want to revert this change and think of something else.<div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 08.12.2017 02:21:34 schrieb David T. Lewis <lewis@mail.msen.com>:</p>Good idea, I think we could put a hint in the debugger. <br><br>Project>>enterForEmergencyRecovery opens the debugger with window title<br>'FATAL PROJECT ERROR!'. We could change this to have it identify the name<br>of the project from which the problem originated.<br><br>One concern that I still have - If the fatal error is something that is<br>going to fail in both MVC and Morphic (or others), then we could have<br>an endless failure loop where a failure in Morphic opens a debugger in<br>MVC, which fails and opens a debugger in Morphic, ...<br><br>I do not know if this is a problem in practice, but I would like to think<br>of a way to prevent it happening.<br><br>Dave<br><br><br>On Thu, Dec 07, 2017 at 09:48:49AM +0100, Jakob Reschke wrote:<br>> At least if they are aware of the feature... Would it make sense to place a<br>> hint to it in the recovery world? For example in the debugger?<br>> <br>> Am 07.12.2017 09:13 schrieb "Marcel Taeumel" <marcel.taeumel@hpi.de>:<br>> <br>> > Hi Dave.<br>> ><br>> > Cool! :) Since we have "Enter previous project", one will not get lost<br>> > after fixing the particular bug and continuing the task.<br>> ><br>> > B est,<br>> > Marcel<br>> ><br>> > Am 07.12.2017 04:12:06 schrieb David T. Lewis <lewis@mail.msen.com>:<br>> > This is an extension of Marcel's tryOtherProjectForRecovery: mechanism.<br>> ><br>> > My working image has many Morphic projects, and a few MVC projects, but in<br>> > general the Morphic projects do not have an MVC project as a parent<br>> > project.<br>> ><br>> > This change allows a fatal error in the UI for any of the Morphic projects<br>> > to find any available MVC project and use it for error recovery.<br>> ><br>> > For example, if I am in a Mophic project and I comment out the<br>> > implementation<br>> > of Morph>>bounds, this leads to a fatal error. Normally this would have<br>> > dropped<br>> > into an emergency evaluator. With this change, we instead enter an MVC<br>> > project<br>> > with a debugger on the failure that occurred in the Morphic UI.<br>> ><br>> > Dave<br>> ><br>> ><br>> > On Thu, Dec 07, 2017 at 02:52:28AM +0000, commits@source.squeak.org wrote:<br>> > > David T. Lewis uploaded a new version of System to project The Inbox:<br>> > > http://source.squeak.org/inbox/System-dtl.981.mcz<br>> > ><br>> > > ==================== Summary ====================<br>> > ><br>> > > Name: System-dtl.981<br>> > > Author: dtl<br>> > > Time: 6 December 2017, 9:52:13.947225 pm<br>> > > UUID: d00b5ac2-0e56-40d3-91d6-7803be283e1c<br>> > > Ancestors: System-mt.980<br>> > ><br>> > > For emergency evaluator handling, Project class>>handlePrimitiveError:<br>> > will first try to find a parent project of different type (e.g. MVC if<br>> > current project is Morphic, or vice versa). If found, the other project is<br>> > opened, and the error is handled there. If no such project is found, then<br>> > the traditional emergency evaluator transcript is opened.<br>> > ><br>> > > Extend this strategy by first checking parent project types, and if not<br>> > successful search all projects to find any project of different type.<br>> > ><br>> > > A typical scenario is the case of an image with many Morphic projects,<br>> > and one MVC project anywhere in the project hierarchy. In the event of an<br>> > unrecoverable error in any of the Morphic projects, the MVC project will be<br>> > identified as the project for emergency recovery. This permits an MVC<br>> > debugger to be used to recover from the error condition, after which the<br>> > failed Morphic user interface can be reentered.<br>> > ><br>> > > =============== Diff against System-mt.980 ===============<br>> > ><br>> > > Item was changed:<br>> > > ----- Method: Project class>>tryOtherProjectForRecovery: (in category<br>> > 'error recovery') -----<br>> > > tryOtherProjectForRecovery: errorMessage<br>> > > "Try entering the parent project if it uses a different user interface.<br>> > We determine this by comparing the project's class."<br>> > ><br>> > > | safeProject nextProject |<br>> > > nextProject := Project current.<br>> > > safeProject := nil.<br>> > > [safeProject notNil or: [nextProject isTopProject]] whileFalse: [<br>> > > nextProject := nextProject parent.<br>> > > (Project current isKindOf: nextProject class)<br>> > > ifFalse: [safeProject := nextProject]].<br>> > > +<br>> > > + "Parent project was not of a different type. Search through all known<br>> > > + projects to find any one that is of different project type."<br>> > > + safeProject ifNil: [<br>> > > + Smalltalk garbageCollect.<br>> > > + safeProject := Project allSubInstances<br>> > > + detect: [ :proj | proj class ~= Project<br>> > > + or: [ (proj isKindOf: Project current class) not ] ]<br>> > > + ifNone: [ nil ] ].<br>> > > +<br>> > > safeProject ifNotNil: [:p |<br>> > > p enterForEmergencyRecovery.<br>> > > "Active process will usually suspend after this."].!<br>> > ><br>> > ><br>> ><br>> ><br>> ><br>> ><br>> ><br><br>> <br><br><br></lewis@mail.msen.com></marcel.taeumel@hpi.de>
</blockquote>
</div></body>