From 544075d1431380b0f7e72e86c33383d22dd411de Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 6 Dec 2024 23:43:18 +0100 Subject: [PATCH] Invocation: rearrange the Render Node development tests This is an attempt to take aim at the next step, which is to fill in the missing part for an actual node invocation... ''...still fighting to get ahead, due to complexity of involced concerns...'' --- src/steam/engine/render-invocation.hpp | 2 +- src/steam/engine/weaving-pattern-builder.hpp | 2 +- tests/46node.tests | 16 +- ...node-basic-test.cpp => node-base-test.cpp} | 13 +- tests/core/steam/engine/node-builder-test.cpp | 2 +- tests/core/steam/engine/node-devel-test.cpp | 2 +- ...node-input-test.cpp => node-feed-test.cpp} | 12 +- ...de-linkage-test.cpp => node-link-test.cpp} | 12 +- tests/core/steam/engine/node-meta-test.cpp | 50 ++++ ...operation-test.cpp => node-opera-test.cpp} | 12 +- ...factory-test.cpp => node-storage-test.cpp} | 10 +- .../core/steam/engine/test-rand-ontology.hpp | 2 +- wiki/thinkPad.ichthyo.mm | 281 ++++++++++-------- 13 files changed, 253 insertions(+), 163 deletions(-) rename tests/core/steam/engine/{node-basic-test.cpp => node-base-test.cpp} (90%) rename tests/core/steam/engine/{node-input-test.cpp => node-feed-test.cpp} (74%) rename tests/core/steam/engine/{node-linkage-test.cpp => node-link-test.cpp} (93%) create mode 100644 tests/core/steam/engine/node-meta-test.cpp rename tests/core/steam/engine/{node-operation-test.cpp => node-opera-test.cpp} (75%) rename tests/core/steam/engine/{node-factory-test.cpp => node-storage-test.cpp} (81%) diff --git a/src/steam/engine/render-invocation.hpp b/src/steam/engine/render-invocation.hpp index cda2793a4..d70fbf82a 100644 --- a/src/steam/engine/render-invocation.hpp +++ b/src/steam/engine/render-invocation.hpp @@ -20,7 +20,7 @@ ** ** @see engine::ProcNode ** @see turnout-system.hpp - ** @see NodeBasic_test + ** @see NodeBase_test ** */ diff --git a/src/steam/engine/weaving-pattern-builder.hpp b/src/steam/engine/weaving-pattern-builder.hpp index 195dc3d1f..bc8a916a8 100644 --- a/src/steam/engine/weaving-pattern-builder.hpp +++ b/src/steam/engine/weaving-pattern-builder.hpp @@ -80,7 +80,7 @@ ** ** @see turnout.hpp ** @see node-builder.hpp - ** @see NodeLinkage_test + ** @see NodeLink_test ** ** @todo WIP-WIP-WIP as of 10/2024 prototyping how to build and invoke render nodes /////////////////////////TICKET #1371 ** diff --git a/tests/46node.tests b/tests/46node.tests index adb2f6c99..79e7ea7ca 100644 --- a/tests/46node.tests +++ b/tests/46node.tests @@ -2,7 +2,7 @@ TESTING "Component Test Suite: Render Engine parts" ./test-suite --group=node -PLANNED "Proc Node basics" NodeBasic_test < @@ -11,14 +11,15 @@ * *****************************************************************/ -/** @file node-basic-test.cpp - ** unit test \ref NodeBasic_test +/** @file node-base-test.cpp + ** Unit test \ref NodeBase_test covers elementary components of render nodes. */ #include "lib/test/run.hpp" -#include "steam/engine/node-factory.hpp" +#include "steam/engine/proc-node.hpp" //#include "steam/engine/nodewiring-obsolete.hpp" /////////////////////////////////////////////////////TICKET #1367 : sort out dependencies for reworked Node Invocation +#include "steam/engine/turnout.hpp" #include "steam/engine/turnout-system.hpp" #include "steam/engine/channel-descriptor.hpp" #include "steam/mobject/session/effect.hpp" @@ -66,7 +67,7 @@ namespace test { /***************************************************************//** * @test basic render node properties and behaviour. */ - class NodeBasic_test : public Test + class NodeBase_test : public Test { virtual void run(Arg) { @@ -98,7 +99,7 @@ namespace test { /** Register this test class... */ - LAUNCHER (NodeBasic_test, "unit node"); + LAUNCHER (NodeBase_test, "unit node"); diff --git a/tests/core/steam/engine/node-builder-test.cpp b/tests/core/steam/engine/node-builder-test.cpp index abe923131..f9e56967a 100644 --- a/tests/core/steam/engine/node-builder-test.cpp +++ b/tests/core/steam/engine/node-builder-test.cpp @@ -12,7 +12,7 @@ * *****************************************************************/ /** @file node-builder-test.cpp - ** unit test \ref NodeBuilder_test + ** Unit test \ref NodeBuilder_test demonstrates how to build render nodes. */ diff --git a/tests/core/steam/engine/node-devel-test.cpp b/tests/core/steam/engine/node-devel-test.cpp index 9794587f7..565c94bf5 100644 --- a/tests/core/steam/engine/node-devel-test.cpp +++ b/tests/core/steam/engine/node-devel-test.cpp @@ -12,7 +12,7 @@ * *****************************************************************/ /** @file node-devel-test.cpp - ** unit test \ref NodeDevel_test + ** Unit test \ref NodeDevel_test verifies helpers for testing of render nodes. */ diff --git a/tests/core/steam/engine/node-input-test.cpp b/tests/core/steam/engine/node-feed-test.cpp similarity index 74% rename from tests/core/steam/engine/node-input-test.cpp rename to tests/core/steam/engine/node-feed-test.cpp index 32e71b3c8..0ed6c19da 100644 --- a/tests/core/steam/engine/node-input-test.cpp +++ b/tests/core/steam/engine/node-feed-test.cpp @@ -1,8 +1,8 @@ /* - NodeInput(Test) - unit test of the source reading render node + NodeFeed(Test) - verify render node data feeds Copyright (C) - 2008, Hermann Vosseler + 2025, Hermann Vosseler   **Lumiera** is free software; you can redistribute it and/or modify it   under the terms of the GNU General Public License as published by the @@ -11,8 +11,8 @@ * *****************************************************************/ -/** @file node-input-test.cpp - ** unit test \ref NodeInput_test +/** @file node-feed-test.cpp + ** Feeding into and retrieving data from render nodes is covered by \ref NodeFeed_test. */ @@ -33,7 +33,7 @@ namespace test { /***************************************************************//** * @test the source reading render node. */ - class NodeInput_test : public Test + class NodeFeed_test : public Test { virtual void run(Arg) { @@ -43,7 +43,7 @@ namespace test { /** Register this test class... */ - LAUNCHER (NodeInput_test, "unit node"); + LAUNCHER (NodeFeed_test, "unit node"); diff --git a/tests/core/steam/engine/node-linkage-test.cpp b/tests/core/steam/engine/node-link-test.cpp similarity index 93% rename from tests/core/steam/engine/node-linkage-test.cpp rename to tests/core/steam/engine/node-link-test.cpp index 22435cb56..86edfbc00 100644 --- a/tests/core/steam/engine/node-linkage-test.cpp +++ b/tests/core/steam/engine/node-link-test.cpp @@ -1,8 +1,8 @@ /* - NodeLinkage(Test) - verify proper render node operation and calldown + NodeLink(Test) - render node connectivity and collaboration Copyright (C) - 2009, Hermann Vosseler + 2024, Hermann Vosseler   **Lumiera** is free software; you can redistribute it and/or modify it   under the terms of the GNU General Public License as published by the @@ -11,8 +11,8 @@ * *****************************************************************/ -/** @file node-linkage-test.cpp - ** unit test \ref NodeLinkage_test +/** @file node-link-test.cpp + ** The \ref NodeLink_test covers the essence of connected render nodes. */ @@ -44,7 +44,7 @@ namespace test { * - starting from any Port, a TurnoutSystem can be established * - which in turn allows _turn out_ a render result from this port. */ - class NodeLinkage_test : public Test + class NodeLink_test : public Test { virtual void run (Arg) @@ -133,7 +133,7 @@ SHOW_EXPR(metaN1.genNodeSpec(con.leads)) /** Register this test class... */ - LAUNCHER (NodeLinkage_test, "unit node"); + LAUNCHER (NodeLink_test, "unit node"); diff --git a/tests/core/steam/engine/node-meta-test.cpp b/tests/core/steam/engine/node-meta-test.cpp new file mode 100644 index 000000000..53849ad86 --- /dev/null +++ b/tests/core/steam/engine/node-meta-test.cpp @@ -0,0 +1,50 @@ +/* + NodeMeta(Test) - verify render node data feeds + + Copyright (C) + 2024, Hermann Vosseler + +  **Lumiera** is free software; you can redistribute it and/or modify it +  under the terms of the GNU General Public License as published by the +  Free Software Foundation; either version 2 of the License, or (at your +  option) any later version. See the file COPYING for further details. + +* *****************************************************************/ + +/** @file node-meta-test.cpp + ** Naming and hash-key identification of render nodes is covered by \ref NodeMeta_test. + */ + + +#include "lib/test/run.hpp" +//#include "lib/util.hpp" + + +//using std::string; + + +namespace steam { +namespace engine{ +namespace test { + + + + + /***************************************************************//** + * @test Render node metadata and hash identity keys. + */ + class NodeMeta_test : public Test + { + virtual void run(Arg) + { + UNIMPLEMENTED ("render node pulling source data from vault"); + } + }; + + + /** Register this test class... */ + LAUNCHER (NodeMeta_test, "unit node"); + + + +}}} // namespace steam::engine::test diff --git a/tests/core/steam/engine/node-operation-test.cpp b/tests/core/steam/engine/node-opera-test.cpp similarity index 75% rename from tests/core/steam/engine/node-operation-test.cpp rename to tests/core/steam/engine/node-opera-test.cpp index 4edccd876..8f0a5da50 100644 --- a/tests/core/steam/engine/node-operation-test.cpp +++ b/tests/core/steam/engine/node-opera-test.cpp @@ -1,8 +1,8 @@ /* - NodeOperation(Test) - verify proper render node operation and calldown + NodeOpera(Test) - verify proper render node operation modes Copyright (C) - 2009, Hermann Vosseler + 2024, Hermann Vosseler   **Lumiera** is free software; you can redistribute it and/or modify it   under the terms of the GNU General Public License as published by the @@ -11,8 +11,8 @@ * *****************************************************************/ -/** @file node-operation-test.cpp - ** unit test \ref NodeOperation_test +/** @file node-opera-test.cpp + ** Let the nodes sing with \ref NodeOpera_test. */ @@ -33,7 +33,7 @@ namespace test { /***************************************************************//** * @test check render node operation modes and collaboration. */ - class NodeOperation_test : public Test + class NodeOpera_test : public Test { virtual void run(Arg) { @@ -43,7 +43,7 @@ namespace test { /** Register this test class... */ - LAUNCHER (NodeOperation_test, "unit node"); + LAUNCHER (NodeOpera_test, "unit node"); diff --git a/tests/core/steam/engine/node-factory-test.cpp b/tests/core/steam/engine/node-storage-test.cpp similarity index 81% rename from tests/core/steam/engine/node-factory-test.cpp rename to tests/core/steam/engine/node-storage-test.cpp index a74984b9f..0660c668e 100644 --- a/tests/core/steam/engine/node-factory-test.cpp +++ b/tests/core/steam/engine/node-storage-test.cpp @@ -1,5 +1,5 @@ /* - NodeFactory(Test) - building render nodes + NodeStorage(Test) - verify storage setup for render nodes in the engine Copyright (C) 2009, Hermann Vosseler @@ -11,8 +11,8 @@ * *****************************************************************/ -/** @file node-factory-test.cpp - ** unit test \ref NodeFactory_test +/** @file node-storage-test.cpp + ** Actual storage setup for render nodes is demonstrated by \ref NodeStorage_test. ** @todo 12/2024 this test will focus on the high-level integration, ** which is future work and possibly addressed in the next »Vertical Slice« ** when we add processing of a given media clip from disk. @@ -36,7 +36,7 @@ namespace test { /***************************************************************//** * @test creating and wiring various kinds of render nodes. */ - class NodeFactory_test : public Test + class NodeStorage_test : public Test { virtual void run (Arg) @@ -47,7 +47,7 @@ namespace test { /** Register this test class... */ - LAUNCHER (NodeFactory_test, "unit node"); + LAUNCHER (NodeStorage_test, "unit node"); diff --git a/tests/core/steam/engine/test-rand-ontology.hpp b/tests/core/steam/engine/test-rand-ontology.hpp index 1993d0935..7ff9a047f 100644 --- a/tests/core/steam/engine/test-rand-ontology.hpp +++ b/tests/core/steam/engine/test-rand-ontology.hpp @@ -79,7 +79,7 @@ namespace test { * * @see TestFrame_test * @see NodeDevel_test - * @see NodeLinkage_test + * @see NodeLink_test * */ class TestRandOntology diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 5f7fae6c5..9f28952b0 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -20662,9 +20662,7 @@ - - - +

verwende eine Beziehungs-Entität @@ -21019,9 +21017,7 @@ - - - +

wir könnten zwar Widgets aufbauen, diese aber dann später nicht umordnen oder zerstören @@ -21529,9 +21525,7 @@ - - - +

2/2023 @@ -22250,9 +22244,7 @@ - - - +

Problem: Slave-Timeline @@ -23116,9 +23108,7 @@ - - - +

hey, es ist mein Leben @@ -25034,9 +25024,7 @@ - - - +

  • @@ -28736,9 +28724,7 @@ - - - +

    anstatt (konventionell) den Time-Ruler separat explizit auszuprogrammieren, @@ -34404,9 +34390,7 @@ - - - +

    Nebenbei bemerkt: die Aktion muß idempotent sein @@ -38287,9 +38271,7 @@ - - - +

    Das bekommt dieser Controller dann nicht mit, und die Geste wird insofern auch nicht getriggert. Da hat der User eben Pech gehabt. @@ -39980,9 +39962,7 @@ - - - +

    • @@ -40810,9 +40790,7 @@ - - - +

      sofern wir den Speicher haben... @@ -41214,9 +41192,7 @@ - - - +

      empirsche Kontrolle @@ -41837,9 +41813,7 @@ - - - +

      ...und das betrachte ich als gutmütig und hinreichend abgesichert... @@ -42011,9 +41985,7 @@ - - - +

      Problem: detox() macht den zu Null @@ -87438,8 +87410,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      - + @@ -87587,8 +87559,25 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
       - + + + + + + + + + + + + + + + + + + @@ -87714,10 +87703,32 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
             - + + + + + + + + + + + + - + + + + + +

      + Dieser Test ist der Schlüssel zum Aufbau des Render-Node-Network — sowohl für mich selber in der Entwicklung, alsauch später zur Dokumentation. Der Aufbau sollte sorgfältig vorgehen und sich auf das Wesentliche beschränken +

      + +       + +       @@ -88157,8 +88168,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      ...das ein bestimmtes Schema für Funktionsaufrufe und Buffer-Arrays fest vorgibt; damit kann dann auch die FeedManifold Teil des InvocationAdapters werden und beide zusammen liegen beim Aufruf im Stack-Frame

      - - +       @@ -88562,8 +88572,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      welcher hiermit nur noch über eine virtuelle Methode weave() zur Laufzeit eingebunden ist

      - - +       @@ -88599,8 +88608,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      ...wäre demnach ehr eine Hintertür im Design

      - - + @@ -93897,12 +93905,28 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
       - + + + + + + +

      + Hab mich in den letzten Tagen wieder in einem Knoten festgefahren — der nun zum Glück wenigstens in meinem Kopf schon gelöst ist....  Trotzdem ist die Situation sehr schwierig, da ich mehrere »intuitiv geklärte« Sachverhalte gleichzeitig aufbauen muß, und nicht recht weiß, wo beginnen.... +

      + + +       + + + + +       @@ -93931,6 +93955,15 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      + + + + + + + + + @@ -93954,8 +93987,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      - + @@ -94084,15 +94117,12 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

      Also explizit für Kern-Funktionalität; das wäre ein naheliegender Lösungsansatz, der sich gewissermaßen unter der Struktur der Feed-Manifold »durchgräbt«. Hierzu würde man spezielle Buffer vereinbaren, in denen ein Adapter-Typ liegt, der dann irgendwie mit den Parametern versorgt wird.

      -

      - -

      +

      Besonders fragwürdig ist die hohe Komplexität, und auch die Indirektion, die über mehrere Level des Builders hinweg durchgereicht werden muß

      - - +       @@ -94106,8 +94136,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      effizient, denn Buffer-Speicher wird gepoolt und damit gute Chancen auf Cache-Locality

      - - +       @@ -94117,8 +94146,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      die bisher bedachten Strukturen sind auf die Datenströme ausgerichtet — es wäre ungeschickt, hier explizit etwas zur Parameterversortung einzurichten; vielmehr kann der Apekt der Berechnungs-Verknüpfung hier mit abgebildet werden, aber die eigentliche Ansteuerung muß von der Invocation ausgehen, und kann daher nur durch das Turnout-System laufen, welches hierdurch seinen bisher nur abstrakt gefaßten Sinn bekommt.

      - -       +       @@ -94143,8 +94171,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      da drücke ich mich schon seit Jahren drum

      - -       + @@ -94163,8 +94190,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      »geliefert« ist das Wort das diese Debatte klärt

      - - + @@ -94172,8 +94198,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Hier im Rahmen der Render-Engine wird nach einem einheitlichen Webemuster vorgegangen: die Berechnung erfolgt lazy und schreitet in Wellen von der Quelle in Richtung des Resultats fort. Und, ganz wichtig, die Berechnungen sind hochgradig concurrent. Deshalb muß jedweder intemediäre Berechnungszustand externalisiert werden — wir brauchen Storage, die in Buffern organisiert ist und jweils für eine Node-Invocation bereitgestellt wird. Daher muß ein Berechnungsergebnis stets irgendwo abgestellt werden — und das heißt, es fällt als Wert an.

      - -       +       @@ -94196,8 +94221,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      als Funktion der nominal Time

      - - +       @@ -94229,8 +94253,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Es ist eine ungeklärte Frage, ob Abkürzungen in der Render-Engine sinnvoll sind. Diese Frage kann nur empirisch geklärt werden, und vermutlich niemals abschließend. Erfahrung im high-Performance-Computing zeigt, daß Schematisierung oft der Einzelfallbehandlung überlegen ist — es sei denn, der Einzelfalls stellt selbst ein Schema dar

      - - +       @@ -94249,8 +94272,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Automation ist eine Domain-Ontology

      - - + @@ -94264,8 +94286,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      nenne sie »Special Agent«

      - - +       @@ -94278,8 +94299,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      DataAgent: Übergabe von Daten aus einem anderen Job

      - - +       @@ -94289,8 +94309,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      ParamAgent: Einspielen von Steuerparametern

      - -       +       @@ -94378,8 +94397,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Fahrweg — Weichenstraße — konkrete Spurführung

      - -       +       @@ -94395,8 +94413,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Seitens der Nodes ist mir das wohl ganz gut gelungen, aber es besteht die Gefahr, sich letztlich doch noch irgendwo auf ein Über-System festzulegen; daher sollte auch auf der Seite der Kontrolle und Steuerung ein Erweiterungspunkt vorgesehen werden

      - -       +       @@ -94412,8 +94429,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Das ist hochgradig relevant, weil auf diesem Weg jetzt etwas gebaut werden kann, ohne die Gefahr von Architektur-Fehlern

      - - +       @@ -94440,8 +94456,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      die würde sich der SpecialAgent dann vom generischen TurnoutSystem holen um dann in einem speziellen Service einen hinterlegten Kontext aufzugreifen

      - - +       @@ -94455,8 +94470,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      das widerspricht jedoch dem Erkenntnisbild von Fahrweg ⟶ Weichenstraße ⟶ Spurführung

      - - +       @@ -94489,8 +94503,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Festlegung: genau ein virtual call pro Node

      - - +       @@ -94528,8 +94541,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    - -     + @@ -94542,8 +94554,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    VTable-Träger ist der »opaque Gegenstand«

    - - +     @@ -94595,8 +94606,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    und zwar muß noch festgelegt werden, auf welche Art Parameter zugegriffen wird, und wo; das könnte allerdings Teil eines Parameter-Berechnungsfunktors sein, der dann ein TurnoutSystem& als Argument nimmt — damit wäre die Prekonfiguration auf einem vergleichbaren Level wie für die Medienberechnungs-Nodes

    - - +     @@ -94606,8 +94616,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    Unabhängig davon ob lediglich ein Basis-Parameter zugegriffen wird, oder ob ein vorher explizit berechneter Parameterwerd von einer ParamAgent-Node abgeholt wird: es ist eine Indirektion notwendig, um die die Konkrete Daten_Adresse zu bekommen, denn diese ist i.d.R. erst zum Zeitpunkt der Invocation feststellbar

    - -     +     @@ -94631,8 +94640,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    Paramter werden in ParamAgent-Nodes berechnet, welche über den normalen Builder eingehängt werden — und zwar nur bei Bedarf. Sofern also spezielle Parameter-Berechnung notwendig ist, wird dies in der Belegung und Verschaltung der Nodes prekonfiguriert, so daß die eigentliche Invocation davon nichts wissen muß.

    - - +     @@ -94642,8 +94650,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    Obzwar weitgehende Flexibilität besteht, soll im Regelfall die weitergehende Parameter-Berechnung in einer speziellen Parameter-Aufbereitungs-Node gebündelt werden; diese ist als erster Lead unter der Exit-Node eingehängt und wird somit als erste aktiviert. Die Berechnungsfunktion in dieser Node bekommt eine Referenz auf das TurnoutSystem, und kann somit dort per Seiteneffekt zusätzliche Daten-Module registrieren. Als Storage für die zusätzlichen Datenmodule dient der Ausgabepuffer dieser Aufbereitungs-Node, welcher — gemäß allgemeinem Auswertungsschema — garantiert bis zum Ende der Render-Invocation im Speicher bestehen bleibt.

    - -     +     @@ -94653,8 +94660,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    Das Turnout-System erlaubt es, einzelne Datenmodule zu registrieren und später über diese Registrierung auch wieder (mit integriertem Cast) abzugreifen. In der Grundausstattung bietet das Turnout-System nur Zugriff auf die Invocation-Koordinaten (vor allem: die absolute nominal Time). In die ParamAgentNodes (welche letztlich einen konkreten Parameter für eine nachfolgend aufgeschaltete Berechnungs-Node bereitstellen) wird ein konkret abgeschlossenes Zugriffs-λ gebunden, welches das TurnoutSystem als Referenz bekommt, und dann aber eine Template-Funktion für den konkreten Datenzugriff aufruft. An dieser Stelle finden keine Verifikationen mehr statt, aber das Turnout-System speichert die Indirektion auf den konkreten Datenpuffer

    - -     +     @@ -94674,6 +94680,18 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    + + + + + + + + + + + + @@ -94769,7 +94787,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    0000000515: INFO: testframe.cpp:168: thread_1: getFrame: Growing channel #0 of test frames 0 -> 1 elements.

    - 0000000516: CHECK: buffer-provider-protocol-test.cpp:107: thread_1: verifySimpleUsage: (testData(0) == checker.accessMemory (0)) + 0000000516: CHECK: buffer-provider-protocol-test.cpp:107: thread_1: verifySimpleUsage: (testData(0) == checker.accessMemory (0))

    @@ -95001,8 +95019,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    ...weil man es nicht erwarten kann, daß irgend ein Library-Plugin hier eine sinnvolle Systematik einführt

    - - +     @@ -95018,8 +95035,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     nicht einfach ad hoc verdrahten

    - - +     @@ -95724,7 +95740,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    - + @@ -95844,18 +95860,37 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     - + - - + - - - - - + - + + + + +

    + Nodes werden hier noch direkt erzeugt und verwenden die automatische Heap-Allokation; denn es geht um die Zusammenarbeit der Funktionalität in den Render-Nodes. +

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

    + Framework und Services aus dem produktiven Setup verwenden, möglichst auch den realen Memory-Buffer-Provider. Damit stellt sich die Frage, wie hier überhaupt verifiziert werden kann; vermutlich werde ich Instrumentierungs-Hilfsmittel einführen und dafür auch Zugangspunkte in die produktiven Services einführen müssen — ähnlich wie ich es erfolgreich für den Block-Flow-Allokator im Scheduler getan habe +

    + + +     +     @@ -95878,8 +95913,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    - +