From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:75c2:: with SMTP id y185-v6mr2307683itc.35.1521661865899; Wed, 21 Mar 2018 12:51:05 -0700 (PDT) X-Received: by 2002:a9d:29d2:: with SMTP id g18-v6mr1315472otd.5.1521661865778; Wed, 21 Mar 2018 12:51:05 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!xmission!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!u184-v6no3675ita.0!news-out.google.com!d3-v6ni5itf.0!nntp.google.com!u184-v6no3671ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 21 Mar 2018 12:51:05 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <858fbe8b-43a2-4ee3-ad51-1d100123a1a3@googlegroups.com> Subject: Re: Ada-Oriented GUI From: "Dan'l Miller" Injection-Date: Wed, 21 Mar 2018 19:51:05 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:51108 Date: 2018-03-21T12:51:05-07:00 List-Id: On Wednesday, March 21, 2018 at 2:11:13 PM UTC-5, Simon Wright wrote: > I suspect that Dmitry only meant that output-pending must occur before > output-complete, whichever thread you view it from. I assume that output here is event emission from the head-end of the river = from the upstream perspective of producing output to downstream receivers t= hat handle that output-from-upstream as input. Event emission occurs in se= quence from a single-threaded source in Rx. Operating under than axiom, of= course, events in flight within a sequence must occur and do get transmitt= ed in sequence prior to later transaction-ending events unless those events= in flight were declared (at the time of subscription) to be lossy & worthl= ess upon successful or aberrant termination of the sequence. Each sequence= lacks asynchrony within itself, hence the term sequence. Each sequence (a= s per a composable system) may be declared to retire/commit its own transac= tions independently of any pestering from any other sequences. Each sequen= ce (as per a composable system) may be declared to merge events from 2 or m= ore sequences where those upstream events impact the processing of each oth= er (e.g., Twitter newsfeed event arrival need to be rendered differently no= w that the human being rotated from portrait to landscape orientation; all = that needs to done more power-conservingly now that the battery just crosse= d the 20% capacity in the downward direction; oh forget about all that righ= t now! your all-hands-on-deck the-sky-is-falling stock-price trigger that y= ou set last month just fired indicating that you should be urgently managin= g at your investment portfolio, not wasting time & precious battery power o= n Twitter; and so forth among drastically disparate realtime concerns). (Here I am eliding the Rx jargon. The river metaphor here is properly Rx's= sequence [or also stream in RxJava]. The head-end metaphor here is proper= ly Rx's Observable. The downstream receiver metaphor here is properly Rx's= Subscriber. and so forth)