Invocation: draft how the 1:1-fallback wiring could work

...and as expected, this turns up quite some inconsistencies,
especially regarding usage of the »buffer types«.

Basically, the `PortBuilder` is responsible for the high-level functionality
and thus must ensure the nested `WiringBuilder` is addressed and parameterised
properly to connect all »slots« of the processing function.
 - can use a helper function in the WiringBuilder to fill in connections
 - but the actual buffer types passed over these connectinos are totally
   unchecked at that level, and can not see yet how this danger can be
   mitigated one level above, where the PortBuilder is used.
 - it is still unclear what a »buffer type« actually means; it could
   be the pointer type, but it could also imply a class or struct type
   to be emplaced into the buffer, which is a special extension to the
   `BufferProvider` protocol, yet seems to be used here rather to transport
   specific data types required by the actual media handling library (e.g. FFmpeg)
This commit is contained in:
Fischlurch 2024-10-14 04:07:47 +02:00
parent 4df4ff2792
commit 4a963c9fee
8 changed files with 259 additions and 81 deletions

View file

@ -60,6 +60,8 @@ namespace engine{
EngineCtx::~EngineCtx() { }
/** */
EngineCtx::EngineCtx()
: services_{make_unique<Facilities>()}

View file

@ -70,6 +70,7 @@ namespace engine {
static lib::Depend<EngineCtx> access;
private:
~EngineCtx();
EngineCtx();
friend class lib::DependencyFactory<EngineCtx>;

View file

@ -70,6 +70,7 @@ namespace engine {
: util::NonCopyable
{
using BuffS = lib::UninitialisedStorage<BuffHandle,N>;
enum{ STORAGE_SIZ = N };
BuffS inBuff;
BuffS outBuff;

View file

@ -313,7 +313,9 @@ namespace engine {
NodeBuilder<POL>
completePort()
{
//////////////////////////////////////////////////////////OOO finish port data setup here
//////////////////////////////////////////////////////////OOO need to provide all links to lead nodes here
weavingBuilder_.fillRemainingBufferTypes();
_Par::ports_.append(weavingBuilder_.build());
return static_cast<NodeBuilder<POL>&&> (*this);
} // slice away the subclass

View file

@ -266,11 +266,12 @@ namespace engine {
* - `invoke()` invoke the processing function, passing the connected buffers
*/
template<class ADA>
constexpr void
constexpr bool
_verify_usable_as_InvocationAdapter()
{
ASSERT_MEMBER_FUNCTOR (&ADA::connect, void(uint, uint));
ASSERT_MEMBER_FUNCTOR (&ADA::invoke, void());
return sizeof(ADA);
}
@ -302,7 +303,7 @@ namespace engine {
//////////////////////////////////////////OOO builder must set-up those descriptors
template<typename...ARGS>
SimpleWeavingPattern(Several<PortRef>&& pr, Several<BuffDescr> dr, ARGS&& ...args)
SimpleWeavingPattern(Several<PortRef>&& pr, Several<BuffDescr>&& dr, ARGS&& ...args)
: CONF{forward<ARGS>(args)...}
, leadPort{move(pr)}
, outTypes{move(dr)}

View file

@ -43,6 +43,8 @@
#include "steam/engine/turnout.hpp"
#include "steam/engine/engine-ctx.hpp"
#include "steam/engine/buffer-provider.hpp"
#include "steam/engine/buffhandle-attach.hpp" /////////////////OOO why do we need to include this? we need the accessAs<TY>() template function
#include "lib/test/test-helper.hpp"
//#include "lib/util-foreach.hpp"
//#include "lib/iter-adapter.hpp"
//#include "lib/meta/function.hpp"
@ -148,7 +150,7 @@ namespace engine {
using BuffI = typename _ProcFun<FUN>::BuffI;
using BuffO = typename _ProcFun<FUN>::BuffO;
enum{ N = MAN::inBuff::size()
enum{ N = MAN::STORAGE_SIZ
, FAN_I = _ProcFun<FUN>::FAN_I
, FAN_O = _ProcFun<FUN>::FAN_O
};
@ -166,7 +168,7 @@ namespace engine {
template<typename...INIT>
SimpleFunctionInvocationAdapter (INIT&& ...funSetup)
: FUN{forward<INIT> (funSetup)...}
: process{forward<INIT> (funSetup)...}
{ }
@ -203,6 +205,16 @@ namespace engine {
enum{ MAX_SIZ = N };
std::function<Feed()> buildFeed;
// template<typename INIT>
Conf_DirectFunctionInvocation(FUN fun)
: buildFeed{[=]//procFun = forward<INIT> (fun)]
{
// using URGS = decltype(procFun);
// lib::test::TypeDebugger<URGS> murks;
return Feed{fun};
}}
{ }
};
@ -243,7 +255,7 @@ namespace engine {
attachToLeadPort(ProcNode& lead, uint portNr)
{
PortRef portRef; /////////////////////////////////////OOO TODO need Accessor on ProcNode!!!!!
leadPort.emplace (portRef);
leadPort.append (portRef);
ENSURE (leadPort.size() < N);
return move(*this);
}
@ -259,6 +271,16 @@ namespace engine {
return move(*this);
}
WeavingBuilder
fillRemainingBufferTypes()
{
using FunSpec = _ProcFun<FUN>;
auto constexpr FAN_O = FunSpec::FAN_O;
using BuffO = typename FunSpec::BuffO;
uint cnt = FAN_O - buffTypes.size();
return appendBufferTypes<BuffO>(cnt);
}
WeavingBuilder
selectResultSlot(uint idx)
{
@ -271,10 +293,11 @@ namespace engine {
build()
{
maybeFillDefaultProviders (buffTypes.size());
REQUIRE (providers.size() == buffTypes.size());
uint i=0;
for (auto& typeConstructor : buffTypes)
outTypes.emplace (
typeConstructor (providers[i]));
outTypes.append (
typeConstructor (providers[i++]));
ENSURE (leadPort.size() < N);
ENSURE (outTypes.size() < N);

View file

@ -29,9 +29,11 @@
#include "steam/engine/proc-node.hpp"
#include "steam/engine/node-builder.hpp"
#include "steam/engine/test-rand-ontology.hpp" ///////////TODO
//#include "lib/util.hpp"
#include "lib/test/diagnostic-output.hpp"/////////////////TODO
#include "lib/util.hpp"
using util::isnil;
//using std::string;
@ -74,7 +76,8 @@ namespace test {
.invoke(dummyOp)
.completePort()
.build();
UNIMPLEMENTED ("build render nodes linked into a connectivity network");
CHECK (isnil (con.leads));
CHECK (1 == con.ports.size());
}

View file

@ -8417,9 +8417,7 @@
<icon BUILTIN="button_cancel"/>
<node CREATED="1510365447736" ID="ID_268132850" MODIFIED="1510365460367">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
dann aber als <b>State Monad</b>
@ -8451,9 +8449,7 @@
</node>
<node CREATED="1510366161399" ID="ID_854251162" MODIFIED="1510366222663">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
wende die resultierende State-Monade
@ -8494,9 +8490,7 @@
</node>
<node CREATED="1510446985581" FOLDED="true" HGAP="7" ID="ID_1266495962" MODIFIED="1561827469127" VSHIFT="44">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
alternatives
@ -8527,9 +8521,7 @@
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1510540265979" FOLDED="true" HGAP="17" ID="ID_1160853986" MODIFIED="1561827469147" VSHIFT="26">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Fazit:
@ -8553,9 +8545,7 @@
<node CREATED="1510540740977" ID="ID_1864011655" MODIFIED="1512797263191" TEXT="ersetzt aktuellen Knoten durch seine Kinder"/>
<node CREATED="1510939295181" ID="ID_454143909" MODIFIED="1512797263191">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
das impliziert <i>grunds&#228;tzlich</i>&#160;einen <b>Stack</b>
@ -9228,9 +9218,7 @@
<icon BUILTIN="button_cancel"/>
<node CREATED="1512251214046" ID="ID_1353274464" MODIFIED="1512251270499" TEXT="Konsequenz: alle Layer m&#xfc;ssen StateCore sein">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn wenn mal ein Layer &quot;nur&quot; Iterator w&#228;re,
@ -11357,9 +11345,7 @@
<node CREATED="1513893653949" ID="ID_201919603" MODIFIED="1513893660896" TEXT="Up erfordert Backlink"/>
<node CREATED="1513893682521" ID="ID_1477689037" MODIFIED="1513893811288">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<i>m&#246;glicherwese</i>&#160;aber notwendig
@ -12713,9 +12699,7 @@
<node CREATED="1516910736388" ID="ID_1267411576" MODIFIED="1518487921067" TEXT="Principle of least surprise"/>
<node CREATED="1516910715343" ID="ID_1721041331" MODIFIED="1576282358116" TEXT="sonst default f&#xfc;r den default">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
sonst bekommen wir eine versteckte
@ -13621,9 +13605,7 @@
<icon BUILTIN="idea"/>
<node CREATED="1519359176855" ID="ID_853060191" MODIFIED="1519359192777">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
der <i>Level</i>&#160;im UI ist noch offen
@ -15085,9 +15067,7 @@
<icon BUILTIN="button_ok"/>
<node CREATED="1509143055036" ID="ID_810015478" MODIFIED="1576282358114" TEXT="absichtlich unorthogonal repr&#xe4;sentiert">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...um zu pr&#252;fen, ob das allgemeine Design
@ -81429,7 +81409,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</p>
</body>
</html></richcontent>
<node CREATED="1720220989004" ID="ID_1204792955" MODIFIED="1720220996471" TEXT="linkt den neu definierten Port">
<node CREATED="1720220989004" ID="ID_1204792955" MODIFIED="1728856456964" TEXT="linkt den neu definierten Port">
<arrowlink COLOR="#4225b0" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="-964;48;" ID="Arrow_ID_287970761" STARTARROW="None" STARTINCLINATION="-440;43;"/>
<linktarget COLOR="#5f6184" DESTINATION="ID_1204792955" ENDARROW="Default" ENDINCLINATION="486;31;" ID="Arrow_ID_197971585" SOURCE="ID_346803250" STARTARROW="None" STARTINCLINATION="361;16;"/>
</node>
<node CREATED="1720220997038" ID="ID_1481586771" MODIFIED="1720221137187" TEXT="kehrt dann zum aufrufenden NodeBuilder zur&#xfc;ck">
@ -89466,6 +89447,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="broken-line"/>
</node>
<node COLOR="#435e98" CREATED="1728569398198" ID="ID_1013813267" MODIFIED="1728606967970" TEXT="&#x27f9; das f&#xe4;llt dann der n&#xe4;chst h&#xf6;heren Ebene zu &#x2259; dem PortBuilder">
<arrowlink COLOR="#667ba9" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="73;-4;" ID="Arrow_ID_198065069" STARTARROW="None" STARTINCLINATION="-159;7;"/>
<icon BUILTIN="idea"/>
</node>
</node>
@ -89473,6 +89455,162 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1728575095471" ID="ID_807507393" MODIFIED="1728580412842" TEXT="mu&#xdf; aber auch API-Design bedenken">
<arrowlink COLOR="#507ec8" DESTINATION="ID_1267841334" ENDARROW="Default" ENDINCLINATION="-66;-100;" ID="Arrow_ID_537610685" STARTARROW="None" STARTINCLINATION="-257;20;"/>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1728856264065" ID="ID_647212329" MODIFIED="1728856511042" TEXT="erst im completePort() ggfs fall-back auf 1:1-Verdrahtung">
<linktarget COLOR="#4225b0" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="-964;48;" ID="Arrow_ID_287970761" SOURCE="ID_1204792955" STARTARROW="None" STARTINCLINATION="-440;43;"/>
<linktarget COLOR="#667ba9" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="73;-4;" ID="Arrow_ID_198065069" SOURCE="ID_1013813267" STARTARROW="None" STARTINCLINATION="-159;7;"/>
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728856564010" ID="ID_351253239" MODIFIED="1728856613658" TEXT="Erf&#xfc;llungs-Kriterium">
<icon BUILTIN="forward"/>
<node CREATED="1728856581150" ID="ID_1770028915" MODIFIED="1728856607090" TEXT="alle Slots des InvocationAdapters werden bedient">
<icon BUILTIN="yes"/>
<node CREATED="1728857251364" ID="ID_880125093" MODIFIED="1728857272946" TEXT="FeedManifold::inBuff und outBuff"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728857277871" ID="ID_1643482991" LINK="#ID_174258961" MODIFIED="1728857399366" TEXT="enth&#xe4;lt jeweils ein BuffHandle"/>
</node>
<node CREATED="1728856616380" ID="ID_1508359460" MODIFIED="1728856643102" TEXT="Ausgabe-Slots &#x27f9; brauchen empfangenden Buffer"/>
<node CREATED="1728856644258" ID="ID_61712664" MODIFIED="1728856683944" TEXT="Eingabe-Slots &#x27f9; brauchen Datenversorgung">
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728856766094" ID="ID_276112278" MODIFIED="1728856774433" TEXT="hier ggfs Fehler m&#xf6;glich">
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
<node CREATED="1728857699331" ID="ID_25559479" MODIFIED="1728857849299" TEXT="sp&#xe4;ter zur Invocation dann...">
<icon BUILTIN="info"/>
<node CREATED="1728858252686" ID="ID_232790909" MODIFIED="1728858255148" TEXT="pull">
<node CREATED="1728858262402" ID="ID_807172869" MODIFIED="1728858267263" TEXT="rekursiver call-down"/>
<node CREATED="1728858268443" ID="ID_1337335793" MODIFIED="1728858280841" TEXT="liefert direkt BuffHandle in die FeedManifold"/>
</node>
<node CREATED="1728858291271" ID="ID_1032851869" MODIFIED="1728858294323" TEXT="shed">
<node CREATED="1728858345985" ID="ID_151628152" MODIFIED="1728858540930" TEXT="f&#xfc;r alle outTypes">
<node CREATED="1728858394149" ID="ID_672697263" MODIFIED="1728858485197" TEXT="im jeweilgen Slot liegt ein BufferDescriptor"/>
<node CREATED="1728858486270" ID="ID_134365508" MODIFIED="1728858498129" TEXT="in diesen ist bereits der erwartete Buffer-Typ encodiert"/>
<node CREATED="1728858502500" ID="ID_192657626" MODIFIED="1728858539006" TEXT="ruft lockBuffer() &#x27fc; BuffHandle &#x27f6; in den slot der FeedManifold"/>
</node>
<node CREATED="1728857728456" ID="ID_1108346903" MODIFIED="1728858311859" TEXT="SimpleFunctionInvocationAdapter::connect()">
<node CREATED="1728857749871" ID="ID_571778632" MODIFIED="1728857759068" TEXT="geht blindlings alle seine Slots durch"/>
<node CREATED="1728857760524" ID="ID_1488115240" MODIFIED="1728857824010" TEXT="ruft jeweils im slot: BuffHandle::accessAs&lt;Buffer*&gt;()"/>
<node CREATED="1728857826372" ID="ID_1750707944" MODIFIED="1728857844418" TEXT="&#xfc;bernimmt diesen Pointer in das interne Buffer-Ptr-Array"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728856777992" ID="ID_1457051384" MODIFIED="1728856785965" TEXT="Verdrahtung (fertig) ausf&#xfc;hren">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1728858555925" ID="ID_65764746" MODIFIED="1728858571751" TEXT="was zu leisten ist....">
<node CREATED="1728858604761" ID="ID_790361441" MODIFIED="1728858624320" TEXT="eingangsseitig mu&#xdf; f&#xfc;r jeden Slot eine Lead-Connection bestehen">
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728858628016" ID="ID_303987757" MODIFIED="1728858659791" TEXT="Datentyp mu&#xdf; pasen &#x2014; hier nicht mehr &#xfc;berpr&#xfc;fbar">
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1728858723831" ID="ID_38123688" MODIFIED="1728858886282" TEXT="nur der Build-Vorgang in der Domain-Ontology kann wissen was woher kommt">
<icon BUILTIN="idea"/>
</node>
<node CREATED="1728858668070" ID="ID_1431639114" MODIFIED="1728858931894" TEXT="kann nur noch Anzahl pr&#xfc;fen und fehlende Slots per Lead/default-Port befriedigen">
<node CREATED="1728860974222" ID="ID_1130205156" MODIFIED="1728860983031" TEXT="Ports werden der Reihe nach eingef&#xfc;llt"/>
<node CREATED="1728860984062" ID="ID_322570697" MODIFIED="1728861006719" TEXT="&#x27f9; PortBuilder kann seine eigene Port-Nummer erschlie&#xdf;en"/>
<node CREATED="1728861007944" ID="ID_1830241208" MODIFIED="1728861032180" TEXT="mu&#xdf; aber gespeichert werden, da konfigurierbar"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728858747160" ID="ID_1825558530" MODIFIED="1728858939877" TEXT="Konsequenz &#x27f9; zu wenig Leads bedeutet error::Logic">
<icon BUILTIN="yes"/>
</node>
</node>
<node CREATED="1728858952853" ID="ID_157065776" MODIFIED="1728858971152" TEXT="ausgangsseitig hat der WeavingBuilder ein Array mit Typinfos">
<node CREATED="1728859055657" ID="ID_1509836267" MODIFIED="1728859066657" TEXT="das mu&#xdf; mit Typ-Markern gef&#xfc;llt werden"/>
<node CREATED="1728859075077" ID="ID_708925676" MODIFIED="1728859099002" TEXT="1:1-Verdrahtung hei&#xdf;t hier: den festen Output-Typ einf&#xfc;llen"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728861156109" ID="ID_717078277" MODIFIED="1728861169116" TEXT="den mu&#xdf; daher der PortBuilder ermitteln">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1728861989407" ID="ID_1702195585" MODIFIED="1728862007092" TEXT="konkreter Typ wird erst f&#xfc;r den InvocationAdapter + Manifold ermittelt"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728862023317" ID="ID_82788432" MODIFIED="1728862039191" TEXT="...und der steckt bisher fest verdrahtet im WeavingBuilder">
<icon BUILTIN="broken-line"/>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728861938092" ID="ID_474371188" MODIFIED="1728862042391" TEXT="bisher alles noch zu knapp gehalten">
<arrowlink COLOR="#dd0239" DESTINATION="ID_865228634" ENDARROW="Default" ENDINCLINATION="1738;0;" ID="Arrow_ID_1284493211" STARTARROW="None" STARTINCLINATION="-299;23;"/>
<icon BUILTIN="messagebox_warning"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728862045992" ID="ID_1245289000" MODIFIED="1728862204253" TEXT="Prototyp &#x27f9; erst mal das Type-Binding explizit in den WeavingBuilder aufdoppeln">
<icon BUILTIN="yes"/>
<node CREATED="1728862298588" ID="ID_1483120295" MODIFIED="1728862313310" TEXT="und zwar als Spezialisierung f&#xfc;r die 1:1-Verdrahtung"/>
<node CREATED="1728862314322" ID="ID_21254566" MODIFIED="1728862354792" TEXT="denn hief&#xfc;r m&#xfc;ssen stets alle restlichen Output-Buffer ausgef&#xfc;llt werden"/>
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1728862763793" ID="ID_842556948" MODIFIED="1728862777881" TEXT="Logische Inkonsistenz im Design">
<icon BUILTIN="broken-line"/>
<node CREATED="1728862780842" ID="ID_1335801248" MODIFIED="1728862813235" TEXT="&#xbb;buffer type&#xab; : einerseits ein explizit getypter Pointer"/>
<node CREATED="1728862814218" ID="ID_73032642" MODIFIED="1728862857856" TEXT="&#xbb;buffer type&#xab; : andererseits ein Inlay-Typ, der vom BufferProider in den Buffer konstruiert wird"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728862873502" ID="ID_780472721" MODIFIED="1728862893714" TEXT="TOTAL UNKLAR was &#x201e;die Libraries&#x201c; wirklich brauchen">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1728862945789" ID="ID_1315354060" MODIFIED="1728862967044" TEXT="mutma&#xdf;lich zwei Pattern">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...da es sich um C-Libraries handelt....
</p>
</body>
</html></richcontent>
<node CREATED="1728862969220" ID="ID_1526575552" MODIFIED="1728863006246" TEXT="Quelle / Generator alloziert auch Speicher"/>
<node CREATED="1728863010348" ID="ID_1461256214" MODIFIED="1728863036884" TEXT="Quelle / Vorg&#xe4;nger erwartet einen Speicherblock"/>
</node>
<node CREATED="1728863084211" ID="ID_1367824352" MODIFIED="1728863094410" TEXT="ersteres w&#xe4;re ein ganz erhebliches Problem"/>
<node CREATED="1728863100280" ID="ID_942277652" MODIFIED="1728863115524" TEXT="aber l&#xf6;sbar durch einen smart-Adapter im Buffer">
<icon BUILTIN="ksmiletris"/>
</node>
<node CREATED="1728863117520" ID="ID_1664512933" MODIFIED="1728863132032" TEXT="zweiteres k&#xf6;nnte man auf einen Inlay-Typ abbilden"/>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1728863140155" ID="ID_739905259" MODIFIED="1728863470251" TEXT="Fazit: f&#xfc;r den Prototyp weiterhin mit einem InlayTyp arbeiten">
<linktarget COLOR="#653656" DESTINATION="ID_739905259" ENDARROW="Default" ENDINCLINATION="-69;74;" ID="Arrow_ID_577244058" SOURCE="ID_1241817970" STARTARROW="None" STARTINCLINATION="463;18;"/>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
</node>
</node>
<node COLOR="#338800" CREATED="1728863361338" ID="ID_228239335" MODIFIED="1728863430987" TEXT="damit implementierbar">
<icon BUILTIN="button_ok"/>
</node>
</node>
<node CREATED="1728863381122" ID="ID_1241817970" MODIFIED="1728863470251" TEXT="PortBuilder mu&#xdf; hier vorerst Hilfsfunktion auf WeavingBuilder aufrufen">
<arrowlink COLOR="#653656" DESTINATION="ID_739905259" ENDARROW="Default" ENDINCLINATION="-69;74;" ID="Arrow_ID_577244058" STARTARROW="None" STARTINCLINATION="463;18;"/>
<icon BUILTIN="yes"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1728870351532" ID="ID_228375055" MODIFIED="1728871019335" TEXT="Implementierung(Prototyp)">
<icon BUILTIN="pencil"/>
<node CREATED="1728870363207" ID="ID_695992250" MODIFIED="1728870530894" TEXT="Probleme beim Weitergeben des Typs der Processing-Function">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Unsicherheiten beim Durchreichen des Initialisierers.
</p>
<p>
Das notorische Problem; ich m&#246;chte in der eigentlichen ProcNode keine std::function haben, sondern idealerweise ein Lambda. Aber irgendwo im Turnout mu&#223; ein Prototyp dieses Funktors liegen, von dem wir f&#252;r jeden Aufruf kopieren k&#246;nnen. Das ist kniffelig, wenn der Initialisierer hierf&#252;r durch eine perfect-forwarding-Kette durchgereicht werden soll.
</p>
</body>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728870377629" ID="ID_616326824" MODIFIED="1728870428683" TEXT="Irgendetwas mit der move/realloc-Funktion in lib::SeveralBuilder ist nicht in Ordnung">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
src/lib/several-builder.hpp:327:39: warning: parameter 'src' set but not used [-Wunused-but-set-parameter]
</p>
<p>
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;moveElem (size_t idx, Bucket* src, Bucket* tar)
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728870929451" ID="ID_1740846481" MODIFIED="1728870951984" TEXT="der Gebrauch des BuffHandle::accessAs&lt;TY&gt;() ist zweifelhaft">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1728870953831" ID="ID_1005617048" MODIFIED="1728870963978" TEXT="ich bekomme einen LInker-Fehler"/>
<node CREATED="1728870964942" ID="ID_1694707450" MODIFIED="1728870992248" TEXT="ist n&#xe4;mlich nur im Header buffhandle-attach.hpp definiert"/>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1728870993972" ID="ID_1606733362" MODIFIED="1728871010352" TEXT="warum ist das so? ist das als Extension gedacht?">
<icon BUILTIN="help"/>
</node>
</node>
</node>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1721782550869" ID="ID_173220882" MODIFIED="1721782642416" TEXT="vereinfachtes Aufruf-API: Slots der Reihe nach belegen">
@ -89600,6 +89738,31 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</html></richcontent>
<icon BUILTIN="idea"/>
</node>
<node CREATED="1728861567310" ID="ID_1015927332" MODIFIED="1728861674145" TEXT="&#x27f9; eigentlich m&#xfc;&#xdf;te die Flexibilit&#xe4;t zwischen PortBuilder und WeavingBuilder liegen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...weil es immer mehr darauf hinaus l&#228;uft, da&#223; der PortBuilder die high-level-Sicht auf die Verdrahtung hat, w&#228;hrend der WeavingBuilder von ersterem explizit gesteuert werden mu&#223;
</p>
</body>
</html>
</richcontent>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1728861676015" ID="ID_865228634" MODIFIED="1728861963334" TEXT="da habe ich f&#xfc;r den Prototypen zu stark vereinfacht">
<linktarget COLOR="#dd0239" DESTINATION="ID_865228634" ENDARROW="Default" ENDINCLINATION="1738;0;" ID="Arrow_ID_1284493211" SOURCE="ID_474371188" STARTARROW="None" STARTINCLINATION="-299;23;"/>
<icon BUILTIN="broken-line"/>
</node>
<node CREATED="1728861734053" ID="ID_1720499002" MODIFIED="1728861867336" TEXT="m&#xfc;&#xdf;te das Produkt des WeavingBuilders konfigurierbar machen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...derzeit verwendet der fest eingestellt das SimpleWeavingPattern &#8212; und ebenso eine fest verdrahtete Basis-Konfiguration. Richtig w&#228;re es, entweder mehrere WeavingBuilder-Varianten zu haben, oder &#8212; wenn schon ein einziger WeavingBuilder gen&#252;gt &#8212; diesen nicht nur mit der Funktion zu parametrisieren
</p>
</body>
</html></richcontent>
</node>
</node>
</node>
</node>
</node>
@ -89690,8 +89853,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
siehe <b><font face="Monospaced">TestFrame_test</font></b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="idea"/>
<node CREATED="1728778030637" ID="ID_450784295" MODIFIED="1728778047012" TEXT="hat eine fixierte Gr&#xf6;&#xdf;e von 1k (+Metadata)"/>
<node CREATED="1728777455066" ID="ID_1238676043" MODIFIED="1728777545746" TEXT="Inhalt reproduzierbar, geordnet nach Channel and Seq-No">
@ -89702,8 +89864,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
es gibt nur einen festen Seed-Mechanismus, der auf der Kanal- und Sequenz-Nummer beruht
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728777897375" ID="ID_560401601" MODIFIED="1728777958502">
<richcontent TYPE="NODE"><html>
@ -89713,8 +89874,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
kann Lifecycle markieren als <font color="#563c31">CREATED, EMITTED, DISCARDED</font>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728778080366" ID="ID_1631642281" MODIFIED="1728778216760" TEXT="kann Konsistenz und damit Korruption erkennen"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728777587128" ID="ID_939285679" MODIFIED="1728786873689" TEXT="fehlt bisher">
@ -89733,8 +89893,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
bringt nicht wirklich was, aber zumindest sollte std::random mit kompatiblem Generator verwendet werden
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="button_cancel"/>
</node>
<node CREATED="1728781231984" ID="ID_283829609" MODIFIED="1728781974281" TEXT="w&#xfc;nschenswert">
@ -89750,8 +89909,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Es fehlt ja generell noch ein Framework f&#252;r Zufallswerte in Tests, so da&#223; jeder Test seinen definiten Seed bekommt, welcher zwar normalerweise zuf&#228;llig, ansonsten aber feststellbar und reproduzierbar sein sollte
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728781144210" ID="ID_51267004" MODIFIED="1728781989516" TEXT="Standard Generator-Sequenzen auf jeder Stufe sind unabh&#xe4;ngig hierarchisch">
@ -89762,8 +89920,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Das sind sie bereits in der bestehenden Implementierung, und das Prinzip ist auch bereits gut genug; allerdings sollten wir das Schema von std::random verwenden, d.h. jeweils einen Generator und darauf aufbauend eine Distribution
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="flag-yellow"/>
</node>
</node>
@ -89776,8 +89933,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Das Daten-Array liegt nicht am Anfang, und ist deshalb plattform/implementierungsabh&#228;ngig aligned; das erschwert auch die direkte Interpretation eines Datenblocks als TestFrame....
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1728778765874" ID="ID_1342398369" MODIFIED="1728778778502" TEXT="der Metadatenblock sollte am Ende sein"/>
<node CREATED="1728778790871" ID="ID_92579679" MODIFIED="1728779021706" TEXT="Metadaten sollten optional sein">
@ -89788,8 +89944,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
....und damit sollte man jede beliebige Speicherlocation als Testframe interpretieren k&#246;nnen, ohne diese zu korrumpieren; das impliziert auch, da&#223; der behandelnde Code erkennen kann, ob ein Metadatenblock &#252;berhaupt angelegt wurde &#8212; und wenn das nicht der Fall ist, sollte auch niemals implizit in den Speicher geschrieben werden
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728779023048" ID="ID_1104714285" MODIFIED="1728779233787" TEXT="man sollte die Pr&#xfc;fsumme explizit markieren k&#xf6;nnen">
<richcontent TYPE="NOTE"><html>
@ -89799,8 +89954,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Dabei ist die Pr&#252;fsumme ein verkn&#252;pfter Hash, und man sollte diese jederzeit berechnen k&#246;nnen; jedoch ein regul&#228;r erstellter TestFrame sollte die Pr&#252;fsumme explizit speichern, und auch f&#252;r beliebigen Dateninhalt sollte sich die Pr&#252;fsumme explizit markiern (speichern) lassen, denn damit werden auch weitergehende Berechnungen auf den Daten m&#246;glich, die vom initialen Seed abweichen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728778477601" ID="ID_1156423837" MODIFIED="1728778494727" TEXT="direkter Zugang zu den Daten / Iteration">
@ -89817,8 +89971,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<b>neue Bedeutung</b>: es ist ein TestFrame mit erkennbarem Metadatenblock (auch wenn ansonsten keine der Pr&#252;fsummen mit den Daten zusammenpa&#223;t); es sollte recht unwahrscheinlich sein, da&#223; ein zuf&#228;lliger Datenblock diesen Test besteht.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728779408099" ID="ID_186109727" MODIFIED="1728779644910" TEXT="isValid">
<richcontent TYPE="NOTE"><html>
@ -89828,8 +89981,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Es ist ein TestFrame mit g&#252;ltigem Metadaten-Block, und die dort gespeicherte Pr&#252;fsumme wird durch die Daten best&#228;tigt
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728779415747" ID="ID_135096780" MODIFIED="1728779750157" TEXT="isPristine">
<richcontent TYPE="NOTE"><html>
@ -89839,8 +89991,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
entspricht dem bisherigen isSane() &#8212; d.h. isValid() aber zus&#228;tzlich passen die Daten auf die gespeicherte distinction, und das hei&#223;t, die Daten wurden vom Standard-Schema erzeugt und nicht weiter bearbeitet
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -89880,8 +90031,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</li>
</ul>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -89913,8 +90063,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
...das bedeutet, sie l&#228;uft auf size_t (oder was dann letztlich die Wortbreite sein wird f&#252;r Lumiera Hash-Vorg&#228;nge) und sie ist <b>nicht kommutativ<i>&#160;</i></b>in den Argumenten
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728782252204" ID="ID_757336693" MODIFIED="1728782549197" TEXT="es wird ein uniformer Seed-Wert f&#xfc;r jeden Datenpunkt mit injiziert">
<richcontent TYPE="NOTE"><html>
@ -89924,8 +90073,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Jeder Funktionsaufruf ist &#8222;gef&#228;rbt&#8220;, aber ansonsten &#228;quivalent. Das hei&#223;t, ein fester Parameterwert flie&#223;t mit in die Berechnung jedes einzelnen Datenpunktes, und dieser Wert ist an den jeweiligen Aufruf gebunden wird, wodurch auch eine Kette gleichartiger Aufrufe in der Reihenfolge unterscheidbar gemacht werden kann.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728782874164" ID="ID_1997651851" MODIFIED="1728783179058" TEXT="dieser Seed, zusammen mit den Kenndaten, bildet eine reproduzierbare Identit&#xe4;t">
<richcontent TYPE="NOTE"><html>
@ -89935,8 +90083,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
...zwar handelt es sich stets nur um eine Hash-Verkn&#252;pfung, aber die Arit&#228;t (und ggfs. sp&#228;ter auch noch ein Array-Wertiger Input) kommen als Steuerparameter hinzu. Diese Parameter k&#246;nnen als lesbarer Spec-String ausgegeben werden, und in einen Hash eingerechnet werden, der dann die Funktion markiert und unterscheidbar macht. Wenn ein Seed explizit angegeben wird, dann flie&#223;t er zus&#228;tzlich mit ein, und markiert au&#223;erdem auch die Berechnung an jedem Datenpunkt
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728783188923" ID="ID_1138350224" MODIFIED="1728783420787" TEXT="der Seed k&#xf6;nnte sp&#xe4;ter wie ein Automations-Parameterwert eingebracht werden">
<richcontent TYPE="NOTE"><html>
@ -89946,8 +90093,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
...sp&#228;ter, wenn ich abschlie&#223;end gekl&#228;rt habe, wie Automation funktionieren soll. Derzeit denke ich, da&#223; solche Funktions-Parameter in einem Tree-walk vor dem eigentlichen pull() der Invocation gesetzt werden, also &#252;ber das Turnout-System. Speziell f&#252;r die Test-Ontology k&#246;nnte man hier auch eine Node-ID oder einen Node-Struktur-Hash einflie&#223;en lassen (wobei mit jetzt aber nicht klar ist, ob diese Idee f&#252;r das Testen &#252;berhaupt von Nutzen ist)
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node CREATED="1728782162715" ID="ID_647461586" MODIFIED="1728783566268" TEXT="Berechnung unabh&#xe4;ngig pro Datenpunkt">
@ -89958,8 +90104,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Ich will also eine laterale Vermischung der Daten vermeiden; erst &#252;ber die Pr&#252;fsumme des Ergebnis-Datenblocks werden die einzelnen Datenpunkte zusammengef&#252;hrt; theoretisch w&#228;re es dadurch sogar m&#246;glich, die Korruption einzelner Datenpunkte zu erkennen, indem man die intendierte Berechnungskette explizit gecodet nochmal ausf&#252;hrt und dann die Ergebnisdaten vergleicht.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728783585707" ID="ID_288581450" MODIFIED="1728783674793" TEXT="f&#xfc;r jede Berechnung gibt es eine human-readable spec">
<richcontent TYPE="NOTE"><html>
@ -89982,8 +90127,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
d.h. das EventLog liegt in einem Singleton, und wenn es da ist, dann hinterl&#228;&#223;t jeder Funktionsaufruf einen Log-Eintrag, so da&#223; sich der gesamte Berechnungsweg mit allen Aufruf-Reihenfolgen nachvollziehen und verifizieren l&#228;&#223;t
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -90006,10 +90150,10 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="ksmiletris"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785768422" ID="ID_1775907930" MODIFIED="1728785783907" TEXT="ProcNode als Ergebnis bekommen">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785768422" ID="ID_1775907930" MODIFIED="1728836959981" TEXT="Connectivity als Ergebnis bekommen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785785350" ID="ID_1997976250" MODIFIED="1728785795791" TEXT="1:1-Verdrahtung durchf&#xfc;rhen">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785785350" ID="ID_1997976250" MODIFIED="1728785795791" TEXT="1:1-Verdrahtung durchf&#xfc;hren">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
@ -90017,6 +90161,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="hourglass"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785829235" ID="ID_59153641" MODIFIED="1728785837551" TEXT="Zahl der Leads / Ports">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1728837023895" ID="ID_605946582" MODIFIED="1728837031771" TEXT="auf Connectivity direkt zug&#xe4;nglich"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785840998" ID="ID_663732870" MODIFIED="1728785852800" TEXT="Funktions-ID generieren">
<icon BUILTIN="flag-yellow"/>