I am so grateful you share in my astonishment at the potential power of a promise system. C.f. seeing as how you’ve prepared the Way! I’m so bloody grateful! My dreams seem to coming true! 🙏🏻 God is good.
I’ve several questions below. 🐰
— Have a good one; keep it, light. Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
Sent from Callisto House mobile - Ganymede :: decentralized mobile homeless solutions ::
On Fri, Mar 3, 2023 at 10:41, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 2, 2023, at 11:54 PM, rabbit rabbit@callistohouse.org wrote:
Does a block closure preserve its creating context?
Yes, but not the creating context’s continuation.
Would you explain the difference between a context and a continuation?
Are they to be stored by us?
How do continuations fulfill the debugger stack? Would changes to the debugger be necessary?
•••
Walking the future tree, we could collect the back tree of creating contexts to establish an historical tree. I say tree because reactor #1 was then: immediately after causal send leading to the exception, and the promise got passed around and another belly cat sent a then: for reactor #2, both in the same promise’s pendingSends queue. Therefore the historical view of a future tree is also a tree. So the eventual debugger has a future / historical toggle. And we debug the tree and not the stack.
This is a good idea and could be fine efficiently with the current VM architecture. (*) Promises would be created with the equivalent of “call-cc”, (*) scheme’s call-with-current-continuation. I’ve discussed this with Andreas, Avi Bryant, Colin Putney, and others over the years. It would elevate the level of comprehensibility in future/promise based systems significantly.
Delighted! How should I go about doing this when creating a promise?
Further, because the exception system is first-class, handler search could be extended from the promise’s stack to its enclosing continuation’s stack
If I’m following you, the promise stack is the immediate call stack within a Process, while the enclosing continuation’s ‘stack’ is what and where and how and such?
, which would make managing errors in promises much easier; one would not have to establish an error handler where each promise is created, but could establish a single error handler in the thread that creates promises (etc, this can nest if desired/so implemented).
Yet, reactor #1 could also have been sent outside the causal send context. So we may still want to hold the causal context in the promise / eMsgSend object.
(*) an implementation note for those looking fir a juicy VM project. The essence of call-cc is stack duplication. C.f. the explicit stack duplication in Seaside’s delimited continuations. When call-cc occurs effectively the entire stack is duplicated so that both the creating and the created thread can continue. (for promises this allows us to see where the promise originates long after the creating thread has continued and returned from where it created the promise, which is why this helps with debugging).
I’ve too many other priorities, atm. I’m trying to get the Galaxy Object Scenario running in remote-promises. Yet I’m most curious to file away what’s needed. What VM changes are you suggesting? Support for call-cc when creating Promises or does Seaside’s delimited continuations suffice? Or are you speaking of stack zones support?
I am told that in efficient scheme implementations stack duplication is made lazy. Essentially a flag is set in an activation record that does call-cc that is checked at return time. This causes the activation to be preserved for the call-cc continuation and set for the activation record being returned into, lazily duplicating only those activations that are actually returned from. Neat.
In the Cog VM, executable activation records (contexts) live in a special form on small stack pages in the stack zone. This is done both to avoid having to create context objects until unavoidable (home contexts for blocks, reifying the contexts stack for the debugger, etc), abc to allow the JIT to optimize sends using conventional call instructions. Each stack page is large enough ti hold about 40 normal sized activations (& only one of two huge activations). Having the equivalent of call-cc duplicate the entire stack page, and propagate down the “preserve/duplicate me” flag to the next page, could be extremely efficient, avoiding the relatively expensive return-time check of scheme implementations.
Anybody seriously considering building in Squeak above Cog things like a massively parallel compute architecture, or making things like Teatime (in Croquet) much easier to debug, would do well to take such an approach.
Yes, please! Hello somebody! 🐰🙌🐿️💋🙈🤣⁉️
BTW, Jecek’s explanation of the concurrency architecture in Morphic is masterful and should at least be copied into the help browser. Thank you, Jecel.
🐰
— Have a good one; keep it, light. Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
Sent from Callisto House mobile - Ganymede :: decentralized mobile homeless solutions ::
On Fri, Mar 3, 2023 at 02:42, rabbit rabbit@callistohouse.org wrote:
This was a little confusing my apologies.
This example
(anObject eventual identityHash * 10)
I incorrectly labeled promise chaining. It’s more properly called in the literature as pipelining, where we send a follow on DNU message to anENearPromise. Let’s break it down
anObject eventual returns anENear
Sending identityHash schedules it’s EventualMessageSend, in the Vat, and reteruns anENearPromise.
Immediately following this promised send, we eventually send a * 10. This stores it’s EventualMessageSend in the ENearPromise’s pendingSends queue and returns anENearPromise #2.
This is Promise Pipelining.
In my opinion right now it is more convenient to develop in a synchronous manner in Squeak because the debugger in its current state is better suited for that. It does not support you very well with Promises, deferred UI messages, spawned processes and the like... And when some of the tools that you are used to do not support you well anymore, it does not feel good.
Yes, indeed. I’ve been thinking about this. Deep in a send tree, an exception occurs. We would like to see a stack representation of some kind. What kind?
First guess is the stack of sending contexts leading to the exceptional send. However, good Eventual Sending Style would see calling sends to eventuality send its work and exit. Therefore, it is highly likely there is no stack available.
Is it feasible to store sends leading down to the exceptional send? This is a disconnect that could seriously affect our ability to debug effectively.
So what sort of stack could we build? As this only happens when debugging, we could afford to seek the stack for the EventualMessageSend activating the immediate stack. Store the ENearPromise that corresponds to the eMsgSend’s resolver withe the eMsgSend. Then when the activating eMsgSend is found, access the promise’s pendingSends and collect the registered reactors from calls to the promise #then: / #whenResolved: / #whenRejected:. They themselves have promises with pendingSends, so a tree of future sends could be established. These should all get #smashed: from the exceptional send, once resumed into the future.
Andso, it seems to me we could struggle to produce an historical stack, but we could provide a futuristic promise tree.
I’m thinking we really need the historical stack. For example an argument is provided that fails. Where did this argument come from. We need to backup and regenerate the argument. Without a historical stack I don’t see how that works.
Therefore, I think we may need to preserve the sending contexts. What are the implications to do this? I don’t know.
🐰
On Wed, Mar 1, 2023 at 15:23, rabbit rabbit@callistohouse.org wrote:
Let’s make better Turbinado Sugar for our café con leche! The #* is sent to the result promise from #identityHash’s esend. This promise’s #doesNotUnderstand: redirectMessage: of the ‘* 10’ and returns the 2nd promise. The argument to show: cannot be an eventual ref, at this time, so a then: with a reactor is required. No promise chaining will work.
(anObject eventual identityHash * 10) then: [:codeMag | Transcript cr; show: ‘code order of magnitude = ‘, codeMag].
🐰
— Have a good one; keep it, light. Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
Sent from Callisto House mobile - Ganymede :: decentralized mobile homeless solutions ::
On Wed, Mar 1, 2023 at 14:52, rabbit rabbit@callistohouse.org wrote:
On Wed, Mar 1, 2023 at 14:18, Jakob Reschke jakres+squeak@gmail.com wrote:
Event-loop based UI development is usually a good strategy. It is how Windows works at the foundations... I know that this will sound rather like an argument against it for some people. ;-P
lol! Certainement! Yet they built the Midori eventual sending OS [1].
The question is whether it is convenient to program like that. All parts involved must account for the asynchronicity. It may be more convenient to just send a Smalltalk message rather than using addDeferredUiMessage: and wrapping your intent in a block, but the code that comes after that line looks different, too.
Yes indeed. The EST: Eventual Sending Style.
((an object eventual send: #identityHash) then: [:code | code * 10]) then: [:codeMag | Transcript cr; show: ‘code order of magnitude = ‘, codeMag].
Looking into sugar, with ESqueak, where EAbstract>>#doesNotUnderstand: eventually sends the msg like a trampoline:
(anObject eventual identityHash
>: [:code | code * 10] >: [:codeMag | Transcript cr; show: ‘code order of magnitude = ‘, codeMag].
Where the as yet unimplemented ENearPromise>>#>>:>>: would be
^ (self then: reactor1) then: reactor2.
Of course instead of a block the reactor could be (an anonymous) subclass of WhenResolvedReactor and set a closure object in initialize.
Especially if you need a result/response to continue your overall computation.
I was thinking of a possible marking of a closure as #immediate to turn all eventual sending within as immediate calls.
You may be inclined to use Promises there, where you would not do that otherwise, for example.
Right.
In my opinion right now it is more convenient to develop in a synchronous manner in Squeak because the debugger in its current state is better suited for that. It does not support you very well with Promises, deferred UI messages, spawned processes and the like... And when some of the tools that you are used to do not support you well anymore, it does not feel good.
An excellent observation, Jakob! Tool support for eventual sending would be a must, specifically the debugger.
I think this exposes the coordination problem, I guess we could call it. How does one intrepid souk debug control flow among independent event processes?
Given success with these issue, does it make sense to keep eventual sending as a candidate?
Would it not allow controller / view / model interactions to be thought about clearly?
Thanks for your consideration.
🐰
Am Mi., 1. März 2023 um 19:40 Uhr schrieb rabbit rabbit@callistohouse.org:
> Awesome! Jecel, I’m quite curious to hear your thoughts on eventual sending. EVERYBODIES thoughts, really. Is event-loop eventual sending a feasible style / function for UI development? > > 🐰 > > — > Have a good one; keep it, light. > Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇 > > Sent from Callisto House mobile - Ganymede > :: decentralized mobile homeless solutions :: > > On Wed, Mar 1, 2023 at 13:00, Jecel Assumpcao Jr jecel@merlintec.com wrote: > >> David T. Lewis wrote on Tue, 28 Feb 2023 20:39:54 -0500 >>> In MVC, each Controller has its own Process, and those processes are >>> scheduled when needed as windows are activated. In Morphic, there is >>> a single UI process. >> >> True, but misleading. Just like the VM has a single OS thread that it >> multiplexes between image level processes, the single Morphic thread >> pretends to run each morph in parallel at a known rate by repeated >> sending #step to them. >> >> Because we know that only when #step for one morph is finished that >> #step will be sent to the next morph, we have been programming as it >> morphs did not execute in parallel even though that is what the model >> was supposed to be. That is why we get in trouble when things happen >> outside of the GUI scheduler. >> >> In Self you have have more than one Morphic window and each gets its own >> GUI thread, but they are unlikely to share the same objects so we don't >> notice the problem. You can also have multiple windows in different >> machines viewing the same "world" and in that case they all share a >> single GUI thread. >> >> -- Jecel
E’s Galaxy Object Scenario •
https://www.dropbox.com/s/lq9hxd6cj55fzeo/The%20GalaxyObject%20scenario%20re...
— Have a good one; keep it, light. Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
Sent from Callisto House mobile - Ganymede :: decentralized mobile homeless solutions ::
On Sun, Mar 5, 2023 at 09:51, rabbit rabbit@callistohouse.org wrote:
I am so grateful you share in my astonishment at the potential power of a promise system. C.f. seeing as how you’ve prepared the Way! I’m so bloody grateful! My dreams seem to coming true! 🙏🏻 God is good.
I’ve several questions below. 🐰
— Have a good one; keep it, light. Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
Sent from Callisto House mobile - Ganymede :: decentralized mobile homeless solutions ::
On Fri, Mar 3, 2023 at 10:41, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 2, 2023, at 11:54 PM, rabbit rabbit@callistohouse.org wrote:
Does a block closure preserve its creating context?
Yes, but not the creating context’s continuation.
Would you explain the difference between a context and a continuation?
Are they to be stored by us?
How do continuations fulfill the debugger stack? Would changes to the debugger be necessary?
•••
Walking the future tree, we could collect the back tree of creating contexts to establish an historical tree. I say tree because reactor #1 was then: immediately after causal send leading to the exception, and the promise got passed around and another belly cat sent a then: for reactor #2, both in the same promise’s pendingSends queue. Therefore the historical view of a future tree is also a tree. So the eventual debugger has a future / historical toggle. And we debug the tree and not the stack.
This is a good idea and could be fine efficiently with the current VM architecture. (*) Promises would be created with the equivalent of “call-cc”, (*) scheme’s call-with-current-continuation. I’ve discussed this with Andreas, Avi Bryant, Colin Putney, and others over the years. It would elevate the level of comprehensibility in future/promise based systems significantly.
Delighted! How should I go about doing this when creating a promise?
Further, because the exception system is first-class, handler search could be extended from the promise’s stack to its enclosing continuation’s stack
If I’m following you, the promise stack is the immediate call stack within a Process, while the enclosing continuation’s ‘stack’ is what and where and how and such?
, which would make managing errors in promises much easier; one would not have to establish an error handler where each promise is created, but could establish a single error handler in the thread that creates promises (etc, this can nest if desired/so implemented).
Yet, reactor #1 could also have been sent outside the causal send context. So we may still want to hold the causal context in the promise / eMsgSend object.
(*) an implementation note for those looking fir a juicy VM project. The essence of call-cc is stack duplication. C.f. the explicit stack duplication in Seaside’s delimited continuations. When call-cc occurs effectively the entire stack is duplicated so that both the creating and the created thread can continue. (for promises this allows us to see where the promise originates long after the creating thread has continued and returned from where it created the promise, which is why this helps with debugging).
I’ve too many other priorities, atm. I’m trying to get the Galaxy Object Scenario running in remote-promises. Yet I’m most curious to file away what’s needed. What VM changes are you suggesting? Support for call-cc when creating Promises or does Seaside’s delimited continuations suffice? Or are you speaking of stack zones support?
I am told that in efficient scheme implementations stack duplication is made lazy. Essentially a flag is set in an activation record that does call-cc that is checked at return time. This causes the activation to be preserved for the call-cc continuation and set for the activation record being returned into, lazily duplicating only those activations that are actually returned from. Neat.
In the Cog VM, executable activation records (contexts) live in a special form on small stack pages in the stack zone. This is done both to avoid having to create context objects until unavoidable (home contexts for blocks, reifying the contexts stack for the debugger, etc), abc to allow the JIT to optimize sends using conventional call instructions. Each stack page is large enough ti hold about 40 normal sized activations (& only one of two huge activations). Having the equivalent of call-cc duplicate the entire stack page, and propagate down the “preserve/duplicate me” flag to the next page, could be extremely efficient, avoiding the relatively expensive return-time check of scheme implementations.
Anybody seriously considering building in Squeak above Cog things like a massively parallel compute architecture, or making things like Teatime (in Croquet) much easier to debug, would do well to take such an approach.
Yes, please! Hello somebody! 🐰🙌🐿️💋🙈🤣⁉️
BTW, Jecek’s explanation of the concurrency architecture in Morphic is masterful and should at least be copied into the help browser. Thank you, Jecel.
🐰
— Have a good one; keep it, light. Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
Sent from Callisto House mobile - Ganymede :: decentralized mobile homeless solutions ::
On Fri, Mar 3, 2023 at 02:42, rabbit rabbit@callistohouse.org wrote:
This was a little confusing my apologies.
This example
(anObject eventual identityHash * 10)
I incorrectly labeled promise chaining. It’s more properly called in the literature as pipelining, where we send a follow on DNU message to anENearPromise. Let’s break it down
anObject eventual returns anENear
Sending identityHash schedules it’s EventualMessageSend, in the Vat, and reteruns anENearPromise.
Immediately following this promised send, we eventually send a * 10. This stores it’s EventualMessageSend in the ENearPromise’s pendingSends queue and returns anENearPromise #2.
This is Promise Pipelining.
> In my opinion right now it is more convenient to develop in a synchronous manner in Squeak because the debugger in its current state is better suited for that. It does not support you very well with Promises, deferred UI messages, spawned processes and the like... And when some of the tools that you are used to do not support you well anymore, it does not feel good.
Yes, indeed. I’ve been thinking about this. Deep in a send tree, an exception occurs. We would like to see a stack representation of some kind. What kind?
First guess is the stack of sending contexts leading to the exceptional send. However, good Eventual Sending Style would see calling sends to eventuality send its work and exit. Therefore, it is highly likely there is no stack available.
Is it feasible to store sends leading down to the exceptional send? This is a disconnect that could seriously affect our ability to debug effectively.
So what sort of stack could we build? As this only happens when debugging, we could afford to seek the stack for the EventualMessageSend activating the immediate stack. Store the ENearPromise that corresponds to the eMsgSend’s resolver withe the eMsgSend. Then when the activating eMsgSend is found, access the promise’s pendingSends and collect the registered reactors from calls to the promise #then: / #whenResolved: / #whenRejected:. They themselves have promises with pendingSends, so a tree of future sends could be established. These should all get #smashed: from the exceptional send, once resumed into the future.
Andso, it seems to me we could struggle to produce an historical stack, but we could provide a futuristic promise tree.
I’m thinking we really need the historical stack. For example an argument is provided that fails. Where did this argument come from. We need to backup and regenerate the argument. Without a historical stack I don’t see how that works.
Therefore, I think we may need to preserve the sending contexts. What are the implications to do this? I don’t know.
🐰
On Wed, Mar 1, 2023 at 15:23, rabbit rabbit@callistohouse.org wrote:
Let’s make better Turbinado Sugar for our café con leche! The #* is sent to the result promise from #identityHash’s esend. This promise’s #doesNotUnderstand: redirectMessage: of the ‘* 10’ and returns the 2nd promise. The argument to show: cannot be an eventual ref, at this time, so a then: with a reactor is required. No promise chaining will work.
(anObject eventual identityHash * 10) then: [:codeMag | Transcript cr; show: ‘code order of magnitude = ‘, codeMag].
🐰
— Have a good one; keep it, light. Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇
Sent from Callisto House mobile - Ganymede :: decentralized mobile homeless solutions ::
On Wed, Mar 1, 2023 at 14:52, rabbit rabbit@callistohouse.org wrote:
On Wed, Mar 1, 2023 at 14:18, Jakob Reschke jakres+squeak@gmail.com wrote:
> Event-loop based UI development is usually a good strategy. It is how Windows works at the foundations... I know that this will sound rather like an argument against it for some people. ;-P
lol! Certainement! Yet they built the Midori eventual sending OS [1].
> The question is whether it is convenient to program like that. All parts involved must account for the asynchronicity. It may be more convenient to just send a Smalltalk message rather than using addDeferredUiMessage: and wrapping your intent in a block, but the code that comes after that line looks different, too.
Yes indeed. The EST: Eventual Sending Style.
((an object eventual send: #identityHash) then: [:code | code * 10]) then: [:codeMag | Transcript cr; show: ‘code order of magnitude = ‘, codeMag].
Looking into sugar, with ESqueak, where EAbstract>>#doesNotUnderstand: eventually sends the msg like a trampoline:
(anObject eventual identityHash >>: [:code | code * 10] >>: [:codeMag | Transcript cr; show: ‘code order of magnitude = ‘, codeMag].
Where the as yet unimplemented ENearPromise>>#>>:>>: would be
^ (self then: reactor1) then: reactor2.
Of course instead of a block the reactor could be (an anonymous) subclass of WhenResolvedReactor and set a closure object in initialize.
> Especially if you need a result/response to continue your overall computation.
I was thinking of a possible marking of a closure as #immediate to turn all eventual sending within as immediate calls.
> You may be inclined to use Promises there, where you would not do that otherwise, for example.
Right.
> In my opinion right now it is more convenient to develop in a synchronous manner in Squeak because the debugger in its current state is better suited for that. It does not support you very well with Promises, deferred UI messages, spawned processes and the like... And when some of the tools that you are used to do not support you well anymore, it does not feel good.
An excellent observation, Jakob! Tool support for eventual sending would be a must, specifically the debugger.
I think this exposes the coordination problem, I guess we could call it. How does one intrepid souk debug control flow among independent event processes?
Given success with these issue, does it make sense to keep eventual sending as a candidate?
Would it not allow controller / view / model interactions to be thought about clearly?
Thanks for your consideration.
🐰
> Am Mi., 1. März 2023 um 19:40 Uhr schrieb rabbit rabbit@callistohouse.org: > >> Awesome! Jecel, I’m quite curious to hear your thoughts on eventual sending. EVERYBODIES thoughts, really. Is event-loop eventual sending a feasible style / function for UI development? >> >> 🐰 >> >> — >> Have a good one; keep it, light. >> Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇 >> >> Sent from Callisto House mobile - Ganymede >> :: decentralized mobile homeless solutions :: >> >> On Wed, Mar 1, 2023 at 13:00, Jecel Assumpcao Jr jecel@merlintec.com wrote: >> >>> David T. Lewis wrote on Tue, 28 Feb 2023 20:39:54 -0500 >>>> In MVC, each Controller has its own Process, and those processes are >>>> scheduled when needed as windows are activated. In Morphic, there is >>>> a single UI process. >>> >>> True, but misleading. Just like the VM has a single OS thread that it >>> multiplexes between image level processes, the single Morphic thread >>> pretends to run each morph in parallel at a known rate by repeated >>> sending #step to them. >>> >>> Because we know that only when #step for one morph is finished that >>> #step will be sent to the next morph, we have been programming as it >>> morphs did not execute in parallel even though that is what the model >>> was supposed to be. That is why we get in trouble when things happen >>> outside of the GUI scheduler. >>> >>> In Self you have have more than one Morphic window and each gets its own >>> GUI thread, but they are unlikely to share the same objects so we don't >>> notice the problem. You can also have multiple windows in different >>> machines viewing the same "world" and in that case they all share a >>> single GUI thread. >>> >>> -- Jecel
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
rabbit