diff --git a/src/steam/engine/proc-node.hpp b/src/steam/engine/proc-node.hpp index e0cffe2e2..a626d6d32 100644 --- a/src/steam/engine/proc-node.hpp +++ b/src/steam/engine/proc-node.hpp @@ -72,6 +72,8 @@ namespace engine { /////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation class ProcNode; + class ProcNodeDiagnostic; + // typedef ProcNode* PNode; using ProcNodeRef = std::reference_wrapper; using OptionalBuff = std::optional; @@ -116,7 +118,7 @@ namespace engine { Ports ports; Leads leads; - NodeID const& nodeID; + NodeID const& nodeID; /////////////////////////////////OOO seems to belong rather into the ProcNode /////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation @@ -212,10 +214,38 @@ namespace engine { #endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation /////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation + /// „backdoor“ to watch internals from tests + friend class ProcNodeDiagnostic; }; /////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation + class ProcNodeDiagnostic + : util::MoveOnly + { + ProcNode& n_; + + public: + ProcNodeDiagnostic (ProcNode& theNode) + : n_{theNode} + { } + + auto& leads() { return n_.wiring_.leads; } + auto& ports() { return n_.wiring_.ports; } + + bool + isValid() + { + return 0 < ports().size(); + ///////////////////////////////////////////////////TODO 10/2024 more to verify here + } + }; + + inline ProcNodeDiagnostic + watch (ProcNode& theNode) + { + return ProcNodeDiagnostic{theNode}; + } }} // namespace steam::engine diff --git a/tests/core/steam/engine/node-linkage-test.cpp b/tests/core/steam/engine/node-linkage-test.cpp index ed9edc4c0..3d88c8df6 100644 --- a/tests/core/steam/engine/node-linkage-test.cpp +++ b/tests/core/steam/engine/node-linkage-test.cpp @@ -78,6 +78,12 @@ namespace test { .build(); CHECK (isnil (con.leads)); CHECK (1 == con.ports.size()); + + // can build a ProcNode with this connectivity + ProcNode n1{move(con)}; + CHECK (watch(n1).isValid()); + CHECK (watch(n1).leads().empty()); + CHECK (watch(n1).ports().size() == 1); } diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 30cad4cef..37c676b1e 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -13303,9 +13303,7 @@ - - - +

Preprocessing beim Anlegen der Klausel @@ -13861,9 +13859,7 @@ - - - +

...das würde bedeuten, daß man sogar ein neues Hauptfenster erzeugt. @@ -15376,9 +15372,7 @@ - - - +

...denn irgendwann wird's lächerlich mit der Unit-Testerei. @@ -17166,9 +17160,7 @@ - - - +

...bisher erzeugt die lookup-Operation automatisch @@ -19286,9 +19278,7 @@ - - - +

wenn das Stylesheet eben doch zusätzliche Paddings definiert, dann geht die Rechnung nicht auf, da sie auf den required-sizes der Kind-Widgets beruht, und daher (mit Paddings) zu optimistisch ist. Daher müssen wir zwingend nach einem versuchten wieder-Einblenden die reale Ausdehnung des ganzen IDLabel ermitteln und gegen die Constraints prüfen. Bei der Verkleinerung ist das nicht der Fall, denn da wirken die wegfallenden Paddings als zusätzlicher "Bonus". @@ -22633,9 +22623,7 @@ - - - +

Das muß auch so sein, denn sonst wäre das systematische Modell und die Controller zu eng mit dem Display-Code verwoben. Der Nachteil ist aber, daß derart aufgedoppelte Struktur bei jeder Strukturänderung invalide wird @@ -48210,9 +48198,7 @@ - - - +

aber: Aufrufprinzip @@ -48861,9 +48847,7 @@ - - - +

....denn dann müßte der Benutzer die Mechanik sehr genau verstehen, und stets eine auto-Variable definieren. @@ -49327,9 +49311,7 @@ - - - +

Stand 2021: @@ -49487,9 +49469,7 @@ - - - +

  • @@ -49866,9 +49846,7 @@ - - - +

    bei einem echten Downstream könnte man dafür sorgen, @@ -54787,6 +54765,7 @@

    + @@ -56925,6 +56904,431 @@ + + + + + + + + +

    + EventLog : zeitliche Abläufe verifizieren +

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

    + commit bb627fc1f8180009958c72a03696bacf87c65434 +

    +

    + Author: Ichthyostega <prg@ichthyostega.de> +

    +

    + Date:   Thu Nov 26 21:10:38 2015 +0100 +

    +

    + +

    +

    +     draft of the UI-Bus communication structure +

    +

    +     +

    +

    +     what you see here now is just the tip of the icebearg... +

    +

    +     If we follow this route, the Lumiera UI will become way more +

    +

    +     elaborate and responsive than average desktop applications +

    + +     +     + + + + +

    + commit 40b69e1fd2b335b303e60497906d754a8ec599af +

    +

    + Author: Ichthyostega <prg@ichthyostega.de> +

    +

    + Date:   Fri Feb 19 01:13:44 2016 +0100 +

    +

    + +

    +

    +     planning: consider implications of tree-diff application to arbitrary data structures +

    + +     + +     + + + + +

    + commit 2520ee82d13cb78248efb8d798f9ac9b05ca99ed +

    +

    + Author: Ichthyostega <prg@ichthyostega.de> +

    +

    + Date:   Sat Sep 1 17:30:20 2018 +0200 +

    +

    + +

    +

    +     EventLog: investigate failed match in EventLog +

    +

    +     +

    +

    +     seemingly my quick-n-dirty implementation was to naiive. +

    +

    +     We need real backtracking, if we want to support switches +

    +

    +     in the search direction (match("y").after("x").before("z") +

    +

    +     +

    +

    +     Up to now, I have cheated myself around this obvious problem :-/ +

    + +     + +     + + + + +

    + commit db1adb63a71f470970013f6cbbcc6e48bb0fe471 +

    +

    + Author: Ichthyostega <prg@ichthyostega.de> +

    +

    + Date:   Mon Jul 31 21:53:16 2023 +0200 +

    +

    + +

    +

    +     Activity-Lang: draft a diagnostic helper +

    +

    +     +

    +

    +     ...for coverage of the Activity-Language, +

    +

    +     various invocations of unspecific functions must be verified, +

    +

    +     with the additional twist that the implementation avoids indirections +

    +

    +     and is thus hard to rig for tests. +

    +

    +     +

    +

    +     Solution-Idea: provide a λ-mock to log any invocation into the +

    +

    +     Event-Log helper, which was created some years ago to trace GUI communication... +

    + +     + +     + + + + +

    + commit 4df4ff27922c2596ee1b78c84d8dc9d18ebf526f +

    +

    + Author: Ichthyostega <prg@ichthyostega.de> +

    +

    + Date:   Sun Oct 13 03:49:01 2024 +0200 +

    +

    + +

    +

    +     Invocation: consider minimal test setup and verification +

    +

    +     +

    +

    +     Analysis: what kind of verifications are sensible to employ +

    +

    +     to cover building, wiring and invocation of render nodes? +

    +

    +     Notably, a test should cover requirements and observable functionality, +

    +

    +     while avoiding direct hard coupling to implementation internals... +

    +

    +     +

    +

    +     Draft: the most simple node builder invocation conceivable... +

    + +     + +     +     +     + + + + +

    + TestFrame : verifizierbare Dummy-Berechnungen +

    + + +     + + + + + + +

    + belegen daß eine Berechnung stattgefunden hat +

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

    + commit cafe271830c136d613de19e91f6ce8a804c0e4f5 +

    +

    + Author: Ichthyostega <prg@ichthyostega.de> +

    +

    + Date:   Mon Sep 19 01:42:37 2011 +0200 +

    +

    + +

    +

    +     stubbing of basic buffer provider functionality +

    + +     +     + + + + + + + +

    + TestFrame wurde zwar schon 2011 angelegt, soll nun (2024) aber auch die Basis für eine Test-Ontology werden; die Analyse ergab, daß die vorhandene Funktionalität hierfür lediglich maßvoll erweitert werden muß: +

    +
      +
    • + das Datenlayout im Speicher sollte konsistenter sein +
      • +
    • + wir brauchen einen dedizierten Metadaten-Block, der aber optional ist +
      • +
    • + die Zufallsberechnung bleibt inhaltlich komplett gleich, aber wird umgestellt auf std::random +
      • +
    • + zusätzlich wird noch eine Hashberechnung über die konkreten Datenwerte hinzugefügt +
      • +
    + +     + +     + + + + + + + + + + + + + + + + + + + + + + +

    + neue Bedeutung: es ist ein TestFrame mit erkennbarem Metadatenblock (auch wenn ansonsten keine der Prüfsummen mit den Daten zusammenpaßt); es sollte recht unwahrscheinlich sein, daß ein zufälliger Datenblock diesen Test besteht. +

    + +     +     + + + + +

    + Es ist ein TestFrame mit gültigem Metadaten-Block, und die dort gespeicherte Prüfsumme wird durch die Daten bestätigt +

    + +     +     + + + + +

    + entspricht dem bisherigen isSane() — d.h. isValid() aber zusätzlich passen die Daten auf die gespeicherte distinction, und das heißt, die Daten wurden vom Standard-Schema erzeugt und nicht weiter bearbeitet +

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

    + es gibt einen fest eingebauten Seed-Mechanismus, der auf der Kanal- und Sequenz-Nummer beruht +

    + + +     +     + + + + +

    + kann Lifecycle markieren als CREATED, EMITTED, DISCARDED +

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

    + neue Bedeutung: es ist ein TestFrame mit erkennbarem Metadatenblock (auch wenn ansonsten keine der Prüfsummen mit den Daten zusammenpaßt); es sollte recht unwahrscheinlich sein, daß ein zufälliger Datenblock diesen Test besteht. +

    + +     +     + + + + +

    + Es ist ein TestFrame mit gültigem Metadaten-Block, und die dort gespeicherte Prüfsumme wird durch die Daten bestätigt +

    + +     +     + + + + +

    + entspricht dem bisherigen isSane() — d.h. isValid() aber zusätzlich passen die Daten auf die gespeicherte distinction, und das heißt, die Daten wurden vom Standard-Schema erzeugt und nicht weiter bearbeitet +

    + +     +     +     +     +     + + + + +

    + TestFrame_test +

    + +     + + + + + + + + +     @@ -60011,7 +60415,9 @@ - + + + @@ -77930,7 +78336,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     - + + @@ -86954,6 +87361,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    + @@ -87461,7 +87869,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + + @@ -87940,8 +88349,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     - + + @@ -89373,7 +89783,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + + @@ -89996,8 +90407,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - - + + @@ -90156,8 +90567,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - - + + @@ -90411,8 +90822,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    wir definieren eine Quell-Node ohne Vorgänger, aber binden eine Funktion mit einem Input-Slot

    - - +     @@ -90423,8 +90833,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    ...doch dazu ist das ganze Introspection-Schema für die processing-Function (im Moment) viel zu starr

    - - +     @@ -90432,13 +90841,21 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     - + + + + + + + + + @@ -90581,7 +90998,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + + @@ -90635,7 +91053,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + + @@ -90685,14 +91104,49 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

    - Hier droht die typische Falle des white-box-Testing: daß man auf Implementierungsdetails abstellt — was ganz besonders gefährlich wird, wenn die Implementierung erwartbar eine hohe Kohäsivität aufweist. Daher sollte der Hauptfokus darauf gereichtet sein, eine Test-Ontologie  aufzubauen, vermöge deren der erfolgte Berechnungsvorgang präzise ausgeleuchtet werden kann. + Hier droht die typische Falle des white-box-Testing: daß man auf Implementierungsdetails abstellt — was ganz besonders gefährlich wird, wenn die Implementierung erwartbar eine hohe Kohäsivität aufweist. Daher sollte der Hauptfokus darauf gereichtet sein, eine Test-Ontologie aufzubauen, vermöge deren der erfolgte Berechnungsvorgang präzise ausgeleuchtet werden kann.

    + + + + +

    + Verifikationen: Zugang über das Schema watch(X) +

    + +     + + + +

    + Analog zum BlockFlow, wo sich dieses Baumuster hervorragend bewährt hat: +

    +
      +
    • + es gibt ein generisches Zugangs-Prädikat: watch(X) +
      • +
    • + dieses konstruiert ein Diagnostics-Objekt, das entweder vom Target ableitet oder Friend ist +
      • +
    • + auf diesem gibt es einfache Accessoren und Verifikations-Methoden +
      • +
    • + damit kann man die OO-Kapsel für den Test durchdringen +
      • +
    + +     + +     - + + + @@ -90713,7 +91167,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    - + @@ -90746,7 +91200,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     - + @@ -90985,7 +91439,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + + @@ -91000,8 +91455,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + + @@ -91019,18 +91475,25 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - - + + - - + + + + + - - + + + + + + @@ -91043,6 +91506,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    + + + +     @@ -91055,7 +91522,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + + @@ -91084,90 +91552,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     - + - - - - - - - - -

    - TestFrame wurde zwar schon 2011 angelegt, soll nun (2024) aber auch die Basis für eine Test-Ontology werden; die Analyse ergab, daß die vorhandene Funktionalität hierfür lediglich maßvoll erweitert werden muß: -

    -
      -
    • - das Datenlayout im Speicher sollte konsistenter sein -
      • -
    • - wir brauchen einen dedizierten Metadaten-Block, der aber optional ist -
      • -
    • - die Zufallsberechnung bleibt inhaltlich komplett gleich, aber wird umgestellt auf std::random -
      • -
    • - zusätzlich wird noch eine Hashberechnung über die konkreten Datenwerte hinzugefügt -
      • -
    - -     - -     - - - - - - - - - - - - - - - - - - - - - - -

    - neue Bedeutung: es ist ein TestFrame mit erkennbarem Metadatenblock (auch wenn ansonsten keine der Prüfsummen mit den Daten zusammenpaßt); es sollte recht unwahrscheinlich sein, daß ein zufälliger Datenblock diesen Test besteht. -

    - -     -     - - - - -

    - Es ist ein TestFrame mit gültigem Metadaten-Block, und die dort gespeicherte Prüfsumme wird durch die Daten bestätigt -

    - -     -     - - - - -

    - entspricht dem bisherigen isSane() — d.h. isValid() aber zusätzlich passen die Daten auf die gespeicherte distinction, und das heißt, die Daten wurden vom Standard-Schema erzeugt und nicht weiter bearbeitet -

    - -     -     -     -     -     -     -         @@ -91350,8 +91736,52 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    - + + + + + + + + + +

    + im Gegensatz zum Port, in den auch der aktuelle Implementierungszustand einfließt, aber keine Timeline-Koordinaten, nur die Quell-Koordinaten (wenn man einen Clip nur in der Timeline verschiebt, ohne die Berechnungs-Topologie zu ändern, soll der Cache-Key stabil bleiben) +

    + +     + + + + + + +

    + hier darf kein logischer Zirkel entstehen! Man könnte nämlich auf die Idee kommen, das Proc-Asset durch seine Implementierung zu klassifizieren, aber das wollen wir nicht. Vielmehr brauchen wir hier ein semantisches Konzept, wie z.B. »gaussian blur«. Das bedeutet, diese Basis-IDs müssen vom Library Plug-in belegt werden, und sollen langfristig stabil bleiben (solange der in der LIbrary gebotene Implementierungs-Algorithmus kompatibel bleibt und auf Sicht äquivalente Ergebnisse liefert) +

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

    + es sollte eine human-readable-Ausprägung geben +

    + + +     +     + + + +         @@ -91369,8 +91799,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + + @@ -91428,6 +91859,159 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     + + + + + + + +

    + Zwar ist es eine Zusammenführung bereits abgeschlossener Konzepte, Planungen und Teilkomponenten, jedoch mußten diese zunächst in eine undefinierte Umgebung hinein entworfen werden, so daß sich ihre Form erst durch die Zusammenschaltung ausprägen kann. Und — aufgrund der zyklischen Natur des Unterfangens — diese Zusammenschaltung selbst kann nur vorläufig sein; gebaut wird die Demonstration eines Render-Vorganges, auf Basis einer vorläufigen Integration externer Render-Funktionalität; und dabei wird sich zeigen, was glatt aufgeht und was sich sperrt. Bewußt wird der Kern der gesamten Architektur, der Builder/Compiler, für dieses Konstrukt ausgelassen — denn das, was sich sperrt, soll über diesen Dreh- und Angelpunkt nach Außen transformiert und dort entfaltet werden. +

    + +     +     + + + + +

    + Und das ganz bewußt nur auf Basis eines intuitiven Verständnisses der Anforderungen und API-Strukturen einer in C geschriebenen Media-Handling-Library — also explizit ohne direkte Analyse konkreter Libraries wie FFmpeg oder GStreamer. Denn mein Ziel ist, zunächst eine Hohlform zu bekommen, eine Ausprägung der inneren Anforderungen, aus meinem generellen Verständnis des Sachverhalts, sowie der bisher geschaffenen Implementierung der Render-Nodes. Die entstehende Struktur soll sich zunächst gradlinig entwickeln können, und dann erst später, in weiteren Prototyping-Schritten auf konkrete Anforderungen adapteiert werden. +

    + + +     +     + + + + +

    + Inkrementelles Prototyping schafft mir hier einen Mittelweg zwischen deduktivem top-down-Ansatz und einem induktiven bottom-up-Aufbau; ich gehe aus von einigen, intuitiv gewählten Formen in der Mitte des auszuspannenden Raumes und stelle von dort einen ersten Durchgang her. Die Belange der Performance und die Datenstruktur spielen dabei ebenso eine Rolle, wie das Streben nach Klarheit, welches die geschaffene Struktur nachhalltig macht. +

    + + +     + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +     +     + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +     @@ -92372,6 +92956,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     + + + + +

    + Render-Node (ProcNode) +

    + +     + + + + + + + + +     @@ -94964,6 +95566,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         + @@ -132212,7 +132815,42 @@ std::cout << tmpl.render({"what", "World"}) << s - + + + + + + + + + + + + +

    + Alles, was aus Sicht des Benutzers mit sich selbst identisch ist, bekommt die gleiche Namens-ID. Diese setzt sich zusammen aus.... +

    +
      +
    • + der Domain-Ontology (z.B. FFmpeg) +
      • +
    • + der eindeutigen high-Level-Bezeichnung der Operation (z.B. gaussian blur) +
      • +
    • + (optional) eine Epochen-Versionsnummer (da es im Lauf der Zeit passieren kann, daß die Library-Implementierung modifiziert wird, mit sichtbar geändertem Verhalten) +
      • +
    + + +     +     + + +     +     +     +