The Inbox: Morphic-dtl.1376.mcz

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

The Inbox: Morphic-dtl.1376.mcz

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


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Morphic-dtl.1376.mcz

marcel.taeumel
Hmm... now #letTheMusicPlay cannot work anymore. :-)

Best,
Marcel

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




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Morphic-dtl.1376.mcz

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

I moved the "SoundService stop" from Project>>finalExitActions: to
MVCProject>>finalExitActions: so that it would not affect Morphic, which
handles it differently (and the Morphic handling would not work for MVC
or SqueakShellProject).

I'm not sure if SoundService is important in a SqueakShellProject, but
if so, it would be necessary to add the "SoundService stop" to
SqueakShellProject>>finalExitActions:.

So maybe it would be better to leave the SoundService handling as it was?
In that case we could add handling for EmergencyRecoveryRequested in
MorphicProject>>finalExitActions:. But overall I think I prefer calling
super in the that method, although I cannot really give any good reason
for preferring it.

Thanks for looking that this :-)

Thanks,
Dave

On Mon, Dec 11, 2017 at 07:48:25AM +0100, Marcel Taeumel wrote:

> Hmm... now #letTheMusicPlay cannot work anymore. :-)
>
> Best,
> Marcel
> 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. !
>
>

>


Reply | Threaded
Open this post in threaded view
|

Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

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



>
> I moved the "SoundService stop" from Project>>finalExitActions: to
> MVCProject>>finalExitActions: so that it would not affect Morphic, which
> handles it differently (and the Morphic handling would not work for MVC
> or SqueakShellProject).
>
> I'm not sure if SoundService is important in a SqueakShellProject, but
> if so, it would be necessary to add the "SoundService stop" to
> SqueakShellProject>>finalExitActions:.
>
> So maybe it would be better to leave the SoundService handling as it was?
> In that case we could add handling for EmergencyRecoveryRequested in
> MorphicProject>>finalExitActions:. But overall I think I prefer calling
> super in the that method, although I cannot really give any good reason
> for preferring it.
>
> Thanks for looking that this :-)
>
> Thanks,
> Dave
>
> On Mon, Dec 11, 2017 at 07:48:25AM +0100, Marcel Taeumel wrote:
> > Hmm... now #letTheMusicPlay cannot work anymore. :-)
> >
> > Best,
> > Marcel
> > 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. !
> >
> >
>
> >



EmergencyProjects-dtl.3.cs (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

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


Reply | Threaded
Open this post in threaded view
|

Re: Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

marcel.taeumel
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
- 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. 

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.

Best,
Marcel

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




Reply | Threaded
Open this post in threaded view
|

Re: Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

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 <[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
>
>

>


Reply | Threaded
Open this post in threaded view
|

Re: Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

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

>




Reply | Threaded
Open this post in threaded view
|

Re: Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

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



Reply | Threaded
Open this post in threaded view
|

Re: Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

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

Reply | Threaded
Open this post in threaded view
|

Re: Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

marcel.taeumel
Hi Dave,

looks good. :) Thanks!

Best,
Marcel

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
> >>
> >>
> >
> >>
> >
> >
> >
> >
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

David T. Lewis
In reply to this post by David T. Lewis
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 <[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
> > > >>

Reply | Threaded
Open this post in threaded view
|

Re: Emergency Projects (was: The Inbox: Morphic-dtl.1376.mcz)

marcel.taeumel
Hi Dave,

you can merge it into Trunk. :)

Best,
Marcel

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
> > > >>