The changes for this are Morphic-dtl.1376, ST80-dtl.233, and System-dtl.983 in the inbox.

Hopefully I got it right this time :-/

Dave


On Sun, Dec 10, 2017 at 01:37:52PM -0500, David T. Lewis wrote:
> Thanks Jakob,
> 
> Ugh, I think I must have logical dyslexia ;-)
> 
> I'll fix the tryOtherProjectForRecovery: problem, but there is also another
> issue in that MorphicProject overrides #finalExitActions: such that the
> guard flag is not being cleared in the case of a Morphic project serving as
> the project for emergency evaluation for an error in a MVC project.
> 
> I think this will require updates to System, Morphic and ST80 to make it
> work properly.
> 
> Thanks for reviewing,
> Dave
> 
> On Sun, Dec 10, 2017 at 05:09:19PM +0100, Jakob Reschke wrote:
> > I think there might be a problem with the case when no parent project
> > is of a different type:
> > 
> > in Project class>>tryOtherProjectForRecovery:
> > 
> > Project allSubInstances
> > detect: [ :proj | proj class ~= Project
> > or: [ (proj isKindOf: Project current class) not ] ]
> > ifNone: [ nil ]
> > 
> > Isn't this true for every practical project: proj class ~= Project?
> > Then the detect block would always return true and the project which
> > happens to come first in allSubInstances would be selected, regardless
> > of its class. This might even be the very project that the emergency
> > recovery procedure is trying to evacuate from.
> > 
> > Kind regards,
> > Jakob
> > 
> > 2017-12-09 17:21 GMT+01:00 David T. Lewis <lewis at mail.msen.com>:
> > > I put another update in the inbox (System-dtl.982) that provides a more
> > > meaningful title for the emergency debugger as Jakob Reschke suggested.
> > > It also adds a guard to prevent recursive emergency projects.
> > >
> > > This seems to be working well now. Marcel and Jakob, if you can take a
> > > look at this again I'd appreciate it.
> > >
> > > Dave
> > >
> > >
> > > On Fri, Dec 08, 2017 at 08:19:40AM +0100, Marcel Taeumel wrote:
> > >> 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.
> > >> Am 08.12.2017 02:21:34 schrieb David T. Lewis <lewis at mail.msen.com>:
> > >> Good idea, I think we could put a hint in the debugger.
> > >>
> > >> Project>>enterForEmergencyRecovery opens the debugger with window title
> > >> 'FATAL PROJECT ERROR!'. We could change this to have it identify the name
> > >> of the project from which the problem originated.
> > >>
> > >> One concern that I still have - If the fatal error is something that is
> > >> going to fail in both MVC and Morphic (or others), then we could have
> > >> an endless failure loop where a failure in Morphic opens a debugger in
> > >> MVC, which fails and opens a debugger in Morphic, ...
> > >>
> > >> I do not know if this is a problem in practice, but I would like to think
> > >> of a way to prevent it happening.
> > >>
> > >> Dave
> > >>
> > >>
> > >> On Thu, Dec 07, 2017 at 09:48:49AM +0100, Jakob Reschke wrote:
> > >> > At least if they are aware of the feature... Would it make sense to place a
> > >> > hint to it in the recovery world? For example in the debugger?
> > >> >
> > >> > Am 07.12.2017 09:13 schrieb "Marcel Taeumel" :
> > >> >
> > >> > > Hi Dave.
> > >> > >
> > >> > > Cool! :) Since we have "Enter previous project", one will not get lost
> > >> > > after fixing the particular bug and continuing the task.
> > >> > >
> > >> > > B est,
> > >> > > Marcel
> > >> > >
> > >> > > Am 07.12.2017 04:12:06 schrieb David T. Lewis :
> > >> > > This is an extension of Marcel's tryOtherProjectForRecovery: mechanism.
> > >> > >
> > >> > > My working image has many Morphic projects, and a few MVC projects, but in
> > >> > > general the Morphic projects do not have an MVC project as a parent
> > >> > > project.
> > >> > >
> > >> > > This change allows a fatal error in the UI for any of the Morphic projects
> > >> > > to find any available MVC project and use it for error recovery.
> > >> > >
> > >> > > For example, if I am in a Mophic project and I comment out the
> > >> > > implementation
> > >> > > of Morph>>bounds, this leads to a fatal error. Normally this would have
> > >> > > dropped
> > >> > > into an emergency evaluator. With this change, we instead enter an MVC
> > >> > > project
> > >> > > with a debugger on the failure that occurred in the Morphic UI.
> > >> > >
> > >> > > Dave
> > >> > >
> > >> > >
> > >> > > On Thu, Dec 07, 2017 at 02:52:28AM +0000, commits at source.squeak.org wrote:
> > >> > > > David T. Lewis uploaded a new version of System to project The Inbox:
> > >> > > > http://source.squeak.org/inbox/System-dtl.981.mcz
> > >> > > >
> > >> > > > ==================== Summary ====================
> > >> > > >
> > >> > > > Name: System-dtl.981
> > >> > > > Author: dtl
> > >> > > > Time: 6 December 2017, 9:52:13.947225 pm
> > >> > > > UUID: d00b5ac2-0e56-40d3-91d6-7803be283e1c
> > >> > > > Ancestors: System-mt.980
> > >> > > >
> > >> > > > For emergency evaluator handling, Project class>>handlePrimitiveError:
> > >> > > will first try to find a parent project of different type (e.g. MVC if
> > >> > > current project is Morphic, or vice versa). If found, the other project is
> > >> > > opened, and the error is handled there. If no such project is found, then
> > >> > > the traditional emergency evaluator transcript is opened.
> > >> > > >
> > >> > > > Extend this strategy by first checking parent project types, and if not
> > >> > > successful search all projects to find any project of different type.
> > >> > > >
> > >> > > > A typical scenario is the case of an image with many Morphic projects,
> > >> > > and one MVC project anywhere in the project hierarchy. In the event of an
> > >> > > unrecoverable error in any of the Morphic projects, the MVC project will be
> > >> > > identified as the project for emergency recovery. This permits an MVC
> > >> > > debugger to be used to recover from the error condition, after which the
> > >> > > failed Morphic user interface can be reentered.
> > >> > > >
> > >> > > > =============== Diff against System-mt.980 ===============
> > >> > > >
> > >> > > > Item was changed:
> > >> > > > ----- Method: Project class>>tryOtherProjectForRecovery: (in category
> > >> > > 'error recovery') -----
> > >> > > > tryOtherProjectForRecovery: errorMessage
> > >> > > > "Try entering the parent project if it uses a different user interface.
> > >> > > We determine this by comparing the project's class."
> > >> > > >
> > >> > > > | safeProject nextProject |
> > >> > > > nextProject := Project current.
> > >> > > > safeProject := nil.
> > >> > > > [safeProject notNil or: [nextProject isTopProject]] whileFalse: [
> > >> > > > nextProject := nextProject parent.
> > >> > > > (Project current isKindOf: nextProject class)
> > >> > > > ifFalse: [safeProject := nextProject]].
> > >> > > > +
> > >> > > > + "Parent project was not of a different type. Search through all known
> > >> > > > + projects to find any one that is of different project type."
> > >> > > > + safeProject ifNil: [
> > >> > > > + Smalltalk garbageCollect.
> > >> > > > + safeProject := Project allSubInstances
> > >> > > > + detect: [ :proj | proj class ~= Project
> > >> > > > + or: [ (proj isKindOf: Project current class) not ] ]
> > >> > > > + ifNone: [ nil ] ].
> > >> > > > +
> > >> > > > safeProject ifNotNil: [:p |
> > >> > > > p enterForEmergencyRecovery.
> > >> > > > "Active process will usually suspend after this."].!
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >>
> > >> >
> > >>
> > >>
> > >
> > >>
> > >
> > >
> > 
>