<html><head></head><body>
<p>Thank you, Marcel! Great feedback, I will look to it.</p>
<p>K, r<br/>
</p>
<p>On 8/3/20 10:48 AM, Marcel Taeumel wrote:<br/>
</p>
<blockquote type="cite" cite="mid:Mailbird-0e13e300-5381-4306-8732-a586b5619d3b@hpi.de">
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<div id="__MailbirdStyleContent" style="font-size:
10pt;font-family: Arial;color: #000000"> Hi, Rob.
<div><br/>
</div>
<div>> <span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px">Why are you -1 with
PromisesLocal?</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px"><br/>
</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px">- Missing class comments, thus
no clarification of vocabulary "ERef", "Vat", "Reactor",
"Resolver", etc.</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px">- Too many extensions in Object
and ProtoObject</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px">- Some unconventional
wording/style such as #newWithNick:, #onOneArgClosure:..., </span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px"><br/>
</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px">This is just very high-level
feedback and not specific to your implementation strategy. I
did not have more time yet to take a closer look, sorry.</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px"><br/>
</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px">Best,</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px">Marcel</span></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top:
20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 03.08.2020
12:55:18 schrieb Robert Withers
<a class="moz-txt-link-rfc2396E" href="mailto:robert.withers@pm.me"><robert.withers@pm.me></a>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">
<p>Hi Marcel,</p>
<p>Why are you -1 with PromisesLocal? It is easy to add the
protocol published by the current Promise class, minus the
wait protocols. I can certainly rename the proxies, as
well. So what specifically are you -1 abut wrt
PromisesLocal? <br/>
</p>
<p>PromisesRemote is in addition to PromisesLocal, it
extends several remote proxies.</p>
<p>K, r<br/>
</p>
<div class="moz-cite-prefix">On 8/3/20 4:21 AM, Marcel
Taeumel wrote:<br/>
</div>
<blockquote type="cite" cite="mid:Mailbird-aed33cae-fbc9-4dec-9aea-463598c7ebc1@hpi.de" style="min-width: 500px">
<div id="__MailbirdStyleContent" style="font-size:
10pt;font-family: Arial;color: #000000"> Hi all!
<div><br/>
</div>
<div>I like the idea of fixing Squeak's implementation
of promises. However, I am -1 for adding
PromiseLocal/PromiseRemote but would rather like to
sse am implementation of Promise that works for both
cases. Also, "<span style="font-family: Arial,
Helvetica, sans-serif;font-size: 13px">PromiseERefs"
and "BrokenERefs" sounds too cryptic. We can find
better names here. :-)</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px"><br/>
</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px">Best,</span></div>
<div><span style="font-family: Arial, Helvetica,
sans-serif;font-size: 13px">Marcel</span></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width:
1px;margin-top: 20px;margin-left: 0px;padding-left:
10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am
02.08.2020 15:48:49 schrieb Robert Withers via
Squeak-dev <a class="moz-txt-link-rfc2396E" href="mailto:squeak-dev@lists.squeakfoundation.org" moz-do-not-send="true"><squeak-dev@lists.squeakfoundation.org></a>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">
<p>Hello, there,<br/>
</p>
<p>In reading the chapter on Promises, in the
section on the E programming language, of which
PromisesLocal is modeled, the following needs
clarification:</p>
<blockquote style="min-width: 500px">
<p>Subsequent messages can also be eventually sent
to a promise before it is resolved. In this
case, these messages are queued up and forwarded
once the promise is resolved.</p>
</blockquote>
<p>The messages are not queued up at the local
promise, pending forwarding to the eventual
result; they are forwarded to a promise, local to
the computation. This is mainly important once you
have introduced remote promises (PromisesRemote).
Messages are sent to the computation and they
queue up local, for execution upon the eventual
value, #whenMoreResolved:.</p>
<p>K, r</p>
<p>NB: here is a chained message sending eventually,
with Promises.</p>
<blockquote style="min-width: 500px">((10 eventual
factorial / 100) * 25)<br/>
whenResolved: [:i | i value].<br/>
</blockquote>
<br/>
<div class="moz-cite-prefix">On 8/2/20 8:55 AM,
Robert Withers wrote:<br/>
</div>
<blockquote type="cite" cite="mid:265e61a3-00a4-ee10-eb88-3c3741418cb7@pm.me" style="min-width: 500px">
<p>Hi all'y'all!</p>
<p>Here is a textbook on Promises, for your
understanding.</p>
<blockquote style="min-width: 500px">[Inspired by
functional programming, one of the major
distinctions between different interpretations
of this construct have to do with pipelineing or
composition. Some of the more popular
interpretations of futures/promises make it
possible to chain operations, or define a
pipeline of operations to be invoked upon
completion of the computation represented by the
future/promise. This is in contrast to
callback-heavy or more imperative direct
blocking approaches.]</blockquote>
<div class="" dir="auto">
<div class="ecm0bbzt hv4rvrfc ihqw7lf3 dati1w0a" data-ad-comet-preview="message" data-ad-preview="message" id="jsc_c_j">
<div class="j83agx80 cbu4d94t ew0dbk1b
irj2b8pg">
<div class="qzhwtbm6 knvmm38d"><span class="oi732d6d ik7dh3pa d2edcug0
qv66sw1b c1et5uql a8c37x1j muag1w35
ew0dbk1b jq4qci2q a3bd9o3v knj5qynh
oo9gr5id hzawbc8m" dir="auto">
<div class="o9v6fnle cxmmr5t8 oygrvhab
hcukyx3x c1et5uql ii04i59q">
<div dir="auto" style="text-align:
start;"><a class="moz-txt-link-freetext" href="http://dist-prog-book.com/chapter/2/futures.html" moz-do-not-send="true">http://dist-prog-book.com/chapter/2/futures.html</a></div>
<div dir="auto" style="text-align:
start;">K, r<br/>
</div>
<div dir="auto" style="text-align:
start;"><br/>
</div>
</div>
</span></div>
</div>
</div>
</div>
<div class="moz-cite-prefix">On 8/1/20 12:09 PM,
Robert Withers wrote:<br/>
</div>
<blockquote type="cite" cite="mid:7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me" style="min-width: 500px">
<pre class="moz-quote-pre" wrap="">Good afternoon!
I wish to offer a proposal for discussion to include PromisesLocal into
trunk and to replace the implementation of Promise/BrokenPromise with
PromiseERefs and BrokenERefs. The underlying concurrency model has
explicit use of an event loop in PromisesLocal. The code size is minimal
but adds the Promises/A+ specification to Squeak, that can be extended
into a remote reference solution and an Agent communications
architecture. Exceptions are processed.
I want to define a VatSemaphore that allows the user to #wait/#signal,
and they get 'immediate' control flow which most folks find as a valid
way to describe steps taken.Under the covers the VatSemaphore is
connected to the Vat, as an element in a forthcoming continuationPool.
So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the
continuation is captured and placed in the pool and the vat's event loop
continues with the next event. When #signal is sent to this
VatSemaphore, the continuation is scheduled: in the queue and removed
from the pool. The event loop will process the continuation.
</pre>
<blockquote type="cite" style="min-width: 500px">
<blockquote type="cite" style="min-width:
500px">
<pre class="moz-quote-pre" wrap="">On 7/28/20 3:41 PM, Jakob Reschke wrote:
My other suspicion is that we would nevertheless need an extended
debugger to deal well with such eventual control flow. A debugger
with a "step to resolution" or so that steps to the point where the
messages are eventually answered, or the receiver even activated.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I think that this is a great idea!
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Research in this direction would be AWESOME!
On 8/1/20 11:39 AM, Robert Withers wrote:
</pre>
<blockquote type="cite" style="min-width: 500px">
<blockquote type="cite" style="min-width:
500px">
<pre class="moz-quote-pre" wrap="">On 7/28/20 3:41 PM, Jakob Reschke wrote:
Current Kernel Promises are also not good at that without sprinkling
breakpoints... This and the dreadful error handling ("well so I
forgot the block argument for the callback again and got an error
from value:, now how do I find out in the debugger which method even
contains my wrong block?!?"
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">What if the debugger could allow you to browse reactor creation
methods? Where is the closure created?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I can imagine an implementation of EIO
(<a class="moz-txt-link-freetext" href="http://wiki.erights.org/wiki/EIO_Redesign" moz-do-not-send="true">http://wiki.erights.org/wiki/EIO_Redesign</a>), Eventual I/O, that has a
#whenAvailable: semantic. Then the UI event loop is just an EInputStream
and we could flip the entire system over to using a promise architecture.
Kindly,
rabbit
</pre>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body></html>