diff --git a/src/steam/engine/node-builder.hpp b/src/steam/engine/node-builder.hpp index 424e6275b..708f58e73 100644 --- a/src/steam/engine/node-builder.hpp +++ b/src/steam/engine/node-builder.hpp @@ -56,19 +56,19 @@ namespace engine { /////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation - class NodeWiringBuilder + class PortBuilder : util::MoveOnly { public: - NodeWiringBuilder + PortBuilder inSlots (uint s) { UNIMPLEMENTED ("define number of predecessor-source slots"); return move(*this); } - NodeWiringBuilder + PortBuilder outSlots (uint r) { UNIMPLEMENTED ("define number of result slots"); @@ -76,13 +76,51 @@ namespace engine { } template - NodeWiringBuilder + PortBuilder createBuffers (ARGS&& ...args) { UNIMPLEMENTED ("define builder for all buffers to use"); return move(*this); } + /****************************************************//** + * Terminal: complete the Port wiring and return to the node level. + */ + void //////////////////////////////////////////////////////////OOO return type + completePort() + { + UNIMPLEMENTED("finish and link-in port definition"); + } + }; + + + + class NodeBuilder + : util::MoveOnly + { + public: + + NodeBuilder + inSlots (uint s) + { + UNIMPLEMENTED ("define number of predecessor-source slots"); + return move(*this); + } + + NodeBuilder + outSlots (uint r) + { + UNIMPLEMENTED ("define number of result slots"); + return move(*this); + } + + void //////////////////////////////////////////////////////////OOO return type + preparePort () + { + UNIMPLEMENTED ("recursively enter detailed setup of a single processing port"); +// return move(*this); + } + /****************************************************//** * Terminal: complete the Connectivity defined thus far. */ @@ -94,6 +132,50 @@ namespace engine { }; + class ProcBuilder + : util::MoveOnly + { + public: + + void //////////////////////////////////////////////////////////OOO return type + requiredSources () + { + UNIMPLEMENTED ("enumerate all source feeds required"); +// return move(*this); + } + + void //////////////////////////////////////////////////////////OOO return type + retrieve (void* streamType) + { + UNIMPLEMENTED ("recursively define a predecessor feed"); +// return move(*this); + } + + /****************************************************//** + * Terminal: trigger the Level-3 build walk to produce a ProcNode network. + */ + void //////////////////////////////////////////////////////////OOO return type + build() + { + UNIMPLEMENTED("Level-3 build-walk"); + } + }; + + + class LinkBuilder + : util::MoveOnly + { + public: + + void //////////////////////////////////////////////////////////OOO return type + from (void* procAsset) + { + UNIMPLEMENTED ("recursively enter definition of processor node to produce this feed link"); +// return move(*this); + } + }; + + /** * Entrance point for building node Connectivity */ @@ -102,7 +184,7 @@ namespace engine { buildPatternFor() { UNIMPLEMENTED("instantiate Domain Ontology Facade and outfit the NodeWiringBuilder"); - return NodeWiringBuilder{}; + return NodeBuilder{}; } diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index b03ae2d6f..55ed69e35 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -869,9 +869,7 @@ - - - +

wenn ich per Value capture, dann gibts schon @@ -1523,9 +1521,7 @@ - - - +

...und insofern ist auch die Behandlung einer Folge-Exception noch offen @@ -2655,9 +2651,7 @@ - - - +

weil so sichergestellt ist, daß er stets existiert, @@ -3597,9 +3591,7 @@ - - - +

0000001180: INFO: subsystem-runner.hpp:208: worker_3: sigTerm: Subsystem 'Lumiera GTK GUI' terminated. @@ -4798,9 +4790,7 @@ - - - +

muß SessionCommandService schließen @@ -5764,9 +5754,7 @@ - - - +

wenn man die Gruppe auflöst, wendet Inkscape die Transformation auf jedes Einzelelement an, und schiebt eine inverse Transformation in alle referenzierten Gradienten @@ -6776,9 +6764,7 @@ - - - +

Lösung: schwebende Bindung @@ -7824,9 +7810,7 @@ - - - +

eine reverse resolution @@ -8747,9 +8731,7 @@ - - - +

echte Expand-Funktion notwendig @@ -23181,9 +23163,7 @@ - - - +

weil nun ViewHooked schon als ctor-Parameter einen ViewHook bekommen muß... @@ -23935,9 +23915,7 @@ - - - +

wir lassen es offen, welche Art von ID das ist. @@ -24586,9 +24564,7 @@ - - - +

↯ Nein! @@ -32845,9 +32821,7 @@ - - - +

und zwar im Wesentliche zur Schattierung der Flanken. @@ -33657,9 +33631,7 @@ - - - +

ist ineffizient, aber der Code ist so klarer @@ -34588,9 +34560,7 @@ - - - +

box-shadow (inset) innerhalb des Rechteckss, und innerhalb der (gedachten) border @@ -35632,9 +35602,7 @@ - - - +

...für eine zentrale Schaltstelle und Verteiler.
Denn nur der DisplayFrame ist hinreichend loka und dennoch erreichbar @@ -43729,9 +43697,7 @@ - - - +

...damit meine ich: ausrechnen wie viele Pixel die jetzt eingestelle Fenstergröße in der ursprünglich geforderten Metrik einnehmen würde..... @@ -44644,9 +44610,7 @@ - - - +

kommt dadurch zustande, daß ich nach dem Hochskalieren i.d.R doch noch einen Rest habe, den ich für Integer-Arithmetik abrunde; damit dann trotzdem die gewünschte (i.d.R. um einen Pixel höhere) Pixelzahl rauskommt, inkrementiere ich die letzte Stelle, und das ist zugleich meine maximale Fehlerschranke. In Extremfällen haben wir im Zähler noch eine 4-stellige Zahl (1000/LIM_HAZARD) und damit etwa 1‰ Fehler maximal. Das ist nicht schön, aber akzeptabel — gemessen daran, daß ich dadruch eine »ungiftige« Metrik sicherstellen kann. Sobald man etwas weg ist von der Unterschranke der Metrik 1000/LIM_HAZARD, wirkt das Nach-Skalieren und Mitnehmen des gebrochenen Anteils viel besser, und der Fehler sinkt drastisch @@ -45635,9 +45599,7 @@ - - - +

...das sind 4ms @@ -46418,9 +46380,7 @@ - - - +

alle Steuersignale aus dem GUI kommen in Pixel-Einheiten, entweder absolut oder relativ; das ZoomWindow selber aber arbeitet in Zeit-Einheiten (und das ist auch seine Aufgabe). @@ -47287,9 +47247,7 @@ - - - +

aus Performance-Gründen. @@ -47820,9 +47778,7 @@ - - - +

...wird sinnvoll im Rahmen von InteractionControl @@ -51181,9 +51137,7 @@ - - - +

Compiler-Bug Gcc-#63723 @@ -51880,9 +51834,7 @@ - - - +

...und das heißt auch, wo werden die Aussage-Sätze gebildet?
wird das Formen von kontextbezogenen Anweisungen im UI-Bus-Protokoll eigens verankert, oder erfolgt dies komplett intern im Stage-Layer? @@ -52548,9 +52500,7 @@ - - - +

CommandID und Argumente gegeben @@ -71243,49 +71193,38 @@ - - - +

«Domain-Ontology-Mapping»

- - + - - - +

Einfach gesagt: jede Media-handling-Library definiert, was für Medien-Dinge es geben kann, wie diese zusammenhängen und klassifiziert werden und wie deren Eigenschaften festgestellt werden können...

- - + - - - +

Feststellung: Domain-Ontologies werden über Aufgaben-Callbacks  eingebunden

- - + - - - +

Dies ist ein Beschluß auf Basis einer induktiven Grundhaltung: Wir haben den bestehenden Umgang mit dem Thema »Media-Processing« betrachtet und auf diesem Hintergrund eine Architektur-Lösung gefunden, die nicht auf einer mutwillig deduktiv gesetzten Ordnung beruht. Es wird ein Rahmen abgesteckt, was man typischerweise „mit Medien machen“ möchte, und aus diesem wird ein Baukasten-System destilliert, auf dessen Basis sich diese üblichen Ziele und Zwecke erreichen lassen. Dieser Rahmen bleibt jedoch offen, insofern er nicht als eine innere Systematik ausgearbeitet wird. Stattdessen gibt es — aus diesem Baukasktensystem heraus — bestimmte Aufgaben, die im Rahmen der jeweiligen Domain-Ontology zu lösen sind. Lumiera stellt dafür den Raum für ein Modell bereit, und einen Ordnungsrahmen, wie mit den Modellbestandteilen umzugehen ist. Es obliegt dann aber dem jeweiligen Domain-Adapter (Façade), diese von Lumiera vorgegebenen Erwartungen in der jeweiligen Domäne zu realisieren. @@ -71294,15 +71233,12 @@ Zur Wirkung der aufgerufenen Aufgaben und zur Semantik müssen gewisse Annahmen gemacht werden, wie z.B. das ein Medium gerendert werden kann. Es wird aber nicht versucht, dies weiter klassifikatorisch zu fassen; die Wirkung dieser Aktionen wird durchgereicht, und der Sinn liegt bei demjenigen, der Lumiera verwendet, um damit etwas zu bauen.

- - + - - - +

Beispiele: @@ -71325,8 +71261,7 @@ - - + @@ -71358,16 +71293,13 @@ - - - +

....gehe aber nicht davon aus, daß dies möglich ist, weil es den Zugriff auf Inhalte aus Plug-ins überall deutlich komplexer macht und auch zu Contention führen könnte

- - + @@ -72393,17 +72325,15 @@ - - - +

Callback: configureNode(builder)

- + @@ -81987,18 +81917,94 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + +
    +
  • + orientiert sich an der Reihenfolge der Outputs aus der Proc-Function +
    • +
  • + lediglich der Result-Slot muß spezifiziert werden +
    • +
+ + - - - - - - - + + + + + + + + + + + + + + + + + +

+ konkret: der InvocationAdapter muß Code enthalten, der sich aus den jeweiligen BuffHandles die expliziten Buffer-Pointer holt. Dazu muß er wissen, wo und in welcher Reihenfolge diese BuffHandles liegen — Beachte: diese Reihenfolge ist nicht zwingend die Parameter-Reihenfolge der aufzurufenden Library-Funktion. +

+ + + + + + + + + + + +
    +
  • + in einem früheren Build-Schritt wird festgestellt, welche Eingabeparameter eine Lib-Funktion braucht +
    • +
  • + für alle diese Eingabe-Parameter wird eine Quelle vorgemerkt +
    • +
  • + ein weiterer Build-Schritt organisiert diese Datenquellen in Vorläufer-Nodes +
    • +
  • + ein weiterer Build-Schritt legt die pull()-Reihenfolge dieser Vorläufer fest +
    • +
  • + hierbei können weitere Vorläufer-Nodes hinzugefügt werden, um externe Belange zu befriedigen, wie z.B. Automation bereitzustellen +
    • +
+

+ ⟹ Nun, auf diesem Level muß der eigentliche LIbrary-Aufruf konfiguriert werden, und dabei muß jeder Input der Library-Funktion mit den richtigen Daten aus dem richtigen Vorläufer BuffHandle versorgt werden. Diese BuffHandles liegen nun aber in einer möglicherweise geänderten Reihenfolge vor, und es sind weitere BuffHandles dabei, die für den eigentlichen Aufruf nicht gebraucht werden (sondern für die weiteren, externen Belange) +

+ + + - + + + + + + + + + + + + + + @@ -82006,10 +82012,42 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
diese wird später irgendwo instantiiert

- - + + + + + + +

+ Erwartetes Resultat: Aufruf der Library Funktion +

+ + + + + + + + +

+ Terminal: completePort() +

+ + + + + + + +

+ das heißt, muß ohnehin einen Back-link halten, muß aber sich selber in den Parent-Builder zurückschieben (tricky und potentiell gefährlich....) +

+ + + + @@ -82063,16 +82101,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - +

...nach dem Level-3-Build-walk sind sie allesamt nicht mehr erforderlich — und könnten per AllocationCluster auf einen Schlag weggeworfen werden

- - + @@ -82094,9 +82129,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...d.h. die Planung steigt für einen Port ein, findet für dieses in Proc-Asset in einem bereits vorliegenden Prototypen der Connectivity, und kann für dieses Proc-Asset alle benötigten Inputs identifizieren und jeden von diesen einem anderen, ebenfalls bereits bekannten Vorläufer Proc-Asset zuordnen; diese Zuordnung wäre dann die Belegung eines Port, und das Proc-Asset würde zu einer geplanten Node. Im Besonderen ist durch diese Vorraussetzung festgelegt, daß alle diese Belegungen bereits eindeutig und entscheidbar sind; Zweideutigeiten und Unmöglichkeiten sind in den vorausgehenden Verarbeitungsschritten bereits aussortiert worden... @@ -82110,16 +82143,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Leads (≙Vorgänger-Nodes) werden nach Bedarf angelegt als Level-3-Builder

- - + @@ -82135,30 +82165,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...anders als die Konfigurations-Walks auf Level-3 vor dem Triggern des Build-Walk; diese traversieren über Ports und Stream-Verbindungen, folgen also einem bestimmten Berechnungspfad. Dagegen für die Level-2-Builder sind Lead-Nodes vorrausgesetzt, und das bedeutet, ein Build erfolgt für die ganze Nodes, für alle Ports zusammen

- - + - - - +

sodann wird für den Vorgänger ein Level-2-Builder erstellt

- - + @@ -82167,16 +82191,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - +

tatsächlich ist jede Port-Impl ≙ Turnout ein Level-1-Builder

- - + @@ -82192,16 +82213,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

nichts davon hängt von Strukturen aus der Domain-Ontology ab

- - + @@ -82222,43 +82240,34 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...und hinter dem liegen ebenfalls Strukturen aus der Ontologie; das ist ja sogar gradezu der Kern der Sache: jede Library bestimmt was es für Arten von Medien und Strömen geben kann

- - + - - - +

...das klingt vielleicht nach einer steilen These, beruht aber auf der Beobachtung, daß eine solche Schematisierung (wiewohl denkbar), ihrerseits wieder Teil einer Domain-Ontology wäre — jeder Versuch, dies zu generalisieren liefe auf eine Universal-Ontologie des ganzen Fachbereichs hinaus, und ist daher grundsätzlich zum Scheitern verurteilt, denn so etwas gehört nicht auf die Ebene praktischer Organisation, auf der wir uns hier bewegen, bei der Konstruktion von Systemen der Informationstechnik.

- - + - - - +

Konsequenz ⟹ der Aufruf der Level-2-Parametrisierung muß in einem Callback passieren

- - + @@ -82280,29 +82289,23 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - +

Das bedeutet: wenn man auf dem default-konstruierten Builder die build()-Metode ausführt, dann entsteht eine Node, die zwar alle erwarteten Ports hat, aber alle diese Ports liefern bei Aufruf ein NULL-Handle des jeweils eingesetzten BufferProviders liefert. (Selbstverständlich wäre es viel schöner, an dieser Stelle einen leeren Frame zu liefern, aber das ist nicht möglich, ohne das Format zu kennen, welches jedoch von der Domain-Façade geleistet werden muß)

- - + - - - +

der Callback lautet: configureNode(builder)

- - + @@ -82314,30 +82317,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - +

Hiermit sei nur angezeigt, daß es weitere solche Festlegungen zur Betriebsart geben kann, die typischerweise auf einem höheren Level bereits entschieden wurden, vermutlich ebernfalls unter Zuhilfename der Domain-Façade

- - + - - - +

Alle diese Callbacks werden auf dem Interface DomainFacade gesammelt

- - + @@ -82346,16 +82343,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...diese muß die Grundzüge des Asset-Systems, die Schnittstellen-Entitägen des Builders, das Stream-Type-Framework (und vmtl.) noch Weiteres enthalten. Außerdem müssen alle die genannten Entitäten von der Implementierungs-Ebene entkoppelt sein

- - + @@ -86197,8 +86191,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- +