The Inbox: Morphic-dtl.1376.mcz

Am 10.12.2017 20:07:19 schrieb [hidden email] <[hidden email]>:

David T. Lewis uploaded a new version of Morphic to project The Inbox:
http://source.squeak.org/inbox/Morphic-dtl.1376.mcz

==================== Summary ====================

Name: Morphic-dtl.1376
Author: dtl
Time: 10 December 2017, 2:04:07.58309 pm
UUID: eaa7809b-73bf-4643-b2a1-3d9d7ac54362
Ancestors: Morphic-nice.1375

Call super in finalExitActions: in order to clear the EmergencyRecoveryRequested guard.

=============== Diff against Morphic-nice.1375 ===============

Item was changed:
----- Method: MorphicProject>>finalExitActions: (in category 'enter') -----
finalExitActions: enteringProject

+ super finalExitActions: enteringProject.
world triggerClosingScripts.
-
"Pause sound players, subject to preference settings"
(world hasProperty: #letTheMusicPlay)
ifTrue: [world removeProperty: #letTheMusicPlay]
ifFalse: [SoundService stop].

world sleep.
(world findA: ProjectNavigationMorph)
ifNotNil: [:navigator | navigator retractIfAppropriate].
self clearGlobalState.
Sensor flushAllButDandDEvents. !

Am 13.12.2017 22:28:05 schrieb David T. Lewis <[hidden email]>:

On Tue, Dec 12, 2017 at 10:42:54PM -0500, David T. Lewis wrote:

> On Mon, Dec 11, 2017 at 08:38:51AM -0500, David T. Lewis wrote:
> > I think that it wlll work with the most recent versions of Morphic-dtl.1376,
> > ST80-dtl.233, and System-dtl.983 in the inbox.
> >
> > I'll check it later tonight to make sure.
>
> Unfortunately I am not able to test the sound service, because I do not
> have sound output on the cog/spur VMs on my Linux computer. Maybe someone
> else can double check to make sure that #letTheMusicPlay still works. I
> think I have it right, but I can't verify it on my PC.
>
> I am attaching a change set with the lastest version of the changes, which
> may be more convenient that loading the MCZs from the inbox.
>
> Dave
>

If no objections, I will merge this into trunk in another day or so.

Dave

Am 14.12.2017 14:49:21 schrieb David T. Lewis <[hidden email]>:

Hi Marcel,

On Thu, Dec 14, 2017 at 10:18:33AM +0100, Marcel Taeumel wrote:
> Hi Davis,
>
> I finally looked at your changes. :) So far, they are reasonable. However, the mere wish for not just entering parent projects for recovery but any other introduces a complexity that I am not really happy with. The class var EmergencyRecoveryRequested requires you to:
>
> - take care of the code for set/clear??EmergencyRecoveryRequested??across multiple methods

Did I make a mistake (again!?!) in these updates? There should be only two
references to EmergencyRecoveryRequested in the image. These are:

Project>>enterForEmergencyRecovery
Project>>finalExitActions:


> - makes the super call in #finalExitActions: mandatory, which is dangerous in my opinion and easy to miss in new kinds of projects
>
> The whole reason for this change is that we think that programmers are not able to establish a safety net of different parent projects on their own. Yet, we should rather pre-configure parent projects for the next release so that nobody has to worry. Maybe the SqueakShell at its root project.
>
> So, overall, this is a -1 from me here. Sorry.??


OK, thanks for reviewing :-)

It was an interesting exercise to figure out how to make this work. I may
play with the idea some more in my own image.

>
> Here is another take on #tryOtherProjectForRecovery: ??What about creating a new project of a different kind? Or re-ordering existing projects as parents? Nevertheless, I think that we should just pre-configure parent projects.

This hard part is to find something that does not add additional complexity
to the emergency mechanism. I would be nervous about trying to create a new
project or reoorder the existing hierarchy, but if someone can find a way to
do it, that would be good.

I do like the idea of having a SqueakShell as the root project, so that might
be a good thing to try. For myself, I am more comfortable dropping into MVC in
case of an error, but that may be only because I am already familiar with the
debugger in MVC. In the general case, dropping into a SqueakShell might be
better, I'm not sure.

Thanks,
Dave

>
> Best,
> Marcel
>
> Am 13.12.2017 22:28:05 schrieb David T. Lewis :
> On Tue, Dec 12, 2017 at 10:42:54PM -0500, David T. Lewis wrote:
> > On Mon, Dec 11, 2017 at 08:38:51AM -0500, David T. Lewis wrote:
> > > I think that it wlll work with the most recent versions of Morphic-dtl.1376,
> > > ST80-dtl.233, and System-dtl.983 in the inbox.
> > >
> > > I'll check it later tonight to make sure.
> >
> > Unfortunately I am not able to test the sound service, because I do not
> > have sound output on the cog/spur VMs on my Linux computer. Maybe someone
> > else can double check to make sure that #letTheMusicPlay still works. I
> > think I have it right, but I can't verify it on my PC.
> >
> > I am attaching a change set with the lastest version of the changes, which
> > may be more convenient that loading the MCZs from the inbox.
> >
> > Dave
> >
>
> If no objections, I will merge this into trunk in another day or so.
>
> Dave
>
>

>

Am 15.12.2017 04:00:51 schrieb David T. Lewis <[hidden email]>:

Marcel,

Much better, thanks :-)

After moving the EmergencyRecoveryRequested recursion guard reset from
#finalExitActions: to #enter:revert:saveForRevert: the Morphic and ST80
dependencies are gone. The end result is a total of three changed methods
in Project, plus the new EmergencyRecoveryRequested class variable.

Since they are no longer needed, I moved the Morphic and ST80 parts from
inbox to treated inbox. All of the remaining changes are in the inbox
as System-dtl.985.

To summarize the changes: The original behavior of seaching for a parent
MVCProject or MorphicProject to host the emergency evaluator works as
originally designed. If no project is found, then search for any suitable
project elsewhere in the project hierarchy. If that is not found then
fall back on the traditional emergency evaluator. If error handling fails
in the project for emergency evaluation, the also fall back on the
traditional emergency evaluator.

I expect this to work with other kinds of Project such as SqueakShellProject
or EtoysProject, although I have not tested these so well.

Dave


On Thu, Dec 14, 2017 at 12:50:06PM -0500, David T. Lewis wrote:
> Hi Marcel,
>
> Oh - now I understand what you mean (d'oh!). You are right. I will follow
> up on your suggestion of putting it in #enter:revert:saveForRevert: (but
> maybe not today).
>
> Thanks,
> Dave
>
>
> > Hi Dave,
> >
> > #finalExitActions: should not contain such critical code. That's what I
> > meant. :) I see it more like a "Template Method" that does nothing serious
> > by default.
> >
> > Maybe we could reset????EmergencyRecoveryRequested in
> > #enter:revert:saveForRevert: so that #finalExitActions: becomes free
> > again. :-)
> >
> > Best,
> > Marcel
> > Am 14.12.2017 14:49:21 schrieb David T. Lewis :
> > Hi Marcel,
> >
> > On Thu, Dec 14, 2017 at 10:18:33AM +0100, Marcel Taeumel wrote:
> >> Hi Davis,
> >>
> >> I finally looked at your changes. :) So far, they are reasonable.
> >> However, the mere wish for not just entering parent projects for
> >> recovery but any other introduces a complexity that I am not really
> >> happy with. The class var EmergencyRecoveryRequested requires you to:
> >>
> >> - take care of the code for
> >> set/clear??EmergencyRecoveryRequested??across multiple methods
> >
> > Did I make a mistake (again!?!) in these updates? There should be only two
> > references to EmergencyRecoveryRequested in the image. These are:
> >
> > Project>>enterForEmergencyRecovery
> > Project>>finalExitActions:
> >
> >
> >> - makes the super call in #finalExitActions: mandatory, which is
> >> dangerous in my opinion and easy to miss in new kinds of projects
> >>
> >> The whole reason for this change is that we think that programmers are
> >> not able to establish a safety net of different parent projects on their
> >> own. Yet, we should rather pre-configure parent projects for the next
> >> release so that nobody has to worry. Maybe the SqueakShell at its root
> >> project.
> >>
> >> So, overall, this is a -1 from me here. Sorry.??
> >
> >
> > OK, thanks for reviewing :-)
> >
> > It was an interesting exercise to figure out how to make this work. I may
> > play with the idea some more in my own image.
> >
> >>
> >> Here is another take on #tryOtherProjectForRecovery: ??What about
> >> creating a new project of a different kind? Or re-ordering existing
> >> projects as parents? Nevertheless, I think that we should just
> >> pre-configure parent projects.
> >
> > This hard part is to find something that does not add additional
> > complexity
> > to the emergency mechanism. I would be nervous about trying to create a
> > new
> > project or reoorder the existing hierarchy, but if someone can find a way
> > to
> > do it, that would be good.
> >
> > I do like the idea of having a SqueakShell as the root project, so that
> > might
> > be a good thing to try. For myself, I am more comfortable dropping into
> > MVC in
> > case of an error, but that may be only because I am already familiar with
> > the
> > debugger in MVC. In the general case, dropping into a SqueakShell might be
> > better, I'm not sure.
> >
> > Thanks,
> > Dave
> >
> >>
> >> Best,
> >> Marcel
> >>
> >> Am 13.12.2017 22:28:05 schrieb David T. Lewis :
> >> On Tue, Dec 12, 2017 at 10:42:54PM -0500, David T. Lewis wrote:
> >> > On Mon, Dec 11, 2017 at 08:38:51AM -0500, David T. Lewis wrote:
> >> > > I think that it wlll work with the most recent versions of
> >> Morphic-dtl.1376,
> >> > > ST80-dtl.233, and System-dtl.983 in the inbox.
> >> > >
> >> > > I'll check it later tonight to make sure.
> >> >
> >> > Unfortunately I am not able to test the sound service, because I do
> >> not
> >> > have sound output on the cog/spur VMs on my Linux computer. Maybe
> >> someone
> >> > else can double check to make sure that #letTheMusicPlay still works.
> >> I
> >> > think I have it right, but I can't verify it on my PC.
> >> >
> >> > I am attaching a change set with the lastest version of the changes,
> >> which
> >> > may be more convenient that loading the MCZs from the inbox.
> >> >
> >> > Dave
> >> >
> >>
> >> If no objections, I will merge this into trunk in another day or so.
> >>
> >> Dave
> >>
> >>
> >
> >>
> >
> >
> >
> >
>
>
>

Am 16.12.2017 02:11:46 schrieb David T. Lewis <[hidden email]>:

Thanks Marcel,

Should I merge this into trunk, or just leave it as an experiment for now?

Dave

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