Smalltalk › Squeak › Squeak - Dev

Changeset: Eliminating global state from Morphic

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

56 messages Options

123

Squeak - Dev mailing list

Re: Multiple processes and morphic state (was Re: Changeset: Eliminating global state from Morphic)

Hi Tony, I am excited to conversate with you, regarding Promises. Vollständig geil!

Von: Tony Garnock-Jones [hidden email]

Gesendet: Freitag, 25. September 2020 16:55:23
An: The general-purpose Squeak developers list; Thiede, Christoph
Betreff: Multiple processes and morphic state (was Re: Changeset: Eliminating global state from Morphic)

Hi Christoph,

On 9/24/20 2:08 PM, Thiede, Christoph wrote:
>> It's true that in Morphic there is one distinct Process associated
> with the user interface for each Morphic world.
>
> I'm not so sure about this. You can always do forks within UI code, so
> sometimes there are also multiple Processes within one Morphic world.
> Just think about Shout's background process or debugging processes, and
> please keep in mind that Jakob justifiably proposed to renew the process
> handling for non-modal dialogs, which maybe could also result in
> multiple processes being active at the same time.
> A world can have multiple hands, for example, RemoteHandMorphs
> (Nebraska), event-simulating hands (EventRecorder), or just
> multiple plain HandMorphs as demonstrated by Tony recently in
> his PostmarketOS implementation. There is no reason for these hands to
> run on the same process. Analogously, I don't see why we should restrict
> a hand not to be thread-safe, so the hand-event relation is 1:n again.

I've found that while, yes, there are lots of opportunities for
concurrency in Morphic, actually *taking* those opportunities results in
all sorts of problems.

Morphic state is I think not thread-safe enough to allow multiple
processes "inside" of it at once.

So I've ended up being *very* careful to serialize all Morphic access
within the one, main UI process. Where other processes (Actors) exist, I
send messages from the UI process to the others, and when Morphic state
change code has to run, I package it up into a block and enqueue it for
later execution by the UI process rather than doing it in each Actor.

(It's painful, actually, having to be so careful about it, in such a
C-style "you do all the work yourself and the system won't help you"
manner. Maybe there's something we can improve here?)

So I think it's *morally* true that "there is one distinct Process
associated with the user interface for each Morphic world," even if as a
rule it can be bent a little :-)

This would be sa-super spot to put a Vat, running an event loop, with a proscribed way to submit a new context through its queue.

I have gotten super-lazy about it, am watching Jen Aniston's show The Morning Show and other avoidance behaviors (Totally Awsome!). I am halfway through getting tests to work.

I maybe 65% there in porting ELibs PromisesLocal as the implementation behind your Promise/A* protocol interface. The main issue is your Promise can immediately resolve to a value, whereas ELibs event loop has to process the resolution async, so many tests need a small delay to allow the Promise to resolve and process its traffic (#whenResolved:).

I am having some trouble with figuring out my own process architecture and services. I believe I have the event loop restarting if it blows up, but with a loop guard requiring a #running state (#stopping isFalse). I believe I am passing Halts up the stack. I am trying to reschedule the context copy through the vat, when a VatSemaphore is signaled. Trying to create a pool of event pending contexts to get rescheduled so, my efforts are not quite right and it is Process/Exception handling. Extremely complicated for Noobs. I am unsure!

My plan was to port PromisesLocal over and onto and get all the PromiseTests tests running. As I was needing to modify them for the async resolution, I was going to get them all passing, then unload the PromisesLocal and verify the Kernel-Tests work in the updated trunk. Then publish the Tests to the Inbox, would be my first time! Make sure all is coebatany, then publish PromisesLocal for considerations of bringing that ELib model into trunk Squeak, with all of its corresponding PromisesLocal Tests #Green.

I am proposing a deep change, in an area you developed and extended into your Actors model. It underlies a greeat work orf yours, so geil to always see happening in Squeak!!! Again, vollständig geil!

My PromisesRemote brings a remote messaging solution. I am unsure whether your Promises or Actors are remote aware. PromisesRemote are #green (aside from 3-way and the Galaxy Object Scenario [1] being broken). Its core are the proxy references that mutate through their state, forwarding all traffic, at the right time.

Speaking of only PromisesLocal, as to her ability to reimplement your Promise; having a Resolver object is powerful and a good place to control the manner in which a value manifests. All activity outgoing or incoming is interleaved through the Vat's priority queues. It is a strong guarantee of thread-safe activity. The #becoming of Promises into References or Broken, is an interesting feature that really helps one chain pipelined promises, is PPPS [2]. It's core is the EventualProcess running contexts, as the Vat pumps them in priority [#1-#4] order.

[1] Galaxy Object Scenario - https://www.dropbox.com/s/5rxwno7heimimx2/The%20GalaxyObject%20scenario%20repaired.pdf?dl=0
[2] PPS - PromisePipeliningProgrammingStyle

Kindly,
Robert

Cheers,
Tony

--
K, r

Squeak - Dev mailing list

Re: Multiple processes and morphic state (was Re: Changeset: Eliminating global state from Morphic)

In reply to this post by Christoph Thiede

My current #RED code in progress to these ends are:

http://www.squeaksource.com/Oceanside/PromisesLocal-rww.12.mcz

http://www.squeaksource.com/Oceanside/PromisesLocal-KernelTests-rww.383.mcz

K, r

On 9/25/20 9:42 PM, Robert Withers wrote:

Hi Tony, I am excited to conversate with you, regarding Promises. Vollständig geil!

Von: Tony Garnock-Jones [hidden email]

Gesendet: Freitag, 25. September 2020 16:55:23
An: The general-purpose Squeak developers list; Thiede, Christoph
Betreff: Multiple processes and morphic state (was Re: Changeset: Eliminating global state from Morphic)

Hi Christoph,

On 9/24/20 2:08 PM, Thiede, Christoph wrote:
>> It's true that in Morphic there is one distinct Process associated
> with the user interface for each Morphic world.
>
> I'm not so sure about this. You can always do forks within UI code, so
> sometimes there are also multiple Processes within one Morphic world.
> Just think about Shout's background process or debugging processes, and
> please keep in mind that Jakob justifiably proposed to renew the process
> handling for non-modal dialogs, which maybe could also result in
> multiple processes being active at the same time.
> A world can have multiple hands, for example, RemoteHandMorphs
> (Nebraska), event-simulating hands (EventRecorder), or just
> multiple plain HandMorphs as demonstrated by Tony recently in
> his PostmarketOS implementation. There is no reason for these hands to
> run on the same process. Analogously, I don't see why we should restrict
> a hand not to be thread-safe, so the hand-event relation is 1:n again.

I've found that while, yes, there are lots of opportunities for
concurrency in Morphic, actually *taking* those opportunities results in
all sorts of problems.

Morphic state is I think not thread-safe enough to allow multiple
processes "inside" of it at once.

So I've ended up being *very* careful to serialize all Morphic access
within the one, main UI process. Where other processes (Actors) exist, I
send messages from the UI process to the others, and when Morphic state
change code has to run, I package it up into a block and enqueue it for
later execution by the UI process rather than doing it in each Actor.

(It's painful, actually, having to be so careful about it, in such a
C-style "you do all the work yourself and the system won't help you"
manner. Maybe there's something we can improve here?)

So I think it's *morally* true that "there is one distinct Process
associated with the user interface for each Morphic world," even if as a
rule it can be bent a little :-)

This would be sa-super spot to put a Vat, running an event loop, with a proscribed way to submit a new context through its queue.

I have gotten super-lazy about it, am watching Jen Aniston's show The Morning Show and other avoidance behaviors (Totally Awsome!). I am halfway through getting tests to work.

I maybe 65% there in porting ELibs PromisesLocal as the implementation behind your Promise/A* protocol interface. The main issue is your Promise can immediately resolve to a value, whereas ELibs event loop has to process the resolution async, so many tests need a small delay to allow the Promise to resolve and process its traffic (#whenResolved:).

I am having some trouble with figuring out my own process architecture and services. I believe I have the event loop restarting if it blows up, but with a loop guard requiring a #running state (#stopping isFalse). I believe I am passing Halts up the stack. I am trying to reschedule the context copy through the vat, when a VatSemaphore is signaled. Trying to create a pool of event pending contexts to get rescheduled so, my efforts are not quite right and it is Process/Exception handling. Extremely complicated for Noobs. I am unsure!

My plan was to port PromisesLocal over and onto and get all the PromiseTests tests running. As I was needing to modify them for the async resolution, I was going to get them all passing, then unload the PromisesLocal and verify the Kernel-Tests work in the updated trunk. Then publish the Tests to the Inbox, would be my first time! Make sure all is coebatany, then publish PromisesLocal for considerations of bringing that ELib model into trunk Squeak, with all of its corresponding PromisesLocal Tests #Green.

I am proposing a deep change, in an area you developed and extended into your Actors model. It underlies a greeat work orf yours, so geil to always see happening in Squeak!!! Again, vollständig geil!

My PromisesRemote brings a remote messaging solution. I am unsure whether your Promises or Actors are remote aware. PromisesRemote are #green (aside from 3-way and the Galaxy Object Scenario [1] being broken). Its core are the proxy references that mutate through their state, forwarding all traffic, at the right time.

Speaking of only PromisesLocal, as to her ability to reimplement your Promise; having a Resolver object is powerful and a good place to control the manner in which a value manifests. All activity outgoing or incoming is interleaved through the Vat's priority queues. It is a strong guarantee of thread-safe activity. The #becoming of Promises into References or Broken, is an interesting feature that really helps one chain pipelined promises, is PPPS [2]. It's core is the EventualProcess running contexts, as the Vat pumps them in priority [#1-#4] order.

[1] Galaxy Object Scenario - https://www.dropbox.com/s/5rxwno7heimimx2/The%20GalaxyObject%20scenario%20repaired.pdf?dl=0
[2] PPS - PromisePipeliningProgrammingStyle

Kindly,
Robert

Cheers,
Tony

--
K, r

--
K, r

marcel.taeumel

Re: Changeset: Eliminating global state from Morphic

In reply to this post by Christoph Thiede

Hi Christoph.

>> It's true that in Morphic there is one distinct Process associated

>> with the user interface for each Morphic world.

> I'm not so sure about this. You can always do forks within UI code,

> so sometimes there are also multiple Processes within one Morphic

> world. Just think about Shout's background process or debugging

> processes, and please keep in mind that Jakob justifiably proposed to

> renew the process handling for non-modal dialogs, which maybe could

> also result in multiple processes being active at the same time.

There is (and should) only be a single UI process running in Morphic at any time. All other processes that can be scheduled must synchronize with that single UI process when doing UI stuff. Shout, for example, does that via #addDeferredUIMessage:, which is effectively a SharedQueue (using a Mutex or similar). Having two UI processes running (or be scheduled) at the same time will produce strange side effects or even lock up the image. I don't know. At least, things will slow down.

You could change that by re-desiging the ownership partitioning of UI objects. Even then, there will be some process responsible for a set of UI objects. All other processes must synchronize into that one when talking to those (foreign) UI objects.

I forgot. When does process switching happen through higher-priority processes having a semaphore ready (i.e. Delay >> #wait)? At byte-code level? Oder message-send level? Well, you might not see the effects of omitting such process synchronization immediately. However, occasionally, debuggers with "nil does not understand" may pop up. Causing you headaches. :-)

Best,

Marcel

Am 24.09.2020 14:08:56 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

sorry for the long delay on this issue. I'm attaching a new version of the changeset including the following changes:

* Use DynamicVariables for storing the active variable states

* Refactor and reduce the visibility of active variable accessors on Object

* Clean up implementations of #activeHand and #primaryHand

@Dave I think associating these objects to Process is an implementation detail of DynamicVariables which I would not like to denigrate in general.

> It's true that in Morphic there is one distinct Process associated with the user interface for each Morphic world.

I'm not so sure about this. You can always do forks within UI code, so sometimes there are also multiple Processes within one Morphic world. Just think about Shout's background process or debugging processes, and please keep in mind that Jakob justifiably proposed to renew the process handling for non-modal dialogs, which maybe could also result in multiple processes being active at the same time.

A world can have multiple hands, for example, RemoteHandMorphs (Nebraska), event-simulating hands (EventRecorder), or just multiple plain HandMorphs as demonstrated by Tony recently in his PostmarketOS implementation. There is no reason for these hands to run on the same process. Analogously, I don't see why we should restrict a hand not to be thread-safe, so the hand-event relation is 1:n again.

PS: Thanks for the hint to the new wiki page!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Montag, 14. September 2020 17:49:34
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

On Mon, Sep 14, 2020 at 11:17:53AM +0000, Thiede, Christoph wrote:
> Hi Dave,
>
>
> I agree that could try to place the active variables at better places than the most generic Object class. Still, I am not sure whether you are arguing against the thread-local storage of their values - which I do find pretty important for enabling concurrency.
>
>
> Of course, we could move my proposed implementation #activeWorld down to Project, and on Object, forward the request to "Project current activeWorld". Still, I do not think that an instance variable would be the right way to store the world, because it is not thread-local. If you would like to do this, we should implement some kind of PluggableThreadLocalVariable as proposed below, and store an instance of this class in Project.
>
>
> What do you think?
>

Hi Christoph,

The thing that I like (a lot) about your changes is that they make it
much easier to see and understand the accesses to the global variables.
The references now all go through a small number of methods in Object,
so that you can see what they do now.

Clearly we would want to leave this logic in Object, since we don't
want to add more clutter to its protocol. But you have collected the logic
in one place now, which makes it easier to think about where it ultimately
should go, and that's great.

But where do these things actually belong? Thinking in terms of the
responsiblities of objects in the system [1], I don't think that associating
them with a Process seems to be a good fit. It's true that in Morphic there
is one distinct Process associated with the user interface for each Morphic
world. So you can make things work by associating these variables with
a Process, but it seems like an unnatural fit to me. A Morphic world has
a process, but a Process is not responsible for knowing the state of
the Morphic world.

Dave

[1] https://en.wikipedia.org/wiki/Responsibility-driven_design#:~:text=Responsibility%2Ddriven%20design%20is%20a,information%20that%20the%20object%20shares.

Christoph Thiede

Re: Changeset: Eliminating global state from Morphic

Hi all,

Dave, I double-checked it. When loading the second changeset, can you confirm that you used the new option in the drop handler dialog?

Marcel, I absolutely see that you should not run two UI processes side by side in the sense that both of them handle events at the same time. (As a consequence of some attempts in my image, I accidentally ran into this situation a few times (2 worlds active at the same time), and in practice, about every second event is just ignored.) I was only talking about deferred event-handling actions, such as:

mouseDown: anEvent

[|result|

result := self doLongComputation.

self currentHand attachMorph: result asMorph] fork.

In this trivial example, a deferred UI message for attaching the morph would obviously be the better choice, but in other examples, this is not so easy, for example when some application logic raises a FileDoesNotExistException which opens some UI stuff again ... We could, of course, try to use more deferred UI messages in such cases and maybe use Promises or some other mechanism to resume the background process after that, but I am not sure we can completely get rid of any sends to activeHand, activeWorld, and activeEvent in every non-UI process.

What do you think? :-)

Best,

Christoph

Von: Taeumel, Marcel
Gesendet: Montag, 28. September 2020 11:01:05
An: Thiede, Christoph; squeak-dev
Betreff: Re: AW: [squeak-dev] Changeset: Eliminating global state from Morphic

Hi Christoph.

>> It's true that in Morphic there is one distinct Process associated

>> with the user interface for each Morphic world.

> I'm not so sure about this. You can always do forks within UI code,

> so sometimes there are also multiple Processes within one Morphic

> world. Just think about Shout's background process or debugging

> processes, and please keep in mind that Jakob justifiably proposed to

> renew the process handling for non-modal dialogs, which maybe could

> also result in multiple processes being active at the same time.

Best,

Marcel

Am 24.09.2020 14:08:56 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

sorry for the long delay on this issue. I'm attaching a new version of the changeset including the following changes:

* Use DynamicVariables for storing the active variable states

* Refactor and reduce the visibility of active variable accessors on Object

* Clean up implementations of #activeHand and #primaryHand

@Dave I think associating these objects to Process is an implementation detail of DynamicVariables which I would not like to denigrate in general.

> It's true that in Morphic there is one distinct Process associated with the user interface for each Morphic world.

I'm not so sure about this. You can always do forks within UI code, so sometimes there are also multiple Processes within one Morphic world. Just think about Shout's background process or debugging processes, and please keep in mind that Jakob justifiably proposed to renew the process handling for non-modal dialogs, which maybe could also result in multiple processes being active at the same time.

A world can have multiple hands, for example, RemoteHandMorphs (Nebraska), event-simulating hands (EventRecorder), or just multiple plain HandMorphs as demonstrated by Tony recently in his PostmarketOS implementation. There is no reason for these hands to run on the same process. Analogously, I don't see why we should restrict a hand not to be thread-safe, so the hand-event relation is 1:n again.

PS: Thanks for the hint to the new wiki page!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Montag, 14. September 2020 17:49:34
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

On Mon, Sep 14, 2020 at 11:17:53AM +0000, Thiede, Christoph wrote:
> Hi Dave,
>
>
> I agree that could try to place the active variables at better places than the most generic Object class. Still, I am not sure whether you are arguing against the thread-local storage of their values - which I do find pretty important for enabling concurrency.
>
>
> Of course, we could move my proposed implementation #activeWorld down to Project, and on Object, forward the request to "Project current activeWorld". Still, I do not think that an instance variable would be the right way to store the world, because it is not thread-local. If you would like to do this, we should implement some kind of PluggableThreadLocalVariable as proposed below, and store an instance of this class in Project.
>
>
> What do you think?
>

Hi Christoph,

The thing that I like (a lot) about your changes is that they make it
much easier to see and understand the accesses to the global variables.
The references now all go through a small number of methods in Object,
so that you can see what they do now.

Clearly we would want to leave this logic in Object, since we don't
want to add more clutter to its protocol. But you have collected the logic
in one place now, which makes it easier to think about where it ultimately
should go, and that's great.

But where do these things actually belong? Thinking in terms of the
responsiblities of objects in the system [1], I don't think that associating
them with a Process seems to be a good fit. It's true that in Morphic there
is one distinct Process associated with the user interface for each Morphic
world. So you can make things work by associating these variables with
a Process, but it seems like an unnatural fit to me. A Morphic world has
a process, but a Process is not responsible for knowing the state of
the Morphic world.

Dave

[1] https://en.wikipedia.org/wiki/Responsibility-driven_design#:~:text=Responsibility%2Ddriven%20design%20is%20a,information%20that%20the%20object%20shares.

pastedImage.png (38K) Download Attachment

Carpe Squeak!

marcel.taeumel

Re: Changeset: Eliminating global state from Morphic

Hi Christoph.

> In this trivial example, a deferred UI message for attaching the morph would obviously be the better choice

Not only better but the only correct way without risking debuggers. ;-) You should not just #fork UI code or any code for that matter that makes shared use of an object. In your example, the problems come through the use of "self" as well as the access to hand morph.

Don't do it. Never. Please. Avoid #fork for such things. Use #deferredUIMessages.

Best,

Marcel

Am 28.09.2020 12:55:46 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

Dave, I double-checked it. When loading the second changeset, can you confirm that you used the new option in the drop handler dialog?

Marcel, I absolutely see that you should not run two UI processes side by side in the sense that both of them handle events at the same time. (As a consequence of some attempts in my image, I accidentally ran into this situation a few times (2 worlds active at the same time), and in practice, about every second event is just ignored.) I was only talking about deferred event-handling actions, such as:

mouseDown: anEvent

[|result|

result := self doLongComputation.

self currentHand attachMorph: result asMorph] fork.

In this trivial example, a deferred UI message for attaching the morph would obviously be the better choice, but in other examples, this is not so easy, for example when some application logic raises a FileDoesNotExistException which opens some UI stuff again ... We could, of course, try to use more deferred UI messages in such cases and maybe use Promises or some other mechanism to resume the background process after that, but I am not sure we can completely get rid of any sends to activeHand, activeWorld, and activeEvent in every non-UI process.

What do you think? :-)

Best,

Christoph

Von: Taeumel, Marcel
Gesendet: Montag, 28. September 2020 11:01:05
An: Thiede, Christoph; squeak-dev
Betreff: Re: AW: [squeak-dev] Changeset: Eliminating global state from Morphic

Hi Christoph.

>> It's true that in Morphic there is one distinct Process associated

>> with the user interface for each Morphic world.

> I'm not so sure about this. You can always do forks within UI code,

> so sometimes there are also multiple Processes within one Morphic

> world. Just think about Shout's background process or debugging

> processes, and please keep in mind that Jakob justifiably proposed to

> renew the process handling for non-modal dialogs, which maybe could

> also result in multiple processes being active at the same time.

There is (and should) only be a single UI process running in Morphic at any time. All other processes that can be scheduled must synchronize with that single UI process when doing UI stuff. Shout, for example, does that via #addDeferredUIMessage:, which is effectively a SharedQueue (using a Mutex or similar). Having two UI processes running (or be scheduled) at the same time will produce strange side effects or even lock up the image. I don't know. At least, things will slow down.

You could change that by re-desiging the ownership partitioning of UI objects. Even then, there will be some process responsible for a set of UI objects. All other processes must synchronize into that one when talking to those (foreign) UI objects.

I forgot. When does process switching happen through higher-priority processes having a semaphore ready (i.e. Delay >> #wait)? At byte-code level? Oder message-send level? Well, you might not see the effects of omitting such process synchronization immediately. However, occasionally, debuggers with "nil does not understand" may pop up. Causing you headaches. :-)

Best,

Marcel

Am 24.09.2020 14:08:56 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

sorry for the long delay on this issue. I'm attaching a new version of the changeset including the following changes:

* Use DynamicVariables for storing the active variable states

* Refactor and reduce the visibility of active variable accessors on Object

* Clean up implementations of #activeHand and #primaryHand

@Dave I think associating these objects to Process is an implementation detail of DynamicVariables which I would not like to denigrate in general.

> It's true that in Morphic there is one distinct Process associated with the user interface for each Morphic world.

I'm not so sure about this. You can always do forks within UI code, so sometimes there are also multiple Processes within one Morphic world. Just think about Shout's background process or debugging processes, and please keep in mind that Jakob justifiably proposed to renew the process handling for non-modal dialogs, which maybe could also result in multiple processes being active at the same time.

A world can have multiple hands, for example, RemoteHandMorphs (Nebraska), event-simulating hands (EventRecorder), or just multiple plain HandMorphs as demonstrated by Tony recently in his PostmarketOS implementation. There is no reason for these hands to run on the same process. Analogously, I don't see why we should restrict a hand not to be thread-safe, so the hand-event relation is 1:n again.

PS: Thanks for the hint to the new wiki page!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Montag, 14. September 2020 17:49:34
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

On Mon, Sep 14, 2020 at 11:17:53AM +0000, Thiede, Christoph wrote:
> Hi Dave,
>
>
> I agree that could try to place the active variables at better places than the most generic Object class. Still, I am not sure whether you are arguing against the thread-local storage of their values - which I do find pretty important for enabling concurrency.
>
>
> Of course, we could move my proposed implementation #activeWorld down to Project, and on Object, forward the request to "Project current activeWorld". Still, I do not think that an instance variable would be the right way to store the world, because it is not thread-local. If you would like to do this, we should implement some kind of PluggableThreadLocalVariable as proposed below, and store an instance of this class in Project.
>
>
> What do you think?
>

Hi Christoph,

The thing that I like (a lot) about your changes is that they make it
much easier to see and understand the accesses to the global variables.
The references now all go through a small number of methods in Object,
so that you can see what they do now.

Clearly we would want to leave this logic in Object, since we don't
want to add more clutter to its protocol. But you have collected the logic
in one place now, which makes it easier to think about where it ultimately
should go, and that's great.

But where do these things actually belong? Thinking in terms of the
responsiblities of objects in the system [1], I don't think that associating
them with a Process seems to be a good fit. It's true that in Morphic there
is one distinct Process associated with the user interface for each Morphic
world. So you can make things work by associating these variables with
a Process, but it seems like an unnatural fit to me. A Morphic world has
a process, but a Process is not responsible for knowing the state of
the Morphic world.

Dave

[1] https://en.wikipedia.org/wiki/Responsibility-driven_design#:~:text=Responsibility%2Ddriven%20design%20is%20a,information%20that%20the%20object%20shares.

marcel.taeumel

Re: Changeset: Eliminating global state from Morphic

Hi, all!

> Don't do it. Never. Please. Avoid #fork for such things. Use #deferredUIMessages.

Let me clarify this a little bit more. :-) Given that the OpenSmalltalk VM offers cooperative process scheduling with priority-based interrupting and round-robin for each priority level, a simple #fork from the UI process will do no harm. That forked process will get the same priority as the UI process and thus safely run (and likely finish) the next time the UI process yields after each cycle. However, Squeak is in the lucky position to enable experimentation with in-image process scheduling algorithms ... if you fancy. :-) Writing code that relys on the current scheduling behavior may break for those experiments. Given that we already have those deferred-ui-messages, there is no reason not to use them.

Best,

Marcel

Am 28.09.2020 13:00:06 schrieb Marcel Taeumel <[hidden email]>:
Hi Christoph.

> In this trivial example, a deferred UI message for attaching the morph would obviously be the better choice

Not only better but the only correct way without risking debuggers. ;-) You should not just #fork UI code or any code for that matter that makes shared use of an object. In your example, the problems come through the use of "self" as well as the access to hand morph.

Don't do it. Never. Please. Avoid #fork for such things. Use #deferredUIMessages.

Best,
Marcel

Am 28.09.2020 12:55:46 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

Dave, I double-checked it. When loading the second changeset, can you confirm that you used the new option in the drop handler dialog?

Marcel, I absolutely see that you should not run two UI processes side by side in the sense that both of them handle events at the same time. (As a consequence of some attempts in my image, I accidentally ran into this situation a few times (2 worlds active at the same time), and in practice, about every second event is just ignored.) I was only talking about deferred event-handling actions, such as:

mouseDown: anEvent

[|result|

result := self doLongComputation.

self currentHand attachMorph: result asMorph] fork.

In this trivial example, a deferred UI message for attaching the morph would obviously be the better choice, but in other examples, this is not so easy, for example when some application logic raises a FileDoesNotExistException which opens some UI stuff again ... We could, of course, try to use more deferred UI messages in such cases and maybe use Promises or some other mechanism to resume the background process after that, but I am not sure we can completely get rid of any sends to activeHand, activeWorld, and activeEvent in every non-UI process.

What do you think? :-)

Best,

Christoph

Von: Taeumel, Marcel
Gesendet: Montag, 28. September 2020 11:01:05
An: Thiede, Christoph; squeak-dev
Betreff: Re: AW: [squeak-dev] Changeset: Eliminating global state from Morphic

Hi Christoph.

>> It's true that in Morphic there is one distinct Process associated

>> with the user interface for each Morphic world.

> I'm not so sure about this. You can always do forks within UI code,

> so sometimes there are also multiple Processes within one Morphic

> world. Just think about Shout's background process or debugging

> processes, and please keep in mind that Jakob justifiably proposed to

> renew the process handling for non-modal dialogs, which maybe could

> also result in multiple processes being active at the same time.

There is (and should) only be a single UI process running in Morphic at any time. All other processes that can be scheduled must synchronize with that single UI process when doing UI stuff. Shout, for example, does that via #addDeferredUIMessage:, which is effectively a SharedQueue (using a Mutex or similar). Having two UI processes running (or be scheduled) at the same time will produce strange side effects or even lock up the image. I don't know. At least, things will slow down.

You could change that by re-desiging the ownership partitioning of UI objects. Even then, there will be some process responsible for a set of UI objects. All other processes must synchronize into that one when talking to those (foreign) UI objects.

I forgot. When does process switching happen through higher-priority processes having a semaphore ready (i.e. Delay >> #wait)? At byte-code level? Oder message-send level? Well, you might not see the effects of omitting such process synchronization immediately. However, occasionally, debuggers with "nil does not understand" may pop up. Causing you headaches. :-)

Best,

Marcel

Am 24.09.2020 14:08:56 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

sorry for the long delay on this issue. I'm attaching a new version of the changeset including the following changes:

* Use DynamicVariables for storing the active variable states

* Refactor and reduce the visibility of active variable accessors on Object

* Clean up implementations of #activeHand and #primaryHand

@Dave I think associating these objects to Process is an implementation detail of DynamicVariables which I would not like to denigrate in general.

> It's true that in Morphic there is one distinct Process associated with the user interface for each Morphic world.

I'm not so sure about this. You can always do forks within UI code, so sometimes there are also multiple Processes within one Morphic world. Just think about Shout's background process or debugging processes, and please keep in mind that Jakob justifiably proposed to renew the process handling for non-modal dialogs, which maybe could also result in multiple processes being active at the same time.

A world can have multiple hands, for example, RemoteHandMorphs (Nebraska), event-simulating hands (EventRecorder), or just multiple plain HandMorphs as demonstrated by Tony recently in his PostmarketOS implementation. There is no reason for these hands to run on the same process. Analogously, I don't see why we should restrict a hand not to be thread-safe, so the hand-event relation is 1:n again.

PS: Thanks for the hint to the new wiki page!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Montag, 14. September 2020 17:49:34
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

On Mon, Sep 14, 2020 at 11:17:53AM +0000, Thiede, Christoph wrote:
> Hi Dave,
>
>
> I agree that could try to place the active variables at better places than the most generic Object class. Still, I am not sure whether you are arguing against the thread-local storage of their values - which I do find pretty important for enabling concurrency.
>
>
> Of course, we could move my proposed implementation #activeWorld down to Project, and on Object, forward the request to "Project current activeWorld". Still, I do not think that an instance variable would be the right way to store the world, because it is not thread-local. If you would like to do this, we should implement some kind of PluggableThreadLocalVariable as proposed below, and store an instance of this class in Project.
>
>
> What do you think?
>

Hi Christoph,

The thing that I like (a lot) about your changes is that they make it
much easier to see and understand the accesses to the global variables.
The references now all go through a small number of methods in Object,
so that you can see what they do now.

Clearly we would want to leave this logic in Object, since we don't
want to add more clutter to its protocol. But you have collected the logic
in one place now, which makes it easier to think about where it ultimately
should go, and that's great.

But where do these things actually belong? Thinking in terms of the
responsiblities of objects in the system [1], I don't think that associating
them with a Process seems to be a good fit. It's true that in Morphic there
is one distinct Process associated with the user interface for each Morphic
world. So you can make things work by associating these variables with
a Process, but it seems like an unnatural fit to me. A Morphic world has
a process, but a Process is not responsible for knowing the state of
the Morphic world.

Dave

[1] https://en.wikipedia.org/wiki/Responsibility-driven_design#:~:text=Responsibility%2Ddriven%20design%20is%20a,information%20that%20the%20object%20shares.

Christoph Thiede

Re: Changeset: Eliminating global state from Morphic

Hi Marcel,

probably the example I have given was oversimplified. Please give me another chance to give a better example. :-)

Imagine a CalculatorMorph, which has the purpose to run an expensive computation (#doExpensiveComputation). When the morph is clicked, it should start the computation, and when it is clicked again, it should abort the computation. During the computation, unfortunately, an error could be raised which's handling logic might communicate to UI elements (such as a FileDoesNotExistException (#inform:) or a SyntaxError (#openAsTool)).

So I would implement #mouseDown: in the following way:

mouseDown: anEvent

status caseOf: {

[#ready] -> [

computation := [

result := self doExpensiveComputation.

self world addDeferredUIMessage: [

self showResult: result]] forkAt: Processor userBackgroundPriority.

self status: #computing].

[#computing] -> [

computation terminate.

self status: #ready] }

Isn't this a justified reason to use forks in UI code? :-)

Best,

Christoph

Von: Taeumel, Marcel
Gesendet: Montag, 28. September 2020 13:14:26
An: Thiede, Christoph; squeak-dev
Betreff: Re: AW: AW: [squeak-dev] Changeset: Eliminating global state from Morphic

Hi, all!

> Don't do it. Never. Please. Avoid #fork for such things. Use #deferredUIMessages.

Best,

Marcel

Am 28.09.2020 13:00:06 schrieb Marcel Taeumel <[hidden email]>:

Hi Christoph.

> In this trivial example, a deferred UI message for attaching the morph would obviously be the better choice

Not only better but the only correct way without risking debuggers. ;-) You should not just #fork UI code or any code for that matter that makes shared use of an object. In your example, the problems come through the use of "self" as well as the access to hand morph.

Don't do it. Never. Please. Avoid #fork for such things. Use #deferredUIMessages.

Best,

Marcel

Am 28.09.2020 12:55:46 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

Dave, I double-checked it. When loading the second changeset, can you confirm that you used the new option in the drop handler dialog?

Marcel, I absolutely see that you should not run two UI processes side by side in the sense that both of them handle events at the same time. (As a consequence of some attempts in my image, I accidentally ran into this situation a few times (2 worlds active at the same time), and in practice, about every second event is just ignored.) I was only talking about deferred event-handling actions, such as:

mouseDown: anEvent

[|result|

result := self doLongComputation.

self currentHand attachMorph: result asMorph] fork.

In this trivial example, a deferred UI message for attaching the morph would obviously be the better choice, but in other examples, this is not so easy, for example when some application logic raises a FileDoesNotExistException which opens some UI stuff again ... We could, of course, try to use more deferred UI messages in such cases and maybe use Promises or some other mechanism to resume the background process after that, but I am not sure we can completely get rid of any sends to activeHand, activeWorld, and activeEvent in every non-UI process.

What do you think? :-)

Best,

Christoph

Von: Taeumel, Marcel
Gesendet: Montag, 28. September 2020 11:01:05
An: Thiede, Christoph; squeak-dev
Betreff: Re: AW: [squeak-dev] Changeset: Eliminating global state from Morphic

Hi Christoph.

>> It's true that in Morphic there is one distinct Process associated

>> with the user interface for each Morphic world.

> I'm not so sure about this. You can always do forks within UI code,

> so sometimes there are also multiple Processes within one Morphic

> world. Just think about Shout's background process or debugging

> processes, and please keep in mind that Jakob justifiably proposed to

> renew the process handling for non-modal dialogs, which maybe could

> also result in multiple processes being active at the same time.

There is (and should) only be a single UI process running in Morphic at any time. All other processes that can be scheduled must synchronize with that single UI process when doing UI stuff. Shout, for example, does that via #addDeferredUIMessage:, which is effectively a SharedQueue (using a Mutex or similar). Having two UI processes running (or be scheduled) at the same time will produce strange side effects or even lock up the image. I don't know. At least, things will slow down.

You could change that by re-desiging the ownership partitioning of UI objects. Even then, there will be some process responsible for a set of UI objects. All other processes must synchronize into that one when talking to those (foreign) UI objects.

I forgot. When does process switching happen through higher-priority processes having a semaphore ready (i.e. Delay >> #wait)? At byte-code level? Oder message-send level? Well, you might not see the effects of omitting such process synchronization immediately. However, occasionally, debuggers with "nil does not understand" may pop up. Causing you headaches. :-)

Best,

Marcel

Am 24.09.2020 14:08:56 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

sorry for the long delay on this issue. I'm attaching a new version of the changeset including the following changes:

* Use DynamicVariables for storing the active variable states

* Refactor and reduce the visibility of active variable accessors on Object

* Clean up implementations of #activeHand and #primaryHand

@Dave I think associating these objects to Process is an implementation detail of DynamicVariables which I would not like to denigrate in general.

> It's true that in Morphic there is one distinct Process associated with the user interface for each Morphic world.

I'm not so sure about this. You can always do forks within UI code, so sometimes there are also multiple Processes within one Morphic world. Just think about Shout's background process or debugging processes, and please keep in mind that Jakob justifiably proposed to renew the process handling for non-modal dialogs, which maybe could also result in multiple processes being active at the same time.

A world can have multiple hands, for example, RemoteHandMorphs (Nebraska), event-simulating hands (EventRecorder), or just multiple plain HandMorphs as demonstrated by Tony recently in his PostmarketOS implementation. There is no reason for these hands to run on the same process. Analogously, I don't see why we should restrict a hand not to be thread-safe, so the hand-event relation is 1:n again.

PS: Thanks for the hint to the new wiki page!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Montag, 14. September 2020 17:49:34
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

On Mon, Sep 14, 2020 at 11:17:53AM +0000, Thiede, Christoph wrote:
> Hi Dave,
>
>
> I agree that could try to place the active variables at better places than the most generic Object class. Still, I am not sure whether you are arguing against the thread-local storage of their values - which I do find pretty important for enabling concurrency.
>
>
> Of course, we could move my proposed implementation #activeWorld down to Project, and on Object, forward the request to "Project current activeWorld". Still, I do not think that an instance variable would be the right way to store the world, because it is not thread-local. If you would like to do this, we should implement some kind of PluggableThreadLocalVariable as proposed below, and store an instance of this class in Project.
>
>
> What do you think?
>

Hi Christoph,

The thing that I like (a lot) about your changes is that they make it
much easier to see and understand the accesses to the global variables.
The references now all go through a small number of methods in Object,
so that you can see what they do now.

Clearly we would want to leave this logic in Object, since we don't
want to add more clutter to its protocol. But you have collected the logic
in one place now, which makes it easier to think about where it ultimately
should go, and that's great.

But where do these things actually belong? Thinking in terms of the
responsiblities of objects in the system [1], I don't think that associating
them with a Process seems to be a good fit. It's true that in Morphic there
is one distinct Process associated with the user interface for each Morphic
world. So you can make things work by associating these variables with
a Process, but it seems like an unnatural fit to me. A Morphic world has
a process, but a Process is not responsible for knowing the state of
the Morphic world.

Dave

[1] https://en.wikipedia.org/wiki/Responsibility-driven_design#:~:text=Responsibility%2Ddriven%20design%20is%20a,information%20that%20the%20object%20shares.

Carpe Squeak!

marcel.taeumel

Re: Changeset: Eliminating global state from Morphic

Hi Christoph.

Of course. That's what Shout does. Yet, you have to ensure that you only work on your own objects in #doExpensiveComputation. You can make a #copy like Shout does.

Best,

Marcel

Am 28.09.2020 13:40:54 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,

probably the example I have given was oversimplified. Please give me another chance to give a better example. :-)

Imagine a CalculatorMorph, which has the purpose to run an expensive computation (#doExpensiveComputation). When the morph is clicked, it should start the computation, and when it is clicked again, it should abort the computation. During the computation, unfortunately, an error could be raised which's handling logic might communicate to UI elements (such as a FileDoesNotExistException (#inform:) or a SyntaxError (#openAsTool)).

So I would implement #mouseDown: in the following way:

mouseDown: anEvent

status caseOf: {

[#ready] -> [

computation := [

result := self doExpensiveComputation.

self world addDeferredUIMessage: [

self showResult: result]] forkAt: Processor userBackgroundPriority.

self status: #computing].

[#computing] -> [

computation terminate.

self status: #ready] }

Isn't this a justified reason to use forks in UI code? :-)

Best,

Christoph

Von: Taeumel, Marcel
Gesendet: Montag, 28. September 2020 13:14:26
An: Thiede, Christoph; squeak-dev
Betreff: Re: AW: AW: [squeak-dev] Changeset: Eliminating global state from Morphic

Hi, all!

> Don't do it. Never. Please. Avoid #fork for such things. Use #deferredUIMessages.

Let me clarify this a little bit more. :-) Given that the OpenSmalltalk VM offers cooperative process scheduling with priority-based interrupting and round-robin for each priority level, a simple #fork from the UI process will do no harm. That forked process will get the same priority as the UI process and thus safely run (and likely finish) the next time the UI process yields after each cycle. However, Squeak is in the lucky position to enable experimentation with in-image process scheduling algorithms ... if you fancy. :-) Writing code that relys on the current scheduling behavior may break for those experiments. Given that we already have those deferred-ui-messages, there is no reason not to use them.

Best,

Marcel

Am 28.09.2020 13:00:06 schrieb Marcel Taeumel <[hidden email]>:

Hi Christoph.

> In this trivial example, a deferred UI message for attaching the morph would obviously be the better choice

Not only better but the only correct way without risking debuggers. ;-) You should not just #fork UI code or any code for that matter that makes shared use of an object. In your example, the problems come through the use of "self" as well as the access to hand morph.

Don't do it. Never. Please. Avoid #fork for such things. Use #deferredUIMessages.

Best,

Marcel

Am 28.09.2020 12:55:46 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

Dave, I double-checked it. When loading the second changeset, can you confirm that you used the new option in the drop handler dialog?

Marcel, I absolutely see that you should not run two UI processes side by side in the sense that both of them handle events at the same time. (As a consequence of some attempts in my image, I accidentally ran into this situation a few times (2 worlds active at the same time), and in practice, about every second event is just ignored.) I was only talking about deferred event-handling actions, such as:

mouseDown: anEvent

[|result|

result := self doLongComputation.

self currentHand attachMorph: result asMorph] fork.

In this trivial example, a deferred UI message for attaching the morph would obviously be the better choice, but in other examples, this is not so easy, for example when some application logic raises a FileDoesNotExistException which opens some UI stuff again ... We could, of course, try to use more deferred UI messages in such cases and maybe use Promises or some other mechanism to resume the background process after that, but I am not sure we can completely get rid of any sends to activeHand, activeWorld, and activeEvent in every non-UI process.

What do you think? :-)

Best,

Christoph

Von: Taeumel, Marcel
Gesendet: Montag, 28. September 2020 11:01:05
An: Thiede, Christoph; squeak-dev
Betreff: Re: AW: [squeak-dev] Changeset: Eliminating global state from Morphic

Hi Christoph.

>> It's true that in Morphic there is one distinct Process associated

>> with the user interface for each Morphic world.

> I'm not so sure about this. You can always do forks within UI code,

> so sometimes there are also multiple Processes within one Morphic

> world. Just think about Shout's background process or debugging

> processes, and please keep in mind that Jakob justifiably proposed to

> renew the process handling for non-modal dialogs, which maybe could

> also result in multiple processes being active at the same time.

There is (and should) only be a single UI process running in Morphic at any time. All other processes that can be scheduled must synchronize with that single UI process when doing UI stuff. Shout, for example, does that via #addDeferredUIMessage:, which is effectively a SharedQueue (using a Mutex or similar). Having two UI processes running (or be scheduled) at the same time will produce strange side effects or even lock up the image. I don't know. At least, things will slow down.

You could change that by re-desiging the ownership partitioning of UI objects. Even then, there will be some process responsible for a set of UI objects. All other processes must synchronize into that one when talking to those (foreign) UI objects.

I forgot. When does process switching happen through higher-priority processes having a semaphore ready (i.e. Delay >> #wait)? At byte-code level? Oder message-send level? Well, you might not see the effects of omitting such process synchronization immediately. However, occasionally, debuggers with "nil does not understand" may pop up. Causing you headaches. :-)

Best,

Marcel

Am 24.09.2020 14:08:56 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

sorry for the long delay on this issue. I'm attaching a new version of the changeset including the following changes:

* Use DynamicVariables for storing the active variable states

* Refactor and reduce the visibility of active variable accessors on Object

* Clean up implementations of #activeHand and #primaryHand

@Dave I think associating these objects to Process is an implementation detail of DynamicVariables which I would not like to denigrate in general.

> It's true that in Morphic there is one distinct Process associated with the user interface for each Morphic world.

I'm not so sure about this. You can always do forks within UI code, so sometimes there are also multiple Processes within one Morphic world. Just think about Shout's background process or debugging processes, and please keep in mind that Jakob justifiably proposed to renew the process handling for non-modal dialogs, which maybe could also result in multiple processes being active at the same time.

A world can have multiple hands, for example, RemoteHandMorphs (Nebraska), event-simulating hands (EventRecorder), or just multiple plain HandMorphs as demonstrated by Tony recently in his PostmarketOS implementation. There is no reason for these hands to run on the same process. Analogously, I don't see why we should restrict a hand not to be thread-safe, so the hand-event relation is 1:n again.

PS: Thanks for the hint to the new wiki page!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Montag, 14. September 2020 17:49:34
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

On Mon, Sep 14, 2020 at 11:17:53AM +0000, Thiede, Christoph wrote:
> Hi Dave,
>
>
> I agree that could try to place the active variables at better places than the most generic Object class. Still, I am not sure whether you are arguing against the thread-local storage of their values - which I do find pretty important for enabling concurrency.
>
>
> Of course, we could move my proposed implementation #activeWorld down to Project, and on Object, forward the request to "Project current activeWorld". Still, I do not think that an instance variable would be the right way to store the world, because it is not thread-local. If you would like to do this, we should implement some kind of PluggableThreadLocalVariable as proposed below, and store an instance of this class in Project.
>
>
> What do you think?
>

Hi Christoph,

The thing that I like (a lot) about your changes is that they make it
much easier to see and understand the accesses to the global variables.
The references now all go through a small number of methods in Object,
so that you can see what they do now.

Clearly we would want to leave this logic in Object, since we don't
want to add more clutter to its protocol. But you have collected the logic
in one place now, which makes it easier to think about where it ultimately
should go, and that's great.

But where do these things actually belong? Thinking in terms of the
responsiblities of objects in the system [1], I don't think that associating
them with a Process seems to be a good fit. It's true that in Morphic there
is one distinct Process associated with the user interface for each Morphic
world. So you can make things work by associating these variables with
a Process, but it seems like an unnatural fit to me. A Morphic world has
a process, but a Process is not responsible for knowing the state of
the Morphic world.

Dave

[1] https://en.wikipedia.org/wiki/Responsibility-driven_design#:~:text=Responsibility%2Ddriven%20design%20is%20a,information%20that%20the%20object%20shares.

David T. Lewis

Re: Changeset: Eliminating global state from Morphic

In reply to this post by Christoph Thiede

On Mon, Sep 28, 2020 at 10:55:45AM +0000, Thiede, Christoph wrote:
> Hi all,
>
>
> Dave, I double-checked it. When loading the second changeset, can you confirm that you used the new option in the drop handler dialog?
>
>
> [cid:3848a1c6-d67f-4999-a714-ffafff2b4a22]
>

No, I did definitely not do that. I opened a FileList and selected the
change sets one at a time, and clicked install for each. Installing the
second change set locked the image.

After reading your email, I did this:

1) Forwarded your email to my [hidden email] (spam oriented) account
so I could view the graphic attachment, which showed that you are using
drag and drop when you load the change sets.

2) Opened a GUI file browser on my Ubuntu laptop, and used drag and drop
to copy the two change sets to my image.

3) On dropping the second change set into the image, I selected the
"... without updating UI" option.

That worked.

Dave

Christoph Thiede

Re: Changeset: Eliminating global state from Morphic

Hm, probably we should integrate the "filein without UI updates" option into the FileList menu, too ...?

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Mittwoch, 30. September 2020 02:22:06
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

Carpe Squeak!

Christoph Thiede

Re: Changeset: Eliminating global state from Morphic

Here is another version of the changeset that does not even longer raise a debugger when removing the current hand.

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 30. September 2020 11:40:05
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

Hm, probably we should integrate the "filein without UI updates" option into the FileList menu, too ...?

Best,

Christoph

Hide activeVariables.4.cs (329K) Download Attachment

Carpe Squeak!

Christoph Thiede

Re: Changeset: Eliminating global state from Morphic

This version includes a test method, #testActiveVariablesObsoletion, that makes sure that no one will try to reference one of the deprecated ActiveVariable bindings again in the future. Thanks to Marcel for the tip!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 30. September 2020 17:50:43
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

Here is another version of the changeset that does not even longer raise a debugger when removing the current hand.

Best,

Christoph

Hm, probably we should integrate the "filein without UI updates" option into the FileList menu, too ...?

Best,

Christoph

Hide activeVariables.5.cs (346K) Download Attachment

Carpe Squeak!

marcel.taeumel

Re: Changeset: Eliminating global state from Morphic

Hi Christoph, hi all!

The first part of this refactoring is in the Trunk. Please try updating your images and report back!

http://forum.world.st/The-Trunk-Morphic-mt-1697-mcz-td5123173.html

If all went well, I will commit the second part, too, which will remove all remaining references to ActiveWorld etc.

Best,

Marcel

Am 30.09.2020 18:22:43 schrieb Thiede, Christoph <[hidden email]>:

This version includes a test method, #testActiveVariablesObsoletion, that makes sure that no one will try to reference one of the deprecated ActiveVariable bindings again in the future. Thanks to Marcel for the tip!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 30. September 2020 17:50:43
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

Here is another version of the changeset that does not even longer raise a debugger when removing the current hand.

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 30. September 2020 11:40:05
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

Hm, probably we should integrate the "filein without UI updates" option into the FileList menu, too ...?

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Mittwoch, 30. September 2020 02:22:06
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

On Mon, Sep 28, 2020 at 10:55:45AM +0000, Thiede, Christoph wrote:
> Hi all,
>
>
> Dave, I double-checked it. When loading the second changeset, can you confirm that you used the new option in the drop handler dialog?
>
>
> [cid:3848a1c6-d67f-4999-a714-ffafff2b4a22]
>

No, I did definitely not do that. I opened a FileList and selected the
change sets one at a time, and clicked install for each. Installing the
second change set locked the image.

After reading your email, I did this:

1) Forwarded your email to my [hidden email] (spam oriented) account
so I could view the graphic attachment, which showed that you are using
drag and drop when you load the change sets.

2) Opened a GUI file browser on my Ubuntu laptop, and used drag and drop
to copy the two change sets to my image.

3) On dropping the second change set into the image, I selected the
"... without updating UI" option.

That worked.

Dave

Christoph Thiede

Re: Changeset: Eliminating global state from Morphic

Hi Marcel,

thanks for reviewing and splitting up the changes! I confirm that two members of my image farm survived the recent patches without any problem. :D

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Donnerstag, 8. Oktober 2020 17:20:26
An: squeak-dev
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

Hi Christoph, hi all!

The first part of this refactoring is in the Trunk. Please try updating your images and report back!

http://forum.world.st/The-Trunk-Morphic-mt-1697-mcz-td5123173.html

If all went well, I will commit the second part, too, which will remove all remaining references to ActiveWorld etc.

Best,

Marcel

Am 30.09.2020 18:22:43 schrieb Thiede, Christoph <[hidden email]>:

This version includes a test method, #testActiveVariablesObsoletion, that makes sure that no one will try to reference one of the deprecated ActiveVariable bindings again in the future. Thanks to Marcel for the tip!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 30. September 2020 17:50:43
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

Here is another version of the changeset that does not even longer raise a debugger when removing the current hand.

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Thiede, Christoph
Gesendet: Mittwoch, 30. September 2020 11:40:05
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

Hm, probably we should integrate the "filein without UI updates" option into the FileList menu, too ...?

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von David T. Lewis <[hidden email]>
Gesendet: Mittwoch, 30. September 2020 02:22:06
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

On Mon, Sep 28, 2020 at 10:55:45AM +0000, Thiede, Christoph wrote:
> Hi all,
>
>
> Dave, I double-checked it. When loading the second changeset, can you confirm that you used the new option in the drop handler dialog?
>
>
> [cid:3848a1c6-d67f-4999-a714-ffafff2b4a22]
>

No, I did definitely not do that. I opened a FileList and selected the
change sets one at a time, and clicked install for each. Installing the
second change set locked the image.

After reading your email, I did this:

1) Forwarded your email to my [hidden email] (spam oriented) account
so I could view the graphic attachment, which showed that you are using
drag and drop when you load the change sets.

2) Opened a GUI file browser on my Ubuntu laptop, and used drag and drop
to copy the two change sets to my image.

3) On dropping the second change set into the image, I selected the
"... without updating UI" option.

That worked.

Dave

Carpe Squeak!

marcel.taeumel

Re: Changeset: Eliminating global state from Morphic

> Hi Marcel,
>
>
> thanks for reviewing and splitting up the changes! I confirm that two
> members of my image farm survived the recent patches without any problem.
> :D
>
>
> Best,
>
> Christoph
>
> <http://www.hpi.de/>
> ________________________________
> Von: Squeak-dev <

> squeak-dev-bounces@.squeakfoundation

> > im Auftrag von Taeumel, Marcel
> Gesendet: Donnerstag, 8. Oktober 2020 17:20:26
> An: squeak-dev
> Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic
>
> Hi Christoph, hi all!
>
> The first part of this refactoring is in the Trunk. Please try updating
> your images and report back!
> http://forum.world.st/The-Trunk-Morphic-mt-1697-mcz-td5123173.html
>
> If all went well, I will commit the second part, too, which will remove
> all remaining references to ActiveWorld etc.
>
> Best,
> Marcel
>
> Am 30.09.2020 18:22:43 schrieb Thiede, Christoph <

> christoph.thiede@.uni-potsdam

> >:
>
> This version includes a test method, #testActiveVariablesObsoletion, that
> makes sure that no one will try to reference one of the deprecated
> ActiveVariable bindings again in the future. Thanks to Marcel for the tip!
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev <

> squeak-dev-bounces@.squeakfoundation

> > im Auftrag von Thiede, Christoph
> Gesendet: Mittwoch, 30. September 2020 17:50:43
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic
>
>
> Here is another version of the changeset that does not even longer raise a
> debugger when removing the current hand.
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev <

> squeak-dev-bounces@.squeakfoundation

> > im Auftrag von Thiede, Christoph
> Gesendet: Mittwoch, 30. September 2020 11:40:05
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic
>
>
> Hm, probably we should integrate the "filein without UI updates" option
> into the FileList menu, too ...?
>
>
> Best,
>
> Christoph
>
> <http://www.hpi.de/>
> ________________________________
> Von: Squeak-dev <

> squeak-dev-bounces@.squeakfoundation

> > im Auftrag von David T. Lewis <

> lewis@.msen

> >
> Gesendet: Mittwoch, 30. September 2020 02:22:06
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic
>
> On Mon, Sep 28, 2020 at 10:55:45AM +0000, Thiede, Christoph wrote:
>> Hi all,
>>
>>
>> Dave, I double-checked it. When loading the second changeset, can you
>> confirm that you used the new option in the drop handler dialog?
>>
>>
>> [cid:3848a1c6-d67f-4999-a714-ffafff2b4a22]
>>
>
> No, I did definitely not do that. I opened a FileList and selected the
> change sets one at a time, and clicked install for each. Installing the
> second change set locked the image.
>
> After reading your email, I did this:
>
> 1) Forwarded your email to my

> dtlewis290@

> (spam oriented) account
> so I could view the graphic attachment, which showed that you are using
> drag and drop when you load the change sets.
>
> 2) Opened a GUI file browser on my Ubuntu laptop, and used drag and drop
> to copy the two change sets to my image.
>
> 3) On dropping the second change set into the image, I selected the
> "... without updating UI" option.
>
> That worked.
>
> Dave

--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Christoph Thiede

Re: Changeset: Eliminating global state from Morphic

Hi Marcel,

these are reasonable follow-ups, though I think they would be part of another big project, decoupling various packages in Squeak and cleaning up their dependencies.

However, your list looks like a good guide for developers that do not know the differences between these variants. Shall we copy your text somewhere into the wiki?

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Sonntag, 11. Oktober 2020 13:54:23
An: [hidden email]
Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic

Hi Christoph.

It's all in Trunk now. ;-) Here are possible next steps:

1. "Project current world" vs. "self currentWorld"

In all packages that should not be dependent from Morphic, use "Project
current world". Otherwise, use "self currentWorld".

2. "self currentWorld" vs. "self world"

In morphs, try to use "self world" whenever possible. Only class-side
methods should use "self currentWorld". Well, if you have code that should
work with morphs not being installed in any world, use "self currentWorld"
because it will fall back to "Project current world".

3. "self currentHand" in non-Morphic packages (ST80, Tools, etc.)

Well, there are some cases where the use of "self currentHand" adds a
dependency to the Morphic package. Not sure whether we can fix this now or
whether we want to extract object-oriented event handling out of Morphic
first to be used in other graphics frameworks such as ST80, SqueakShell,
etc. :-)

Best,
Marcel

Christoph Thiede wrote
> Hi Marcel,
>
>
> thanks for reviewing and splitting up the changes! I confirm that two
> members of my image farm survived the recent patches without any problem.
> :D
>
>
> Best,
>
> Christoph
>
> <http://www.hpi.de/>
> ________________________________
> Von: Squeak-dev <

> squeak-dev-bounces@.squeakfoundation

> > im Auftrag von Taeumel, Marcel
> Gesendet: Donnerstag, 8. Oktober 2020 17:20:26
> An: squeak-dev
> Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic
>
> Hi Christoph, hi all!
>
> The first part of this refactoring is in the Trunk. Please try updating
> your images and report back!
> http://forum.world.st/The-Trunk-Morphic-mt-1697-mcz-td5123173.html
>
> If all went well, I will commit the second part, too, which will remove
> all remaining references to ActiveWorld etc.
>
> Best,
> Marcel
>
> Am 30.09.2020 18:22:43 schrieb Thiede, Christoph <

> christoph.thiede@.uni-potsdam

> >:
>
> This version includes a test method, #testActiveVariablesObsoletion, that
> makes sure that no one will try to reference one of the deprecated
> ActiveVariable bindings again in the future. Thanks to Marcel for the tip!
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev <

> squeak-dev-bounces@.squeakfoundation

> > im Auftrag von Thiede, Christoph
> Gesendet: Mittwoch, 30. September 2020 17:50:43
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic
>
>
> Here is another version of the changeset that does not even longer raise a
> debugger when removing the current hand.
>
>
> Best,
>
> Christoph
>
> ________________________________
> Von: Squeak-dev <

> squeak-dev-bounces@.squeakfoundation

> > im Auftrag von Thiede, Christoph
> Gesendet: Mittwoch, 30. September 2020 11:40:05
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic
>
>
> Hm, probably we should integrate the "filein without UI updates" option
> into the FileList menu, too ...?
>
>
> Best,
>
> Christoph
>
> <http://www.hpi.de/>
> ________________________________
> Von: Squeak-dev <

> squeak-dev-bounces@.squeakfoundation

> > im Auftrag von David T. Lewis <

> lewis@.msen

> >
> Gesendet: Mittwoch, 30. September 2020 02:22:06
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Changeset: Eliminating global state from Morphic
>
> On Mon, Sep 28, 2020 at 10:55:45AM +0000, Thiede, Christoph wrote:
>> Hi all,
>>
>>
>> Dave, I double-checked it. When loading the second changeset, can you
>> confirm that you used the new option in the drop handler dialog?
>>
>>
>> [cid:3848a1c6-d67f-4999-a714-ffafff2b4a22]
>>
>
> No, I did definitely not do that. I opened a FileList and selected the
> change sets one at a time, and clicked install for each. Installing the
> second change set locked the image.
>
> After reading your email, I did this:
>
> 1) Forwarded your email to my

> dtlewis290@

> (spam oriented) account
> so I could view the graphic attachment, which showed that you are using
> drag and drop when you load the change sets.
>
> 2) Opened a GUI file browser on my Ubuntu laptop, and used drag and drop
> to copy the two change sets to my image.
>
> 3) On dropping the second change set into the image, I selected the
> "... without updating UI" option.
>
> That worked.
>
> Dave

--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Carpe Squeak!

123