<html><head></head><body> <div dir="auto">This was a little confusing my apologies.</div><div dir="auto"><br></div><div dir="auto">This example</div><div dir="auto"><span style="color: var(--text-color); background: var(--bg-color);" dir="auto"><br></span></div><div dir="auto"><span style="color: var(--text-color); background: var(--bg-color);" dir="auto"> (anObject eventual identityHash * 10)</span></div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div>anObject eventual returns anENear<div dir="auto"><br></div><div dir="auto">Sending identityHash schedules it’s EventualMessageSend, in the Vat, and reteruns anENearPromise. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">This is Promise Pipelining. </div><div dir="auto"><br></div><div dir="auto"><blockquote class="protonmail_quote" type="cite" style="unicode-bidi: plaintext; padding: 0px 0px 0px 0.6rem !important; margin: 0px !important; border-style: solid !important; border-width: 0px 0px 0px 1px !important; margin-block: 1rem 20px !important; margin-inline: 0px !important; San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none;"><blockquote class="protonmail_quote" type="cite" style="unicode-bidi: plaintext; padding: 0px 0px 0px 0.6rem !important; margin: 0px !important; border-style: solid !important; border-width: 0px 0px 0px 1px !important; margin-block: 1rem 20px !important; margin-inline: 0px !important;"><div dir="auto" style="unicode-bidi: plaintext; outline: none;"><blockquote class="protonmail_quote" type="cite" style="unicode-bidi: plaintext; padding: 0px !important; margin: 0px !important; border: none !important; margin-block: 1rem 20px !important; margin-inline: 0px !important;"><div dir="auto" style="unicode-bidi: plaintext; outline: none;"><div style="unicode-bidi: plaintext; outline: none;">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.</div></div></blockquote></div></blockquote></blockquote>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?</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Andso, it seems to me we could struggle to produce an historical stack, but we could provide a futuristic promise tree. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Therefore, I think we may need to preserve the sending contexts. What are the implications to do this? I don’t know.</div><div dir="auto"><br></div><div dir="auto">🐰<caret></caret><br><div dir="auto"><br>On Wed, Mar 1, 2023 at 15:23, rabbit <<a href="mailto:rabbit@callistohouse.org" class="">rabbit@callistohouse.org</a>> wrote:<blockquote class="protonmail_quote" type="cite"> <div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"> (anObject eventual identityHash * 10)</div><div dir="auto"> <span style="color: var(--text-color); background: var(--bg-color);" dir="auto">then: [:codeMag | </span></div><div dir="auto"><span style="color: var(--text-color); background: var(--bg-color);" dir="auto"> Transcript cr; </span></div><div dir="auto"><span style="color: var(--text-color); background: var(--bg-color);" dir="auto"> show: ‘code order of magnitude = ‘, codeMag].</span></div><div dir="auto"><span style="color: var(--text-color); background: var(--bg-color);" dir="auto"><br></span></div><div dir="auto"><span style="color: var(--text-color); background: var(--bg-color);" dir="auto">🐰</span></div><div><br></div><div id="protonmail_signature_block" class="protonmail_signature_block"><div>—<br>Have a good one; keep it, light.<br>Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇<br><br>Sent from Callisto House mobile - Ganymede<br>:: decentralized mobile homeless solutions ::</div></div> <div class="signature_br" contenteditable="false"><br></div><div class="signature_br" contenteditable="false"><br></div> <div><br></div><div><br></div>On Wed, Mar 1, 2023 at 14:52, rabbit <<a href="mailto:rabbit@callistohouse.org" class="">rabbit@callistohouse.org</a>> wrote:<blockquote class="protonmail_quote" type="cite"> <div><br></div><div dir="auto"><br></div>On Wed, Mar 1, 2023 at 14:18, Jakob Reschke <<a href="mailto:jakres+squeak@gmail.com" class="">jakres+squeak@gmail.com</a>> wrote:<blockquote class="protonmail_quote" type="cite"> <div dir="ltr">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</div></blockquote>lol! Certainement! Yet they built the Midori eventual sending OS [1].<br><blockquote class="protonmail_quote" type="cite"><div dir="auto"><div dir="auto">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. </div></div></blockquote>Yes indeed. The EST: Eventual Sending Style.<div dir="auto"><br></div><div dir="auto"> ((an object eventual <span style="color: var(--text-color); background: var(--bg-color);" dir="auto">send: #identityHash)</span></div><div dir="auto"><span style="color: var(--text-color); background: var(--bg-color);" dir="auto"> then: [:code | code * 10])</span></div><div dir="auto"> then: [:codeMag | Transcript cr; show: ‘code order of magnitude = ‘, codeMag].</div><div dir="auto"><br></div><div dir="auto">Looking into sugar, with ESqueak, where EAbstract>>#doesNotUnderstand: eventually sends the msg like a trampoline:</div><div dir="auto"><br></div><div dir="auto"> (anObject eventual identityHash</div><div dir="auto"> >>: [:code | code * 10]</div><div dir="auto"> >>: [:codeMag | <span style="San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;">Transcript cr; show: ‘code order of magnitude </span><span style="San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;" dir="auto">= ‘, codeMag].</span></div><div dir="auto"><span style="San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;" dir="auto"><br></span></div><div dir="auto"><span style="San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;" dir="auto">Where the as yet unimplemented ENearPromise>>#>>:>>: would be</span></div><div dir="auto"><span style="San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;" dir="auto"><br></span></div><div dir="auto"><span style="San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;" dir="auto"> ^ (self then: reactor1)</span></div><div dir="auto"><span style="San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;" dir="auto"> then: reactor2.</span></div><div dir="auto"><span style="San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;" dir="auto"><br></span></div><div dir="auto"><span style="San Francisco", Helvetica, Arial, sans-serif; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: none; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;" dir="auto">Of course instead of a block the reactor could be (an anonymous) subclass of WhenResolvedReactor and set a closure object in initialize.</span></div><div dir="auto"><br><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><div dir="auto">Especially if you need a result/response to continue your overall computation.</div></div></blockquote>I was thinking of a possible marking of a closure as #immediate to turn all eventual sending within as immediate calls.<br><blockquote class="protonmail_quote" type="cite"><div dir="ltr"><div dir="auto">You may be inclined to use Promises there, where you would not do that otherwise, for example.</div></div></blockquote>Right.<br><blockquote class="protonmail_quote" type="cite"><div dir="auto"><div>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.</div></div></blockquote>An excellent observation, Jakob! Tool support for eventual sending would be a must, specifically the debugger. </div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Given success with these issue, does it make sense to keep eventual sending as a candidate?</div><div dir="auto"><br></div><div dir="auto">Would it not allow controller / view / model interactions to be thought about clearly?</div><div dir="auto"><br></div><div dir="auto">Thanks for your consideration.</div><div dir="auto"><br></div><div dir="auto">🐰</div><div dir="auto"><blockquote class="protonmail_quote" type="cite"><div dir="auto"><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 1. März 2023 um 19:40 Uhr schrieb rabbit <<a href="mailto:rabbit@callistohouse.org">rabbit@callistohouse.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> <div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">🐰</div><div dir="auto"><u></u><u></u><br></div><div id="m_6041824441368197938protonmail_signature_block"><div>—<br>Have a good one; keep it, light.<br>Kindly, rabbit . .. … ‘…^,^ 🐇🐇🐇<br><br>Sent from Callisto House mobile - Ganymede<br>:: decentralized mobile homeless solutions ::</div></div> <div><br></div><div><br></div> <div><br></div><div><br></div>On Wed, Mar 1, 2023 at 13:00, Jecel Assumpcao Jr <<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>> wrote:<blockquote type="cite"> David T. Lewis wrote on Tue, 28 Feb 2023 20:39:54 -0500<br>> In MVC, each Controller has its own Process, and those processes are<br>> scheduled when needed as windows are activated. In Morphic, there is<br>> a single UI process.<br><br>True, but misleading. Just like the VM has a single OS thread that it<br>multiplexes between image level processes, the single Morphic thread<br>pretends to run each morph in parallel at a known rate by repeated<br>sending #step to them.<br><br>Because we know that only when #step for one morph is finished that<br>#step will be sent to the next morph, we have been programming as it<br>morphs did not execute in parallel even though that is what the model<br>was supposed to be. That is why we get in trouble when things happen<br>outside of the GUI scheduler.<br><br>In Self you have have more than one Morphic window and each gets its own<br>GUI thread, but they are unlikely to share the same objects so we don't<br>notice the problem. You can also have multiple windows in different<br>machines viewing the same "world" and in that case they all share a<br>single GUI thread.<br><br>-- Jecel<br><br></blockquote></div><br>
</blockquote></div>
</blockquote></div></blockquote></blockquote></div></div></body></html>