diff --git a/src/lib/frameid.hpp b/src/lib/frameid.hpp index 8ee33085f..63804a192 100644 --- a/src/lib/frameid.hpp +++ b/src/lib/frameid.hpp @@ -30,6 +30,9 @@ ** tweak of the edit. This marker was added as a preview in 2010 ** but we didn't get to the point of actually putting that idea ** into practical use. Yet the basic idea remains desirable... + ** @deprecated 10/2024 seems very likely that similar functionality moves down + ** into the render-engine implementation and will no longer be considered + ** a constituent of the public interface. */ diff --git a/src/steam/engine/proc-node.hpp b/src/steam/engine/proc-node.hpp index a626d6d32..760686447 100644 --- a/src/steam/engine/proc-node.hpp +++ b/src/steam/engine/proc-node.hpp @@ -44,7 +44,7 @@ #include "lib/error.hpp" #include "lib/nocopy.hpp" -#include "steam/common.hpp" +#include "lib/hash-value.h" #include "steam/asset/proc.hpp" #include "steam/mobject/parameter.hpp" //#include "steam/engine/state-closure-obsolete.hpp" ///////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation @@ -56,6 +56,7 @@ #include "lib/format-string.hpp" #include "lib/several.hpp" +#include #include #include @@ -66,8 +67,10 @@ namespace engine { namespace err = lumiera::error; using std::move; + using std::string; using std::vector; //////////////TODO; - using lumiera::NodeID; + using lib::HashVal; + using lumiera::NodeID; ///////////////////////TODO likely to be removed using util::_Fmt; /////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation @@ -239,6 +242,30 @@ namespace engine { return 0 < ports().size(); ///////////////////////////////////////////////////TODO 10/2024 more to verify here } + + string + getNodeSpec() + { + UNIMPLEMENTED ("generate a descriptive Spec of this ProcNode for diagnostics"); + } + + 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"); + } }; inline ProcNodeDiagnostic diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index ada768538..9ad442d94 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -13430,9 +13430,7 @@ - - - +

fast immer ist das aber UIC_VIEW @@ -13440,9 +13438,7 @@ - - - +

im Moment fällt mir überhaupt keine Ausnahme ein @@ -14642,9 +14638,7 @@ - - - +

die verfickte Performance wird ignoriert @@ -16896,9 +16890,7 @@ - - - +

in generischer UI-Struktur bewegen @@ -19987,9 +19979,7 @@ - - - +

hierbei ist... @@ -47934,9 +47924,7 @@ - - - +

since, on interface level, we're pretending that this mutator is a single collection like thing, @@ -48474,9 +48462,7 @@ - - - +

und nur letztere sind tangibel @@ -48933,9 +48919,7 @@ - - - +

...aus gutem Grund! @@ -49186,9 +49170,7 @@ - - - +

Instanz-Management ist automatisch @@ -49399,9 +49381,7 @@ - - - +

Also eine generische Implementierung einer Gesten-Erkennung (z.B. dragging), welche dann durch Parametrisierung eingebunden wird @@ -91504,8 +91484,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + @@ -91586,6 +91566,284 @@ 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 +

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

+ So manches Verfahren der symbolischen Repräsentation erscheint zunächst unglaublich elegant und auch effizient; und wenn man es dann in die Praxis übernimmt, und das Verfahren nicht funktioniert, steht man vor einem unlösbaren Rätsel. Also muß der Weg der Lösungsfindung mit aufgezeichnet werden. Und das zerstört die gesamte Eleganz und ist oft aufwendiger, als die eigentliche Lösungsfindung. +

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

+ soll sich genau dann ändern, wenn das Ergebnis aus User-Sicht abweichen wird +

+ + + + + + + +

+ Das ist ein wichtiger Neben-Nutzen; jedoch ist zu beachten, daß dieser die Haupt-Berechnung nicht belastet, denn auf dem kritischen Pfad ist dieser Fall niemals relevant. Er wird aber sicher sehr bedeutsam sein für lesbare Diagnose-Meldungen, und auch für die wenigen aber wesentlichen Testfälle, welche den Aufbau und Zugang zur Datenstruktur der Render-Engine absichern. +

+ + + + + + + +

+ Es handelt sich auch um eine strategische Entscheidung, welche Fehler man routinemäßig zu identifizieren hat. Das System ist entworfen unter der Grundannahme, daß der Builder bereits jedwede Fehlkonfiguration  und Bereichsüberschreitung im Nutzen erfaßt und unterbunden hat, so daß während der Render-Operation nur noch (erwartbare) Zeitüberschreitungen und (unerwartete) Systemfehler und Entgleisungen in externen Libraries passieren können. Es wird deshalb in der Node-Invocation kein Fehlerausgang vorgesehen. Sollte einer der unerwarteten Fehlerfälle noch überhaupt faßbar sein (und nicht unmittelbar zum Absturz führen), so kann von überall eine Exception augeworfen werden; Ressourcen-Lecks schätze ich für diesen Fall als nicht relevant ein, da aller Invocation-State ohnehin auf dem Stack liegt und Buffer durch Timeouts geschützt sind. +

+

+ 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... +

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

+ ohne Differenzierungen auf der Implementierungs-Ebene durch die Ports +

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

+ Beispiel: FFmpeg:gaussianBlur +

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

+ 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 +

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

+ denn in den allermeisten Fällen dürfte es entweder ein Feed sein, oder N gleiche Feeds +

+ + + + + + + + + +

+ Level-3 ist der Builder, der über die tatsächlich zu legenden Verbindungen entscheidet; dafür benötigt er noch die StreamType-Information, wohingegen Level-2 Verbindungen und Typinformationen ungeprüft anwendet. Daher muß zwangsläufig dieser gesamte Qualifier mit den Argumentslisten auf einem höheren Level im Builder etabliert werden. +

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

+ bedeutet, es braucht einen Zugriff auf die ID der Medien-Datenquelle, und diese wird zur Kennzeichnung des Eingangs-Feeds verwendet, und nicht rekursiv die vorläufer-Node-ID +

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

+ 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 +

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

+ ...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) +

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

+ ....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 +

+ + + + + + + + +

+ gefährlicher Hebel durch potentiell +

+

+ sehr große Anzahl an Nodes +

+ + + + + + + + + + + @@ -91751,8 +92009,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
...im Grunde ist die Identität zunächst einmal, daß es die Node gibt, daß sie an einer Speicheradresse sitzt; im aktuellen Design ist es jedoch nicht notwendig, die Node anhand der Identität finden zu können, denn man findet sie über die Verschaltung auf eine Exit-Node

- - + @@ -91774,8 +92031,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
Rein technische Informationen wären z.B. ein Funktions-Symbol im Executable oder Quellcode oder eine Parametersignatur; von solchen Daten kommt man niemals direkt zu einem Urteil "äquivalent für den User"

- - + @@ -91817,7 +92073,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + @@ -91826,7 +92082,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 - + + @@ -91837,8 +92094,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
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)

- - + @@ -91858,6 +92114,19 @@ 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.... +

+ + + + + + @@ -92013,10 +92282,18 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + @@ -132920,8 +133197,9 @@ std::cout << tmpl.render({"what", "World"}) << s - + +