diff --git a/src/steam/engine/proc-id.hpp b/src/steam/engine/proc-id.hpp new file mode 100644 index 000000000..eca1a5800 --- /dev/null +++ b/src/steam/engine/proc-id.hpp @@ -0,0 +1,62 @@ +/* + PROC-ID.hpp - symbolic and hash identification of processing steps + + Copyright (C) Lumiera.org + 2024, Hermann Vosseler + + This program 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. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +*/ + +/** @file proc-id.hpp + ** Metadata interface to generate symbolic and hash ID tags for media processing steps. + ** Functionality is provided to identify a point in the processing chain for sake of + ** error reporting and unit testing; moreover, identifying information can be chained + ** and combined into a systematic hash key, to serve as foundation for a stable cache key. + ** @todo WIP-WIP as of 10/2024 this is a draft created as an aside while working towards + ** the first integration of render engine functionality //////////////////////////////////////////////TICKET #1377 : establish a systematic processing identification + ** @remark the essential requirement for a systematic and stable cache key is + ** - to be be re-generated directly from the render node network + ** - to be differing if and only if the underlying processing structure changes + ** + ** @see turnout.hpp + ** @see engine::ProcNodeDiagnostic + */ + +#ifndef ENGINE_PROC_ID_H +#define ENGINE_PROC_ID_H + + +#include "lib/error.hpp" +#include "lib/hash-value.h" +//#include "steam/streamtype.hpp" + + +namespace steam { +namespace engine { + namespace err = lumiera::error; + + using lib::HashVal; + + class ProcID + { + public: + /** build and register a processing ID descriptor */ + static ProcID& describe(); + }; + + +}} // namespace steam::engine +#endif /*ENGINE_PROC_ID_H*/ diff --git a/src/steam/engine/proc-node.cpp b/src/steam/engine/proc-node.cpp index 1ef6470be..6e499bd1b 100644 --- a/src/steam/engine/proc-node.cpp +++ b/src/steam/engine/proc-node.cpp @@ -28,6 +28,7 @@ */ +#include "steam/engine/proc-id.hpp" #include "steam/engine/proc-node.hpp" namespace steam { @@ -45,7 +46,37 @@ namespace engine { Port::~Port() { } ///< @remark VTables for the Port-Turnout hierarchy emitted from \ref proc-node.cpp + ProcID& + ProcID::describe() + { + UNIMPLEMENTED ("establish and possibly enrol new processing descriptor"); + } + /** @internal */ + string + ProcNodeDiagnostic::getNodeSpec() + { + UNIMPLEMENTED ("generate a descriptive Spec of this ProcNode for diagnostics"); + } + + HashVal + ProcNodeDiagnostic::getNodeHash() ///< @todo not clear yet if this has to include predecessor info + { + UNIMPLEMENTED ("calculate an unique hash-key to designate this node"); + } + + string + ProcNodeDiagnostic::getPortSpec (uint portIdx) + { + UNIMPLEMENTED ("generate a descriptive diagnostic Spec for the designated Turnout"); + } + + HashVal + ProcNodeDiagnostic::getPortHash (uint portIdx) + { + UNIMPLEMENTED ("calculate an unique, stable and reproducible hash-key to identify the Turnout"); + } + }} // namespace steam::engine diff --git a/src/steam/engine/proc-node.hpp b/src/steam/engine/proc-node.hpp index 760686447..b8ddf486f 100644 --- a/src/steam/engine/proc-node.hpp +++ b/src/steam/engine/proc-node.hpp @@ -74,6 +74,7 @@ namespace engine { using util::_Fmt; /////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation + class ProcID; class ProcNode; class ProcNodeDiagnostic; @@ -88,12 +89,14 @@ namespace engine { { public: virtual ~Port(); ///< this is an interface + Port (ProcID& id) : procID{id} { } virtual BuffHandle weave (TurnoutSystem&, OptionalBuff =std::nullopt) =0; // // compiler does not generate a move-ctor automatically due to explicit dtor // Port() = default; // Port(Port&&) = default; + ProcID& procID; }; using PortRef = std::reference_wrapper; @@ -243,29 +246,11 @@ namespace engine { ///////////////////////////////////////////////////TODO 10/2024 more to verify here } - string - getNodeSpec() - { - UNIMPLEMENTED ("generate a descriptive Spec of this ProcNode for diagnostics"); - } + string getNodeSpec(); ///< generate a descriptive Spec of this ProcNode for diagnostics + HashVal getNodeHash(); ///< calculate an unique hash-key to designate this node - HashVal - getNodeHash() ///< @todo not clear yet if this has to include predecessor info - { - UNIMPLEMENTED ("calculate an unique hash-key to designate this node"); - } - - string - getPortSpec (uint portIdx) - { - UNIMPLEMENTED ("generate a descriptive diagnostic Spec for the designated Turnout"); - } - - HashVal - getPortHash (uint portIdx) - { - UNIMPLEMENTED ("calculate an unique, stable and reproducible hash-key to identify the Turnout"); - } + string getPortSpec (uint portIdx); ///< generate a descriptive diagnostic Spec for the designated Turnout + HashVal getPortHash (uint portIdx); ///< calculate an unique, stable and reproducible hash-key to identify the Turnout }; inline ProcNodeDiagnostic diff --git a/src/steam/engine/turnout.hpp b/src/steam/engine/turnout.hpp index 5da4aa619..5d322b796 100644 --- a/src/steam/engine/turnout.hpp +++ b/src/steam/engine/turnout.hpp @@ -383,9 +383,13 @@ namespace engine { // , util::MoveOnly { using Feed = typename PAT::Feed; - using PAT::PAT; public: + template + Turnout (ProcID& id, INIT&& ...init) + : Port{id} + , PAT{forward (init)...} + { } // Turnout(Turnout&& rr) ////////////////////////////////////////////OOO investigation of MoveOnly and problems with the builder logic // : Port(static_cast(rr)) // , PAT(static_cast(rr)) diff --git a/src/steam/engine/weaving-pattern-builder.hpp b/src/steam/engine/weaving-pattern-builder.hpp index 13e2755ec..4f2a0d7c6 100644 --- a/src/steam/engine/weaving-pattern-builder.hpp +++ b/src/steam/engine/weaving-pattern-builder.hpp @@ -105,6 +105,7 @@ //#include "steam/engine/channel-descriptor.hpp" //#include "vault/gear/job.h" #include "lib/several-builder.hpp" +#include "steam/engine/proc-id.hpp" #include "steam/engine/turnout.hpp" #include "steam/engine/engine-ctx.hpp" #include "steam/engine/buffer-provider.hpp" @@ -478,7 +479,8 @@ namespace engine { ] (PortDataBuilder& portData) mutable -> void { - portData.template emplace (move(leads) + portData.template emplace (ProcID::describe() + ,move(leads) ,move(types) ,resultIdx ,move(procFun) diff --git a/tests/core/steam/engine/node-linkage-test.cpp b/tests/core/steam/engine/node-linkage-test.cpp index 42e36f143..085b04921 100644 --- a/tests/core/steam/engine/node-linkage-test.cpp +++ b/tests/core/steam/engine/node-linkage-test.cpp @@ -73,7 +73,7 @@ namespace test { { auto con = prepareNode() .preparePort() - .invoke(TEST_DUMMY, dummyOp) + .invoke(DUMMY_FUN_ID, dummyOp) .completePort() .build(); CHECK (isnil (con.leads)); @@ -84,6 +84,7 @@ namespace test { CHECK (watch(n1).isValid()); CHECK (watch(n1).leads().empty()); CHECK (watch(n1).ports().size() == 1); +SHOW_EXPR(watch(n1).getPortSpec(0)) } diff --git a/tests/core/steam/engine/test-rand-ontology.cpp b/tests/core/steam/engine/test-rand-ontology.cpp index d81c8df9a..ddc59da85 100644 --- a/tests/core/steam/engine/test-rand-ontology.cpp +++ b/tests/core/steam/engine/test-rand-ontology.cpp @@ -42,7 +42,7 @@ namespace test { } // (End) hidden impl details - Literal TEST_DUMMY{"Test-Dummy"}; + Literal DUMMY_FUN_ID{"DummyFun"}; diff --git a/tests/core/steam/engine/test-rand-ontology.hpp b/tests/core/steam/engine/test-rand-ontology.hpp index 554b03ecc..309b17889 100644 --- a/tests/core/steam/engine/test-rand-ontology.hpp +++ b/tests/core/steam/engine/test-rand-ontology.hpp @@ -46,7 +46,7 @@ namespace test { using NoArg = std::array; using SoloArg = std::array; - extern Literal TEST_DUMMY; + extern Literal DUMMY_FUN_ID; /** @todo a placeholder operation to wire a prototypical render node */ diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 9ad442d94..0b8127980 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -13473,9 +13473,7 @@ - - - +

es ist nicht klar, ob die pattern bereits das fragliche View-Element mit einschließen, @@ -14095,9 +14093,7 @@ - - - +

Komma heißt "and then" in der Logikprogrammierung @@ -15741,9 +15737,7 @@ - - - +

Alternative: wrap UI-Coord, @@ -18247,9 +18241,7 @@ - - - +

Ja, und zwar sogar ziemlich einfach und lesbar...  @@ -22463,9 +22455,7 @@ - - - +

...und ich glaube, das ganze Konstrukt wird nicht wesentlich "tiefer" werden @@ -47799,9 +47789,7 @@ - - - +

Primitive @@ -48332,9 +48320,7 @@ - - - +

....denn der liegt (mind) einmal vor, @@ -48636,9 +48622,7 @@ - - - +

rekursiv, @@ -49007,9 +48991,7 @@ - - - +

...was andernfalles komplett vermeidbar wäre, @@ -49302,9 +49284,7 @@ - - - +

  • @@ -78289,8 +78269,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    - + + + + @@ -81701,6 +81684,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    + + + + + @@ -91138,7 +91126,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + + @@ -91578,8 +91567,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    weder müssen wir nach derzeitigem Stand den Node-Datensatz anhand einer ID wiederfinden können, noch müssen wir von einer Node auf ihren Definitions-Kontext zurückschließen. Denn Nodes sind eine reine executiv-Repräsentation; sie werden durch Interpretation semantischer Attributierungen einmal erstellt, dann aber nur noch ausgeführt, und bei jeder Änderung verworfen und neu konstruiert

    - - + @@ -91606,7 +91594,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         - + @@ -91615,6 +91603,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

     +     @@ -91637,8 +91626,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    Nun ist die Frage: will man in einer solchen Situation mehr leisten als »Fehler in Render-Engine«? Denn dann müßte Information über den direkten Invocation-Kontext mit aufgegriffen werden; und um diese Information überhaupt nutzen zu können, bedürfte es dann einer Rückübersetzung in Entitäten und Koordinaten des high-level-Models, um sinnvoll auf die Ursache schließen zu können. Alle mir bekannte Medien-Sofware leistet nicht diesen Grad der Fehlerdiagnose, vielmehr steht in einem solchen Fall der Benutzer allein da, und kann bestenfalls durch schrittweises Herantasten erraten, was das Problem verursacht hat. Insofern könnte man sich auf den Standpunkt stellen, daß Lumiera in dieser Hinsicht keine Probleme zu lösen hat, mit denen man in der Praxis auch anderweitig irgendwie überlebt...

    - -     + @@ -91662,8 +91650,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    ohne Differenzierungen auf der Implementierungs-Ebene durch die Ports

    - - +     @@ -91695,8 +91682,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    hier ist zu markieren, falls der Builder oder die Domain-Ontology konkret einen Entscheidungsspielraum in einem Fall so und in einem anderen Fall so nutzt, also z.B. eine spezielle Parametrisierung des Algorithmus, die vom Default abweicht. Wenn dagegen der Algorithmus selber sich inkompatibel geändert hat, so wird das bereits n der ID des Proc-Asset durch ein Postfix .v# markiert

    - - +     @@ -91711,8 +91697,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    denn in den allermeisten Fällen dürfte es entweder ein Feed sein, oder N gleiche Feeds

    - - +     @@ -91753,8 +91738,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    zwar könnte man bereits im Builder festlegen, daß eine solche Komponente dazukommt; jedoch ist erst zum Zeitpunkt der konkreten Invocation klar, welche dynamischen Parameterwerte sich ergeben und noch in die Medien-Berechnung einfließen

    - - +     @@ -91768,14 +91752,14 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    ...will sagen, diese Funktionen interpretieren dann zwar noch die Connectivity-Information, verwenden aber für alle tatsächlich zu inkorporierenden Texte eine externe Symbol-Tabelle, allein schon zur Deduplikation. Das bedeutet aber im Umkehrschluß: hier haben wir doch einen »Rückwärts-Zugriff« (auch wenn er funktional realisiert werden kann, indem eine Node-ID reproduzierbar aus der Connectivity errechnet wird)

    - - +     - + + @@ -91798,12 +91782,79 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    - + +     + + + + +     + + + + + + + + + +

    + ich bohre jetzt schon mehr als einen Tag an dieser Stelle herum — was mir zeigt, daß ich den Hebel für so bedrohlich halte, daß ich micht nicht überwinden kann, eine „dumme“ Implementierung schnell reinzuklopfen +

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

    + Ich sehe das als einen Laufzeit-Cache, der jederzeit regeneriert werden kann; er wird sich maximal mit den im Model verwendeten Processing-Funktions-Deskriptoren füllen +

    + + +     + +     +     + + + + + + + + + + + + + + + + + +     @@ -91820,8 +91871,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    ....die Vorraussetzungen hierfür sind gut, da der einzige Zugang über eine zentrale Builder-Schnittstelle erfolgt; dennoch wird ein solches Schema komplex, bedingt durch die Verteilung von Logik auf die verschiedenen Media-processing-Library-Plug-ins

    - - +     @@ -92122,8 +92172,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    wenn wir für jede Node wieder eine texturelle ID speichern, oder auch nur mehrere Hash-Komponenten, wäre der Hebel gewaltig — irgendwo muß dedupliziert werden....

    - -     +     @@ -93326,6 +93375,14 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         + + + + + + + +     @@ -133188,6 +133245,26 @@ std::cout << tmpl.render({"what", "World"}) << s + + + + +

    + Frame-Cache (Service) +

    + + +     + + + + + + + + + +     @@ -133198,8 +133275,8 @@ std::cout << tmpl.render({"what", "World"}) << s - +