From ea183086ca7dd3a8311d18955b4779e8f418cab0 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 24 Jul 2024 20:29:37 +0200 Subject: [PATCH] Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call --- src/steam/engine/weaving-pattern-builder.hpp | 51 +++- wiki/thinkPad.ichthyo.mm | 294 ++++++++++++++++--- 2 files changed, 301 insertions(+), 44 deletions(-) diff --git a/src/steam/engine/weaving-pattern-builder.hpp b/src/steam/engine/weaving-pattern-builder.hpp index c963d034d..2cd001829 100644 --- a/src/steam/engine/weaving-pattern-builder.hpp +++ b/src/steam/engine/weaving-pattern-builder.hpp @@ -41,6 +41,7 @@ //#include "vault/gear/job.h" #include "lib/several-builder.hpp" #include "steam/engine/turnout.hpp" +#include "steam/engine/buffer-provider.hpp" //#include "lib/util-foreach.hpp" //#include "lib/iter-adapter.hpp" //#include "lib/meta/function.hpp" @@ -48,7 +49,9 @@ //#include "lib/util.hpp" //#include +#include //#include +#include namespace steam { @@ -72,6 +75,20 @@ namespace engine { DataBuilder leadPort; DataBuilder outTypes; + using TypeMarker = std::function; + using ProviderRef = std::reference_wrapper; + + std::vector buffTypes; + std::vector providers; + + struct ServiceCtx + { + ProviderRef mem; + ProviderRef cache; + ProviderRef output; + }; + ServiceCtx ctx; //////////////////////////////////////////OOO need to wire that top-down through all builders! + SimpleWeavingBuilder attachToLeadPort(ProcNode& lead, uint portNr) { @@ -81,21 +98,49 @@ namespace engine { return move(*this); } + template SimpleWeavingBuilder - appendBufferTypes(size_t cnt, BuffDescr const& descriptor) + appendBufferTypes(size_t cnt) { - outTypes.fillElm (cnt, descriptor); - ENSURE (outTypes.size() < N); + while (cnt--) + buffTypes.emplace_back([](BufferProvider& provider) + { return provider.getDescriptor(); }); + ENSURE (buffTypes.size() < N); return move(*this); } + SimpleWeavingBuilder + selectOutputSlot(size_t i) + { + maybeFillDefaultProviders (i+1); + ENSURE (providers.size() > i); + providers[i] = ctx.output; + } + + auto build() { + maybeFillDefaultProviders (buffTypes.size()); + uint i=0; + for (auto& typeCtor : buffTypes) + outTypes.emplace (typeCtor(providers[i])); + + ENSURE (leadPort.size() < N); + ENSURE (outTypes.size() < N); + using Product = Turnout>; ///////////////////////////////OOO need a way to prepare SeveralBuilder-instances for leadPort and outDescr --> see NodeBuilder return Product{leadPort.build(), outTypes.build}; } + + private: + void + maybeFillDefaultProviders (size_t maxSlots) + { + for (uint i=providers.size(); i < maxSlots; ++i) + providers.emplace_back (ctx.mem); + } }; /////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : (End)Prototyping: how to assemble a Turnout diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index eae573a44..39a5785c6 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -4214,9 +4214,7 @@ - - - +

...und zwar wirklich sehr implizit, @@ -4235,9 +4233,7 @@ - - - +

das folgt einfach aus den logischen Eigenschaften der beteiligten Komponenten, @@ -4263,9 +4259,7 @@ - - - +

wer besitzt die @@ -4307,9 +4301,7 @@ - - - +

muß alle Operationen durchschleifen @@ -4322,9 +4314,7 @@ - - - +

meint: zwei gekoppelte Statusvariable @@ -4788,9 +4778,7 @@ - - - +

Idee: Zusammenarbeit @@ -5469,9 +5457,7 @@ - - - +

letztlich bin ich davon abgekommen, einen gezeichneten Pfeil zu integrieren; auch die Insets habe ich aufgegeben, dadurch wird das Design stringenter. Die Hervorhebung erfolgt nur durch ein Glanzlicht oben links, im Zusammenspiel mit den 2px Gehrungen und einem zusätzlichen Schatten an der Kehle der Gehrung @@ -7208,9 +7194,7 @@ - - - +

...and this anchorage can be covered and backed by the currently existing UI configuration @@ -9300,9 +9284,7 @@ - - - +

also IterableDecorator aufgesetzt auf die Core im Transformer @@ -12459,9 +12441,7 @@ - - - +

realer Pfad endet mit elided nach Wildcard @@ -82131,7 +82111,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + @@ -86937,7 +86918,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + @@ -87842,8 +87824,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
UseHeapAlloc ⟵ default-Policy für alle Builder

- - + @@ -87853,8 +87834,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
...vermutlich wird es irgendwann so eine Art »Builder-Framework« geben, und dorthin gehören dann solche Definitionen. Derzeit kann ich hierfür noch keine sinnvolle Code-Struktur festlegen

- - + @@ -87996,6 +87976,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

+ @@ -88214,19 +88195,28 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + + + +

+ Stufe-1: zunächst einmal brauchen wir ein Array von BufferProvider(n) +

+ + + - +

- der zentrale Test verifyStandardCase() ist auskommentiert,  da er sich auf die BufferTable abstützt — und mit deren Implementierung bin ich seinerzeit irgendwo in genau dem gleichen Wald versumpft, in dem ich jetzt auch wieder stecke ... + der zentrale Test verifyStandardCase() ist auskommentiert, da er sich auf die BufferTable abstützt — und mit deren Implementierung bin ich seinerzeit irgendwo in einem ähnlich gelagerten Wald versumpft, in dem ich jetzt auch wieder herumrirre ...

 ☹ @@ -88262,7 +88252,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + @@ -88282,6 +88272,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ @@ -88401,6 +88392,225 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + + + +

+ was bis jetzt feststeht: dem Weaving-Pattern werden BufferDescriptors gegeben +

+ + + + + + + + + +

+ Begründung: der Aufrufer legt das zusammen mit der konkreten Funktion fest +

+ + + + + + +

+ Der Aufrufer ist Code im Kontext der Domain-Ontology, und nur von dort kann bekannt sein, was die eingebundene Funktion konkret auf jedem »output slot« liefert +

+ + + + + + + + +

+ Einschränkung: der Aufrufer kennt den benötigten Typ des Buffers +

+ + + + + + + + + +

+ aber auch nur diesen +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ heißt konkret, ein BufferProdiver könnte einen BufferDescriptor eines anderen Providers übernehmen und re-interpretieren +

+ + + + + + + + + + +

+ wenn man nur ein opaques Handle herausgibt, dann läßt man sich Spiel für spätere Entwicklung im BufferProvider selber; wenn wir das aufgeben, dann wird die derzeitige Prototyp-Implementierung zum Standard; und es ist immer eine sehr schlechte Idee, eine Implementierung zum Standard werden zu lassen +

+ + + + + + + + + + + +

+ und zwar, weil wir ja auf den Aufrufer / den Kontext der Domain-Ontology angewiesen sind, um überhaupt zu wissen, wie viele Slots es geben wird +

+ + + + + + + + + + + + + + +

+ zur Erinnerung: die vollständige Form lautet... +

+

+ +

+

+   template<typename BU, typename...ARGS> +

+

+   BuffDescr +

+

+   BufferProvider::getDescriptor (ARGS  ...args) +

+ + + + + + + + + + + + + + + + + + + + + +

+ ⟹ das müßte dann in den shed()-Aufruf gehen +

+ + + + + + + + + + + + + + + + + + +

+ ...im aktuellen Stand brauchen wir die Info nur während dem Build-Vorgang; sobald man aber später übergeht zu einem ctor-λ, müßte man die Info in die Node (in den Turnout) materialisieren. Nun könnte man aktuell „einfach“ einen std::vector nehmen — oder aber, genauso „einfach“ einen weiteren SeveralBuilder mitlaufen lassen. Vorteil: der Speicher liegt im AllocationCluster / Nachteil: der Speicher wird verschwendet +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -88434,7 +88644,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + +