The Inbox: System-dtl.981.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: System-dtl.981.mcz

commits-2
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."].!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

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."].!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

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



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

Jakob Reschke-2
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" <[hidden email]>:
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 <[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."].!
>
>






Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

David T. Lewis
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" <[hidden email]>:
>
> > 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 <[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."].!
> > >
> > >
> >
> >
> >
> >
> >

>


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

marcel.taeumel
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 <[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."].!
> > >
> > >
> >
> >
> >
> >
> >

>




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

David T. Lewis
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.

Don't worry, it's only in the inbox for review, so nothing to revert :-)

Dave



> 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."].!
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
>
> >
>
>

>


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

David T. Lewis
In reply to this post by marcel.taeumel
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 <[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."].!
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
>
> >
>
>

>


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

Jakob Reschke-2
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 <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

David T. Lewis
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 <[hidden email]>:
> > 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 <[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."].!
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >>
> >> >
> >>
> >>
> >
> >>
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: System-dtl.981.mcz

David T. Lewis
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 <[hidden email]>:
> > > 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 <[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."].!
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >>
> > >> >
> > >>
> > >>
> > >
> > >>
> > >
> > >
> >
>