diff --git a/src/steam/engine/node-builder.hpp b/src/steam/engine/node-builder.hpp index 31509035c..150f85ec6 100644 --- a/src/steam/engine/node-builder.hpp +++ b/src/steam/engine/node-builder.hpp @@ -298,11 +298,11 @@ namespace engine { private: - PortBuilderRoot(NodeBuilder&& anchor) - : NodeBuilder{move(anchor)} + PortBuilderRoot(NodeBuilder&& anchor) + : NodeBuilder{move(anchor)} { } - friend PortBuilderRoot NodeBuilder::preparePort(); + friend PortBuilderRoot NodeBuilder::preparePort(); }; /** diff --git a/tests/core/steam/engine/node-link-test.cpp b/tests/core/steam/engine/node-link-test.cpp index aade1ca89..58f0d14b8 100644 --- a/tests/core/steam/engine/node-link-test.cpp +++ b/tests/core/steam/engine/node-link-test.cpp @@ -51,19 +51,20 @@ namespace test { { seedRand(); + build_simple_node(); build_connected_nodes(); - generate_turnout_system(); trigger_node_port_invocation(); } - /** @test TODO Build render nodes linked into a connectivity network - * @todo WIP 7/24 🔁 define ⟶ ✔ implement + /** @test Build Node Port for simple function + * and verify observable properties of a Render Node + * @todo 7/24 ✔ define ⟶ ✔ implement */ void - build_connected_nodes() + build_simple_node() { // use some dummy specs and a dummy operation.... StrView nodeID{ont::DUMMY_NODE_ID}; @@ -115,13 +116,37 @@ namespace test { } - /** @test TODO Use existing node connectivity to generate a TurnoutSystem - * @todo WIP 12/24 🔁 define ⟶ implement + /** @test TODO Build more elaborate Render Nodes linked into a connectivity network + * @todo WIP 1/25 🔁 define ⟶ implement */ void - generate_turnout_system() + build_connected_nodes() { - UNIMPLEMENTED ("use existing node connectivity to generate a TurnoutSystem"); + auto srcOp = [](int param, int* res){ *res = param; }; + + // A Node with two (source) ports + ProcNode n1{prepareNode("n1") + .preparePort() + .invoke("a(int)", srcOp) + .setParam(5) + .completePort() + .preparePort() + .invoke("b(int)", srcOp) + .setParam(23) + .completePort() + .build()}; + + auto add1Op = [](int* src, int* res){ *res = 1 + *src; }; + ProcNode n2{prepareNode("n2") + .preparePort() + .invoke("+1(int)(int)", add1Op) + .connectLead(n1) + .completePort() + .preparePort() + .invoke("+1(int)(int)", add1Op) + .connectLead(n1) + .completePort() + .build()}; } diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 18a6bf0eb..be2d03b53 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -88492,8 +88492,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + @@ -89363,8 +89363,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - + + @@ -91395,7 +91395,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -99292,8 +99292,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + @@ -99337,8 +99337,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) Ich lasse diese Dummy-Operation dennoch bestehen, vor allem, weil auch dazu passende Specs gegeben sind

- - + @@ -99511,8 +99510,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - - + + + @@ -99654,11 +99654,74 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + + + + + + + + + + + + + + + + + + + + +

+ NodeBuilder<POL,DAT> +

+

+ in der friend-Deklaration, sowie im Argument des intendierten Konstruktors (wenigstens bin ich konsequent...) +

+ + + + + + + + +

+ ...denn die einzelnen Klauseln werden nur instantiiert wenn angesprochen. In einem bisher nie aktivierten Codepfad können ganz banale Fehler lange überdauern ... +

+ + + + + + + + +

+ der Test muß zumindest soweit gehen, +

+

+ alle Aspekte der Builder-Syntax auszuleuchten +

+ + + + + + + + + + + + + @@ -101873,40 +101936,66 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + - - - + + + - - + - - - - - - + + + - + - - - + + + + + + + + + + + + + + + + + + + - - + + + + + + + + + + + + + + + + - + @@ -101948,6 +102037,55 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + + + + + + + + + + + + + + + + +

+ ...weiterhin bleibt es dabei, daß der Zugang zum Buffer-Management über das Turnout-System (früher StateAdapter) läuft; aber dafür ist kein klassisches OO-Interface notwendig, sofern das Buffer-Handling seinerseits auf einem Interface aufbaut. Die Aufgabe, an der sich das entscheidet ist, wie der konkrete Turnout eine konkrete FeedManifold bauen kann (und ob er das überhaupt tut) +

+ + + + + + + +

+ ...das war mir lange Zeit nicht klar; tatsächlich ist das verborgen in der Richtung der Abstraktion, die auf einen top-down-Zugang hindeutet — ein Solcher ist aber nur zielführend, wenn man im Prinzip über ein Gesamtbild der Domäne verfügt. Das ist allerdings die ganz normale, professionelle Dreistigkeit des Entwicklers, getreu dem Motto „let's do the first step, and then we'll figure out the rest“. +

+

+ +

+

+ Im Rückblick ist das, was mir dann passiert ist, also folgerichtig, und ich habe mich richtig verhalten, indem ich den Ansatz „hängen ließ“.... +

+ + + + + + + + + + @@ -102083,53 +102221,58 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + - + - + - - - - - - - - - - - - - - - - - - - -

- ...weiterhin bleibt es dabei, daß der Zugang zum Buffer-Management über das Turnout-System (früher StateAdapter) läuft; aber dafür ist kein klassisches OO-Interface notwendig, sofern das Buffer-Handling seinerseits auf einem Interface aufbaut. Die Aufgabe, an der sich das entscheidet ist, wie der konkrete Turnout eine konkrete FeedManifold bauen kann (und ob er das überhaupt tut) -

- - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -102167,7 +102310,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - +