提交: b181a1b05a4ea79f273d3606aeafa2d69f4ba561 - DocIdeas (hg)

Commit MetaInfo

• 修订版: b181a1b05a4ea79f273d3606aeafa2d69f4ba561 (tree)
• 时间: 2024-03-28 04:20:34
• 作者: Albert Mietus < albert AT mietus DOT nl >
• Commiter: Albert Mietus < albert AT mietus DOT nl >

Log Message

CCastle-4.blog: Updated theSieve & Heisenbug -- keep in simple. Move (upcomming) variants to other blog

更改概述

• modified: CCastle/4.Blog/Heisenbug-sidebar-Sequence.irst
• modified: CCastle/4.Blog/index.rst
• modified: CCastle/4.Blog/sieve-Sequence-1b1.puml
• modified: CCastle/4.Blog/sieve-Sequence-Wrong.puml
• modified: CCastle/4.Blog/sieve-Sequence-concept.puml
• modified: CCastle/4.Blog/sieve-Sequence-details.puml
• modified: CCastle/4.Blog/sieve-design.irst
• modified: CCastle/4.Blog/sieve-protocols-sidebar.irst
• add: CCastle/4.Blog/1.TheSieve.rst
• add: CCastle/4.Blog/2.Heisenbug.rst
• add: CCastle/4.Blog/sieve-castle.irst
• add: CCastle/4.Blog/sieve-main.irst
• add: CCastle/4.Blog/sieve-moat.irst
• add: CCastle/4.Blog/sieve-protocols2-sidebar.irst
• add: CCastle/4.Blog/variants/SlowStart.rst
• add: CCastle/4.Blog/variants/TEMP.isrt
• delete: CCastle/4.Blog/a.Heisenbug.rst
• delete: CCastle/4.Blog/b.TheSieve.rst
• delete: CCastle/4.Blog/sieve-code.irst

差异

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/1.TheSieve.rst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/CCastle/4.Blog/1.TheSieve.rst	Wed Mar 27 20:20:34 2024 +0100
@@ -0,0 +1,174 @@
+.. (C) 2023,2024 Albert Mietus. Part of CCastle project
+
+.. _Castle-TheSieve:
+
+=========================
+The Sieve (basic variant)
+=========================
+
+.. post:: 2024/03/25
+   :category: CastleBlogs, Demo
+   :tags: Castle
+
+
+   To show some features of CCastle, I use *‘the Sieve’*, short for the `Sieve of Eratosthenes
+   <https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes>`__. An old, well-known, algorithm to find prime numbers; with
+   implicit concurrency.
+
+   With an almost trivial implementation, many “CC concepts” can be shown; in only a handful of lines....
+
+Several variants of ‘the Sieve’ will be presented to introduce various concepts. This is the most basic one. As we will
+see, it does contain a :ref:`Heisenbug <Castle-Heisenbug>`, which will only be solved in another variant.
+|BR|
+Aside from demonstrating some CCastle concepts, ‘the Sieve’ (in all its variants) is used also to demo the compiler (see
+:ref:`Castle-WorkshopTools`).
+
+
+
+The design
+**********
+
+We only need three simple components as shown below, and a main component (not shown). We also use two protocols, which
+are given below.
+
+.. include:: ./sieve-design.irst
+
+The elements of the sieve
+=========================
+
+CCastle uses “components” [#not-package]_ as the main decomposition. Each kind of component can be instantiated multiple
+times; sometimes called an *element*, or also just a *component*. This is very alike the difference between *“classes”
+and “objects”* in OO [#active-class]_.
+
+Let’s introduce those components
+
+Generator
+---------
+
+This component generates just numbers, which will be tested for prime (see below). As primes are always integers bigger
+than one; the output is the stream stream of numbers: 2,3,4, …
+
+Sieve (on prime)
+----------------
+
+We use a (growing) chain of sieve elements. Each one is the same; except for the sieving constant --an already found
+prime. That number is set when instantiating the element.
+
+
+Each Sieve tries to divide each incoming number by its own, sieve-constant. When the modulo isn’t zero, we call it a
+*coprime* (relative to the already tested primes) and send it downstream. When it can be divided, the number is not
+prime and ignored.
+
+Finder
+------
+
+Each number that comes out of the chain of sieves is a prime (that is the algorithm; see Wikipedia for details). It is
+collected by the finder. For each found prime, an extra sieve (element) is created and added to the chain. This kind
+of shifts the finder to the right (aka downstream)
+
+In some implementations that is the responsibility of the finder (therefore sometimes called “head”). In a variant, the
+‘main’ component is carrying that load.
+
+Communication
+=============
+.. include:: ./sieve-protocols-sidebar.irst
+
+CCastle uses “protocols” to communicate between components. There are several kinds of protocols; we use the ‘event’ kind
+here. Two ports can be connected when both use the same protocol.
+
+Notice, that a *protocol* is not the same as an API in most languages; it is a fundamental concept of the :ref:`CC`
+concept of CCastle. And enforced the strict separation between “outside” and “inside” of a component. No implementation detail of a
+component can call the interface of another component -- it has to be routed by ports and protocols.
+
+StartSieve
+----------
+
+With the StartSieve protocol, the sieving (so generating numbers) is started. The passed parameter is the maximum number to check for
+“primeness”, and so forces a halt. In this (dumb) demo, there is no direct way to specify the number of primes to find.
+
+There is however an option to change that maximum number, with the ``newMax(int:max)`` event.
+|BR|
+In this demo, that event has no effect when the (old) max is already reached -- it is trivial to improve, but that is
+outside the scope of this demo.
+
+SimpleSieve
+-----------
+
+In this variant, we use an event-based protocol, that just holds one event (read: a message), that
+carries the integer to be tried.
+
+The ``input(int:try)`` event gives *input* to the (next) sieve, carrying the number to *try*.
+
+
+Heisenbug
+---------
+
+As we will see in :ref:`Castle-Heisenbug`, this design has a flaw. Depending on :ref:`TheMachinery`, the algorithm may
+work, or terminate early. To manage the (variability in) concurrent communication, the protocol(s) have to be enriched.
+|BR|
+As it does work with the simple (:ref:`Machinery-DirectCall`) machinery, and as it is just a “Hello World” demo, we
+prefer this imperfect version for the demo, as a kind of reference.
+
+.. attention:: Do not use this example in real (generic, production) code.
+
+   See the variant(s) for an improved version. For example: :ref:`SlowStart-Sieve` details.)
+
+The Code
+********
+
+Below, we show all Castle-code for the components. With some comments to explain some typical castle concepts.
+|BR|
+Some parts (like import-lines) are not shown. See the code examples for full examples.
+
+Moat (*interfaces*)
+===================
+
+“Moat files” are like the interfaces, or *contracts*, to the components. The above-shown protocols are also part of
+those *Moat files* -- but as they are already shown, we will not repeat them.
+
+
+.. include:: ./sieve-moat.irst
+
+Castle (*implementation*)
+=========================
+
+The “Castle files” contain the implementation of all components.
+
+.. include:: ./sieve-castle.irst
+
+Main
+====
+
+Components have to be created (statically or dynamically) into “elements”. This is typically done by a component that
+‘holds’ the “sub-components” -- look for the ``sub`` [#subalias]_ keyword. This applies to all levels.
+
+At the very top, there is one element --usually called “main” -- that holds the major elements. In this example, that are
+the `Generator`, the `Finder` and the `Sieve`\s themself.
+
+Note that “main” isn’t  special. Unlike in C/C++ there is no need for a (single) main. The name *main* is more of a
+convention (like in Python).
+|BR|
+Any component with a ``powerOn()`` method will act as (a) main component.
+
+
+.. include:: ./sieve-main.irst
+
+----------
+
+.. rubric:: Footnotes
+
+.. [#not-package]
+   A CCastle **component** is unrelated to a *UML component*. It is **not** a package, as many people use for the UML variant.
+
+.. [#active-class]
+   A (CCastle) **component** (or actually, an element) is sometimes described as an “active class (aka object)” -- a
+   class with a thread inside. This is not completely correct, but gives a good, first impression.
+   |BR|
+   Notice however there a no threads in CCastle -- just concurrency and parallelism.
+
+.. [#subalias]
+   You will encounter both ``sub`` and ``alias`` in this example. Both refer to a (sub)component inside the element,
+   with a small difference. A `sub` is part of the current element, whereas an `alias` is more a (temporally) reference to
+   *sub* -- for example, the last (most right) sieve element in the chain.
+
+..  LocalWords:  coprime Heisenbug

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/2.Heisenbug.rst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/CCastle/4.Blog/2.Heisenbug.rst	Wed Mar 27 20:20:34 2024 +0100
@@ -0,0 +1,213 @@
+.. (C) 2023,2024 Albert Mietus. Part of CCastle project
+
+.. _Castle-Heisenbug:
+
+========================
+A Heisenbug in the Sieve
+========================
+
+.. post:: 2024/03/27
+   :category: CastleBlogs, Castle, DesignStudy
+   :tags: Castle, DRAFT
+
+   In Castle, one can dynamically connect components and send *events* over those connections. Typically, this is an
+   action on an incoming message (see: :ref:`CCC-Actors`). And depending on ‘:ref:`TheMachinery`’, those events can be
+   queued. It is this combination that *can result* in a **beautiful Heisenbug**.
+
+   First, let’s explain the Heisenbug, before we give an example. Then we analyze it, show how to improve the code, and
+   finally formulate a *requirement* to prevent & detect this kind of bug in Castle.
+
+What is a Heisenbug?
+====================
+
+The `heisenbug <https://en.wikipedia.org/wiki/Heisenbug>`__ is named after the theoretical physics *Werner Heisenberg*, who
+described the *“observer effect”*: when you look closely, the behaviour changes. The same can happen to software
+(bugs). The behaviour apparently changes when you study -or slightly adjust- that code.  Often, this is due to small
+changes in timing, possibly even in generated code. Therefore old (old-fashioned) sequential code on slow CPUs is less
+likely to have heisenbugs than concurrent code on fast multi-core systems. It’s also common in threaded programs.
+
+.. include:: ./Heisenbug-sidebar-Sequence.irst
+
+The Sieve goes wrong
+====================
+
+My standard example, :ref:`Castle-TheSieve`, suffered from this issue. The initial version did work for years
+but failed horribly when another “machinery” was used. After studying this, the bug is simple and easy to fix.
+
+There are two related timing issues that together result in the Heisenbug. First, we introduce them and then
+show how the combination may fail.
+
+
+Event-order
+-----------
+
+Conceptually, the `Generator` sends (events with) integers to `Sieve(2)`, which may forward them to `Sieve(3)`, then to
+`Sieve(5)`, etc. As shown in the **Conceptual sidebar**, we probably assume that each integer is sieved before the next
+*’int’* *starts*: the classic “sequential view” we are used to.
+
+However, that isn’t how it works. In Castle, *only* the order of events on a single connection is defined (*one by one,
+sequential*). And given the code, the integer sent by a `Sieve` is always later than the incoming one. That is all we
+may assume.
+|BR|
+The timing of unrelated events on multiple connections is not defined. That order may depend on :ref:`TheMachinery` and
+many other factors. Do not assume any order -- as I did!
+
+
+The diagram in the **One-by-One** sidebar shows another (allowed) order. The Generator outputs all events first before
+Sieve(2) starts filtering. Then, the odd integers are passed to Sieve(3), which processes all its input, then Sieve(5),
+etc.
+|BR|
+Although we aren’t using concurrency, and it needs tremendous buffers when finding big primes, it does conceptually
+work. And so, it is an allowed execution [#ButImprove]_.
+
+As that order is “possible” we should have a design (and code) that handles it. But it doesn't ... (in the basic variant).
+
+Reconnecting
+------------
+
+The chain of `Sieve`\s will grow as we find more primes. Whenever an *int* isn’t filtered out and reaches the `Finder` a
+*new prime* is found. Then, a new Sieve element is created and inserted into the chain.
+|BR|
+Building the chain  is done by the Main component (which is signalled by the Finder) [#orVariant]_.
+
+Therefore, `Main` remembers the ``last_sieve`` and reconnects that output to the newly created `Sieve`.
+Which output is temporally connected to the `Finder`
+|BR|
+For every newly found prime, this is repeated.
+
+This detail is shown in the “**with Details**” sidebar diagram; where the `Finder` and `Main` and all its messages
+are shown too.
+
+Assuming the initial “conceptual” order, you will see the same Sieve(s) become alive (“new” message), and are added to
+the end of the sieve chain. The integers still flow (now, shown as “try(`int`)” messages) by this sieve.
+|BR|
+You will also notice the `Finder` does indeed find all primes.
+
+
+The combination
+===============
+
+Now let us study how the sieve chain will grow with a “fast generator”, and the one-by-one order of events is used. This
+diagram is shown below.
+
+As we can see in the picture, it goes dreadfully wrong. No proper chain is created, and we will find integers like **4**
+and **6**.  This is wrong, they are not prime.
+|BR|
+With a (very) *fast Generator*, **all** integers are sent to the `Finder` --before any `Sieve` is created, and so any
+int is reported as prime. besides, too many elements are added to the chain as a Sieve component is created for each found
+“prime”.  On top of that, no integer is ever sieved...
+
+This is just **an** example. As we can’t predict (or assume) any order, we can find other results too. And, when we add
+“debugging print statement” (and *look closer*), we change the timing and will find other results. We found the
+*observer effect*!
+
+.. uml:: ./sieve-Sequence-Wrong.puml
+
+
+.. warning::
+
+   It is not *“the timing”* that is wrong!
+   |BR|
+   A concurrent program is only correct when it goes right for **any** possible timing.
+
+   As in all software engineering, we can prove it is buggy when it goes wrong at least once. That is what we have
+   shown. And so, the original code is *wrong*.
+
+
+How to improve?
+===============
+
+Finding this heisenbug triggered an investigation  to improve Castle as well as ‘:ref:`Castle-TheSieve`’. Where our goal
+is not just to improve the sieve code, but all programs. And give the programmer options to prevent heisenbugs.
+
+As we will see fixing ‘:ref:`the sieve <Castle-TheSieve>` is simple: use the **SLowStart** (base) protocol. It changes
+only three lines!
+|BR|
+But we start with a new requirement, for a new tool in the :ref:`Castle Workshop <Workshop-Design>`.
+
+
+Simulation
+----------
+
+As we will see below the `SlowStart` protocol will *remove* our Heisenbug. But it does not abolish the Heisenbug!
+
+The feature does by no means prevent a developer from using other solutions, with a comparable flaw. Besides, it’s
+hopeless to use testing to prove the absence of a Heisenbug. As we have seen above, all variants of all possible
+concurrent execution orders should be correct. Where we have very limited control over which variant is used.
+
+This led to a new requirement: :need:`U_Tools_EventOrder.` To assist the developer the Castle Workshop will come
+with tools to detect such bugs. See :ref:`simulation` for more on this.
+
+
+.. include:: ./sieve-protocols2-sidebar.irst
+SlowStart
+---------
+
+Castle (now) comes [#KipEi]_ with the parametric *base* protocol :ref:`SlowStart <doc-SlowStart>`, which is based on
+`TCP Slow start <https://en.wikipedia.org/wiki/TCP_congestion_control#Slow_start>`__ and contains a queueing model
+[#ModelOnly]_ to control the speed of an (event) connection. As the name suggests, initially the connections with be
+slow. Roughly, the parameter set the maximal number of unhandled events on a connection.
+|BR|
+The (improved) version of :ref:`Castle-TheSieve` uses a SlowStart of **1**. And `Main` will remove (or increase) that
+limit after reconnecting.
+
+Initially, the `Generator` is only *allowed* to send one event, which is received by the `Finder`. Then, `Main` will create
+the first Sieve (`Sieve(2)`), reconnect the Generator to that component, and increase the “speed” of the
+connection. As the connection **Generator->Sieve(2)** is stable, the is no need to limit the “queue”.
+
+The `Generator` acts as before: it sends (events with) integers over its output. But now, the SimpleSieve protocol can
+slow down the `Generator` --no code changes are needed for this. This may happen when the second event is sent before
+it is received (or “handled”) by the Finder, and the limit is set to **1**.
+|BR|
+As this limit is removed when a Sieve-component is inserted into the chain, only the start is slow...
+
+The same happens to every Sieve: initially (when it is connected to the Finder) there is a limit of 1 event in the
+queue. But when that connection is reconnected --and the potential Heisenbug is gone-- the limit is removed.
+
+.. tip:: Unlimited or better?
+
+   In this blog, we remove the limit of the ``SlowStart protocol`` completely, for simplicity. Then the Heisenbug is
+   solved.
+
+   That is not the only option.
+   |BR|
+   Given the `Generator` is a simple loop it can produce many integers fast. And so causes huge piles of queued
+   events. That can be done better, by the same concept: a maximal queue size. (again: just model).
+
+   It’s up to the developer to optimize this. Some prefer the maximum queue length equal to the number of
+   Sieve-components,  others relate the maximum queue length  to the number of available cores. Some use static values,
+   others will adjust them over the run-time of the application.
+   |BR|
+   That is all possible with a few lines in the `Main` component. But also the Sieve component can set this
+   limit, both for incoming ports as well for outgoing ports.
+
+
+
+-----
+
+.. rubric:: Footnotes
+
+.. [#orVariant]
+   Again, there are many variants of :ref:`Castle-TheSieve`. In some adding a `Sieve` to the chain is done by the `Finder`,
+   in others by `Main`. In both alternatives, the same reconnect is needed. There is no real difference  -- but the name
+   of the component  initiating the change.
+   |BR|
+   The Heisenbug will not (trivially) disappear when switching between hose variants
+
+.. [#ButImprove]
+   Still, as language designers, we need to give the programmer more options to hint at a more optimal implementation.
+
+.. [#KipEi]
+   This *SlowStart* base protocol is part of Castle; see :ref:`Protocol-SlowStart`. But the need for it follows
+   --like this blog-- from the discovery of these :ref:`Castle-Heisenbug` in :ref:`Castle-TheSieve`.
+
+
+.. [#ModelOnly]
+   Remember, this queue exists as a *model* **only** (like everything in Castle-code)!
+   |BR|
+   Depending on ‘:ref:`TheMachinery`, there may be no need to implement the queue (e.g.with DirectCall) at all; or there may
+   only be a queue length and -maximum, or ...
+
+
+
+..  LocalWords:  heisenbug heisenbugs

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/Heisenbug-sidebar-Sequence.irst
--- a/CCastle/4.Blog/Heisenbug-sidebar-Sequence.irst	Sun Mar 17 23:21:39 2024 +0100
+++ b/CCastle/4.Blog/Heisenbug-sidebar-Sequence.irst	Wed Mar 27 20:20:34 2024 +0100
@@ -1,27 +1,29 @@
-.. -*- rst -*-
-   included in  `a.Heisenbug.rst`
+.. -*- rst -*- (C) 2023,2024 Albert Mietus. Part of CCastle project
+   included in  `2.Heisenbug.rst`
 
-.. sidebar::
+.. Sidebar::
 
    .. tabs::
 
       .. tab:: Conceptual
 
-         This diagram shows the order of messages in a logical order. As we show only the integers that are tested for
-         (relative) prime, it looks simple and error-free.
+         This diagram shows the order of messages in a logical order. Hence, we show the “sieving sequence” per
+         integer. The following number starts only after finding a prime.
+         |BR|
+         It looks simple and error-free.
 
          .. uml:: ./sieve-Sequence-concept.puml
 
       .. tab::  One-by-One
 
-         But there is no guarantee for that the simple, conceptual order. For example, the Generator can be *“fast”* and
+         But there is no guarantee for that simple, conceptual order. For example, the Generator can be *“fast”* and
          produce the to-be-sieved integers faster than the Sieves handle.
 
          .. uml:: ./sieve-Sequence-1b1.puml
 
-      .. tab::  With Details
+      .. tab::  with Details
 
-         Adding components-creation (with reconnects) shows a lot more details. We added the event/port names, for
+         Adding components-creation (with reconnects) shows a lot more details. Also, we added the event/port names for 
          clarity. When studying carefully, we can already see there might be a problem when the order changes
 
          .. uml:: ./sieve-Sequence-details.puml

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/a.Heisenbug.rst
--- a/CCastle/4.Blog/a.Heisenbug.rst	Sun Mar 17 23:21:39 2024 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,210 +0,0 @@
-.. include:: /std/localtoc.irst
-
-.. _Castle-Heisenbug:
-
-==========
-Heisenbugs
-==========
-
-.. post:: 2023/04/08
-   :category: CastleBlogs, Castle, DesignStudy
-   :tags: Castle, DRAFT
-
-   In Castle, one can dynamically connect components and send “events” over those connections. Typically this is done as
-   an action on an incoming message (see: :ref:`CCC-Actors`). And depending on ‘:ref:`TheMachinery`’, those events can be
-   queued. It is this combination that *can result* in a **beautiful Heisenbug**.
-
-   First, let’s explain the Heisenbug, before we give an example. Then we analyze it, show how to improve the code, and
-   finally formulate a *requirement* to prevent & detect this kind of bug in Castle.
-
-What is a Heisenbug?
-====================
-
-The `heisenbug <https://en.wikipedia.org/wiki/Heisenbug>`__ is named after the theoretical physics *Werner Heisenberg*, who
-described the *“observer effect”*: when you look closely, the behavior changes. The same can happen to software
-(bugs). The behavior apparently changes when you study -or slightly adjust- that code.  Often this is due to (small)
-changes in timing; possibly even in generated code. Therefore old (old-fashioned) sequential code on slow CPUs is less
-likely to have heisenbugs than concurrent code on fast multi-core systems. It’s also common in threaded programs.
-
-.. include:: ./Heisenbug-sidebar-Sequence.irst
-
-The Sieve goes wrong
-====================
-
-My standard example, :ref:`Castle-TheSieve`, suffered from this issue. The initial version did work for years
-but failed horribly when another “machinery” was used. After studying this, the bug is simple and easy to fix.
-
-There are two related timing issues that together result in the Heisenbug. First, we introduce them and then
-show how the combination may fail.
-
-
-Event-order
------------
-
-Conceptually, the `Generator` sends (events with) integers to `Sieve(2)`, which may forward them to `Sieve(3)`, then
-to `Sieve(5)`, etc. As shown in the **Conceptual sidebar**, we probably like to assume that each integer is sieved
-before the next *’int’* *starts*: the classic “sequential view” we are used to.
-
-However, that isn’t how it works. In Castle, the order of events on a connection is defined (*one by one,
-sequential*). And given the code, the integer sent by a `Sieve` is always later than the incoming one. That is all we
-may assume.
-|BR|
-The timing of unrelated events on multiple connections is not defined. That order may depend on :ref:`TheMachinery` and
-many other factors. Do not, as a developer, assume any order --as I did!
-
-As shown in the **One-by-One sidebar** diagram, this can result that the Generator is outputting all events first. Next,
-Sieve(2) filters out the even integers, then Sieve(3) processes all its input, then Sieve(5), etc.
-|BR|
-Although we aren’t using concurrency, and it needs tremendous buffers when finding big primes, it does
-conceptually work. And so, it is an allowed execution [#ButImprove]_.
-
-
-Reconnecting
-------------
-
-The chain of `Sieve`\s will grow as we find more primes. Whenever an *int* isn’t filtered-out and reaches the `Finder` a
-*new prime* is found. Then, a new Sieve element is created and inserted into the chain.
-|BR|
-Building the chain  is done by the Main component (which is signaled by the Finder) [#orVariant]_.
-
-Therefore, `Main` remembers the ``last_sieve`` and reconnects that output to the newly creates `Sieve`.
-Which output is temporally connected to the `Finder`
-|BR|
-For every newly found prime, this is repeated.
-
-This detail is shown in the **With Details** sidebar diagram; where the `Finder` and `Main` and all its messages
-are shown too.
-
-Assuming the initial “conceptual” order, you will see the same Sieve(s) become alive (“new” message), and are added to
-the end of the sieve chain. The integers still flow (now, shown as “try(`int`)” messages) by this sieve.
-|BR|
-You will also notice the `Finder` does indeed find all primes.
-
-
-The combination
-===============
-
-Now let us study how the sieve chain will grow with a “fast generator”, and the one-by-one order of events is used. This
-diagram is shown below.
-
-As we can see in the picture, it goes dreadfully wrong. No proper chain is created, and we will find integers like **4**
-and **6**.  This is wrong, they are not prime.
-|BR|
-With a (very) *fast Generator*, **all** integers are sent to the `Finder` --before any `Sieve` is created, and so any
-int is reported as prime. besides, too many elements are added to the chain as a Sieve component is created for each found
-“prime”.  On top of that, no integer is ever sieved...
-
-This is just **an** example. As we can’t predict (or assume) any order, we can find other results too. And, when we add
-“debugging print statement” (and *look closer*), we change the timing and will find other results. We found the
-*observer effect*!
-
-.. uml:: ./sieve-Sequence-Wrong.puml
-
-
-.. warning::
-
-   It is not *“the timing”* that is wrong!
-   |BR|
-   A concurrent program is only correct when it goes right for **any** possible timing.
-
-   As in all software engineering, we can prove it is buggy when it goes wrong at least once. That is what we have
-   shown. And so, the original code is *wrong*.
-
-
-How to improve?
-===============
-
-Finding this heisenbug triggered an investigation  to improve Castle as well as ‘:ref:`Castle-TheSieve`’. Where our goal
-is not just to improve the sieve code, but all programs. And give the programmer options to prevent heisenbugs.
-
-As we will see fixing ‘:ref:`the sieve <Castle-TheSieve>` is simple: use the **SLowStart** (base) protocol. It changes
-only three lines!
-|BR|
-But we start with a new requirement, for a new tool in the :ref:`Castle Workshop <Workshop-Design>`.
-
-
-Simulation
-----------
-
-As we will see below the `SlowStart` protocol will *remove* our Heisenbug. But it does not abolish the Heisenbug!
-
-The feature does by no means prevent a developer from using other solutions, with a comparable flaw. Besides, it’s
-hopeless to use testing to prove the absence of a Heisenbug. As we have seen above, all variants of all possible
-concurrent execution orders should be correct. Where we have very limited control over which variant is used.
-
-This led to a new requirement: :need:`U_Tools_EventOrder.` To assist the developer the Castle Workshop will come
-with tools to detect such bugs. See :ref:`simulation` for more on this.
-
-
-.. include:: ./sieve-protocols-sidebar.irst
-SlowStart
----------
-
-Castle (now) comes [#KipEi]_ with the parametric *base* protocol :ref:`SlowStart <doc-SlowStart>`, which is based on
-`TCP Slow start <https://en.wikipedia.org/wiki/TCP_congestion_control#Slow_start>`__ and contains a queueing model
-[#ModelOnly]_ to control the speed of an (event) connection. As the name suggests, initially the connections with be
-slow. Roughly, the parameter set the maximal number of unhandled events on a connection.
-|BR|
-The (improved) version of :ref:`Castle-TheSieve` uses a SlowStart of **1**. And `Main` will remove (or increase) that
-limit after reconnecting.
-
-Initially, the `Generator` is only *allowed* to send one event, which is received by the `Finder`. Then, `Main` will create
-the first Sieve (`Sieve(2)`), reconnects the Generator to that component, and increases the “speed” of the
-connection. As the connection **Generator->Sieve(2)** is stable, the is no need to limit the “queue”.
-
-The `Generator` acts as before: it sends (events with) integers over its output. But now, the SimpleSieve protocol can
-slow down the `Generator` --no code changes are needed for this. This may happen when the second event is sent before
-it is received (or “handled”) by the Finder, and the limit is set to **1**.
-|BR|
-As this limit is removed when a Sieve-component is inserted into the chain, only the start is slow...
-
-The same happens to every Sieve: initially (when it is connected to the Finder) there is a limit of 1 event in the
-queue. But when that connection is reconnected --and the potential Heisenbug is gone-- the limit is removed.
-
-.. tip:: Unlimited or better?
-
-   In this blog, we remove the limit of the ``SlowStart protocol`` completely, for simplicity. Then the Heisenbug is
-   solved.
-
-   That is not the only option.
-   |BR|
-   Given the `Generator` is a simple loop it can produce many integers fast. And so cause huge piles of queued
-   events. That can be done better, by the same concept: a maximal queue size. (again: just model).
-
-   It’s up to de developer to optimize this. Some prefer the maximum queue length equal to the number of
-   Sieve-components,  others relate the maximum queue length  to the number of available cores. Some use static values,
-   others will adjust them over the run-time of the application.
-   |BR|
-   That is all possible with a few lines in the `Main` component. But also the Sieve component can set this
-   limit, both for incoming-ports as well for outgoing ports.
-
-
-
------
-
-.. rubric:: Footnotes
-
-.. [#orVariant]
-   Again, there are many variants of :ref:`Castle-TheSieve`. In some adding a `Sieve` to the chain is done by the `Finder`,
-   in others by `Main`. In both alternatives, the same reconnect is needed. There is no real difference  -- but the name
-   of the component  initiating the change.
-   |BR|
-   The Heisenbug will not (trivially) disappear when switching between hose variants
-
-.. [#ButImprove]
-   Still, as language-designer, we need to give the programmer more options to hint at a more optimal implementation.
-
-.. [#KipEi]
-   This *SlowStart* base protocol is part of Castle; see :ref:`Protocol-SlowStart`. But the need for it --follows like
-   this blog-- follows from the discovery of these :ref:`Castle-Heisenbug` in :ref:`Castle-TheSieve`.
-
-
-.. [#ModelOnly]
-   Remember, this queue exists as a *model* **only** (like everything in Castle-code)!
-   |BR|
-   Depending on ‘:ref:`TheMachinery`, there may be no need to implement the queue (e.g.with DirectCall) at all; or they may
-   only be a queue length and -maximum, or ...
-
-
-
-..  LocalWords:  heisenbug heisenbugs

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/b.TheSieve.rst
--- a/CCastle/4.Blog/b.TheSieve.rst	Sun Mar 17 23:21:39 2024 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,148 +0,0 @@
-.. .. include:: /std/localtoc.irst
-
-.. _Castle-TheSieve:
-
-============================
-The Sieve demo (start/DRAFT)
-============================
-
-.. post::
-   :category: CastleBlogs, Demo
-   :tags: Castle, DRAFT
-
-
-   To show some features of CCastle, I use *‘the sieve’*, short for the `Sieve of Eratosthenes
-   <https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes>`__. An old, well known, algorithm to find prime numbers; with
-   impliciet concurrency.
-
-   With an almost trivial implementation, many “CC concepts” can be shown. In only a handful of lines....
-
-The design
-**********
-
-We only need tree simple components as shown below, and a main component (not shown). We also use two protocols, that
-are given below.
-
-.. include:: ./sieve-design.irst
-
-The elements of the sieve
-=========================
-
-CCastle use “components” [#not-package]_ as main decomposition. Each kind of component can be instantiated multiple
-times; sometimes called a *element*, or also just *component*. This is very like *“classes” and “objects”* in OO
-[#active-class]_.
-
-Let’s introduce the those components
-
-Generator
----------
-
-This component generates just numbers, which will be tested for prime (see below). As primes are always integer bigger
-then one; it output is the stream stream of numbers: 2,3,4, …
-
-Sieve (on prime)
-----------------
-
-We use a (growing) chain of sieve-elements. Each one is the same; except for the sieving-constant --a already found
-prime. That number is set when instantiating the element.
-
-
-Each Sieve tries to divide each incoming number to its own, sieve-constant. When the modulo isn’t zero, we call it
-a *coprime* (relative to the already tested primes) and send downstream. When it can be divided, the number is clearly
-not prime and ignored
-
-Finder
-------
-
-Each number that comes out of the chain of sieves is a prime (that is the algorithm; see Wikipedia for details). It is
-collected by the finder. For each found prime, an extra sieve (element) is created and added to the chain. This kind
-of shifts the finder to the right (aka downstream)
-
-In some implementations that is the responsibility of the finder (therefore sometimes calls “head”). In a variant, the
-‘main’ component is caring that load.
-
-Communication
-=============
-.. include:: ./sieve-protocols-sidebar.irst
-
-CCastle uses “protocols” to communicate between components. There are several kind of protocols; we use the ‘event’ kind
-here. Two ports can be connected when both use the same protocol.
-
-Notice, that a *protocol* is not the same as an API in most language’s. A fundamenta concept of :ref:`CC`/CCastle is the
-strict seperation between outside and inside
-
-StartSieve
-----------
-
-The StartSieve protocol signals to start sieving (so generating numbers), and when to stop. This “max” number is the
-maximal number to be tried, and does not need to be a prime.
-
-Currently, the is no way to specify the number of primes to be found.
-
-
-SimpleSieve
------------
-
-In this variant [#sieve-variants]_, we use an event-based protocol, that just hold one event (read: a message), that
-carries the integer to be tried.
-
-In the *Original* version, it was a basic `Protocol`. Which worked fine until we studied the another :ref:`machinery
-<TheMachinery>`: :ref:`Machinery-LibDispatch`, and it become clear we had a :ref:`Castle-Heisenbug`! (See there for
-details.)
-|BR|
-Now, we use an improved version, where we use a simple push-back algorithm by inheriting from ``SlowStart``. This adds a
-queue to the model, that limits (slows down) the sender to a maximum number of (unhandled) events; in this case that is
-initially: only one event ``SlowStart(1)``.
-
-.. note::
-
-   Without going into details, it important to realize the *queue* is only added in the model! Depending on the
-   :ref:`TheMachinery` it will probably  **not** exist in the computer-code.
-   |BR|
-   For example, the :ref:`Machinery-DirectCall` machinery will never need, not use this queue
-
-   It also shows normal Castle-programmer can focus on the functional aspect of the protocol. The SimpleSieve doesn't
-   need any extra message to controll this SlowStart (or sliding windows, as is also know) algorithm. That is fully
-   handled in a generic base-protocol.
-   |BR|
-   Additionally, the even more technical aspect of how to send events between (CC) components are completely hidden. As
-   long as both components use the same protocol it will work. ref:`TheMachinery` will make sure that both components
-   use the same technical details on both ends.
-
-
-
-Main
-****
-
-All the components (or elements) above have to created (statically or dynamically) by an top-level component, which is
-usually called “main”. However the name is not special (like in C/C++), it’s  more a convention (like in Python).
-
-
-
-
-XXXX
-
-The Code
-********
-
-.. include:: ./sieve-code.irst
-
-----------
-
-.. rubric:: Footnotes
-
-.. [#not-package]
-   A CCastle **component** is unrelated to an *UML-component*. It is **not** a package, as many people use for the UML variant.
-
-.. [#active-class]
-   A (CCastle) **component** (or actually, an element) is sometimes described as an “active class (aka object)” -- a
-   class with a thread inside. This is not completely correct, but gives a good, first impression.
-   |BR|
-   Notice however, there a no threads in CCastle -- just concurrency and parallelism.
-
-.. [#sieve-variants]
-   There are multiple variants of ‘the Sieve’; all showing other (CC/Castle) aspects. In this one event-bases protocols
-   are used. There is also a variant with data-based protocol, variants with, and without :ref:`Castle-Heisenbug`, etc.
-
-
-..  LocalWords:  coprime

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/index.rst
--- a/CCastle/4.Blog/index.rst	Sun Mar 17 23:21:39 2024 +0100
+++ b/CCastle/4.Blog/index.rst	Wed Mar 27 20:20:34 2024 +0100
@@ -1,3 +1,4 @@
+.. (C) 2023,2024 Albert Mietus. Part of CCastle project
 ==============================
 Blog on various CCastle topics
 ==============================

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-Sequence-1b1.puml
--- a/CCastle/4.Blog/sieve-Sequence-1b1.puml	Sun Mar 17 23:21:39 2024 +0100
+++ b/CCastle/4.Blog/sieve-Sequence-1b1.puml	Wed Mar 27 20:20:34 2024 +0100
@@ -1,3 +1,4 @@
+' (C) 2023,2024 Albert Mietus. Part of CCastle project
 @startuml
 hide footbox
 title OutOfOrder (Fast generator)

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-Sequence-Wrong.puml
--- a/CCastle/4.Blog/sieve-Sequence-Wrong.puml	Sun Mar 17 23:21:39 2024 +0100
+++ b/CCastle/4.Blog/sieve-Sequence-Wrong.puml	Wed Mar 27 20:20:34 2024 +0100
@@ -1,3 +1,4 @@
+' (C) 2023,2024 Albert Mietus. Part of CCastle project
 @startuml
 'hide footbox
 title Wrong (Generate fast & Slow creation)

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-Sequence-concept.puml
--- a/CCastle/4.Blog/sieve-Sequence-concept.puml	Sun Mar 17 23:21:39 2024 +0100
+++ b/CCastle/4.Blog/sieve-Sequence-concept.puml	Wed Mar 27 20:20:34 2024 +0100
@@ -1,3 +1,4 @@
+' (C) 2023,2024 Albert Mietus. Part of CCastle project
 @startuml
 hide footbox
 title Concept (sequential order)

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-Sequence-details.puml
--- a/CCastle/4.Blog/sieve-Sequence-details.puml	Sun Mar 17 23:21:39 2024 +0100
+++ b/CCastle/4.Blog/sieve-Sequence-details.puml	Wed Mar 27 20:20:34 2024 +0100
@@ -1,3 +1,4 @@
+' (C) 2023,2024 Albert Mietus. Part of CCastle project
 @startuml
 hide footbox
 title Sieve creation details (sequantial order)

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-castle.irst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/CCastle/4.Blog/sieve-castle.irst	Wed Mar 27 20:20:34 2024 +0100
@@ -0,0 +1,70 @@
+.. -*-rst-*- (C) 2023,2024 Albert Mietus. Part of CCastle project
+   included in  `1.TheSieve.rst`
+.. NOTE the code-tabs use ReasonML , but it is Castle-code!!
+
+.. tabs::
+   .. code-tab:: ReasonML Generator
+
+      implement Generator {
+        int maxValue;
+
+      StartSieve.newMax(max) on .controll
+      {
+        .maxValue := max;
+      }
+
+      StartSieve.runTo(max) on .controll
+      {
+        int i;
+
+        .maxValue := max;
+        i:=0;
+        while (i < .maxValue) {
+          .outlet.input(i);
+        }
+      }
+
+      } //@end Generator
+
+
+   .. code-tab:: ReasonML Sieve
+
+      implement Sieve {
+        int myPrime;
+
+      init(int:onPrime)  // `init` is (typically) part of the construction of a element.
+      {
+        super.init();    // `super` acts as port to the base-class
+        .myPrime := onPrime;
+      }
+
+      SimpleSieve.input(try) on .try
+      {
+        if ( (try % .myPrime) !=0 ) {
+          .coprime.input(try);
+        }
+      }
+
+      } //@end Sieve
+
+
+   .. code-tab:: ReasonML Finder
+
+      implement Finder {
+        int count;
+
+      SimpleSieve.input(foundPrime) on .newPrime
+      {
+        .found.input(foundPrime);         // Forward to “main”
+        report()
+      }
+
+      report() // This is a local function -- as it is not connected (to a port) it is “private”
+      {
+        printf("Finder: Found prime (no %s): %8i\n", .count, foundPrime);
+        .count +=1
+      }
+
+      } //@end Finder
+
+

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-code.irst
--- a/CCastle/4.Blog/sieve-code.irst	Sun Mar 17 23:21:39 2024 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,143 +0,0 @@
-.. -*-rst-*-
-   included in  `b.TheSieve.rst`
-
-.. NOTE the code-tabs use ReasonML , but it is Castle-code!!
-
-.. The "No Heisenbug" variant is used as base:    ``.../SIEVE/3.NoHeisenbug/CC-event-sieve.Castle``
-
-Moat (*interfaces*)
-===================
-
-
-.. tabs::
-
-   .. code-tab:: ReasonML Generator
-
-      component Generator : Component {
-        port StartSieve<in>:controll;
-        port SimpleSieve<out>:outlet;
-        port SimpleSieve<in>:collect;
-      }
-
-   .. code-tab:: ReasonML Sieve
-
-      component Sieve(onPrime:int) : Component {
-        port SimpleSieve<in>:try;
-        port SimpleSieve<out>:coprime;
-      }
-
-   .. code-tab:: ReasonML Finder
-
-      component Finder : Component {
-        port SimpleSieve<in>:newPrime;
-        port SimpleSieve<out>:found;
-      }
-
-Castle (*implementation*)
-=========================
-
-.. tabs::
-   .. code-tab:: ReasonML Generator
-
-      implement Generator {
-        int maxValue;
-
-      StartSieve.newMax(max) on self.controll
-      {
-        self.maxValue := max;
-      }
-
-      StartSieve.runTo(max) on self.controll
-      {
-        int i;
-
-        self.maxValue := max;
-        i:=0;
-        while (i < self.maxValue) {
-          self.outlet.input(i);
-        }
-      }
-
-      SimpleSieve.input(foundPrime) on .collect
-      {
-        static int count:=0;
-        count :+= 1;
-        printf("Generator: Collected prime (no %s): %8i\n", count, foundPrime);
-      }
-      } //@end Generator
-
-   .. code-tab:: ReasonML Sieve
-
-      implement Sieve {
-        int myPrime;
-
-      -init(onPrime:int)
-      {
-        super.init();								//note 'super' acts as a port
-        self.myPrime := onPrime;
-      }
-
-      SimpleSieve.input(try) on .try
-      {
-        if ( (try % self.myPrime) !=0 ) {
-          self.coprime.input(try);
-        }
-      }
-      } //@end Sieve
-
-   .. code-tab:: ReasonML Finder
-
-      implement Finder {
-
-      SimpleSieve.input(foundPrime) on self.newPrime
-      {
-        // Send out the newPrime,
-        self.found.input(foundPrime);
-      }
-      } //@end Finder
-
-   .. code-tab:: ReasonML Main
-
-      implement Main {
-        sub generator;
-        sub finder;
-        alias lastSieve;         // The list of Sieve's grow dynamicly!; keep track of the last one
-
-      -init()
-      {
-        self := super.init();
-
-        .generator := Generator.new();
-        .finder    := Finder.new();
-
-        .generator.outlet = .finder.newPrime; // Initially, there aren't any Sieves
-        self.lastSieve := Ground; // Not needed, as it is default. But is clearifies the code below
-      }
-
-      // We have build the sievelist (and reconnect) on a newly found prime ..
-      SimpleSieve.try(newPrime) on self.generator.found
-      {
-        alias s;
-
-        // Extent the sieve-list ...
-        s:= Sieve.new(newPrime);
-        s.coprime = self.finder.newPrime;
-        if (not self.lastSieve == Ground) {              // .lastSieve == Ground, so not connected, so we have the first Sieve to connect to .generator
-          self.generator.outlet = s.try;
-          self.generator.outlet.queue.removeLimit();
-        } else {
-          self.lastSieve.coprime = s.try;
-          self.lastSieve.coprime.queue.removeLimit();
-        }
-        .lastSieve := s;
-
-        self.generator.collect.input(newPrime);   // forward the prime to the Generator
-      }
-
-      powerOn() on self.power
-      {
-        int max := 10;
-
-        self.generator.runTo(max);
-      }
-      } //@end Main

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-design.irst
--- a/CCastle/4.Blog/sieve-design.irst	Sun Mar 17 23:21:39 2024 +0100
+++ b/CCastle/4.Blog/sieve-design.irst	Wed Mar 27 20:20:34 2024 +0100
@@ -1,5 +1,5 @@
 .. -*- rst -*-
-   USED in b.TheSieve.rst
+   USED in 1.TheSieve.rst
 
 .. uml::
 
@@ -14,7 +14,7 @@
    +-----------/    \-----------/    \-----------/    \-----------/    \-----------/    \---------*-+
                                                                                                   |
    0 The shown (horizontal) connections all use the SimpleSieve protocol                          V Primes
-   0 The Generator has an (in-)port for the StartSieve protocol
-   0 The Finder has an optional (out-) port for SimpleSieve protocol
+   0 The Generator has an (in‒) port for the StartSieve protocol
+   0 The Finder has an optional (out‒) port for SimpleSieve protocol
 
    @endditaa

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-main.irst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/CCastle/4.Blog/sieve-main.irst	Wed Mar 27 20:20:34 2024 +0100
@@ -0,0 +1,66 @@
+.. -*-rst-*-  (C) 2023,2024 Albert Mietus. Part of CCastle project
+   included in  `1.TheSieve.rst`
+.. NOTE the code-tabs use ReasonML , but it is Castle-code!!
+
+.. tabs::
+
+   .. code-tab:: ReasonML Main
+
+      implement Main {
+        sub generator;
+        sub finder;
+        alias lastSieve;         // The list of Sieve's grow dynamically!; keep track of the last one
+      ...
+
+
+   .. code-tab:: ReasonML init()
+
+      init()
+      {
+        super.init();
+
+        .generator := Generator();
+        .finder    := Finder();
+
+        // Initially, there aren't any Sieves, so ...
+        .generator.outlet = .finder.newPrime;     // ... connect the generator to the finder
+        .lastSieve := Ground;                     // Not needed (as default); but it clarifies the code below
+      }
+
+
+   .. code-tab:: ReasonML try() on found
+
+      // We have build the sievelist (and reconnect) on a newly found prime ..
+      SimpleSieve.try(newPrime) on .generator.found
+      {
+        alias s;
+
+        // Extent the sieve-list ...
+        s:= Sieve(newPrime);
+        insert_sieve(s);
+        .generator.collect.input(newPrime);   // forward the prime to the Generator
+      }
+
+
+      insert_sieve(alias:s)
+      {
+        // Connect s to the lastSieve, or the Generator
+        if (.lastSieve == Ground) {              // .lastSieve == Ground, so not connected, so we have the first Sieve to connect to .generator
+           .generator.outlet = s.try;
+         } else {
+           .lastSieve.coprime = s.try;
+        }
+
+        // And to the Finder, that is self
+        s.coprime = .finder.newPrime; 
+      }
+
+   .. code-tab:: ReasonML  powerOn() 
+
+      powerOn() // this kick-starts “every main”
+      {
+        int max := 10;
+
+        .generator.runTo(max);
+      }
+

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-moat.irst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/CCastle/4.Blog/sieve-moat.irst	Wed Mar 27 20:20:34 2024 +0100
@@ -0,0 +1,28 @@
+.. -*-rst-*- (C) 2023,2024 Albert Mietus. Part of CCastle project
+   included in  `1.TheSieve.rst`
+.. NOTE the code-tabs use ReasonML , but it is Castle-code!!
+
+.. tabs::
+
+   .. code-tab:: ReasonML Generator
+
+      component Generator : Component {
+        port StartSieve<in>:controll;
+        port SimpleSieve<out>:outlet;
+        port SimpleSieve<in>:collect;
+      }
+
+   .. code-tab:: ReasonML Sieve
+
+      component Sieve(onPrime:int) : Component {
+        port SimpleSieve<in>:try;
+        port SimpleSieve<out>:coprime;
+      }
+
+   .. code-tab:: ReasonML Finder
+
+      component Finder : Component {
+        port SimpleSieve<in>:newPrime;
+        port SimpleSieve<out>:found;
+      }
+

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-protocols-sidebar.irst
--- a/CCastle/4.Blog/sieve-protocols-sidebar.irst	Sun Mar 17 23:21:39 2024 +0100
+++ b/CCastle/4.Blog/sieve-protocols-sidebar.irst	Wed Mar 27 20:20:34 2024 +0100
@@ -1,55 +1,28 @@
-.. -*-rst-*-
+.. -*-rst-*- (C) 2023,2024 Albert Mietus. Part of CCastle project
    included in  `b.TheSieve.rst`
 
-.. note: the code-tabs use ReasonML , but it Castle-code!!
+.. note The code-tabs use ReasonML , but it is Castle-code!!
 
 .. sidebar:: Sieve Protocols
 
    .. tabs::
 
-      .. code-tab:: ReasonML Original
+      .. code-tab:: ReasonML StartSieve
 
-         protocol StartSieve : Protocol {
-              kind: event;
+         protocol StartSieve : EventProtocol {
               runTo(int:max);
+              newMax(int:max);
          }
 
-         protocol SimpleSieve : Protocol {
-              kind: event;
+      .. code-tab:: ReasonML SimpleSieve
+
+         protocol SimpleSieve : EventProtocol {
               input(int:try);
          }
 
-      .. tab:: Improved
-
-         This version has one main change: the SimpleSieve now inherits from **SlowStart**
-
-         .. code-block:: ReasonML
-
-            protocol StartSieve : Protocol {
-                 kind: event;
-                 runTo(int:max);
-            }
-
-            protocol SimpleSieve : SlowStart(1) {
-                 input(int:try);
-            }
-
-         Aside of that, the ``kind: event`` line is gone, as it *inherited* from ``SlowStart``
+      .. tab:: Syntax notes
 
-      .. tab:: Demo of use
-
-         .. code-block:: ReasonML
-            :emphasize-lines: 6,10
+         As the Castle syntax isn’t fully stable, a few notes:
 
-            SimpleSieve.try(newPrime) on self.generator.found
-            {
-               ...
-               // When ``Sieve(2)`` is made (alias: s)
-               self.generator.outlet = s2.try;
-               self.generator.outlet.queue.removeLimit();
-               ...
-               // Simular for other ``Sieve’s``
-               self.lastSieve.coprime = s.try;
-               self.lastSieve.coprime.queue.removeLimit();
-               ...
-            }
+         - Parmeters are in ``type:name`` order, which may change.
+         - The protocol-kind is inherited, not the (older) explicit ``kind: event`` variant.

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/sieve-protocols2-sidebar.irst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/CCastle/4.Blog/sieve-protocols2-sidebar.irst	Wed Mar 27 20:20:34 2024 +0100
@@ -0,0 +1,49 @@
+.. -*-rst-*- (C) 2023,2024 Albert Mietus. Part of CCastle project
+   included in  `b.TheSieve.rst`
+
+.. note The code-tabs use ReasonML , but it is Castle-code!!
+
+.. sidebar:: SimpleSieve Protocols
+
+   .. tabs::
+
+      .. tab:: Original
+
+         The original SimpleSieve protocol is (sic) simple ... too simple.
+
+         .. code-block:: ReasonML
+
+            protocol SimpleSieve : EventProtocol {
+               input(int:try);
+            }
+
+         As there is no flow control “co-primes” can be *queued*,  or arrive too soon.
+
+      .. tab:: SlowStart
+
+         In this version, SimpleSieve inherits from **SlowStart**
+
+         .. code-block:: ReasonML
+
+            protocol SimpleSieve : SlowStart(1) {
+               input(int:try);
+            }
+
+      .. tab:: Demo of use
+
+         .. code-block:: ReasonML
+            :emphasize-lines: 6,10
+
+            SimpleSieve.try(newPrime) on self.generator.found
+            {
+               ...
+               // When ``Sieve(2)`` is made (alias: s)
+               self.generator.outlet = s2.try;
+               self.generator.outlet.queue.removeLimit();
+               ...
+               // Simular for other ``Sieve’s``
+               self.lastSieve.coprime = s.try;
+               self.lastSieve.coprime.queue.removeLimit();
+               ...
+            }
+

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/variants/SlowStart.rst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/CCastle/4.Blog/variants/SlowStart.rst	Wed Mar 27 20:20:34 2024 +0100
@@ -0,0 +1,60 @@
+:orphan:
+.. (C) 2024 Albert Mietus. Part of CCastle project
+
+.. _SLowStart-Sieve:
+
+======================
+SlowStart Sieve (ToDo)
+======================
+
+* variants [#sieve-variants]_,
+
+Now, we use an improved version, where we use a simple push-back algorithm by inheriting from ``SlowStart``. This adds a
+queue to the model, that limits (slows down) the sender to a maximum number of (unhandled) events; in this case that is
+initially: only one event ``SlowStart(1)``.
+
+.. note::
+
+   Without going into details, it important to realize the *queue* is only added in the model! Depending on the
+   :ref:`TheMachinery` it will probably  **not** exist in the computer-code.
+   |BR|
+   For example, the :ref:`Machinery-DirectCall` machinery will never need, not use this queue
+
+   It also shows normal Castle-programmer can focus on the functional aspect of the protocol. The SimpleSieve doesn't
+   need any extra message to controll this SlowStart (or sliding windows, as is also know) algorithm. That is fully
+   handled in a generic base-protocol.
+   |BR|
+   Additionally, the even more technical aspect of how to send events between (CC) components are completely hidden. As
+   long as both components use the same protocol it will work. ref:`TheMachinery` will make sure that both components
+   use the same technical details on both ends.
+
+
+.. [#sieve-variants]
+   There are multiple variants of ‘the Sieve’; all showing other (CC/Castle) aspects. In this one event-bases protocols
+   are used. There is also a variant with data-based protocol, variants with, and without :ref:`Castle-Heisenbug`, etc.
+
+
+.. tabs::
+
+   .. code-tab:: ReasonML try() on found -- with puhback
+
+      // We have build the sievelist (and reconnect) on a newly found prime ..
+      SimpleSieve.try(newPrime) on self.generator.found
+      {
+        alias s;
+
+        // Extent the sieve-list ...
+        s:= Sieve.new(newPrime);
+        s.coprime = self.finder.newPrime;
+        if (not self.lastSieve == Ground) {              // .lastSieve == Ground, so not connected, so we have the first Sieve to connect to .generator
+          self.generator.outlet = s.try;
+          self.generator.outlet.queue.removeLimit();
+        } else {
+          self.lastSieve.coprime = s.try;
+          self.lastSieve.coprime.queue.removeLimit();
+        }
+        .lastSieve := s;
+
+        self.generator.collect.input(newPrime);   // forward the prime to the Generator
+      }
+

diff -r c06529983fb9 -r b181a1b05a4e CCastle/4.Blog/variants/TEMP.isrt
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/CCastle/4.Blog/variants/TEMP.isrt	Wed Mar 27 20:20:34 2024 +0100
@@ -0,0 +1,48 @@
+.. (C) 2023,2024 Albert Mietus. Part of CCastle project
+
+.. -*-rst-*-
+   These where used in a draft, overcomplicated version of “the Sieve” blog. And saved here when that blog was clean-up
+.. note: the code-tabs use ReasonML , but it Castle-code!!
+
+.. sidebar:: SAVED
+
+   .. tabs::
+
+      .. tab:: SlowStart(1)
+
+         This version has one main change: the SimpleSieve now inherits from **SlowStart**
+
+         .. code-block:: ReasonML
+
+            protocol StartSieve : Protocol {
+                 kind: event;
+                 runTo(int:max);
+            }
+
+            protocol SimpleSieve : SlowStart(1) {
+                 input(int:try);
+            }
+
+         Aside of that, the ``kind: event`` line is gone, as it *inherited* from ``SlowStart``
+
+      .. tab:: Demo of use
+
+         .. code-block:: ReasonML
+            :emphasize-lines: 6,10
+
+            SimpleSieve.try(newPrime) on self.generator.found
+            {
+               ...
+               // When ``Sieve(2)`` is made (alias: s)
+               self.generator.outlet = s2.try;
+               self.generator.outlet.queue.removeLimit();
+               ...
+               // Simular for other ``Sieve’s``
+               self.lastSieve.coprime = s.try;
+               self.lastSieve.coprime.queue.removeLimit();
+               ...
+            }
+
+      The Castle syntax isn’t fully stable, Here we use an old/provisionally version
+
+