Invocation: Analysis regarding dispatch of information functions for Nodes
The choice to rely on strictly typed functor bindings for the Node operation bears the danger to produce ''template bloat'' — it would be dangerous to add further functions to the Port-API naïvely; espeically simple information functions will likely not depend on the full type information. A remedy to explore would be to exploit properties marked into the Port's `ProcID` as key for a dispatcher hashtable; assuming that the `NodeBuilder` will be responsible for registering the corresponding implementation functions, such a solution could even be somewhat type-safe, as long as the semantics of the ProcID are maintained correctly.
This commit is contained in:
parent
1aae4fdcdd
commit
abeca98233
5 changed files with 803 additions and 15 deletions
84
src/lib/fun-hash-dispatch.hpp
Normal file
84
src/lib/fun-hash-dispatch.hpp
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
/*
|
||||
FUN-HASH-DISPATCH.hpp - enrol and dispatch prepared functors keyed by hash-ID
|
||||
|
||||
Copyright (C)
|
||||
2025, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
||||
**Lumiera** is free software; you can redistribute it and/or modify it
|
||||
under the terms of the GNU General Public License as published by the
|
||||
Free Software Foundation; either version 2 of the License, or (at your
|
||||
option) any later version. See the file COPYING for further details.
|
||||
|
||||
*/
|
||||
|
||||
|
||||
/** @file fun-hash-dispatch.hpp
|
||||
** Service to register and dispatch opaque functions.
|
||||
** @see FunHashDispatch_test
|
||||
*/
|
||||
|
||||
|
||||
#ifndef LIB_SEVERAL_H
|
||||
#define LIB_SEVERAL_H
|
||||
|
||||
|
||||
#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
|
||||
|
||||
|
||||
|
||||
/************************************************//**
|
||||
*/
|
||||
template<class SIG>
|
||||
class FunHashDispatch
|
||||
: util::MoveOnly
|
||||
{
|
||||
using DispatchTab = std::unordered_map<HashVal, SIG*>;
|
||||
DispatchTab dispatchTab_{};
|
||||
|
||||
public:
|
||||
SIG*
|
||||
enrol (HashVal key, SIG* fun)
|
||||
{
|
||||
auto [entry,_] = dispatchTab_.emplace (key,fun);
|
||||
return entry->second;
|
||||
}
|
||||
|
||||
bool
|
||||
contains (HashVal key) const
|
||||
{
|
||||
return util::contains (dispatchTab_, key);
|
||||
}
|
||||
|
||||
SIG*
|
||||
select (HashVal key)
|
||||
{
|
||||
auto it = dispatchTab_.find (key);
|
||||
if (it == dispatchTab_.end())
|
||||
throw lumiera::error::Logic{"Expect function for given hash to be previously enrolled."};
|
||||
else
|
||||
return it->second;
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
|
||||
} // namespace lib
|
||||
#endif
|
||||
|
|
@ -16,6 +16,34 @@
|
|||
** Functionality is provided to identify a point in the processing chain for sake of
|
||||
** error reporting and unit testing; moreover, identifying information can be chained
|
||||
** and combined into a systematic hash key, to serve as foundation for a stable cache key.
|
||||
** @warning The specification expresses semantic distinctions and it is the responsibility
|
||||
** of the media-processing-library binding plug-in to ensure that classification
|
||||
** matches relevant semantic distinctions. In this context, "different" means
|
||||
** that two functions produce _perceptibly different results_ — which also
|
||||
** implies that for equivalent IDs we can use cached calculation results.
|
||||
**
|
||||
** ## Structure and syntax
|
||||
** A complete processing-specification combines a high-level identification of the enclosing
|
||||
** Node with qualifiers to describe a specific functionality variant for a given Port, together
|
||||
** with the structure of the input and output argument lists, and a set of additional, extended
|
||||
** attributes. Any aspects should be recorded here, if they might cause differences in computed
|
||||
** results or are relevant for some further information function (used for diagnostic, engine
|
||||
** instrumentation and job planning)
|
||||
** - the _Node symbol_ is related to the [processing asset](\ref ProcAsset) and is expected
|
||||
** to be structured as `<ontology>:<semanticID>`, e.g. `FFmpeg:gaussianBlur`
|
||||
** - the _Port qualifier_ accounts for specific configuration applied for the given port
|
||||
** - the _Argument lists_ should follow the pattern `[(inType, ...)](outType,...)`, with the
|
||||
** allowed shorthand notation `<type>/N` to designate N identical arguments of type `type`.
|
||||
** For a complete _processing spec,_ the node symbol is possible decorated with a dot and
|
||||
** the port qualifier (if present), then followed by the argument lists.
|
||||
**
|
||||
** ## Hash computation
|
||||
** Hash-IDs are derived from the full processing spec,_ but also from individual parts alone
|
||||
** for some use cases (e.g. dispatch of information functions). Furthermore, the Hash-IDs of
|
||||
** all Nodes in a processing chain can be combined into a Hash-ID of the chain, which is usable
|
||||
** as cache key: when the hash-ID matches, a cached result can be used instead of re-computation.
|
||||
** @todo Can we assume size_t == 64bit; is this enough to prevent collisions?
|
||||
** Can we afford using a 128bit hash? What about portability of hash values?
|
||||
** @todo WIP-WIP as of 10/2024 this is a draft created as an aside while working towards
|
||||
** the first integration of render engine functionality //////////////////////////////////////////////TICKET #1377 : establish a systematic processing identification
|
||||
** @remark the essential requirement for a systematic and stable cache key is
|
||||
|
|
@ -49,11 +77,42 @@ namespace engine {
|
|||
|
||||
class ProcNode;
|
||||
|
||||
|
||||
/**
|
||||
* Extended Attributes for ProcID metadata.
|
||||
* @remark used for cache key calculation and
|
||||
* to dispatch information functions.
|
||||
* @todo if this grows beyond size_t, it should be
|
||||
* deduplicated and stored in a registry,
|
||||
* similar to the string spec. Storage matters!
|
||||
*/
|
||||
struct ProcAttrib
|
||||
{
|
||||
bool manifold :1;
|
||||
bool isProxy :1;
|
||||
|
||||
ProcAttrib()
|
||||
: manifold{true}
|
||||
, isProxy{false}
|
||||
{ }
|
||||
|
||||
friend bool
|
||||
operator== (ProcAttrib const& l, ProcAttrib const& r)
|
||||
{
|
||||
return l.manifold == r.manifold
|
||||
and l.isProxy == r.isProxy;
|
||||
}
|
||||
};
|
||||
|
||||
/**
|
||||
* Metadata to qualify a Port (and implicitly the enclosing Node).
|
||||
*/
|
||||
class ProcID
|
||||
{
|
||||
StrView nodeSymb_;
|
||||
StrView portQual_;
|
||||
StrView argLists_;
|
||||
ProcAttrib attrib_{};
|
||||
|
||||
ProcID (StrView nodeSymb, StrView portQual, StrView argLists);
|
||||
|
||||
|
|
@ -77,7 +136,8 @@ namespace engine {
|
|||
{
|
||||
return l.nodeSymb_ == r.nodeSymb_
|
||||
and l.portQual_ == r.portQual_
|
||||
and l.argLists_ == r.argLists_;
|
||||
and l.argLists_ == r.argLists_
|
||||
and l.attrib_ == r.attrib_;
|
||||
}
|
||||
|
||||
friend bool
|
||||
|
|
|
|||
|
|
@ -363,6 +363,11 @@ return: 0
|
|||
END
|
||||
|
||||
|
||||
PLANNED "Generic function dispatch" FunHashDispatch_test <<END
|
||||
return: 0
|
||||
END
|
||||
|
||||
|
||||
TEST "Generic ID generation" GenericIdFunction_test <<END
|
||||
return: 0
|
||||
END
|
||||
|
|
|
|||
101
tests/library/fun-hash-dispatch-test.cpp
Normal file
101
tests/library/fun-hash-dispatch-test.cpp
Normal file
|
|
@ -0,0 +1,101 @@
|
|||
/*
|
||||
FunHashDispatch(Test) - verify dispatching of opaque functions keyed by hash-ID
|
||||
|
||||
Copyright (C)
|
||||
2025, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
||||
**Lumiera** is free software; you can redistribute it and/or modify it
|
||||
under the terms of the GNU General Public License as published by the
|
||||
Free Software Foundation; either version 2 of the License, or (at your
|
||||
option) any later version. See the file COPYING for further details.
|
||||
|
||||
* *****************************************************************/
|
||||
|
||||
/** @file fun-hash-dispatch-test.cpp
|
||||
** unit test \ref FunHashDispatch_test
|
||||
*/
|
||||
|
||||
|
||||
|
||||
|
||||
#include "lib/test/run.hpp"
|
||||
#include "lib/test/test-helper.hpp"
|
||||
#include "lib/fun-hash-dispatch.hpp"
|
||||
#include "lib/format-obj.hpp"
|
||||
#include "lib/test/diagnostic-output.hpp"////////////////////TODO
|
||||
//#include "lib/util.hpp"
|
||||
|
||||
//#include <cstdlib>
|
||||
#include <string>
|
||||
|
||||
|
||||
|
||||
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_)>()
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
/***********************************************************************************//**
|
||||
* @test Verify generic helper to provide a hash-based function dispatch table.
|
||||
* @see fun-hash-dispatch.hpp
|
||||
* @see NodeMeta_test
|
||||
*/
|
||||
class FunHashDispatch_test
|
||||
: public Test
|
||||
{
|
||||
|
||||
void
|
||||
run (Arg)
|
||||
{
|
||||
FunHashDispatch<string(int)> dispatch;
|
||||
|
||||
auto one = [](int i) { return toString(i); };
|
||||
auto two = [](int i) { return string(size_t(i),'*'); };
|
||||
|
||||
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);
|
||||
CHECK (res == one);
|
||||
res = dispatch.enrol (3,two);
|
||||
CHECK (res == two);
|
||||
CHECK (dispatch.select(3)(2) == "**"_expect);
|
||||
|
||||
VERIFY_FAIL ("Expect function for given hash"
|
||||
, dispatch.select(5) );
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
/** Register this test class... */
|
||||
LAUNCHER (FunHashDispatch_test, "unit common");
|
||||
|
||||
|
||||
}} // namespace lib::test
|
||||
|
|
@ -98927,8 +98927,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<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="#fdf9be" DESTINATION="ID_1514661165" ENDARROW="Default" ENDINCLINATION="-429;42;" ID="Arrow_ID_1746815334" SOURCE="ID_1677497952" STARTARROW="None" STARTINCLINATION="-358;-43;"/>
|
||||
<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>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -99530,6 +99530,111 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1736354939404" HGAP="68" ID="ID_510494185" MODIFIED="1736354976439" TEXT="Identifikationen" VSHIFT="5">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1736354949714" ID="ID_1256484351" MODIFIED="1736354965722" TEXT="AUA! hier tut sich ein großer Abgrund auf">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
<node CREATED="1736354992116" ID="ID_1351993847" MODIFIED="1736355000632" TEXT="die Node-Identity ist noch einfach">
|
||||
<node CREATED="1736355002067" ID="ID_1120864783" MODIFIED="1736355010840" TEXT="es ist eine Instanz die man in der Hand hat"/>
|
||||
<node CREATED="1736355011826" ID="ID_1814180700" MODIFIED="1736355036210" TEXT="plus ein semantisch begründetes Tagging"/>
|
||||
</node>
|
||||
<node CREATED="1736355038203" ID="ID_1099574201" MODIFIED="1736355055168" TEXT="die Processing-Identity dagegen ist komplex">
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1736355056700" ID="ID_383862700" MODIFIED="1736355075048" TEXT="sie läßt sich nicht auf statische Strukturen reduzieren">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1736355094705" ID="ID_751619290" MODIFIED="1736355120432" TEXT="das ist der tiefere Grund hinter dem Buffer-Hash-Problem">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1736355156534" ID="ID_520548947" MODIFIED="1736355172053" TEXT="das ist größtenteils eine Aufgabe für die Zukunft">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1736355173260" ID="ID_969672769" MODIFIED="1736355183523" TEXT="brauche aber JETZT bereits einen Platzhalter">
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1736355185418" ID="ID_1036010265" MODIFIED="1736355223889" TEXT="Zugang durch das Port-Interface">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1736355230317" ID="ID_77289185" MODIFIED="1736355509999" TEXT="erscheint als die einzige mögliche Lösung">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...da werde ich wohl noch darüber nachdenken müssen ... aber im Moment erscheint mir diese Frage unmittelbar auswegslos eindeutig: der Port ist die einzige Stelle, an der eine minimalistische, rigide Graph-Struktur virtualisiert verbunden ist mit einem unendlichen, amorphen offenen Raum der Möglichkeiten. Andererseits werde ich <b>niemals</b> mehr als eine opaque ID über dieses virtuelle Portal geben dürfen, denn sonst dringen Strukuren der semantischen Attributierung in das Graph-Modell ein, anstatt dieses nur zu markieren.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="clanbomber"/>
|
||||
</node>
|
||||
<node CREATED="1736355246450" ID="ID_484202363" MODIFIED="1736367220103" TEXT="denn hier und nur hier hat man eine Brücke <runtime> ⟼ Metadata">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1736355279998" ID="ID_356312788" MODIFIED="1736367502491" TEXT="dem allgemeinen Schema in Lumiera zufolge läuft die Verbindung über eine Hash-ID">
|
||||
<arrowlink COLOR="#3154cc" DESTINATION="ID_193492901" ENDARROW="Default" ENDINCLINATION="14;-40;" ID="Arrow_ID_23830006" STARTARROW="None" STARTINCLINATION="-91;3;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736367303135" ID="ID_1147883097" MODIFIED="1736367346642">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
das <i>ist und bleibt</i> eine Frage der <b>Ontology</b>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1736367359400" ID="ID_193492901" MODIFIED="1736367492419">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
insofern ist es <i>nur ein Tag</i>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#3154cc" DESTINATION="ID_193492901" ENDARROW="Default" ENDINCLINATION="14;-40;" ID="Arrow_ID_23830006" SOURCE="ID_356312788" STARTARROW="None" STARTINCLINATION="-91;3;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1736367428391" ID="ID_392999774" MODIFIED="1736367440816" TEXT="allein die Domain-Ontology kann dieses Tag korrekt setzen"/>
|
||||
<node CREATED="1736367442120" ID="ID_1375474775" MODIFIED="1736367463464" TEXT="es ist bereits vollständig definiert: als proc-Spec"/>
|
||||
<node CREATED="1736367466394" ID="ID_857536772" MODIFIED="1736367478860" TEXT="die Verwaltung liegt insofern in der ProcID"/>
|
||||
<node COLOR="#5b280f" CREATED="1736367551046" ID="ID_617599358" MODIFIED="1736367560237" TEXT="kein neues API notwendig">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736367561469" ID="ID_622372104" MODIFIED="1736367579365" TEXT="nur Dekoration">
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736367582606" ID="ID_254040608" MODIFIED="1736367941679" TEXT="Aber: Lumiera muß ein Framework dafür bieten">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1736367598580" ID="ID_1883362448" MODIFIED="1736368394322" TEXT="jede ProcID muß exakt sein">
|
||||
<linktarget COLOR="#63707f" DESTINATION="ID_1883362448" ENDARROW="Default" ENDINCLINATION="340;36;" ID="Arrow_ID_1842367707" SOURCE="ID_309182364" STARTARROW="Default" STARTINCLINATION="-162;-10;"/>
|
||||
</node>
|
||||
<node CREATED="1736367616078" ID="ID_730501713" MODIFIED="1736367632991" TEXT="aber auch jede Zusammensetzung muß sich niederschlagen"/>
|
||||
<node CREATED="1736367800718" ID="ID_1665935866" MODIFIED="1736367809687" TEXT="und Lumiera muß für Namensräume sorgen"/>
|
||||
</node>
|
||||
<node CREATED="1736367896503" ID="ID_744666682" MODIFIED="1736368240356">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
jedes <b>konkrete</b> Projekt hat seine eigene <i>kohärente </i>Domain Ontology
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Das folgt unter den Annahme, daß ein konkretes Projekt <i>funktionieren muß.</i> Also macht man nur Dinge, die kohärent aufgehen. Für Zweideutigkeiten findet man eine praktische Konvention, oder man weiß sie unsichtbar zu machen. Daher sollte dieses Problem für jedes konkrete Projekt in dem Sinn »lösbar« sein, daß die Cache-Steuerung fehlerfrei funktioniert. Der Beitrag der Lumiera-Infrastruktur dazu ist, für die notwendige Über-Differenzierung zu sorgen, so daß es niemals zu einer Kollision kommen kann zwischen Beiträgen, welche in disjunkten Libraries und Domain-Ontologies verankert sind.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1736262408883" HGAP="59" ID="ID_1980325374" MODIFIED="1736262722331" TEXT="wie kann die korrekte Verdrahtung geprüft werden?" VSHIFT="96">
|
||||
<arrowlink COLOR="#d10172" DESTINATION="ID_1540010113" ENDARROW="Default" ENDINCLINATION="-473;38;" ID="Arrow_ID_1593223212" STARTARROW="None" STARTINCLINATION="-242;0;"/>
|
||||
<arrowlink COLOR="#d10172" DESTINATION="ID_1424762602" ENDARROW="Default" ENDINCLINATION="-390;24;" ID="Arrow_ID_329256820" STARTARROW="None" STARTINCLINATION="-202;0;"/>
|
||||
|
|
@ -99551,9 +99656,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1736263907378" ID="ID_490139134" MODIFIED="1736263918636" TEXT="...das zwar der Default ist — umso schlimmer!"/>
|
||||
<node CREATED="1736263942477" ID="ID_386851830" MODIFIED="1736266396047" TEXT="die hierfür relevante Node-Info ist weggeworfen worden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...und zwar bewußt;
|
||||
|
|
@ -99562,8 +99665,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
zunächst wollte ich ja einen Routing-Descriptor, um damit nochemal eine zweite Indirektion / Flexibilisierung gegenüber dem InvocationAdapter zu machen. Dann hat sich aber die Bedeutung des Invocation-Adapters so verschoben, daß ein Teil seiner Rolle mit der FeedManifold verschmolzen ist, dafür aber ein rigideres Belegungsschema dem Binding-Functor abverlangt wird. Damit wurde explizite oder schematische Routing-Info eigentlich irrelevant, und ich habe sie durch direkte Referenzen ersetzt. <b>Und das ist nun das Problem</b>.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736266569293" ID="ID_1677497952" MODIFIED="1736267148969" TEXT="Idee: verify-connected-to">
|
||||
|
|
@ -99571,8 +99673,10 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<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ü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="1736266854064" TEXT="getInput(n) ⟼ optional<PortRef>">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736266763928" ID="ID_1486436213" MODIFIED="1736454774708" TEXT="getInput(n) ⟼ optional<PortRef>">
|
||||
<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>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736266878204" ID="ID_767157537" MODIFIED="1736266983110" TEXT="könnte aber auch ein watch(Port)-API sein">
|
||||
|
|
@ -99587,6 +99691,268 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1736368270752" ID="ID_246809408" MODIFIED="1736388048827">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Problem dabei: wer kennt den kokreten Typ,
|
||||
</p>
|
||||
<p>
|
||||
um mit einer solchen Spezialisierung zu binden?
|
||||
</p>
|
||||
</body>
|
||||
</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"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736368299769" ID="ID_1755000008" MODIFIED="1736368311420">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Lösung: per <b>Registrierung</b>
|
||||
</p>
|
||||
</body>
|
||||
</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"/>
|
||||
</node>
|
||||
<node CREATED="1736388200280" ID="ID_1983872321" MODIFIED="1736388234147" TEXT="möglicherweise könnte man so ein breites Port-Interface vermeiden">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1736388236945" ID="ID_1937036501" MODIFIED="1736388974009" TEXT="Erläuterung: weitere virtuelle Funktionen auf dem Port-Interface sind gefährlich">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...wegen <b>Template bloat</b>. Umso schlimmer, wenn diese Funktionen dann fast nur von Unit-Tests genutzt werden. Aber selbst eine einzige zusätzliche Funktion für einen Hash oder konkreten Descriptor würde ich gerne vermeiden wollen, denn man generiert zwangsläufig eine große Menge redundanten codes, der vermutlich niemals aufgerufen wird (was man aber nie wissen kann...)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1736389015376" ID="ID_1735379863" MODIFIED="1736390311555" TEXT="dieser Hebel ließe sich entschärfen wenn viele Fälle für die Diagnostik zusammenfallen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Man würde also ein System von Hash-IDs aufbauen, und dann würde jede Instanz des Turnout-Template bei der Generierung noch entsprechende Handler für die Diagnostik-Funktionen regisrieren. Allerdings nur, wenn die Funktion nicht bereits existiert. Dieser Ansatz würde darauf spekulieren, daß die meisten Diagnostik-Funktionen gar nicht anhand der konkreten Buffer- und Parameter-Typen differenziert sind. Beispielswese Funktionen, die auf Vorgänger-Ports zugreifen, müssen nur die Beschränkung auf die Anzahl der Vorgänger beachten. Aus der Processing-Spec, welche ja exakt den ausreichenden Differenzierungsgrad haben muß (sonst funktioniert das Caching nicht richtig) ließe sich ein Sub-Key für bestimmte Klassen von Diagnostik-Zugriffen gewinnen. Dieser würde dann ein Diagnostic-Objekt aus einer Hashtable holen (was dadurch dedupliziert wäre).
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1736390313779" ID="ID_322453639" MODIFIED="1736390332955" TEXT="das Konzept ließe sich ziemlich weit treiben...">
|
||||
<node CREATED="1736390333991" ID="ID_745167219" MODIFIED="1736390350368" TEXT="auch für Erweiterungs-Funktionalität jenseits von Diagnostik"/>
|
||||
<node CREATED="1736390355524" ID="ID_1337404390" MODIFIED="1736390424156" TEXT="also für Aufgaben, für die der Port keine »black box« sein kann">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...das wäre durchaus denkbar für »operational control«, wenn es um spezielle Instrumentierung geht, also detailierte Zeitmessungen aufgezeichnet werden müssen, die sich nicht über einen einzigen Kamm scheren lassen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1736390427435" ID="ID_1001722813" MODIFIED="1736390454771" TEXT="könnte man sogar mit »LazyInit«-λ verbinden">
|
||||
<node CREATED="1736390456927" ID="ID_1577041072" MODIFIED="1736390512464" TEXT="naja... damals war das eine Notlösung, weil ich mich im Design verrannt habe">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...aber immerhin habe ich mich damals so nobel geschlagen, daß ich daraus noch eine generische Library-Funktion gemacht habe, was mir jetzt zugute kommen könnte
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1736390513879" ID="ID_960263292" MODIFIED="1736390575059" TEXT="zur Erinnerung: das kann ein einmal-Init-λ hinterlegen, welches sich dann selbst umkoppelt"/>
|
||||
<node CREATED="1736390620897" ID="ID_185030337" MODIFIED="1736390629659" TEXT="Vorraussetzung ist std::function als Front-End">
|
||||
<node CREATED="1736390989007" ID="ID_333184177" MODIFIED="1736391028469" TEXT="das bräuchte nicht notwendig mein spezielles »Trojanisches Lambda«"/>
|
||||
<node CREATED="1736391046672" ID="ID_1905902014" MODIFIED="1736391073400" TEXT="die Grundidee: man würde nur eine Registrierungs-Kette speichern"/>
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1736391103528" ID="ID_724977732" MODIFIED="1736391111550" TEXT="sieht ehr nicht passend aus....">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1736391115590" HGAP="29" ID="ID_271611491" MODIFIED="1736391138049" TEXT="bräuchte dafür hierarchisch verknüpfte Hash-IDs" VSHIFT="6"/>
|
||||
<node CREATED="1736391138986" ID="ID_1945590638" MODIFIED="1736391163708" TEXT="denn andernfalls könnte man durchaus gleich das finale setup speichern"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1736391175526" ID="ID_1109783471" MODIFIED="1736391193108" TEXT="HA! aber nur wenn der Code auch das ist bzw. gebraucht wird">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1736391198206" HGAP="21" ID="ID_1288258375" MODIFIED="1736391241731" STYLE="bubble" TEXT="da scheint doch eine Idee zu stecken..." VSHIFT="5">
|
||||
<edge COLOR="#fffad1"/>
|
||||
<icon BUILTIN="hourglass"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1736391304813" ID="ID_1263702781" MODIFIED="1736391333333" TEXT="sinnvoll nur wenn man Code-Generierung dadurch vermeiden kann">
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1736391341912" ID="ID_817734322" MODIFIED="1736453634394" TEXT="Analyse: was für Varianten würden denn gebraucht">
|
||||
<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 CREATED="1736433553250" ID="ID_1633133909" MODIFIED="1736433559725" TEXT="durch Parsen zugänglich">
|
||||
<node CREATED="1736433561025" ID="ID_1814273505" MODIFIED="1736433564605" TEXT="Fan-in"/>
|
||||
<node CREATED="1736433566073" ID="ID_1536576559" MODIFIED="1736433570315" TEXT="Fan-out"/>
|
||||
<node CREATED="1736433573615" ID="ID_1578933185" MODIFIED="1736433580919" TEXT="Typ-Listen"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736433714372" ID="ID_1214545070" MODIFIED="1736433730012" TEXT="konkrete Konfig">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736433731553" ID="ID_451988722" MODIFIED="1736433763220" TEXT="Liste der Quell-Ports">
|
||||
<icon BUILTIN="forward"/>
|
||||
<node CREATED="1736433926440" ID="ID_823357133" MODIFIED="1736434645813" TEXT="mit reduzierter Differenzierung zugänglich">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Zugriff braucht nur die Differenzierung nach Weaving-Pattern, aber keine konkreten Typ-Signaturen. Denn das WeavingPattern legt fest, ob und wo die Sequenz der Vorgänger-Ports zugänglich ist. Das Layout von lib::Several wurde unabhängig von der konkreten Typisierung gehalten — aus ähnlichen Motiven. Selbst der Storage-Header beginnt mit einem einheitlichen Layout, und der size-Parameter liegt ganz vorne. Es erscheint sinnvoll, für diesen Zugriff eine ungetypte neue Library-Funktion bereitzustellen.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1736434648599" ID="ID_265360833" MODIFIED="1736434922646" TEXT="aber leider wird der Weaving-Pattern-Typ erased...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Und das <i>muß auch so sein,</i> denn sonnst wäre das kein freier Extension-Point. Jede Abweichung davon bedeutet effektiv eine Einschränkung der Implementierung — oder anders ausgedrückt, eine Erweiterung des Port-Interfaces. Das wäre durchaus denkbar; hier geht es allerdings um den sekundären Belang, wie man eine solche Erweiterung mit möglichst geringen Kosten realisiert
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1736434939874" ID="ID_606745199" MODIFIED="1736434947980" TEXT="Möglichkeiten einer API-Erweiterung">
|
||||
<node CREATED="1736434971612" ID="ID_584172400" MODIFIED="1736436108981" TEXT="KISS! Port::getLeadPorts() ⟼ Several<PortRef> const&">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Die offensichtliche Lösung ohne Überraschungen: wenn das API tatsächlich breiter ist, sollte man es breiter machen — und zwar auf dem üblichen und etablierten Weg
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="full-1"/>
|
||||
</node>
|
||||
<node CREATED="1736435081029" ID="ID_1972664701" MODIFIED="1736436111935" TEXT="Basisklasse(n) für Weaving-Pattern einführen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Vorschlag wäre eine Klasse PortConnectivity, und eine Alternative als ProxyPort. Davon könnten dann die beiden (derzeit definierten) generischen Weaving-Patterns erben. Dadurch wäre dann eine uniforme Implementierung für gewisse Verhaltensmuster möglich, ohne für jede Detail-Typisierung erneut Code generieren zu müssen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="full-2"/>
|
||||
</node>
|
||||
<node CREATED="1736435474840" ID="ID_15264427" MODIFIED="1736518637003" TEXT="Spec+extended-Attributes in ProcID heranziehen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Das wäre dann ein zusätzliches Differenzierungskriterium oder ein Qualifier; mutmaßlich zu realisieren als <i>extended attributes, </i>d.h. in der normalen Port-Spec unsichtbar oder nur durch einen kompakten Dekorator ausgewiesen. Ein solches zusätzliches Feature wird sehr wahrscheinlich notwendig sein, um eine hinreichend präzise differenzierte Hash-ID zu erzeugen, die auch konkrete Parameter-Werte mit einschließt, sofern diese einen Einfluß auf das Ergebnis und damit auf die Cache-Keys <i>haben könnten.</i>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="full-3"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736436037626" ID="ID_892551132" MODIFIED="1736436044704" TEXT="Kosten dieser Varianten">
|
||||
<node CREATED="1736436141310" ID="ID_1186948820" MODIFIED="1736439304962" TEXT="führt zu Template-Bloat — x-fach redundanter Code">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Jede Subklasse mit nicht-trivialem Verhalten (also effektiv jede) muß diese virtuelle Funktion implementieren; mit jeder Template-Spezialisierung wird erneut Code »abgeworfen«, um einen Funktionspointer darauf dann in die VTable aufnehmen zu können. <i>Theoretisch </i>könnte ein cleverer Compiler hier eine de-Duplikation machen, es ist mir aber kein Standard bekannt, der so etwas auch nur nahelegt (wobei — es <i>ist </i>naheliegend, da Template-Bloat ein bekanntes Problem von generischem modernen C++ ist, und trotzdem für einen durchschnittlichen Entwickler schwer zu vermitteln)
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="full-1"/>
|
||||
</node>
|
||||
<node CREATED="1736436410670" ID="ID_1348922444" MODIFIED="1736439307768" TEXT="damit wäre für >80% der Fälle eine de-Duplikation explizit gecodet">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Egal ob der Compiler de-Duplizieren <i>könnte</i> — wir machen es einfach explizit: Die jeweilige Basisklasse dürfte dann aber keine Abhängikgeit von Template-Parametern haben ⟹ für die beiden bisher definierten Fälle wäre komplette de-Duplikation so realisierbar. Der <b>Preis </b>dafür wäre aber leider eine deutliche Verschlechterung der Lesbarkeit im Weaving-Pattern selber; nicht nur daß man nun eine Basisklasse „im Kopf haben“ müßte, zudem wä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über dieser Lösung. Es ist der typische <i>Pragmatismus, </i>der den Code für alle nachfolgende Wartung und Erweiterung versaut....
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="full-2"/>
|
||||
</node>
|
||||
<node CREATED="1736436883609" ID="ID_639002268" MODIFIED="1736439310634" TEXT="erweiterte Storage in der ProcID — und ein spezielles Spezifikations-Schema">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Die Kosten werden hierdurch in die Laufzeit verschoben, genauer gesagt, aus dem Code-Segment in die Allokation für Nodes. Es ist weiterhin Compile-Time-Logik erforderlich, um für den Standard-Fall ein entsprechendes Tag in den <i>extended attributes</i> zu hinterlassen.
|
||||
</p>
|
||||
<p>
|
||||
Zunächst einmal erzeugt diese Lösung einen <i>erheblichen run-time-Storage-Overhead.</i> Die dynamische Codierung ersetzt einen einzelnen Pointer in der VTable jeweils durch eine String-Spec mit vmtl. mehr als 8 char Länge, sowie dazu noch einen Eintrag in einer sekundären Dispatcher-Table, bestehend aus einer Hash-ID (size_t) plus ... genau einem Function-Pointer. So gesehen, erst mal ziemlich dämlich. ABER es gibt nun einen zusätzlichen Hebel durch <b>de-Duplikation</b>: zum Einen deduplizieren wir die Spec-Strings selber; was aber noch wichtiger ist, da die Detail-Operationen nur auf Teile der Spec-Strings differenzieren, wird es <i>deutlich weniger Einträge</i> in der sekundären Dispatcher-Table geben. Eine String-View kostet <i>zwei «slot»</i> — also wäre bei mehr als <i>zwei</i>  Zusatz-Operationen der Overhead in der ProcID selber bereits reingeholt. Allerdings gibt es noch viel zusätzliche String-Storage, und die Dispatcher-Table-Einträge. Ob sich diese amortisieren, hängt von der Differenzierung in der Praxis ab. Entsprechend gibt es auch noch den Trade-off, ob man in der ProcID weniger oder mehr Teil-Komponenten des Spec-String separat speichert
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="full-3"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1736439316487" ID="ID_699338745" MODIFIED="1736439331297" TEXT="Einschätzung: Lösung-3 ist vertretbar">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1736439333324" ID="ID_1870764319" MODIFIED="1736439698346" TEXT="für das Potential für de-Duplikation kann ich im Moment nur »Bauchgefühl« bieten...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...und das Bauchgefühl neigt Richtung erhebliches Potential, sobald die Projekte groß und komplex werden. Für einfache Projekte, schätze ich, wird diese Lösung verschwenderisch, aber sobald wir eine fünf- bis sechstellige Anzahl an Render Nodes haben, wird das Einsparpotential gewaltig. So viele verschiedene Typen kann man in einem Projekt gar nicht haben, als daß es nicht zu einer erheblichen Reduktion der Strings und noch mehr der Dispatcher führen würde...
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1736439375803" ID="ID_4428033" MODIFIED="1736439530597" TEXT="Hinzu kommt, daß wir erweiterte Attribute für Parameter in der ProcID zwingend brauchen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...wenn es allerdings <i>nur darum ginge,</i> (also um die Cache-keys), kö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ätzliche Operationen...</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1736439705211" ID="ID_1190879993" MODIFIED="1736439967823" TEXT="den computation-overhead halte ich für vertretbar">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Aktuell geht es nur um Zusatz-Operationen, die rein für das Testing gebraucht werden; deshalb sollte auch über einen Lazy-Init-Ansatz nochmal nachgedacht werden. Längerfristig kommen Aufgaben für Instrumentierung und Job-Planung hinzu. Diese laufen nicht in der innersten, hoch-performanten Zone. Man sollte das Thema trotzdem im Auge behalten; möglicherweise kann man Ergebniswerte für einen ganzen Render-Chain in der Exit-Node als Abkürzung speichern, und so die re-Traversierung einsparen.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1736433740868" ID="ID_1999583432" MODIFIED="1736433753635" TEXT="Liste der Buffer-Provider">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1736445851042" ID="ID_338610694" MODIFIED="1736453621875" TEXT="Implementierung">
|
||||
<arrowlink COLOR="#a90b08" DESTINATION="ID_968052606" ENDARROW="Default" ENDINCLINATION="-139;-705;" ID="Arrow_ID_1420066310" STARTARROW="None" STARTINCLINATION="-1107;159;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -99805,9 +100171,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#435e98" CREATED="1736261821538" ID="ID_964402891" MODIFIED="1736262967696" TEXT="außerdem: drei Ports — muß eine Quelle also aufdoppeln">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Das ist ein realistisches Beispiel:
|
||||
|
|
@ -99827,8 +100191,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1736262594933" ID="ID_891914799" MODIFIED="1736262738364" TEXT="mit Builder-Termen definieren">
|
||||
|
|
@ -101910,6 +102273,168 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1736445926470" ID="ID_968052606" MODIFIED="1736453621875" TEXT="Extended-Attributes / Zusatz-Qualifikator">
|
||||
<linktarget COLOR="#a90b08" DESTINATION="ID_968052606" ENDARROW="Default" ENDINCLINATION="-139;-705;" ID="Arrow_ID_1420066310" SOURCE="ID_338610694" STARTARROW="None" STARTINCLINATION="-1107;159;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736453683669" ID="ID_1311023852" MODIFIED="1736453758988" TEXT="Repräsentation für extended-attributes bereitstellen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1736455022905" ID="ID_479685703" MODIFIED="1736455026740" TEXT="Möglichkeiten">
|
||||
<node COLOR="#5b280f" CREATED="1736455028561" ID="ID_1453874344" MODIFIED="1736518935157" TEXT="String in key=value - Syntax">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1736455215391" ID="ID_912960333" MODIFIED="1736455227690" TEXT="Syntax könnte limitierend sein"/>
|
||||
<node CREATED="1736455231453" ID="ID_1754211847" MODIFIED="1736518307038" TEXT="Repräsentation ist verbose"/>
|
||||
<node CREATED="1736455287159" ID="ID_851444156" MODIFIED="1736455292153" TEXT="Normalisierung notwendig"/>
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1736455146993" ID="ID_797473678" MODIFIED="1736518935157" TEXT="deduplizierte Tree-Map instanzen">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1736455301549" ID="ID_550592051" MODIFIED="1736455316534" TEXT="vmtl. ebenfalls String-Storage"/>
|
||||
<node CREATED="1736455319226" ID="ID_980251179" MODIFIED="1736455407146" TEXT="Deduplikation braucht Hash der Map">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
zum Einen ist das komplex, und außerdem birgt es die Gefahr der Korruption durch Updates
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736455424795" ID="ID_1408873676" MODIFIED="1736518472498" TEXT="dedizierter Record-Datentyp">
|
||||
<icon BUILTIN="forward"/>
|
||||
<node CREATED="1736455468174" ID="ID_875438649" MODIFIED="1736519180780">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
keine <i>offene</i> Lösung
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
eine »offene« Lösung würde einer Erweiterung von Lumiera (plug-in) oder einer speziellen Library-Integration ermöglichen, Attribute durch das low-level-Model hindurch zu »tunneln«, ohne spezielle Unterstützung der Core-Implementierung. Ich halte das jedoch aktuell für einen <i>nicht naheliegenden</i> Ansatz, da es keinen »Rück-Kanal« 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>
|
||||
<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ändlich"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736453699380" ID="ID_809402120" MODIFIED="1736453758989" TEXT="Konfigurations-API via Builder integrieren">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736453783056" ID="ID_186513914" MODIFIED="1736453791543" TEXT="Schema für dynamischen Dispatch">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736453849801" ID="ID_708185484" MODIFIED="1736453867637" TEXT="Definition und Einbindung von Zusatz-Funktionen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1736517050324" ID="ID_962992559" MODIFIED="1736517067149" TEXT="ProcID stellt Funktions-Registry/Dispatch als Service bereit"/>
|
||||
<node CREATED="1736517117210" ID="ID_1356796355" MODIFIED="1736517129532" TEXT="außerdem gibt es Kombinatoren für Hash-IDs"/>
|
||||
<node CREATED="1736517068377" ID="ID_931826770" MODIFIED="1736517136406" TEXT="aber Aufrufer ist allein für die sinnvolle Verknüpfung verantwortlich">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1736517164778" ID="ID_1005387710" MODIFIED="1736517549085" TEXT="zwangsläufig — Interface-Mechanismen umgangen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
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ür einzusparen. Stattdessen hinterlegen wir einen Direkt-Zugangsschlüssel, der ohne Prüfung angewendet wird.....
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ebcdab" COLOR="#690f14" CREATED="1736517263411" ID="ID_1602655252" MODIFIED="1736518225536" TEXT="verwendete ID-Features müssen zur Funktionalität auf der Anwendungsseite passen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...also ist der einzige Schutz, den Schlüssel inhaltlich korrekt an die Features der ID zu binden. Diese Bindung ist aber nicht formal-logisch, sondern für eine bestimmte Intention vorkonfiguriert; ob diese Zuordnung korrekt ist und zu einem validen Aufruf führt, hängt allein daran, daß 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ßt, wenn es — bedingt durch eine Lücke im logischen Argument — zur Registrierung zweier inkompatibler Funktionen unter der gleichen ID kommen könnte, gibt es keinen weiteren Schutzmechanismus mehr
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="clanbomber"/>
|
||||
</node>
|
||||
<node CREATED="1736517299722" ID="ID_836268742" MODIFIED="1736517316271">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
der Aufruf ist ein <b>blinder cast</b>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1736518966504" ID="ID_592428793" MODIFIED="1736518991591" TEXT="Nicht zu »schön« machen — es sind verkoppelte Implementierungen">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1736519004243" ID="ID_1088588114" MODIFIED="1736519188536" TEXT="die offene Lösung habe ich aufgegeben">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...weil eine offene Lösung zwar ohne Weiteres mögilch wäre, aber mit erheblich größerem Storage-Overhead einhergeht, der sich dann erst mal durch de-Duplikation amortisieren müßte. Daher sage ich erst einmal YAGNI!  und realisiere die einfache Lösung mit direkter Kollaboration, deren Overhead und Amortisierung leicht abschätzbar ist
|
||||
</p>
|
||||
</body>
|
||||
</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>
|
||||
<node CREATED="1736519225707" ID="ID_956380809" MODIFIED="1736519256762" TEXT="also ist die ProcID direkt mit den Informationsfunktionen involviert"/>
|
||||
<node CREATED="1736519265390" ID="ID_1749861706" MODIFIED="1736519291830" TEXT="es können Abkürzungs-Möglichkeiten im Einzelfall ausgenutzt werden"/>
|
||||
</node>
|
||||
</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 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ä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">
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736453901281" ID="ID_646916289" MODIFIED="1736453920374" TEXT="hierarchische Hash-Keys generieren">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736453954937" ID="ID_1108446670" MODIFIED="1736453966483" TEXT="Diagnostik und Zusatz-Qualifikator">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736454444496" ID="ID_1712779274" MODIFIED="1736454493950" TEXT="Korrektheit">
|
||||
<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">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
erste Anwendung: <font face="Monospaced" color="#3d3c71">PortDiagnostic::<b>srcPorts</b>()</font>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#e5296f" DESTINATION="ID_1486436213" ENDARROW="Default" ENDINCLINATION="-752;56;" ID="Arrow_ID_351949496" STARTARROW="None" STARTINCLINATION="-733;0;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1736454082544" ID="ID_1160836625" MODIFIED="1736454493950" TEXT="Test für Metadaten-Verwaltung">
|
||||
<arrowlink COLOR="#505f70" 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>
|
||||
<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"/>
|
||||
|
|
@ -102597,9 +103122,22 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1733525978260" ID="ID_15277358" MODIFIED="1733527327443" TEXT="NodeMeta_test">
|
||||
<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;"/>
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1733525991242" ID="ID_1334388738" MODIFIED="1733526054926" TEXT="Namen, ID- und Hashverknüpfung"/>
|
||||
<node CREATED="1736454332910" ID="ID_186394445" MODIFIED="1736454339836" TEXT="simpleUse"/>
|
||||
<node CREATED="1733525991242" ID="ID_1334388738" MODIFIED="1733526054926" TEXT="Namen, ID- und Hashverknüpfung">
|
||||
<node CREATED="1736454359803" ID="ID_238686361" LINK="#ID_1783268362" MODIFIED="1736454399462" TEXT="teilweise in NodeLink_test aufgebaut">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736454274966" ID="ID_541115996" MODIFIED="1736454282353" TEXT="parsen und zerlegen der Specs"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736454296307" ID="ID_457736922" MODIFIED="1736454347693" TEXT="extended-attributes">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1736454312595" ID="ID_1645737348" MODIFIED="1736454327248" TEXT="Parameter-Wert ⟼ Cache-Key">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1733527343357" ID="ID_1948224513" MODIFIED="1733527590656" TEXT="NodeOpera_test">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
|
|
|
|||
Loading…
Reference in a new issue