diff --git a/src/steam/engine/turnout.hpp b/src/steam/engine/turnout.hpp index 8455268ed..f047aff3a 100644 --- a/src/steam/engine/turnout.hpp +++ b/src/steam/engine/turnout.hpp @@ -72,6 +72,7 @@ //#include "lib/linked-elements.hpp" //#include "lib/util-foreach.hpp" //#include "lib/iter-adapter.hpp" +#include "lib/meta/function.hpp" //#include "lib/itertools.hpp" //#include "lib/util.hpp" @@ -253,6 +254,24 @@ namespace engine { }; /////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation + /** + * Definition to emulate a _Concept_ for the *Invocation Adapter*. + * For each Proc-Asset, the corresponding Library Adapter must provide + * such adapters to access the input and result buffers and finally to + * invoke the processing functions from this library. + * - `connect(MAN&,fanIn,fanOut)` access the _Feed Manifold_ and link the buffers + * - `invoke()` invoke the processing function, passing the connected buffers + * @tparam MAN the concrete type of the Feed Manifold, holding an array with + * input and output _Buffer Handles_ + */ + template + constexpr void + _verify_usable_as_InvocationAdapter() + { + ASSERT_MEMBER_FUNCTOR (&ADA::connect, void(MAN&, uint, uint)); + ASSERT_MEMBER_FUNCTOR (&ADA::invoke, void()); + } + struct WeavingPatternBase //////////////////////////////OOO non-copyable? move-only?? @@ -267,11 +286,19 @@ namespace engine { }; - template + template + struct InvocationAdapter + : FeedManifold + { + FUN process; + }; + + + template struct SimpleWeavingPattern : PAR { - using Feed = FeedManifold; + using Feed = InvocationAdapter; uint fanIn{0}; uint fanOut{0}; diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 9fe3301ad..7964b66e3 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -863,9 +863,7 @@ - - - +

die Closure eines Lambdas hängt am Kontext @@ -877,9 +875,7 @@ - - - +

konkret: @@ -909,9 +905,7 @@ - - - +

Debug: nur ein Element connected @@ -961,9 +955,7 @@ - - - +

weil die Abstraktion "UI-Element" eben grade @@ -2321,9 +2313,7 @@ - - - +

das Widget hat offensichtlich keine eigene graphische Repräsentation. @@ -4034,9 +4024,7 @@ - - - +

...indem der NotificatonService nun vom UI-Manager gemanaged wird :) @@ -5940,9 +5928,7 @@ - - - +

Name: WLink @@ -8282,9 +8268,7 @@ - - - +

aber es gibt Konsistenzchecks + Exceptions @@ -11788,9 +11772,7 @@ - - - +

vorläufige MInimal-Lösung @@ -82223,6 +82205,35 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -86110,6 +86121,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ @@ -87759,8 +87771,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
das wäre KISS; man würde den gleichen Template-Parameter N heranziehen, der auch die FeedManifold steuert; dieser wird nach dem Schema »eins«, »zwei«, »viele« belegt. Zusätzlich gibt es für diesen Ansatz dann eine dynamische Spec über die tatsächliche Anzahl der Buffer In/Out (die stets <= N wäre)

- - + @@ -87771,8 +87782,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
Im einfachsten Fall wäre das genauso wie die erste Lösung, nur daß der Buffer nicht im Haupt-Objekt liegt (aber natürlich trotzdem im Allocation-Cluster). Allerdings gäbe es hier noch eine weitere, halb-dynamische Lösung: man würde explizit einen Buffer dynamisch allozieren (direkter Allokator-Aufruf, bei dem man die Anzahl Elemente angibt). Das läuft auf einen minimalistischen Spezial-Container hinaus, oder eine ScopedCollection mit Custom-Allocator, oder dann gleich die nächste Lösung....

- - + @@ -87782,8 +87792,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
...dies ist mit wenig Entwicklungs-Aufgand umzusetzen, erfordert dann aber trotzdem eine explizite Verdrahtung des Allocators und damit eine Vermischung zwischen Objekt-Konstruktion und Builder/Allocator.

- - + @@ -87793,8 +87802,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
Unabhängig davon, welche der drei vorgenannten Lösungen zum Zuge kommt, gibt es steths noch eine weitere, komplexere Variante, die aber sehr attraktiv erscheint: es ist nämlich in den weitaus meisten Fällen so, daß nur ein einziger, einheitlicher Buffer-Typ zum Einsatz kommt; daher läuft das Belegen eines Array mit einem expliziten Deskriptor für jeden »Slot« auf erhebliche Speicherverschwendung hinaus. Stattdessen könnte man versucht sein, die Belegung durch ein Stück Code machen zu lassen (eine Closure), und dafür eine Meta-Spec zu interpretieren. Das wird aber in jedem Fell recht komplexer Code, der dann auch zur Render-Zeit läuft (ja wirklich, in jedem Aufruf), und deshalb wieder das Problem aufwirft, woher man die Storage für temporäre Datenstrukturen nimmt. Denn solche wird es zwingend geben, schließlich muß man ja irgendwie markieren, was die bereits behandelten Spezialfälle sind, und welche »Slots« damit übrig bleiben und mit dem Standard-Fall behandelt werden müssen. Ja mei!

- - + @@ -87808,8 +87816,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
diese Lösung ist wohl etwas brachial

- - + @@ -87833,8 +87840,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
...grundsätzlich besteht diese Möglichkeit, und sie könnte eine gewisse Relevanz bekommen, sobald wir es mit Hardware-Accelleration zu tun haben. Dennoch halte ich das nicht für den Regelfall, und zudem treibt es die Komplexität hoch

- - + @@ -87850,6 +87856,103 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Die FeedManifold hätte in diesem Fall einen zusätzlichen Platz für ein spezielles BuffHandle. Dieses müßte so konfiguriert werden, daß der Typ des InvocationAdapters und seine Konstruktions-Parameter in dem zugehörigen BufferDescriptor „versteckt“ sind. Trotzdem müßte man dann auch noch für den Aufruf nochmal eine Referenz der FeedManifold an die Funktionen des InvocationAdapters durchgeben +

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

+ denn die FeedManifold wird als »eins«, »zwei«, »viele« parametrisiert, und nun kommen hier möglicherweise noch weitere Kombinationen hinzu; ich erwarte allerdings kein volles cartesisiches Produkt, da es i.d.R. einen Zusammenhang gibt zwischen der konkreten Funktion und der Anzahl der Buffer +

+ + + + + + + +

+ meine Einschätzung: diese Kombinatorik ist unvermeidbar +

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

+ die FeedManifold ist stets fester Bestandteil des InvocationAdapters +

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