diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 494436795..d64d14929 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -6029,9 +6029,7 @@ - - - +

füge möglichst hoch in der Hierarchie Regeln ein, @@ -6073,9 +6071,7 @@ - - - +

beruht auf der sehr sinnigen Einrichtung von Joel Holdsworth @@ -6698,9 +6694,7 @@ - - - +

generisches Öffnen @@ -7472,9 +7466,7 @@ - - - +

zentrales Problem @@ -8741,9 +8733,7 @@ - - - +

ich brauche ihn nicht @@ -11392,9 +11382,7 @@ - - - +

wenn es sie gäbe könnte man sie hier nutzen @@ -15358,9 +15346,7 @@ - - - +

das ist immer schon korrekt erledigt @@ -22492,9 +22478,7 @@ - - - +

...weil der Vater ja auch neue Kinder "hooken" kann @@ -22507,9 +22491,7 @@ - - - +

d.h. zugleich wird die alte Verbindung gelöst und die neue konstruiert @@ -46331,9 +46313,7 @@ - - - +

Erste Integration: verhält sich korrekt @@ -46349,9 +46329,7 @@ - - - +

Beispiel: Fenster vorher sehr schmal machen... @@ -46362,9 +46340,7 @@ - - - +

per Trace-Meldung überprüft: calibrateExtension() ist so programmiert, daß es die bestehende Metrik erhält, sondern das ZoomWindow entsprechend verkleinert. Der Code verwendet bisher nur default-Werte für die Timeline ⟹ die Metrik bleibt auf 25px/sec stehen, und damit wird die Gesamtlänge stets mindestens 575px sein; Ausnahme: wenn das Fenster ohnehin größer ist... @@ -46421,9 +46397,7 @@ - - - +

innere @@ -46470,9 +46444,7 @@ - - - +

weil wir einen Mechanismus haben, die <cnt>-Dekoration pro Typ global hochzuzählen (treadsafe) @@ -46485,9 +46457,7 @@ - - - +

Problem: key nur innerhalb des Objektes eindeutig @@ -81348,6 +81318,33 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + +

+ man hat bereits die Vorgänger ProcNode(s) irgendwo sitzen +

+ + + + + + + + + + +

+ build() generiert einen Connectivity-Record by-value +

+ + + + + + @@ -87259,6 +87256,58 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

+ + + + + + +

+ will sagen: ich gehe erst mal im Prototyping von einer Test-Ontology aus, die sich aber informell bereits auf meine Kenntnis der Domäne (Video-Processing) abstützt +

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

+ wie beide aus einer »Ontology« heraus angelegt und gesteuert werden können +

+ + + + + + + + +

+ und letztlich wie dann ein konkreter Aufruf ablaufen kann +

+ + + + + + + + +

+ sich nicht verrückt machen: das hier ist ein hermeneutischer Zirkel: Um ein gutes Werkzeug bauen zu können, muß ich die Sache  verstehen — und das mache ich, indem ich auf den Werkzeuggebrauch hin stipuliere +

+ + + + + + + @@ -87823,13 +87872,15 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + - + + @@ -89000,30 +89051,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - +

nämlich den OutputBufferProvider explizit eine Ebene darüber verwenden und dann das BuffHandle direkt in den weave()-Aufruf geben

- - + - - - +

Den OutputBufferProvider handhaben wir jetzt eine Ebene höher, und dort können wir direkt ein LocalTag setzen und dann ein zugehöriges BuffHandle erstellen, das nur an einen bestimmten Buffer im Output-system gebunden ist. Alle anderen Use-Cases (Memory-Blöcke und Cache) sind ohnehin global für die gesamte RenderEngine

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

wenngleich auch dort Zweifel zum Namen bestehen

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

damit lib::Depend ohne Weiteres einfach funktioniert

- - + @@ -89181,7 +89220,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + +