The Inbox: System-dtl.981.mcz

Am 07.12.2017 04:12:06 schrieb David T. Lewis <[hidden email]>:

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, [hidden email] 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."].!
>
>

Am 08.12.2017 02:21:34 schrieb David T. Lewis <[hidden email]>:

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, [hidden email] 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."].!
> > >
> > >
> >
> >
> >
> >
> >

>