benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Invocation: define aspects of ProcID to cover

Browse source 
Building a correct processing-identification is a complex and challenging task; only some aspects can be targeted and implemented right now, as part of the »Playback Vertical Slice«
 * components of the ProcID
 * parsing the argument-spec
 * dispatch of detail information function to retrieve source ports
This commit is contained in:
Fischlurch 2025-01-11 17:05:53 +01:00
parent abeca98233
commit 6207f475eb
5 changed files with 199 additions and 91 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
src/lib/fun-hash-dispatch.hpp
View file

@ -14,7 +14,17 @@
/** @file fun-hash-dispatch.hpp
** Service to register and dispatch opaque functions.
** Under the hood, the implementation is a hash table holding function pointers.
** An instance is thus always tied to one specific function signature. Yet due
** to the implicit conversion, simple capture-less λ can be attached as well.
**
** The purpose for such a setup is to provide a simple per-signature backend for
** some advanced registration scheme involving specific function patterns. The
** hash-IDs may be tied to target properties, which sometimes allows to limit
** the number of actual functions in the dispatcher tables and can thus be
** superior to a classic OO interface when subclasses would be templated.
** @see FunHashDispatch_test
** @see proc-id.hpp "usage example"
*/
@ -25,26 +35,17 @@
#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "lib/hash-value.h"
#include "lib/meta/function.hpp"
#include "lib/util.hpp"
//#include <boost/functional/hash.hpp>
#include <unordered_map>
//#include <cstddef>
//#include <functional>
namespace lib {
namespace {// implementation details
/** @internal mix-in for self-destruction capabilities
*/
}//(End)implementation details
/************************************************//**
/**
* Dispatcher-table for state-less functions with a given signature.
* Entries are keyed by hashID and can not be changed, once entered.
*/
template<class SIG>
class FunHashDispatch
@ -67,6 +68,7 @@ namespace lib {
return util::contains (dispatchTab_, key);
}
/** retrieve entry, which can be invoked directly */
SIG*
select (HashVal key)
{

6
src/steam/engine/proc-node.cpp
View file

@ -26,7 +26,7 @@
#include "lib/format-util.hpp"
#include "lib/util.hpp"
#include <boost/functional/hash.hpp>
#include <boost/functional/hash.hpp> /////////////////////////////////////////////////////TICKET #1391 is boost-hash the proper tool for this task?
#include <unordered_set>
#include <set>
@ -104,9 +104,9 @@ namespace engine {
HashVal
hash_value (ProcID const& procID)
{
HashVal hash = boost::hash_value (procID.nodeSymb_);
HashVal hash = boost::hash_value (procID.nodeSymb_); ///////////////////////////////////////////////////TICKET #1391 : which technology to use for processing-ID hashes -> cache keys?
if (not isnil(procID.portQual_))
hash_combine (hash, procID.portQual_);
hash_combine (hash, procID.portQual_); ////////////////////////////////////////////////////////TICKET #1391 : should use lib/hash-combine.hpp (stable, but not portable!)
hash_combine (hash, procID.argLists_);
return hash;
}

97
tests/core/steam/engine/node-meta-test.cpp
View file

@ -17,10 +17,16 @@
#include "lib/test/run.hpp"
#include "steam/engine/proc-node.hpp"
#include "steam/engine/node-builder.hpp"
//#include "steam/engine/test-rand-ontology.hpp" ///////////TODO
#include "lib/test/diagnostic-output.hpp"/////////////////TODO
//#include "lib/util.hpp"
#include <cmath>
//using std::string;
using std::abs;
namespace steam {
@ -35,10 +41,95 @@ namespace test {
*/
class NodeMeta_test : public Test
{
virtual void run(Arg)
virtual void
run (Arg)
{
UNIMPLEMENTED ("render node pulling source data from vault");
}
verify_ID_specification();
verify_ID_properties();
}
/** @test TODO evaluation of processing-spec for a ProcID
* @todo WIP 1/25 🔁 define ⟶ implement
*/
void
verify_ID_specification()
{
auto& p1 = ProcID::describe("N1","(arg)");
auto& p2 = ProcID::describe("N1","(a1,a2)");
auto& p3 = ProcID::describe("N1","(in/3)(o1,o2/2)");
UNIMPLEMENTED ("parse and evaluate");
}
/** @test TODO aspects of node definition relevant for the ProcID
* @todo WIP 1/25 🔁 define ⟶ implement
*/
void
verify_ID_properties()
{
// This operation emulates a data source
auto src_opA = [](int param, int* res) { *res = param; };
auto src_opB = [](ulong param, ulong* res){ *res = param; };
// A Node with two (source) ports
ProcNode nA{prepareNode("srcA")
.preparePort()
.invoke("a(int)", src_opA)
.setParam(5)
.completePort()
.preparePort()
.invoke("b(int)", src_opA)
.setParam(23)
.completePort()
.build()};
// A different Node with three ports
ProcNode nB{prepareNode("srcB")
.preparePort()
.invoke("a(ulong)", src_opB)
.setParam(7)
.completePort()
.preparePort()
.invoke("b(ulong)", src_opB)
.setParam(13)
.completePort()
.preparePort()
.invoke("c(ulong)", src_opB)
.setParam(17)
.completePort()
.build()};
// This operation emulates fading of two source chains
auto fade_op = [](double mix, tuple<int*,ulong*> src, uint64_t* res)
{
auto [srcA,srcB] = src;
*res = uint64_t(abs(*srcA * mix + (1-mix) * int64_t(*srcB)));
};
// Wiring for the Mix, building up three ports
// Since the first source-chain has only two ports,
// for the third result port we'll re-use the second source
ProcNode nM{prepareNode("fade")
.preparePort()
.invoke("A_mix(int,ulong)(uint64_t)", fade_op)
.connectLead(nA)
.connectLead(nB)
.completePort()
.preparePort()
.invoke("B_mix(int,ulong)(uint64_t)", fade_op)
.connectLead(nA)
.connectLead(nB)
.completePort()
.preparePort()
.invoke("C_mix(int,ulong)(uint64_t)", fade_op)
.connectLeadPort(nA,1)
.connectLead(nB)
.setParam(0.5)
.completePort()
.build()};
UNIMPLEMENTED ("verify connectivity");
}
};

22
tests/library/fun-hash-dispatch-test.cpp
View file

@ -33,26 +33,17 @@
namespace lib {
namespace test{
// using util::isSameAdr;
// using std::rand;
using util::toString;
using std::string;
// namespace error = lumiera::error;
// using error::LUMIERA_ERROR_FATAL;
// using error::LUMIERA_ERROR_STATE;
namespace {
// #define Type(_EXPR_) lib::test::showType<decltype(_EXPR_)>()
}
using util::toString;
/***********************************************************************************//**
* @test Verify generic helper to provide a hash-based function dispatch table.
* - instances are tied to one specific function signature
* - entries are keyed by a hash-ID
* - given that ID, the registered functions can be invoked
* - once enrolled, entries can not be replaced
* @see fun-hash-dispatch.hpp
* @see NodeMeta_test
*/
@ -71,15 +62,12 @@ namespace test{
auto* res = dispatch.enrol (1, one);
CHECK (res == one);
CHECK (dispatch.contains(1));
SHOW_EXPR(dispatch.select(1)(42));
CHECK (dispatch.select(1)(42) == "42"_expect);
dispatch.enrol (2, two);
CHECK (dispatch.contains(1));
CHECK (dispatch.contains(2));
SHOW_EXPR(dispatch.select(1)(5));
CHECK (dispatch.select(1)(5) == "5"_expect);
SHOW_EXPR(dispatch.select(2)(5));
CHECK (dispatch.select(2)(5) == "*****"_expect);
res = dispatch.enrol (1,two);

139
wiki/thinkPad.ichthyo.mm
View file

@ -98903,9 +98903,9 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<linktarget COLOR="#d10172" DESTINATION="ID_1540010113" ENDARROW="Default" ENDINCLINATION="-473;38;" ID="Arrow_ID_1593223212" SOURCE="ID_1980325374" STARTARROW="None" STARTINCLINATION="-242;0;"/>
<icon BUILTIN="flag-yellow"/>
<node CREATED="1736267197593" ID="ID_782732599" MODIFIED="1736267203116" TEXT="watch(Node)">
<node CREATED="1736267212093" ID="ID_175731942" MODIFIED="1736267280092" TEXT="verify_connected(Node&amp;, lead#)"/>
<node CREATED="1736267281885" ID="ID_1401668777" MODIFIED="1736267334900" TEXT="verify_connectedPort(Node&amp;, port#, input#)">
<arrowlink COLOR="#ffe4bc" DESTINATION="ID_1514661165" ENDARROW="Default" ENDINCLINATION="100;-5;" ID="Arrow_ID_792010004" STARTARROW="None" STARTINCLINATION="110;7;"/>
<node CREATED="1736267212093" ID="ID_175731942" MODIFIED="1736605536267" TEXT="verify_connected(lead#, Node&amp;)"/>
<node CREATED="1736267281885" ID="ID_1401668777" MODIFIED="1736605547858" TEXT="verify_connectedPort(port#, input#, Node&amp;)">
<arrowlink COLOR="#ffe4bc" DESTINATION="ID_1514661165" ENDARROW="Default" ENDINCLINATION="100;-5;" ID="Arrow_ID_792010004" STARTARROW="None" STARTINCLINATION="77;5;"/>
</node>
</node>
</node>
@ -98926,9 +98926,9 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<icon BUILTIN="flag-yellow"/>
<node CREATED="1736267134171" ID="ID_145839768" MODIFIED="1736267142436" TEXT="watch(Port)">
<node CREATED="1736267174444" ID="ID_1548126776" MODIFIED="1736267185084" TEXT="andocken per Template-Spezialisierung"/>
<node CREATED="1736267024072" ID="ID_1514661165" MODIFIED="1736267328034" TEXT="verify_connected(port, input#)">
<linktarget COLOR="#ffe4bc" DESTINATION="ID_1514661165" ENDARROW="Default" ENDINCLINATION="100;-5;" ID="Arrow_ID_792010004" SOURCE="ID_1401668777" STARTARROW="None" STARTINCLINATION="110;7;"/>
<linktarget COLOR="#fdf9be" DESTINATION="ID_1514661165" ENDARROW="Default" ENDINCLINATION="-429;42;" ID="Arrow_ID_1746815334" SOURCE="ID_1677497952" STARTARROW="None" STARTINCLINATION="-358;-43;"/>
<node CREATED="1736267024072" ID="ID_1514661165" MODIFIED="1736605602244" TEXT="verify_connected(input#, Port&amp;)">
<linktarget COLOR="#ffe4bc" DESTINATION="ID_1514661165" ENDARROW="Default" ENDINCLINATION="100;-5;" ID="Arrow_ID_792010004" SOURCE="ID_1401668777" STARTARROW="None" STARTINCLINATION="77;5;"/>
<linktarget COLOR="#fdf9be" DESTINATION="ID_1514661165" ENDARROW="Default" ENDINCLINATION="-451;40;" ID="Arrow_ID_1746815334" SOURCE="ID_1677497952" STARTARROW="None" STARTINCLINATION="-358;-43;"/>
</node>
</node>
</node>
@ -99621,8 +99621,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
jedes <b>konkrete</b>&#160;Projekt hat seine eigene <i>koh&#228;rente </i>Domain Ontology
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head/>
<body>
@ -99630,8 +99629,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
Das folgt unter den Annahme, da&#223; ein konkretes Projekt <i>funktionieren mu&#223;.</i>&#160;Also macht man nur Dinge, die koh&#228;rent aufgehen. F&#252;r Zweideutigkeiten findet man eine praktische Konvention, oder man wei&#223; sie unsichtbar zu machen. Daher sollte dieses Problem f&#252;r jedes konkrete Projekt in dem Sinn &#187;l&#246;sbar&#171; sein, da&#223; die Cache-Steuerung fehlerfrei funktioniert. Der Beitrag der Lumiera-Infrastruktur dazu ist, f&#252;r die notwendige &#220;ber-Differenzierung zu sorgen, so da&#223; es niemals zu einer Kollision kommen kann zwischen Beitr&#228;gen, welche in disjunkten Libraries und Domain-Ontologies verankert sind.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -99668,14 +99666,14 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</html></richcontent>
</node>
</node>
<node CREATED="1736266569293" ID="ID_1677497952" MODIFIED="1736267148969" TEXT="Idee: verify-connected-to">
<arrowlink COLOR="#fdf9be" DESTINATION="ID_1514661165" ENDARROW="Default" ENDINCLINATION="-429;42;" ID="Arrow_ID_1746815334" STARTARROW="None" STARTINCLINATION="-358;-43;"/>
<node CREATED="1736266569293" ID="ID_1677497952" MODIFIED="1736605602244" TEXT="Idee: verify-connected-to">
<arrowlink COLOR="#fdf9be" DESTINATION="ID_1514661165" ENDARROW="Default" ENDINCLINATION="-451;40;" ID="Arrow_ID_1746815334" STARTARROW="None" STARTINCLINATION="-358;-43;"/>
<icon BUILTIN="idea"/>
<node CREATED="1736266601561" ID="ID_1764393519" MODIFIED="1736266615731" TEXT="sollte als ein Test-Tool bereitgestellt werden"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736266726272" ID="ID_1019914793" MODIFIED="1736266743347" TEXT="brauche daf&#xfc;r eine Erweiterung des Port-API">
<arrowlink COLOR="#4431d1" DESTINATION="ID_817734322" ENDARROW="Default" ENDINCLINATION="-13;-173;" ID="Arrow_ID_507508399" STARTARROW="None" STARTINCLINATION="33;335;"/>
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736266763928" ID="ID_1486436213" MODIFIED="1736454774708" TEXT="getInput(n) &#x27fc; optional&lt;PortRef&gt;">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736266763928" ID="ID_1486436213" MODIFIED="1736605288823" TEXT="getInput(n) &#x27fc; optional&lt;PortRef&gt;">
<linktarget COLOR="#e5296f" DESTINATION="ID_1486436213" ENDARROW="Default" ENDINCLINATION="-752;56;" ID="Arrow_ID_351949496" SOURCE="ID_1002392068" STARTARROW="None" STARTINCLINATION="-733;0;"/>
<icon BUILTIN="flag-yellow"/>
</node>
@ -99702,8 +99700,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
um mit einer solchen Spezialisierung zu binden?
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1736388060166" HGAP="40" ID="ID_551338912" MODIFIED="1736388127948" TEXT="nur das Turnout-Template" VSHIFT="19"/>
<node CREATED="1736388156515" HGAP="35" ID="ID_243958612" MODIFIED="1736388169999" TEXT="oder der Builder der letzteres instantiiert"/>
@ -99717,8 +99714,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
L&#246;sung: per <b>Registrierung</b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<node CREATED="1736368318390" ID="ID_309182364" MODIFIED="1736368394321" TEXT="man kann Eindeutigkeit der Proc-ID unsterstellen / fordern">
<arrowlink COLOR="#63707f" DESTINATION="ID_1883362448" ENDARROW="Default" ENDINCLINATION="340;36;" ID="Arrow_ID_1842367707" STARTARROW="Default" STARTINCLINATION="-162;-10;"/>
<icon BUILTIN="yes"/>
@ -99733,8 +99729,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
...wegen <b>Template bloat</b>. Umso schlimmer, wenn diese Funktionen dann fast nur von Unit-Tests genutzt werden. Aber selbst eine einzige zus&#228;tzliche Funktion f&#252;r einen Hash oder konkreten Descriptor w&#252;rde ich gerne vermeiden wollen, denn man generiert zwangsl&#228;ufig eine gro&#223;e Menge redundanten codes, der vermutlich niemals aufgerufen wird (was man aber nie wissen kann...)
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1736389015376" ID="ID_1735379863" MODIFIED="1736390311555" TEXT="dieser Hebel lie&#xdf;e sich entsch&#xe4;rfen wenn viele F&#xe4;lle f&#xfc;r die Diagnostik zusammenfallen">
<richcontent TYPE="NOTE"><html>
@ -99744,8 +99739,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
Man w&#252;rde also ein System von Hash-IDs aufbauen, und dann w&#252;rde jede Instanz des Turnout-Template bei der Generierung noch entsprechende Handler f&#252;r die Diagnostik-Funktionen regisrieren. Allerdings nur, wenn die Funktion nicht bereits existiert. Dieser Ansatz w&#252;rde darauf spekulieren, da&#223; die meisten Diagnostik-Funktionen gar nicht anhand der konkreten Buffer- und Parameter-Typen differenziert sind. Beispielswese Funktionen, die auf Vorg&#228;nger-Ports zugreifen, m&#252;ssen nur die Beschr&#228;nkung auf die Anzahl der Vorg&#228;nger beachten. Aus der Processing-Spec, welche ja exakt den ausreichenden Differenzierungsgrad haben mu&#223; (sonst funktioniert das Caching nicht richtig) lie&#223;e sich ein Sub-Key f&#252;r bestimmte Klassen von Diagnostik-Zugriffen gewinnen. Dieser w&#252;rde dann ein Diagnostic-Objekt aus einer Hashtable holen (was dadurch dedupliziert w&#228;re).
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1736390313779" ID="ID_322453639" MODIFIED="1736390332955" TEXT="das Konzept lie&#xdf;e sich ziemlich weit treiben...">
<node CREATED="1736390333991" ID="ID_745167219" MODIFIED="1736390350368" TEXT="auch f&#xfc;r Erweiterungs-Funktionalit&#xe4;t jenseits von Diagnostik"/>
@ -99757,8 +99751,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
...das w&#228;re durchaus denkbar f&#252;r &#187;operational control&#171;, wenn es um spezielle Instrumentierung geht, also detailierte Zeitmessungen aufgezeichnet werden m&#252;ssen, die sich nicht &#252;ber einen einzigen Kamm scheren lassen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1736390427435" ID="ID_1001722813" MODIFIED="1736390454771" TEXT="k&#xf6;nnte man sogar mit &#xbb;LazyInit&#xab;-&#x3bb; verbinden">
<node CREATED="1736390456927" ID="ID_1577041072" MODIFIED="1736390512464" TEXT="naja... damals war das eine Notl&#xf6;sung, weil ich mich im Design verrannt habe">
@ -99769,8 +99762,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
...aber immerhin habe ich mich damals so nobel geschlagen, da&#223; ich daraus noch eine generische Library-Funktion gemacht habe, was mir jetzt zugute kommen k&#246;nnte
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1736390513879" ID="ID_960263292" MODIFIED="1736390575059" TEXT="zur Erinnerung: das kann ein einmal-Init-&#x3bb; hinterlegen, welches sich dann selbst umkoppelt"/>
<node CREATED="1736390620897" ID="ID_185030337" MODIFIED="1736390629659" TEXT="Vorraussetzung ist std::function als Front-End">
@ -99799,8 +99791,8 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<linktarget COLOR="#4431d1" DESTINATION="ID_817734322" ENDARROW="Default" ENDINCLINATION="-13;-173;" ID="Arrow_ID_507508399" SOURCE="ID_1019914793" STARTARROW="None" STARTINCLINATION="33;335;"/>
<icon BUILTIN="info"/>
<node CREATED="1736433458484" ID="ID_196820134" MODIFIED="1736433468453" TEXT="ID-Anteile">
<node CREATED="1736433469774" ID="ID_1116337144" MODIFIED="1736433473473" TEXT="procName"/>
<node CREATED="1736433474506" ID="ID_307816036" MODIFIED="1736433477555" TEXT="procSpec"/>
<node COLOR="#435e98" CREATED="1736433469774" ID="ID_1116337144" MODIFIED="1736605160936" TEXT="procName"/>
<node COLOR="#435e98" CREATED="1736433474506" ID="ID_307816036" MODIFIED="1736605160936" TEXT="procSpec"/>
<node CREATED="1736433553250" ID="ID_1633133909" MODIFIED="1736433559725" TEXT="durch Parsen zug&#xe4;nglich">
<node CREATED="1736433561025" ID="ID_1814273505" MODIFIED="1736433564605" TEXT="Fan-in"/>
<node CREATED="1736433566073" ID="ID_1536576559" MODIFIED="1736433570315" TEXT="Fan-out"/>
@ -99828,8 +99820,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
Und das <i>mu&#223; auch so sein,</i>&#160;denn sonnst w&#228;re das kein freier Extension-Point. Jede Abweichung davon bedeutet effektiv eine Einschr&#228;nkung der Implementierung &#8212; oder anders ausgedr&#252;ckt, eine Erweiterung des Port-Interfaces. Das w&#228;re durchaus denkbar; hier geht es allerdings um den sekund&#228;ren Belang, wie man eine solche Erweiterung mit m&#246;glichst geringen Kosten realisiert
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1736434939874" ID="ID_606745199" MODIFIED="1736434947980" TEXT="M&#xf6;glichkeiten einer API-Erweiterung">
<node CREATED="1736434971612" ID="ID_584172400" MODIFIED="1736436108981" TEXT="KISS! Port::getLeadPorts() &#x27fc; Several&lt;PortRef&gt; const&amp;">
@ -99851,8 +99842,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
Vorschlag w&#228;re eine Klasse PortConnectivity, und eine Alternative als ProxyPort. Davon k&#246;nnten dann die beiden (derzeit definierten) generischen Weaving-Patterns erben. Dadurch w&#228;re dann eine uniforme Implementierung f&#252;r gewisse Verhaltensmuster m&#246;glich, ohne f&#252;r jede Detail-Typisierung erneut Code generieren zu m&#252;ssen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="full-2"/>
</node>
<node CREATED="1736435474840" ID="ID_15264427" MODIFIED="1736518637003" TEXT="Spec+extended-Attributes in ProcID heranziehen">
@ -99887,8 +99877,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
Egal ob der Compiler de-Duplizieren <i>k&#246;nnte</i>&#160;&#8212; wir machen es einfach explizit: Die jeweilige Basisklasse d&#252;rfte dann aber keine Abh&#228;ngikgeit von Template-Parametern haben &#10233; f&#252;r die beiden bisher definierten F&#228;lle w&#228;re komplette de-Duplikation so realisierbar. Der <b>Preis </b>daf&#252;r w&#228;re aber leider eine deutliche Verschlechterung der Lesbarkeit im Weaving-Pattern selber; nicht nur da&#223; man nun eine Basisklasse &#8222;im Kopf haben&#8220; m&#252;&#223;te, zudem w&#228;ren dann alle Zugriffe auf diese Basis-Parameter mit dem self-Typ im Code zu qualifizieren. Deswegen habe ich eine <b>starke Abneigung </b>gegen&#252;ber dieser L&#246;sung. Es ist der typische <i>Pragmatismus, </i>der den Code f&#252;r alle nachfolgende Wartung und Erweiterung versaut....
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="full-2"/>
</node>
<node CREATED="1736436883609" ID="ID_639002268" MODIFIED="1736439310634" TEXT="erweiterte Storage in der ProcID &#x2014; und ein spezielles Spezifikations-Schema">
@ -99927,8 +99916,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
...wenn es allerdings <i>nur darum ginge,</i>&#160;(also um die Cache-keys), k&#246;nnte man genauso gut eine HashID direkt in die ProcID legen (die ja ohnehin embedded im Port liegt). Ich spekuliere also schon explizit auf das Einspar-Potential durch <i>zus&#228;tzliche Operationen...</i>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1736439705211" ID="ID_1190879993" MODIFIED="1736439967823" TEXT="den computation-overhead halte ich f&#xfc;r vertretbar">
<richcontent TYPE="NOTE"><html>
@ -99938,8 +99926,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
Aktuell geht es nur um Zusatz-Operationen, die rein f&#252;r das Testing gebraucht werden; deshalb sollte auch &#252;ber einen Lazy-Init-Ansatz nochmal nachgedacht werden. L&#228;ngerfristig kommen Aufgaben f&#252;r Instrumentierung und Job-Planung hinzu. Diese laufen nicht in der innersten, hoch-performanten Zone. Man sollte das Thema trotzdem im Auge behalten; m&#246;glicherweise kann man Ergebniswerte f&#252;r einen ganzen Render-Chain in der Exit-Node als Abk&#252;rzung speichern, und so die re-Traversierung einsparen.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -102296,8 +102283,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
zum Einen ist das komplex, und au&#223;erdem birgt es die Gefahr der Korruption durch Updates
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node CREATED="1736455424795" ID="ID_1408873676" MODIFIED="1736518472498" TEXT="dedizierter Record-Datentyp">
@ -102310,8 +102296,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
keine <i>offene</i>&#160;L&#246;sung
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head/>
<body>
@ -102319,8 +102304,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
eine &#187;offene&#171; L&#246;sung w&#252;rde einer Erweiterung von Lumiera (plug-in) oder einer speziellen Library-Integration erm&#246;glichen, Attribute durch das low-level-Model hindurch zu &#187;tunneln&#171;, ohne spezielle Unterst&#252;tzung der Core-Implementierung. Ich halte das jedoch aktuell f&#252;r einen <i>nicht naheliegenden</i>&#160;Ansatz, da es keinen &#187;R&#252;ck-Kanal&#171; vom low-level-Model in die Erweiterungen/Plug-ins gibt; generell hat sich das low-level-Model zu einer internen Struktur entwickelt und kann nicht verstanden werden ohne implizite Kenntnis mancher Entwicklungs-Aspekte
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<arrowlink COLOR="#fb5e7e" DESTINATION="ID_1088588114" ENDARROW="Default" ENDINCLINATION="-92;0;" ID="Arrow_ID_1027084112" STARTARROW="None" STARTINCLINATION="235;29;"/>
</node>
<node CREATED="1736455489427" ID="ID_1526693708" MODIFIED="1736455499618" TEXT="maximal effizient und verst&#xe4;ndlich"/>
@ -102346,8 +102330,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
Normalerweise verwendet man die klassischen OO-Interfaces (oder einen generischen aber getypten Kontext) auch grade dazu, die passenden Voraussetzungen durch einen Kontrakt sicherzustellen. Das ganze Unterfangen hier aber umgeht Interfaces und Kontrakt, um die Kosten daf&#252;r einzusparen. Stattdessen hinterlegen wir einen Direkt-Zugangsschl&#252;ssel, der ohne Pr&#252;fung angewendet wird.....
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#ebcdab" COLOR="#690f14" CREATED="1736517263411" ID="ID_1602655252" MODIFIED="1736518225536" TEXT="verwendete ID-Features m&#xfc;ssen zur Funktionalit&#xe4;t auf der Anwendungsseite passen">
<richcontent TYPE="NOTE"><html>
@ -102357,8 +102340,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
...also ist der einzige Schutz, den Schl&#252;ssel inhaltlich korrekt an die Features der ID zu binden. Diese Bindung ist aber nicht formal-logisch, sondern f&#252;r eine bestimmte Intention vorkonfiguriert; ob diese Zuordnung korrekt ist und zu einem validen Aufruf f&#252;hrt, h&#228;ngt allein daran, da&#223; bei der Erstellung die dazu passenden Merkmale in der ID hinterlegt wurden. Da diese Klassifikation zusammen mit der Registrierung der Funktion erfolgt, ist diese Verbindung so sicher wie die Logik, die bei der Registrierung zum Tragen kommt. Das hei&#223;t, wenn es &#8212; bedingt durch eine L&#252;cke im logischen Argument &#8212; zur Registrierung zweier inkompatibler Funktionen unter der gleichen ID kommen k&#246;nnte, gibt es keinen weiteren Schutzmechanismus mehr
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="clanbomber"/>
</node>
<node CREATED="1736517299722" ID="ID_836268742" MODIFIED="1736517316271">
@ -102369,8 +102351,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
der Aufruf ist ein <b>blinder cast</b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
@ -102384,8 +102365,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
...weil eine offene L&#246;sung zwar ohne Weiteres m&#246;gilch w&#228;re, aber mit erheblich gr&#246;&#223;erem Storage-Overhead einhergeht, der sich dann erst mal durch de-Duplikation amortisieren m&#252;&#223;te. Daher sage ich erst einmal YAGNI!&#160;&#160;und realisiere die einfache L&#246;sung mit direkter Kollaboration, deren Overhead und Amortisierung leicht absch&#228;tzbar ist
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<linktarget COLOR="#fb5e7e" DESTINATION="ID_1088588114" ENDARROW="Default" ENDINCLINATION="-92;0;" ID="Arrow_ID_1027084112" SOURCE="ID_875438649" STARTARROW="None" STARTINCLINATION="235;29;"/>
<icon BUILTIN="yes"/>
</node>
@ -102395,15 +102375,19 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736453873367" ID="ID_393745699" MODIFIED="1736453888482" TEXT="Dispatcher-Tables einrichten und bereitstellen">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1736564846036" ID="ID_991521203" MODIFIED="1736564860605" TEXT="Storage und Anordnung">
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1736564846036" ID="ID_991521203" MODIFIED="1736604103097" TEXT="Storage und Anordnung">
<icon BUILTIN="pencil"/>
<node COLOR="#5b280f" CREATED="1736564861858" ID="ID_966735363" MODIFIED="1736564872849" TEXT="erste Idee: statisch per Typ">
<icon BUILTIN="button_cancel"/>
<node CREATED="1736564888749" ID="ID_791051561" MODIFIED="1736564893537" TEXT="ist zwar pfiffig"/>
<node CREATED="1736564894477" ID="ID_1331364315" MODIFIED="1736564906159" TEXT="aber sp&#xe4;ter schwer zu handhaben"/>
<node CREATED="1736564907586" ID="ID_1394350344" MODIFIED="1736564919405" TEXT="irgendwie vermische ich jetzt die Ebenen"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1736564923289" ID="ID_1370096372" MODIFIED="1736564943079" TEXT="besser eine dedizierte HIlfskomponente verwenden">
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1736564923289" ID="ID_1370096372" MODIFIED="1736604034106" TEXT="besser eine dedizierte HIlfskomponente verwenden">
<icon BUILTIN="yes"/>
<node COLOR="#5011eb" CREATED="1736604040268" ID="ID_1751891794" MODIFIED="1736604075748" TEXT="lib::FunHashDispatch&lt;SIG&gt;">
<font NAME="Monospaced" SIZE="12"/>
</node>
</node>
</node>
</node>
@ -102418,7 +102402,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<arrowlink COLOR="#ce3644" DESTINATION="ID_1160836625" ENDARROW="Default" ENDINCLINATION="75;-69;" ID="Arrow_ID_298743045" STARTARROW="None" STARTINCLINATION="-76;15;"/>
<icon BUILTIN="yes"/>
</node>
<node CREATED="1736454504668" ID="ID_1002392068" MODIFIED="1736454782260">
<node CREATED="1736454504668" ID="ID_1002392068" MODIFIED="1736605288823">
<richcontent TYPE="NODE"><html>
<head/>
<body>
@ -102432,9 +102416,24 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1736454082544" ID="ID_1160836625" MODIFIED="1736454493950" TEXT="Test f&#xfc;r Metadaten-Verwaltung">
<arrowlink COLOR="#505f70" DESTINATION="ID_15277358" ENDARROW="Default" ENDINCLINATION="-1313;202;" ID="Arrow_ID_1843979731" STARTARROW="None" STARTINCLINATION="-1286;110;"/>
<arrowlink COLOR="#5387dc" DESTINATION="ID_15277358" ENDARROW="Default" ENDINCLINATION="-1313;202;" ID="Arrow_ID_1843979731" STARTARROW="None" STARTINCLINATION="-1286;110;"/>
<linktarget COLOR="#ce3644" DESTINATION="ID_1160836625" ENDARROW="Default" ENDINCLINATION="75;-69;" ID="Arrow_ID_298743045" SOURCE="ID_1712779274" STARTARROW="None" STARTINCLINATION="-76;15;"/>
<icon BUILTIN="flag-pink"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610754727" ID="ID_575487435" LINK="#ID_25381362" MODIFIED="1736611024745" TEXT="Grobstruktur zerlegen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610781361" ID="ID_1231919908" LINK="#ID_25381362" MODIFIED="1736611024747" TEXT="Argument-Listen parsen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610789680" ID="ID_466994748" LINK="#ID_25381362" MODIFIED="1736611024747" TEXT="extended Attributes auswerten">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610803062" ID="ID_1920110927" LINK="#ID_238141567" MODIFIED="1736611024746" TEXT="Node connectivity">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610811589" ID="ID_745350162" LINK="#ID_238141567" MODIFIED="1736611024746" TEXT="Port connectivity">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1730486716299" ID="ID_95149323" MODIFIED="1730486959772" STYLE="fork" TEXT="Storage bedarf gesondert der Betrachtung">
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
@ -103123,7 +103122,10 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1733525978260" ID="ID_15277358" MODIFIED="1736454430847" TEXT="NodeMeta_test">
<linktarget COLOR="#505f70" DESTINATION="ID_15277358" ENDARROW="Default" ENDINCLINATION="-1313;202;" ID="Arrow_ID_1843979731" SOURCE="ID_1160836625" STARTARROW="None" STARTINCLINATION="-1286;110;"/>
<linktarget COLOR="#5387dc" DESTINATION="ID_15277358" ENDARROW="Default" ENDINCLINATION="-1313;202;" ID="Arrow_ID_1843979731" SOURCE="ID_1160836625" STARTARROW="None" STARTINCLINATION="-1286;110;"/>
<icon BUILTIN="hourglass"/>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1736611061150" ID="ID_64541698" MODIFIED="1736611092737" TEXT="Abzudecken...">
<icon BUILTIN="yes"/>
<icon BUILTIN="hourglass"/>
<node CREATED="1736454332910" ID="ID_186394445" MODIFIED="1736454339836" TEXT="simpleUse"/>
<node CREATED="1733525991242" ID="ID_1334388738" MODIFIED="1733526054926" TEXT="Namen, ID- und Hashverkn&#xfc;pfung">
@ -103139,6 +103141,31 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<icon BUILTIN="hourglass"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610744078" ID="ID_25381362" MODIFIED="1736611008867" TEXT="verify_ID_specification">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610824003" ID="ID_1668456426" LINK="#ID_575487435" MODIFIED="1736611020835" TEXT="Definition einer ProcID">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610838882" ID="ID_1153713265" LINK="#ID_1231919908" MODIFIED="1736611020837" TEXT="Argument-Listen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610845136" ID="ID_1268032350" LINK="#ID_466994748" MODIFIED="1736611020836" TEXT="Qualifier / Attribute">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610750940" ID="ID_238141567" MODIFIED="1736611008867" TEXT="verify_ID_properties">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610859183" ID="ID_1146666158" MODIFIED="1736611020835" TEXT="Node-Connectivity aufbauen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610894914" ID="ID_1506981856" MODIFIED="1736611020834" TEXT="explizit gegebene Specs verifizieren">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610903513" ID="ID_479704860" LINK="#ID_745350162" MODIFIED="1736611020834" TEXT="durch ProcID zug&#xe4;ngliche Connectivity">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1733527343357" ID="ID_1948224513" MODIFIED="1733527590656" TEXT="NodeOpera_test">
<icon BUILTIN="hourglass"/>
<node CREATED="1733527358995" ID="ID_1763413562" MODIFIED="1733532620352" TEXT="Integrationstest &#x2014; im Test-Setup">