From 40d088c62f3deb07b94a102d85d66081b22cab80 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 14 Dec 2024 19:09:22 +0100 Subject: [PATCH] Invocation: reconsider how layout of the `FeedManifold` is established MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is a first step towards the goal to introduce a ''parameter tuple'' into the `FeedManifold`. Doing so invalidates some of the previously taken decisions regarding the `FeedManifold`; at that time I was still under the impression of the old design from 2012, which called for a ''Buffer Table''. Now we are forced to allow for more leeway in the function definition; even more so, since the limitation to one single input and output Buffer type can be deemed unrealistic anyway. So why sticking to an array at all? ''Buffers could also be a tuple...'' Seemingly another reason why I used an array was the idea to somehow limit the number of template instances, by grouping them into a few number of array sizes, like 1,2,5 and 10. This idea falls short, since in reality it can not be avoided to have the processing function on the type signature anyway. Thus, the only point where the number of templates could be limited lies in the library plug-in, where this »processing function« is actually defined as an adapter. --- src/steam/engine/node-builder.hpp | 2 +- src/steam/engine/weaving-pattern-builder.hpp | 60 +-- wiki/thinkPad.ichthyo.mm | 365 ++++++++++++++++--- 3 files changed, 333 insertions(+), 94 deletions(-) diff --git a/src/steam/engine/node-builder.hpp b/src/steam/engine/node-builder.hpp index 112b92f4d..f3c4b2dc3 100644 --- a/src/steam/engine/node-builder.hpp +++ b/src/steam/engine/node-builder.hpp @@ -405,7 +405,7 @@ namespace engine { auto PortBuilderRoot::invoke (StrView portSpec, FUN fun) { - using WeavingBuilder_FUN = WeavingBuilder(), FUN>; + using WeavingBuilder_FUN = WeavingBuilder; return PortBuilder{move(*this), move(fun), portSpec}; } /* diff --git a/src/steam/engine/weaving-pattern-builder.hpp b/src/steam/engine/weaving-pattern-builder.hpp index 3bbe9354d..55e14cc06 100644 --- a/src/steam/engine/weaving-pattern-builder.hpp +++ b/src/steam/engine/weaving-pattern-builder.hpp @@ -149,8 +149,8 @@ namespace engine { static_assert(_Fun() , "something funktion-like required"); static_assert(is_BinaryFun() , "function with two arguments expected"); - using ArgI = remove_reference_t::Args::List::Head>; - using ArgO = remove_reference_t::Args::List::Tail::Head>; + using SigI = remove_reference_t::Args::List::Head>; + using SigO = remove_reference_t::Args::List::Tail::Head>; template struct MatchBuffArray @@ -164,36 +164,14 @@ namespace engine { enum{ SIZ = N }; }; - using BuffI = typename MatchBuffArray::Buff; - using BuffO = typename MatchBuffArray::Buff; + using BuffI = typename MatchBuffArray::Buff; + using BuffO = typename MatchBuffArray::Buff; - enum{ FAN_I = MatchBuffArray::SIZ - , FAN_O = MatchBuffArray::SIZ + enum{ FAN_I = MatchBuffArray::SIZ + , FAN_O = MatchBuffArray::SIZ + , MAXSZ = std::max (uint(FAN_I), uint(FAN_O)) /////////////////////OOO required temporarily until the switch to tuples }; }; - - - /** - * Pick a suitable size for the FeedManifold to accommodate the given function. - * @remark only returning one of a small selection of sizes, to avoid - * excessive generation of template instances. - * @todo 10/24 this is a premature safety guard; - * need to assess if there is actually a problem - * (chances are that the optimiser absorbs most of the combinatoric complexity, - * or that, to the contrary, other proliferation mechanisms cause more harm) - */ - template - inline constexpr uint - manifoldSiz() - { - using _F = _ProcFun; - auto constexpr bound = std::max (_F::FAN_I, _F::FAN_O); - static_assert (bound <= 10, - "Limitation of template instances exceeded"); - return bound < 3? bound - : bound < 6? 5 - : 10; - } }//(End)Introspection helpers. @@ -221,8 +199,8 @@ namespace engine { static_assert(FAN_I <= N and FAN_O <= N); - using ArrayI = std::array; - using ArrayO = std::array; + using ArrayI = typename _ProcFun::SigI; + using ArrayO = typename _ProcFun::SigO; FUN process; @@ -239,7 +217,7 @@ namespace engine { void connect (uint fanIn, uint fanOut) { - REQUIRE (fanIn >= FAN_I and fanOut >= FAN_O); + REQUIRE (fanIn == FAN_I and fanOut == FAN_O); //////////////////////////OOO this distinction is a left-over from the idea of fixed block sizes for (uint i=0; i(); for (uint i=0; i + template struct DirectFunctionInvocation : util::MoveOnly { - using Manifold = FeedManifold; + enum{ MAX_SIZ = _ProcFun::MAXSZ }; + using Manifold = FeedManifold; using Feed = SimpleFunctionInvocationAdapter; - enum{ MAX_SIZ = N }; std::function buildFeed; @@ -346,8 +324,8 @@ namespace engine { - template - using SimpleDirectInvoke = MediaWeavingPattern>; + template + using SimpleDirectInvoke = MediaWeavingPattern>; /** @@ -364,12 +342,12 @@ namespace engine { * @tparam N maximum number of input and output slots * @tparam FUN function or invocation adapter to invoke */ - template + template struct WeavingBuilder : util::MoveOnly { using FunSpec = _ProcFun; - using TurnoutWeaving = Turnout>; + using TurnoutWeaving = Turnout>; static constexpr SizMark sizMark{}; static constexpr uint FAN_I = FunSpec::FAN_I; static constexpr uint FAN_O = FunSpec::FAN_O; @@ -423,7 +401,7 @@ namespace engine { while (cnt--) buffTypes.emplace_back([](BufferProvider& provider) { return provider.getDescriptor(); }); - ENSURE (buffTypes.size() <= N); + ENSURE (buffTypes.size() <= FAN_O); return move(*this); } @@ -474,9 +452,7 @@ namespace engine { outTypes.append ( typeConstructor (providers[i++])); - ENSURE (leadPorts.size() <= N); ENSURE (leadPorts.size() == FunSpec::FAN_I); - ENSURE (outTypes.size() <= N); ENSURE (outTypes.size() == FunSpec::FAN_O); using PortDataBuilder = DataBuilder; diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 5dd62af62..3479e39a2 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -23290,9 +23290,7 @@ - - - +

...das ist in der Tat eine überflüssige Indirektion, die jedoch einen Storage-Slot einspart (weil die VTable ohnehin schon da ist). Man könnte sehr wohl schon im Interface CanvasHook einen Pointer auf eine DisplayMetric vorsehen @@ -23849,9 +23847,7 @@ - - - +

die Teilelemente speichern ihren Wert @@ -24382,9 +24378,7 @@ - - - +

Rekursion ist immer doppelbödig: @@ -25155,9 +25149,7 @@ - - - +

beim ersten Mal wird "nebenbei" festgestellt, daß das Track-Profil (noch)nicht existiert. @@ -26367,9 +26359,7 @@ - - - +

soweit möglich ohne grundlegende Änderungen @@ -28158,9 +28148,7 @@ - - - +

Fall-1: Font-Size ist absolut gegeben ⟹ @@ -30343,9 +30331,7 @@ - - - +

wenn man PACK_SHRINK setzt, dann weist die umschließende Box initial @@ -31524,9 +31510,7 @@ - - - +

  • @@ -34241,9 +34225,7 @@ - - - +

    wenn man das naiv coden würde, dann würden wir für jeden Clip erst mal einen ClipData-Placeholder erzeugen, nur um dann, nach dem Empfangen des vollständigen Diff, diesen wieder zu deallozieren und dafür ein ClipWidget zu erzeugen... @@ -36491,9 +36473,7 @@ - - - +

    @deprecated: 3.4: Key snooping should not be done. Events should  be handled by widgets @@ -37690,9 +37670,7 @@ - - - +

    Und außerdem: die Wiederverwendung einer Implementierung z.B. für Dragging kann man per Vererbung oder per nested component lokal in der Implementierung regeln @@ -38592,9 +38570,7 @@ - - - +

    Name: DisplayMetric @@ -38901,9 +38877,7 @@ - - - +

    ...auch daran kann ich mich jetzt wieder erinnern...
    Dann wäre nämlich das Handle nicht mehr kopierbar @@ -39141,9 +39115,7 @@ - - - +

    aber das von GDK gelieferte Delta hängt eben vom GDK-Window des widgets ab @@ -89993,8 +89965,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    ...während Ausgabepuffer zwar an der Stelle committed werden, aber »der« Ausgabepuffer wird noch nicht freigegeben, denn er ist ja Eingabepuffer der Nachfolger-Node

    - -     +     @@ -91343,6 +91314,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    + @@ -91358,10 +91330,261 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

    + ...weil wir SLOT_I ≔ SLOT_O setzen (wichtig!), wenn es keinen Input gibt; es gibt nur zwei Fälle ohne Parameter, und die lsassen sich damit in diesen Test zusammenfassen +

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

    + da es nur in Traits selber verwendet wird +

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

    + denn im Moment wird der ja wirklich gebraucht, da die FeedManifold noch eine fixed-size-Allocaiton macht +

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

    + das Template DirectFunctionInvocation<N,FUN>  ist der Hebel +

    + +     + +     + + + + + + +

    + Und ich sehe keinerlei Basis, um einen beliebigen Buffer-Mix ausschließen zu können. Denn wir wollen beliebige, nicht weiter bekannte Libraries adaptieren können. Die einzige verbleibende Barriere ist FUN selber, denn das kann auch ein generischer Adapter aus dem Library-Plugin sein; jedoch Vorgaben können wir keine machen. +

    +

    + Jede mögliche Funktions-Signatur erzeugt eine separate Turnout-Instanz +

    + + +     + + + + + +

    + das Media-Lib-Plugin is Problemzone und Ansatzpunkt bzgl Template-Bloat +

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

    + Trade-off: dafür dann eine runtime-Indirection +

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

    + ...denn exakt an dieser Stelle ist das Prototyping bis jetzt gescheitert ... wir konnten bisher nur eine „dämliche“ Dummy-Funktion binden; sobald eine echte Dummy-Funktion eingebunden werden sollte, bin ich darauf aufmerksam geworden, das eine solche Funktion zwangsläufig auch weitere Parameter brauchen wird, und nach einer weiteren, langen „Denk-Schleife“ bin ich hier wo ich grad bin +

    + + +     + +     + + + + + + +     +     + + + + + + + + + + + + + + + + + + + @@ -91369,6 +91592,39 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    + + + + + + +

    + ...insofern dann alle Fälle mit gleicher Signatur zusammenfallen; für die häufigsten Fälle (wie z.B. ein einziger int-Parameter) erwarte ich einen starken Hebel +

    + + +     +     + + + + + + + + + + + + + + + + + + + +         @@ -92737,8 +92993,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    sollte »im Prinzip« auf das bestehende Schema aufgepflantzt werden

    - - + @@ -94278,9 +94533,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         + - @@ -96068,7 +96323,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     - + @@ -96076,6 +96331,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     + + + +     @@ -97019,8 +97278,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
     - + + + + + +     @@ -97212,8 +97476,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
    Folgeschäden eines redundanten Aufrufs zu bedenken

    - - +