ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Invocation: develop a concept for handling parameter data

Browse source 
...as part of the rendering process, executed on top of the
low-level-model (Render Node network) as conceived thus far.

Parameter handling could be ''encoded'' into render nodes altogether,
or, at the other extreme, an explicit parameter handling could be specified
as part of the Render Node execution. As both extremes will lead to some
unfavourable consequences, I am aiming at a middle ground: largely, the
''automation computation'' will be encoded and hidden within the network,
implying that this topic remains to be addressed as part of defining
the Builder semantics and implementation. Yet in part the required
processing structure can be foreseen at an abstract level, and thus
the essential primitive operations are specified explicitly as part
of the Render Node definition. Notably the ''standard Weaving Pattern''
will include a ''parameter tuple'' into each `FeedManifold` and require
a binding function, which accepts this tuple as first argument.

Moreover — at implementation level, a library facility must be provided
to support handling of ''arbitrary heterogeneous data values'' embedded
directly into stack frame memory, together with a type-safe compile-time
overlay, which allows the builder to embed specific ''accessor handles''
into functor bindings, even while the actual storage location is not
yet known at that time (obviously, as being located on the stack).

__Note__: a recurring topic is how to return descriptor objects from builder functions; for this purpose, I am adjusting the semantics of `lib/nocopy.hpp` to be more specific...
This commit is contained in:
Fischlurch 2024-12-09 21:55:48 +01:00
parent 9393942366
commit 8069c874f1
10 changed files with 610 additions and 67 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
src/lib/allocation-cluster.hpp
View file

@ -21,6 +21,17 @@
** pattern. Optionally it is even possible to skip invocation of object
** destructors, making de-allocation highly efficient (typically the
** memory pages are already cache-cold when about to discarded).
** \par base allocation
** The actual allocation of storage extents uses heap memory expanded in blocks
** of AllocationCluster::EXTENT_SIZ. While the idea is to perform allocations
** mostly at start and then hold and use the memory, the allocation is never
** actually _closed_ — implying that further allocations can be added during
** the whole life time, which may possibly even trigger a further base allocation
** if storage space in the last Extent is exhausted. In theory, it would be possible
** to use a custom allocation (in the AllocationCluster::StorageManager::Extents,
** which is a lib::LinkedElements and could be parametrised with a allocator template).
** Allocations are never discarded, and thus any alloted memory will be kept until
** the whole AllocationCluster is destroyed as a compound.
** \par using as STL allocator
** AllocationCluster::Allocator is an adapter to expose the interface
** expected by std::allocator_traits (and thus usable by all standard compliant
@ -28,6 +39,9 @@
** including the invocation of their destructors, while relying on the allocator
** to allot and discard bare memory. However, to avoid invoking any destructors,
** the container itself can be created with AllocationCluster::createDisposable.
** This causes the container (front-end) to be emplaced itself into the used
** AllocationCluster — and since the container's destructor will not be invoked
** in this arrangement, the container will not be able to invoke element dtors.
** \par dynamic adjustments
** Under controlled conditions, it is possible to change the size of the latest
** raw allocation handed out, within the limits of the available reserve in the

94
src/lib/hetero-data.hpp Normal file
View file

@ -0,0 +1,94 @@
/*
HETERO-DATA.hpp - handle chain of heterogeneous data blocks
Copyright (C)
2024, 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 hetero-data.hpp
** Maintain a chained sequence of heterogeneous data blocks without allocation.
** This building block for low-level memory management allows to build up a collection
** of entirely arbitrary data placed into existing and possibly distributed storage.
** The safety of storage and lifetime must be ensured by other means, since data access
** proceeds without further bound checks. However, a type-safe compile-time overlay of
** accessor marker types is provided, allowing to integrate such a storage layout into
** an overall memory safe arrangement.
**
** A usage scenario would be gradually to build up an assortment of data elements directly
** in local automatic storage within an elaborate recursive call stack unfolding recursively.
** Notably the accessor marker types can be assembled independently from the provision of
** actual storage, as the connection between accessor and actual storage address is
** _established late,_ on actual _data access._ Obviously, data access in such an arrangement
** requires traversal in several steps, which, on the other hand, can be justified by a good
** cache locality of recently used stack frames, thereby avoiding heap allocations altogether.
**
** @todo WIP-WIP this is the draft of a design sketch regarding the render node network,
** which seems to be still pretty much in flux as of 12/2024
** @see HeteroData_test
** @see steam::engine::TurnoutSystem (use case)
**
*/
#ifndef LIB_HETERO_DATA_H
#define LIB_HETERO_DATA_H
//#include "lib/error.hpp"
//#include "lib/symbol.hpp"
#include "lib/nocopy.hpp"
#include "lib/linked-elements.hpp"
#include "lib/meta/typelist.hpp"
//#include <algorithm>
//#include <vector>
namespace lib {
struct StorageLoc
{
StorageLoc* next{nullptr};
};
template<typename...DATA>
struct StorageFrame
: StorageLoc
, std::tuple<DATA...>
{
};
/**
*/
template<class SPEC>
class HeteroData
{
};
template<class TAIL, typename...DATA>
class HeteroData<meta::Node<StorageFrame<DATA...>,TAIL>>
: protected StorageFrame<DATA...>
{
public:
size_t constexpr size();
template<size_t slot>
struct Navigator
{
};
};
} // namespace lib
#endif /*LIB_HETERO_DATA_H*/

2
src/lib/iter-stack.hpp
View file

@ -242,7 +242,7 @@ namespace lib {
* to prepare and pre-fill a sequence
*/
struct Builder
: util::Cloneable
: util::NonCopyable
{
Builder(IterQueue& initialElements)
: queue_(initialElements)

27
src/lib/nocopy.hpp
View file

@ -72,19 +72,32 @@ namespace util {
};
/**
* Types marked with this mix-in may be created by
* copy-construction (or move construction),
* but may be not reassigned thereafter.
* @remark especially this allows returning
* by-value from a builder function,
* while prohibiting any further copy
* Types marked with this mix-in may be created and moved
* liberally at construction, while any further assignment
* to object instances is prohibited thereafter.
*/
class NonAssign
{
protected:
~NonAssign() = default;
NonAssign() = default;
NonAssign (NonAssign&&) = default;
NonAssign (NonAssign const&) = default;
NonAssign& operator= (NonAssign&&) = delete;
NonAssign& operator= (NonAssign const&) = delete;
};
/**
* Types marked with this mix-in may be duplicated
* by copy-construction, yet may not be moved or
* transferred any further after creation.
*/
class Cloneable
{
protected:
~Cloneable() = default;
Cloneable() = default;
Cloneable (Cloneable&&) = default;
Cloneable (Cloneable&&) = delete;
Cloneable (Cloneable const&) = default;
Cloneable& operator= (Cloneable&&) = delete;
Cloneable& operator= (Cloneable const&) = delete;

4
src/steam/engine/exit-node.hpp
View file

@ -58,10 +58,10 @@ namespace engine {
* @warning ExitNode should ideally be NonCopyable, since it is referred by the JobTicket
* However, we need to clone-and-remould Segments (Split-Splice-Algo), and this implies
* that the render nodes can be shared among multiple Segments. If all these assessments
* are correct can only be decided when the actual memory management is settled.
* are correct after all can only be decided once actual memory management is settled.
*/
class ExitNode
: util::Cloneable
: util::NonAssign
{
HashVal pipelineIdentity_; //////////////////////////////////////////////////////////TICKET #1293 : Hash-Chaining for invocation-ID... derive from ProcNode wiring
Duration runtimeBound_; ///////////////////////////////////////////////////////////TICKET #1283 : integrate with dynamic runtime observation

9
src/steam/engine/turnout-system.hpp
View file

@ -39,6 +39,7 @@
#include "steam/engine/state-closure.hpp" /////////////////////OOO will take on a different role (if any)
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
#include "lib/nocopy.hpp"
#include "lib/time/timevalue.hpp"
@ -46,7 +47,13 @@ namespace steam {
namespace engine {
using lib::time::Time;
template<typename VAL>
class ParamStorageFrame
: util::NonCopyable
{
};
/**

4
src/steam/engine/turnout.hpp
View file

@ -337,7 +337,7 @@ namespace engine {
void
weft (Feed& feed)
{
feed.invoke();
feed.invoke(); // process data
}
BuffHandle
@ -349,7 +349,7 @@ namespace engine {
}
for (uint i=0; i<outTypes.size(); ++i)
{
feed.outBuff[i].emit();
feed.outBuff[i].emit(); // state transition: data ready
if (i != resultSlot)
feed.outBuff[i].release();
}

5
tests/15library.tests
View file

@ -434,6 +434,11 @@ return: 0
END
PLANNED "Heterogeneous data in local storage" HeteroData_test <<END
return: 0
END
TEST "Instrumentation: concurrent calls" IncidenceCount_test <<END
return: 0
END

66
tests/library/hetero-data-test.cpp Normal file
View file

@ -0,0 +1,66 @@
/*
HeteroData(Test) - verify maintaining chained heterogeneous data in local storage
Copyright (C)
2024, 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 del-stash-test.cpp
** unit test \ref HeteroData_test
*/
#include "lib/test/run.hpp"
#include "lib/hetero-data.hpp"
namespace lib {
namespace test{
namespace { // probe victims
}//(End) test data
/*************************************************************//**
* @test maintain a sequence of data tuples in local storage,
* providing pre-configured type-safe data access.
*
* @see lib::HeteroData
* @see NodeBase_test::verify_TurnoutSystem()
*/
class HeteroData_test : public Test
{
virtual void
run (Arg)
{
// seedRand();
// checksum = 0;
checkSingleKill();
}
void
checkSingleKill ()
{
}
};
/** Register this test class... */
LAUNCHER (HeteroData_test, "unit common");
}} // namespace lib::test

452
wiki/thinkPad.ichthyo.mm
View file

@ -20985,9 +20985,7 @@
</node>
<node CREATED="1575215838399" ID="ID_859406608" MODIFIED="1575215879417" TEXT="nat&#xfc;rliche Code-Organisation">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
man schreibt die konkrete Implementierung direkt bei der Implementierung des Zieltyps mit
@ -21333,9 +21331,7 @@
</node>
<node CREATED="1575559189338" ID="ID_508619525" MODIFIED="1575561473297" TEXT="und diesen m&#xfc;ssen wir f&#xfc;r die &#xbb;Quer-Bewegung&#xab; auch selber erreichen k&#xf6;nnen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...also wenn wir ViewHook f&#252;r einen anderen Kinder-Typ brauchen
@ -21966,9 +21962,7 @@
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1575845525564" HGAP="47" ID="ID_960595364" MODIFIED="1575845553029" VSHIFT="2">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Entscheidung: <b>NonCopoyable</b>
@ -22761,9 +22755,7 @@
<node CREATED="1480725704142" ID="ID_992732373" MODIFIED="1557498707226" TEXT="was bleibt abstrakt?">
<node CREATED="1480725715916" ID="ID_890987188" MODIFIED="1576282358081" TEXT="buildMutator">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
lat&#252;rnich
@ -23493,9 +23485,7 @@
<node CREATED="1666901623044" ID="ID_1492305881" MODIFIED="1666901629255" TEXT="coveredTime()">
<node CREATED="1666901657919" ID="ID_783302636" MODIFIED="1666902040819" TEXT="Implementierung tendentiell problematisch">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
woher soll man das wissen?
@ -25514,9 +25504,7 @@
<node CREATED="1480741552611" ID="ID_1987203186" MODIFIED="1557498707226" TEXT="erzeugen"/>
<node COLOR="#435e98" CREATED="1480741555930" ID="ID_1869427213" MODIFIED="1678406865763">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
wie in Kopf <i>und</i>&#160;Rumpf injizieren
@ -28888,9 +28876,7 @@
<icon BUILTIN="button_ok"/>
<node CREATED="1555806541914" ID="ID_1260020116" MODIFIED="1576282358063" TEXT="der bietet genau den flexiblen inline-Buffer, den ich hier brauche">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
n&#228;mlich mit minimalem Admin-Overhead,
@ -33761,9 +33747,7 @@
</node>
<node CREATED="1582923948176" ID="ID_1562514737" MODIFIED="1582924052715" TEXT="und damit das geht, mu&#xdf; man irgendwo vom reinen ViewHook starten k&#xf6;nnen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...und dieser mu&#223; deshalb auch schon eine Funktion <font face="Monospaced">getAnchorHook()</font>&#160;auf dem API bieten
@ -37741,9 +37725,7 @@
</node>
<node CREATED="1615558821048" ID="ID_553122702" MODIFIED="1615559148819">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
die Konsequenz aus L&#246;sung-1 ist aber nicht <i>wirklich abwegig</i>
@ -39565,9 +39547,7 @@
</node>
<node CREATED="1618574134031" ID="ID_448471388" MODIFIED="1618574349745" TEXT="konkurrierende Gesten erkennen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
einfachers Dragging mit der Maus? oder kommt zum Abschlu&#223; eine spezielle Taste? oder eine spezielle Mausgeste?
@ -40443,9 +40423,7 @@
</node>
<node CREATED="1667156246932" ID="ID_306732730" MODIFIED="1667156379883" TEXT="int64_t kann aus TimeVar &quot;entkommen&quot; und in FSecs &quot;reingeraten&quot;">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<u>Resultat</u>:
@ -40856,9 +40834,7 @@
<icon BUILTIN="help"/>
<node CREATED="1667673606578" ID="ID_1067254564" MODIFIED="1667682151865" TEXT="potentiell gef&#xe4;hrlich: Metrik &#x27f6; visibleWin">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
denn dabei wird gerundet, um die exakte Pixel-Zahl zu erhalten
@ -41135,9 +41111,7 @@
<node CREATED="1667751592378" ID="ID_18326921" MODIFIED="1667751601497" TEXT="mu&#xdf; eine Ganzzahl sein"/>
<node CREATED="1667751607890" ID="ID_132312569" MODIFIED="1667752562566" TEXT="mu&#xdf; kleiner sein als I/S">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
denn f&#252;r x &#8788; I/S&#160;&#160;ergibt sich x/I = 1/s
@ -41595,9 +41569,7 @@
<icon BUILTIN="messagebox_warning"/>
<node COLOR="#435e98" CREATED="1668269822171" ID="ID_1581625515" MODIFIED="1670608805543" TEXT="Resultat sollte &quot;ungiftig&quot; sein">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
weil es direkt in das Feld <font face="Monospaced" color="#87179a">px_per_second_</font>&#160;geht
@ -87412,8 +87384,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Das mu&#223; so sein aus Gr&#252;nden der logischen Konsistenz: Der Invocation-Mechanismus der Render-Engine ist generisch, und das bedeutet, er kann nichts implizit &#252;ber das zu rendernde Modell wissen; zwar wird f&#252;r den Build-Vorgang in <i>absolute Placements</i>&#160; reduziert, aber diese beziehen sich immer noch auf eine bestimmte Timeline &#8212; ebenso wie der Render-Vorgang, der <i>auf einer Timeline</i>&#160; abl&#228;uft. Das bedeutet, <i>f&#252;r den Rendervorgang</i>&#160;ist das Koordinatensystem <i>implizit</i>, und er gibt nur eine <b>absolute nominal Time</b>&#160;relativ dazu an; jedoch wird dieser implizite Kontext in der Job-Planung &#252;bersetzt in den Zugriff auf eine bestimmte <i>konkrete Exit-Node.</i>&#160;Insofern kann dann ein Job komplett generisch auf der Render-Engine laufen, denn er tarnsportiert sowohl die <i>absolute nominal Time,</i>&#160;alsauch die <i>konkrete ExitNode</i>. Das Turnout-System selber ist ebenfalls generisch, und das hei&#223;t, es wird nur sinnvoll in Verbindung mit einer ExitNode zur Auff&#252;hrung gebracht
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<linktarget COLOR="#385061" DESTINATION="ID_523248183" ENDARROW="Default" ENDINCLINATION="87;339;" ID="Arrow_ID_901283158" SOURCE="ID_970386501" STARTARROW="None" STARTINCLINATION="473;26;"/>
</node>
</node>
@ -87468,8 +87439,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
und diese ist massiv (Millionen Zyklen, allerdings in Speicher, der dann im Cache liegt)
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733589981868" ID="ID_1811006818" MODIFIED="1733590042726" TEXT="empirisch zu kl&#xe4;ren....">
<icon BUILTIN="flag-yellow"/>
@ -87491,8 +87461,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
...oder werden sie von der Medien-Berechnung verdr&#228;ngt?
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1733590887977" ID="ID_38832058" MODIFIED="1733590893994" TEXT="TODO: Ticket!">
<icon BUILTIN="flag-pink"/>
@ -87526,8 +87495,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</li>
</ul>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1733590644277" ID="ID_1323648633" MODIFIED="1733590819848" TEXT="Eindeutig KISS &#x27f9; zun&#xe4;chst sticht die Komplexit&#xe4;t der Implementierung">
<richcontent TYPE="NOTE"><html>
@ -87537,8 +87505,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
....die intrusive linked List habe ich n&#228;mlich fertig und getestet, zudem ist der Code daf&#252;r sehr robust zu verwenden, wenn man ohnehin einen privatenTyp f&#252;r ein Bucket definiert. Dem gegen&#252;ber m&#252;&#223;te man die Index-Tabellen-L&#246;sung erst mal konzipieren und austesten, und zudem w&#228;re die wohl eine Spezial-Implementierung und daher auch jedes Mal wieder zu verstehen. Damit ist die Entscheidung klar, man mu&#223; wirklich erst mal zeigen da&#223; ein Problem besteht...
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1733590668584" ID="ID_1093233061" MODIFIED="1733590868744" TEXT="daher implementieren wir zun&#xe4;chst die intrusive linked LIst">
<arrowlink COLOR="#7d8894" DESTINATION="ID_336537504" ENDARROW="Default" ENDINCLINATION="358;0;" ID="Arrow_ID_1380579888" STARTARROW="None" STARTINCLINATION="205;0;"/>
@ -87548,8 +87515,382 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733611147207" ID="ID_867806700" MODIFIED="1733611155184" TEXT="Entwurf: Belegung der Slots">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1733611235157" ID="ID_1373022274" MODIFIED="1733611269549" TEXT="Abstraktes Ablauf-Schema">
<icon BUILTIN="info"/>
<node CREATED="1733611321861" ID="ID_1648703683" MODIFIED="1733615415248">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
der Build-Proze&#223; belegt sukzessiv mehrere <i>abstrakte Slots</i>
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1733611835596" ID="ID_858478342" MODIFIED="1733611855402" TEXT="einzelne ParamAgent-Nodes verwenden jeweils einen solchen Slot"/>
<node CREATED="1733611679582" ID="ID_1095525966" MODIFIED="1733611712314" TEXT="ein Buffer-Storage-Typ wird festgelegt">
<node CREATED="1733611715123" ID="ID_464037291" MODIFIED="1733611731381" TEXT="mit diesem wird ein Buffer-Konstruktor vorbeteietet"/>
<node CREATED="1733611732817" ID="ID_1100481566" MODIFIED="1733611775944" TEXT="die Parameter-Aufbereitungs-Funktion belegt damit einen Ergebnispuffer-Slot"/>
</node>
<node CREATED="1733611782499" ID="ID_1152101042" MODIFIED="1733611798972" TEXT="damit kann eine Parameter-Node gebaut werden"/>
</node>
<node CREATED="1733615228700" ID="ID_1380425177" MODIFIED="1733616010854" TEXT="Design-Schlu&#xdf;folgerungen">
<node CREATED="1733615242584" ID="ID_1830762609" MODIFIED="1733615439843" TEXT="k&#xf6;nnte vielleicht sogar eine reine compiletime-L&#xf6;sung sein...."/>
<node CREATED="1733615483265" ID="ID_1213847672" MODIFIED="1733615505254" TEXT="das w&#xe4;re nat&#xfc;rlich sch&#xf6;n ... dann w&#xe4;re n&#xe4;mlich die Storage einfach ein Tupel"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1733615518940" ID="ID_1505216998" MODIFIED="1733615532779" TEXT="Vorsicht ... riskant">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1733615534866" ID="ID_1412476849" MODIFIED="1733615967508" TEXT="was macht man wenn die Belegung dann doch dynamisch sein mu&#xdf;....?">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Eine compiletime-L&#246;sung setzt zwingend vorraus, da&#223; der Code zur Belegung mehr oder weniger explizit und fest verdrahtet ist
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1733615590377" ID="ID_1369389718" MODIFIED="1733615626721" TEXT="au&#xdf;erdem: dann gibt es N x M Instanzen von einem ParamAgent-Template"/>
<node CREATED="1733615627733" ID="ID_872253027" MODIFIED="1733615648583" TEXT="und wenn schon &#x2014; w&#xe4;re das wirklich ein Problem??"/>
<node COLOR="#5b280f" CREATED="1733615968606" ID="ID_1124926389" MODIFIED="1733616003221" TEXT="Stop! dann w&#xe4;re auch gar kein &#xbb;Mechanismus&#xab; notwendig">
<icon BUILTIN="stop-sign"/>
<icon BUILTIN="idea"/>
<node CREATED="1733616017882" ID="ID_1331983384" MODIFIED="1733616032131" TEXT="wenn man sich ohnehin derart stark einschr&#xe4;nkt....">
<node CREATED="1733616033119" ID="ID_1129472297" MODIFIED="1733616051128" TEXT="also: nur ein einziger Belegungs-Vorgang"/>
<node CREATED="1733616051989" ID="ID_1427342281" MODIFIED="1733616086912" TEXT="nur eine einzige Param-Node pro Aufruf-Graph"/>
</node>
<node CREATED="1733616151983" ID="ID_750092104" MODIFIED="1733616164087" TEXT="...dann k&#xf6;nnte man gleich sagen: fester Record-Typ">
<node CREATED="1733617026305" ID="ID_1938073071" MODIFIED="1733617038715" TEXT="dann w&#xfc;rde im TurnoutSystem nur noch ein Buffer-Ptr gespeichert"/>
<node CREATED="1733617055109" ID="ID_860704082" MODIFIED="1733617079294" TEXT="und der Builder m&#xfc;&#xdf;te explizit Code f&#xfc;r die Automations-Auswertung generieren"/>
<node CREATED="1733617123547" ID="ID_515467072" MODIFIED="1733617166752" TEXT="das w&#xe4;re dann redundant zum Tunrout-System (oder umgekehrt)">
<icon BUILTIN="clanbomber"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1733617168070" ID="ID_196130689" MODIFIED="1733617258225" TEXT="nicht das was mir vorschwebt....">
<arrowlink COLOR="#dd294d" DESTINATION="ID_1106866186" ENDARROW="Default" ENDINCLINATION="48;-115;" ID="Arrow_ID_515415207" STARTARROW="None" STARTINCLINATION="-305;26;"/>
<icon BUILTIN="button_cancel"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733617201642" ID="ID_1106866186" MODIFIED="1733617251089" TEXT="nochmal grunds&#xe4;tzlich nachdenken">
<linktarget COLOR="#dd294d" DESTINATION="ID_1106866186" ENDARROW="Default" ENDINCLINATION="48;-115;" ID="Arrow_ID_515415207" SOURCE="ID_196130689" STARTARROW="None" STARTINCLINATION="-305;26;"/>
<icon BUILTIN="flag-yellow"/>
<node CREATED="1733617429492" ID="ID_1627227887" MODIFIED="1733617435111" TEXT="warum bin ich hier....?">
<node CREATED="1733617437547" ID="ID_344667697" MODIFIED="1733617443145" TEXT="wegen der Notation!"/>
<node CREATED="1733617444178" ID="ID_1478573322" MODIFIED="1733618127045" TEXT="genauer: ich hab das Gef&#xfc;hl da&#xdf; hier Systematik notwendig w&#xe4;re">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Ich hab ein ungutes Gef&#252;hl, wenn man jetzt sagt, das mu&#223; dann halt im Einzelfall programmiert werden. Denn es ist nicht so, da&#223; es hier einen &#187;User&#171; oder &#187;Client&#171; g&#228;be, wie bei einer klassischen Library. Vielmehr mu&#223; sp&#228;ter, in einer weiteren Runde, ein Builder implementiert werden, der seinerseits wieder <i>generisch</i>&#160;sein soll. Demgegen&#252;ber kann das Library-Plug-in zwar Adapter bereitstellen, aber diese Adapter k&#246;nnen keine Implementierung einer Parameter-Automation bereitstellen, denn das ist ein zur Medien-Berechnung komplett disjunkter Belang &#8212; das hei&#223;t, genauso wie es f&#252;r <i>eine Film-Timeline</i>&#160;schon mal eine Video- und eine Audio-Renderpipeline geben wird, wird es zus&#228;tzlich auch noch eine Automations-Pipeline geben. Nur da&#223; diese nun auch noch mit der Audio / Videoverarbeitung <i>quer-verkn&#252;pft sein mu&#223;.</i>&#160;.... hoppla &#8212; das ist <b>eine neue Einsicht</b>
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1733618128348" ID="ID_99082918" MODIFIED="1733618199888" TEXT="was wirklich gebraucht wird...">
<node CREATED="1733618201009" ID="ID_1162361884" MODIFIED="1733618201009" TEXT="eine Verkn&#xfc;pfung zwischen disjunkten Pipelines"/>
<node CREATED="1733618203124" ID="ID_1425658536" MODIFIED="1733618224035" TEXT="also eine Verkn&#xfc;pfung &#xfc;ber mehrere Domain-Ontologien hinweg"/>
<node CREATED="1733618273683" ID="ID_573084687" MODIFIED="1733618306522" TEXT="Ontologie-1 sagt: Effekt #xyz hat folgende Parameter-Slots"/>
<node CREATED="1733618409745" ID="ID_1610697235" MODIFIED="1733618443464" TEXT="Ontologie-2 sagt: ein Parameter-Slot hat einen Typ und wird von einer Funktion bespielt"/>
<node CREATED="1733618506331" ID="ID_1765902930" MODIFIED="1733618529918">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
und dann gibt es <b>eben doch</b>&#160;eine Render-Engine Domain-Ontologie
</p>
</body>
</html></richcontent>
<node CREATED="1733618547003" ID="ID_1820883494" MODIFIED="1733618556164" TEXT="diese nimmt eine ausgezeichnete Stellung ein"/>
<node CREATED="1733618557061" ID="ID_748041422" MODIFIED="1733618573102" TEXT="aber ich versuche, sie nicht zur einer Ober-Systematik werden zu lassen"/>
<node CREATED="1733618605318" ID="ID_352613665" MODIFIED="1733618612266" TEXT="also halte ich sie sehr abstrakt">
<node CREATED="1733618613733" ID="ID_1226492389" MODIFIED="1733618621408" TEXT="Medien werden durch Funktionen berechnet"/>
<node CREATED="1733618622284" ID="ID_108753658" MODIFIED="1733618641505" TEXT="Funktionen arbeiten von Eingabepuffer &#x27fc; Ausgabepuffer"/>
<node CREATED="1733618650714" ID="ID_1169423059" MODIFIED="1733618684731" TEXT="es gibt Parameter">
<node CREATED="1733618686084" ID="ID_1479118348" MODIFIED="1733618738944" TEXT="diese haben einen Typ mit Wert-Semantik"/>
<node CREATED="1733618698122" ID="ID_935633880" MODIFIED="1733618718499" TEXT="sie sind f&#xfc;r jede Instanz der Berechnungsfunktion fixiert"/>
<node CREATED="1733618805915" ID="ID_1665363935" MODIFIED="1733618822397" TEXT="und dieser fixierte Wert stammt aue einer vorgelagerten Funktions-Auswertung"/>
<node CREATED="1733618832507" ID="ID_1669132658" MODIFIED="1733618848777" TEXT="...welche in einer anderen Domain stattfindet: der Automations-Domain"/>
</node>
</node>
<node CREATED="1733618927161" ID="ID_1618386840" MODIFIED="1733668571367" TEXT="&#x27f9; daraus ergeben sich Anforderungen">
<arrowlink COLOR="#342dc7" DESTINATION="ID_1263935808" ENDARROW="Default" ENDINCLINATION="76;-261;" ID="Arrow_ID_1812585389" STARTARROW="None" STARTINCLINATION="-300;21;"/>
</node>
</node>
</node>
<node CREATED="1733618949009" ID="ID_1263935808" MODIFIED="1733668571368" TEXT="Anforderungen">
<linktarget COLOR="#342dc7" DESTINATION="ID_1263935808" ENDARROW="Default" ENDINCLINATION="76;-261;" ID="Arrow_ID_1812585389" SOURCE="ID_1618386840" STARTARROW="None" STARTINCLINATION="-300;21;"/>
<icon BUILTIN="yes"/>
<node CREATED="1733619047617" ID="ID_1317028715" MODIFIED="1733619183693" TEXT="in einer Domain-1 kann gefordert werden: brauche Parameter P&#x2081;">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
ganz analog wie ebenda gefordert werden kann: brauche N Eingabepuffer mit Format F&#8321; und M Ausgabepuffer mit Format F&#8322;
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1733619230153" ID="ID_240619765" MODIFIED="1733619248788" TEXT="hierf&#xfc;r wird nun im High-Level-Modell eine Repr&#xe4;sentation markiert"/>
<node CREATED="1733619283260" ID="ID_208853197" MODIFIED="1733619295220" TEXT="sp&#xe4;ter mu&#xdf; der Builder sagen k&#xf6;nnen....">
<node CREATED="1733619296602" ID="ID_924793726" MODIFIED="1733667323722" TEXT="belege Parameter P&#x2081; mit Wert W&#x2093;"/>
<node CREATED="1733619336236" ID="ID_847600147" MODIFIED="1733667320345" TEXT="oder er sagt: werte Funktion F&#x2093; aus und schicke das Resultat in P&#x2081;"/>
</node>
<node CREATED="1733619398475" ID="ID_5012883" MODIFIED="1733619416189">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
<b>das</b>&#160;ist die <b>Systematik</b>&#160;die auf Level-2 gebraucht wird
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1733619417073" ID="ID_1163122090" MODIFIED="1733619437042" TEXT="und konkret geht es nun darum, daf&#xfc;r eine Implementierung zu erm&#xf6;glichen"/>
<node CREATED="1733619471042" ID="ID_1150277906" MODIFIED="1733619531544" TEXT="Schlu&#xdf;folgerung: der Level-2-Builder mu&#xdf; das Gesamtpaket auf inhaltlichem Level unterst&#xfc;tzen">
<node CREATED="1733619533825" ID="ID_64122116" MODIFIED="1733619602311" TEXT="und nicht irgend eine Verdrahtungs-Mechanik">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...das w&#228;re fatal, denn dann w&#252;rde die Abstraktion zusammenbrechen; etweder der Builder, oder (noch schlimmer) das Library-Plug-in m&#252;&#223;te Render-Engine-Internals instrumentieren
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1733619646970" ID="ID_1558562041" MODIFIED="1733619675762" TEXT="sondern (angepa&#xdf;t an das beteits etablierte Nutz-Schema)....">
<node CREATED="1733619679644" ID="ID_1725579009" MODIFIED="1733619836796" TEXT="baue Node f&#xfc;r Parameter-Funktion"/>
<node CREATED="1733619839656" ID="ID_961939154" MODIFIED="1733619850346" TEXT="(oder stelle direkt Parameter-Wert bereit)"/>
<node CREATED="1733619855478" ID="ID_420830257" MODIFIED="1733619877970" TEXT="und dann: versorge Slot #x mit Parameter-Node"/>
</node>
<node CREATED="1733667612811" ID="ID_1315509331" MODIFIED="1733667630959" TEXT="oder mit modifiziertem Konzept">
<node CREATED="1733667633045" ID="ID_1998558422" MODIFIED="1733667639702" TEXT="Parameter als Tupel &#xfc;bergeben"/>
<node CREATED="1733667640509" ID="ID_365193133" MODIFIED="1733667664914" TEXT="Storage f&#xfc;r Parameter-Tupel in die FeedManifold verlegen"/>
</node>
</node>
</node>
</node>
<node CREATED="1733667505561" ID="ID_281098138" MODIFIED="1733667513616" TEXT="Anpassungen am Konzept">
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1733667711513" ID="ID_709814165" MODIFIED="1733667720567" TEXT="wie weitrechend sind &#xc4;nderungen sinnvoll?">
<icon BUILTIN="help"/>
<node CREATED="1733667732150" ID="ID_715622924" MODIFIED="1733667737561" TEXT="Szenarien">
<node CREATED="1733667738423" ID="ID_1466061748" MODIFIED="1733667742600" TEXT="gar nichts &#xe4;ndern">
<node CREATED="1733667748013" ID="ID_351602982" MODIFIED="1733667757174" TEXT="Parameter kommen weiterhin &#xfc;ber einen Slot"/>
<node CREATED="1733667758426" ID="ID_993854311" MODIFIED="1733667768146" TEXT="nur liegt dort nun stets ein Tupel"/>
<node CREATED="1733667789457" ID="ID_1307307184" MODIFIED="1733667798569" TEXT="und es ist stets der 1.Slot"/>
<node CREATED="1733668361833" ID="ID_1184856567" MODIFIED="1733668384466" TEXT="f&#xfc;r komplexe Vorbereitung gibt es eine Param-Node"/>
<node CREATED="1733668406187" ID="ID_1733583106" MODIFIED="1733668419981" TEXT="auf diese kann per TurnoutSystem zugegriffen werden"/>
<node CREATED="1733668428312" ID="ID_1357285155" MODIFIED="1733668442626" TEXT="Medien-Daten werden durch diese Param-Node am Ende einfach durchgereicht"/>
</node>
<node CREATED="1733668461651" ID="ID_781020379" MODIFIED="1733690304890">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p style="text-align: center">
explizit ausgef&#252;hrte
</p>
<p style="text-align: center">
Parameterbehandlung
</p>
</body>
</html></richcontent>
<node CREATED="1733668477409" ID="ID_923499163" MODIFIED="1733668487791" TEXT="die ExitNode bekommt einen separaten Hook"/>
<node CREATED="1733668488846" ID="ID_1685272547" MODIFIED="1733668512329" TEXT="in dem sitzt ein Parameter-Funktor"/>
<node CREATED="1733668514057" ID="ID_457080437" MODIFIED="1733668526647" TEXT="dieser wird als erstes auf die Invocation angewendet"/>
<node CREATED="1733668527453" ID="ID_297103549" MODIFIED="1733668546051" TEXT="das Ergebnis kommt in einen Buffer, der vom TurnoutSystem gehalten wird"/>
<node CREATED="1733668606600" ID="ID_281720302" MODIFIED="1733668649673" TEXT="jeder Node-Port hat einen impliziten Parameter-Hook"/>
<node CREATED="1733668892050" ID="ID_925090387" MODIFIED="1733668918451" TEXT="dieser liefert eigens in ein separates Argument des Binding-Funktors"/>
</node>
<node CREATED="1733668983462" ID="ID_1024487083" MODIFIED="1733695904757" TEXT="Mischform beider">
<node CREATED="1733668993509" ID="ID_724420845" MODIFIED="1733669059943" TEXT="die ExitNode wird speziell aufgerufen und konstruiert ein Turnout-System"/>
<node CREATED="1733669079793" ID="ID_1857153191" MODIFIED="1733669099650" TEXT="dieses enth&#xe4;lt eine virtuelle Methode zum Einstieg in einen typisierten Kontext"/>
<node CREATED="1733669100478" ID="ID_1104507152" MODIFIED="1733669126512" TEXT="welcher einen Block spezifischer Gr&#xf6;&#xdf;e auf den Stack legt"/>
<node CREATED="1733669126986" ID="ID_387699944" MODIFIED="1733669145435" TEXT="und dorthin alle Parameter generiert"/>
<node CREATED="1733669182452" ID="ID_1048808235" MODIFIED="1733669196341" TEXT="auf Parameter wird per Param-Key-Objekt zugegriffen"/>
</node>
</node>
<node CREATED="1733699916802" ID="ID_166227320" MODIFIED="1733699920374" TEXT="Diskussion">
<node CREATED="1733699922354" ID="ID_467398715" MODIFIED="1733700138275" TEXT="ich halte es f&#xfc;r sinnvoll, das Thema &#xbb;Parameter&#xab; in das Design mit hineinzunehmen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Es geht um die Verst&#228;ndlichkeit und Wartbarkeit des Codes. Wenn ein derart zentrales Thema &#252;berhaupt keinen Niederschlag in konkreten Strukturen findet, sondern nur &#252;ber eine Konvention abgebildet wird, ist das verwirrend und fehleranf&#228;llig. Umso mehr, als hier nun auch noch auf transiente Datenpuffer verwiesen wird.
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1733700144577" ID="ID_1553080608" MODIFIED="1733700166238" TEXT="Extra Datenpuffer f&#xfc;r Parameter m&#xf6;chte ich in den meisten F&#xe4;llen vermeiden"/>
<node CREATED="1733700174958" ID="ID_1943562849" MODIFIED="1733700278792" TEXT="es erscheint attraktiv, ein Parameter-Tupel in die FeedManifold explizit aufzunehmen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Damit w&#228;re n&#228;mlich eine relativ sichere Storage auf dem Stack gegeben, und die Gegenwart der Parameter w&#228;re trotzdem stets eindeutig dokumentiert. Auch im Hinblick darauf, da&#223; vermutlich sehr h&#228;ufig irgend welche Parameter fest gesetzt werden m&#252;ssen (aber nicht per Automation bestimmt)
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1733700311670" ID="ID_459128266" MODIFIED="1733700345967">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
die <b>explizite</b>&#160;Behandlung w&#252;rde damit in das <b>konkrete Weaving-Pattern</b>&#160;verlegt
</p>
</body>
</html>
</richcontent>
<node CREATED="1733700351350" ID="ID_579640246" MODIFIED="1733700474434" TEXT="Node und Port bleiben unver&#xe4;ndert">
<icon BUILTIN="idea"/>
</node>
<node CREATED="1733700450763" ID="ID_1679523771" MODIFIED="1733700485441" TEXT="das &#xbb;SimpleWeavingPattern&#xab; w&#xe4;chst sich nun doch noch zu einem Standard aus">
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1733700534848" ID="ID_1967105643" MODIFIED="1733700554865" TEXT="praktisch jeder Port bekommt damit nun einen &#xbb;Slot&#xab; f&#xfc;r einen Parameter-Funktor"/>
<node CREATED="1733701423224" ID="ID_1016572187" MODIFIED="1733701443388" TEXT="an dieser Stelle w&#xe4;re sogar eine Indirektion denkbar">
<icon BUILTIN="idea"/>
<node CREATED="1733701668623" ID="ID_1331443258" MODIFIED="1733701680116" TEXT="Parameter-Tupel k&#xf6;nnten &#xbb;woanders&#xab; liegen"/>
<node CREATED="1733701904687" ID="ID_946678404" MODIFIED="1733701927672" TEXT="Parameter-&#xc4;nderungen w&#xe4;ren dann ohne Rebuild des Modells denkbar"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1733701946820" ID="ID_1997478599" MODIFIED="1733702333091" TEXT="Relevant f&#xfc;r das Thema &#xbb;Code-Bloat&#xab;">
<linktarget COLOR="#a5075a" DESTINATION="ID_1997478599" ENDARROW="Default" ENDINCLINATION="-1987;137;" ID="Arrow_ID_830705993" SOURCE="ID_1427414774" STARTARROW="None" STARTINCLINATION="118;7;"/>
<icon BUILTIN="bell"/>
<node CREATED="1733702341145" ID="ID_645778772" MODIFIED="1733702418686" TEXT="wenn man alles per &#x3bb; zusammensetzt...."/>
<node BACKGROUND_COLOR="#e5d789" COLOR="#a50125" CREATED="1733702367161" ID="ID_789976216" MODIFIED="1733702410802" TEXT="dann ensteht f&#xfc;r jede Parameter-Belegung eine Port-Subklasse">
<icon BUILTIN="clanbomber"/>
</node>
<node CREATED="1733702474218" ID="ID_1814281127" MODIFIED="1733702534473" TEXT="ein Template-Parameter kann aber auch auf std::function gebunden werden">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
in diesem Fall h&#228;tten alle Bindings die gleiche Port-Subklasse, w&#252;rden aber beim Zugriff auf die Parameter einen virtual call machen
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="idea"/>
</node>
</node>
</node>
<node CREATED="1733702602417" ID="ID_712887211" MODIFIED="1733702632440" TEXT="Parameter-Auswertung h&#xe4;tte weiterhin direkten Zugriff auf das TurnoutSystem (per Referenz)"/>
</node>
<node CREATED="1733703939301" ID="ID_41999689" MODIFIED="1733703954947" TEXT="eine ParamAgent-Node w&#xfc;rde durch diese &#xc4;nderung &#xfc;berfl&#xfc;ssig"/>
<node CREATED="1733703901837" ID="ID_1221228025" MODIFIED="1733703934714" TEXT="f&#xfc;r die komplexe Parameter-Vorberechnung w&#xfc;rde man eine dedizierte Param-Node verwenden">
<node CREATED="1733703978448" ID="ID_978296037" MODIFIED="1733703988824" TEXT="genauer gesagt: es w&#xe4;re ein spezieller Port"/>
<node CREATED="1733703959659" ID="ID_975412935" MODIFIED="1733704000649" TEXT="dieser w&#xfc;rde ein spezialisiertes Weaving-Pattern verwenden"/>
<node CREATED="1733704002273" ID="ID_22358741" MODIFIED="1733704234142" TEXT="das k&#xf6;nnte dann ein angepa&#xdf;tes TurnoutSystem im Callstack hinterlassen"/>
<node CREATED="1733704026706" ID="ID_673324811" MODIFIED="1733704054351" TEXT="und w&#xfc;rde ansonsten die Berechnungen delegieren"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#fefc4e" COLOR="#351d75" CREATED="1733704272454" ID="ID_927225402" MODIFIED="1733755186758" TEXT="damit zeichnet sich ein vielversprechendes Misch-Modell ab">
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
<icon BUILTIN="forward"/>
<node CREATED="1733704318588" ID="ID_1636257155" MODIFIED="1733704334288">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
wichtigster Vorteil: <b>es ist noch nicht festgelegt</b>
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1733704335488" ID="ID_1435251455" MODIFIED="1733704392020" TEXT="der Basis-Fall w&#xe4;re einfach und ziemlich effizient"/>
<node CREATED="1733704365125" ID="ID_547062370" MODIFIED="1733704382326" TEXT="man h&#xe4;tte Spielraum zu mehr Indirektionen aber auch mehr Optimierung"/>
<node CREATED="1733704396160" ID="ID_692446163" MODIFIED="1733704419977" TEXT="die denkbare erweiterte Rolle des Turnout-Systems bleibt als M&#xf6;glichkeit bestehen"/>
<node CREATED="1733704434324" ID="ID_817627181" MODIFIED="1733756104469" TEXT="das Turnout-System bleibt vorerst ein Baukasten, basierend auf LinkedElements">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Ich wollte mehr, und deshalb halte ich die Stelle f&#252;r das TurnoutSystem offen &#8212; obwohl auf gegenw&#228;rtigem Stand seine verbleibende Funktionalit&#228;t komplett in die interne Mechanik integriert werden k&#246;nnte. Auf diesem gegenw&#228;rtigen Stand kann ich die Vorstellung noch nicht weiter entwickeln, weil mir der klare Blick auf den realen Gebrauch in den tats&#228;chlichen Proportionen fehlt &#8212; aber ich hoffe, da&#223; sich dann aus dem Einsatz eines Baukasten-Systems irgendwann klarere Muster codifizieren lassen
</p>
</body>
</html>
</richcontent>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1733704467954" ID="ID_747211178" MODIFIED="1733704491711" TEXT="und alle konkreten Festlegungen k&#xf6;nnen gefahrlos auf sp&#xe4;ter verschoben werden">
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
</node>
</node>
</node>
</node>
<node CREATED="1733704561778" ID="ID_1261599290" MODIFIED="1733704586011">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
<u>Fazit</u>: zur&#252;ck zum ersten Konzept
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="forward"/>
<node CREATED="1733704588158" ID="ID_1436422105" MODIFIED="1733704675964" TEXT="Intrusiv verkn&#xfc;pfte Storage-Frames f&#xfc;r das Turnout-System"/>
<node CREATED="1733761653882" ID="ID_950074593" MODIFIED="1733761667427" TEXT="allerdings h&#xe4;lt jeder Storage-Frame gleich ein Tupel von Werten"/>
<node CREATED="1733704677700" ID="ID_57789571" MODIFIED="1733704753675" TEXT="Storage-Frames werden per Accessor-Key registriert"/>
<node CREATED="1733704793907" ID="ID_1040373700" MODIFIED="1733704816204" TEXT="offen halten &#x2014; keine integrierte Magie"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733704821863" ID="ID_1350706165" MODIFIED="1733704853138" TEXT="au&#xdf;erdem: Umbau auf das Misch-Modell f&#xfc;r Parameter">
<icon BUILTIN="yes"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733590902929" ID="ID_1045639317" MODIFIED="1733590910632" TEXT="Implementierung overflow-Buckets">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1733765037437" ID="ID_1724101101" MODIFIED="1733765062311" TEXT="unterst&#xfc;tzte Interaktionen">
<node CREATED="1733765068881" ID="ID_523511672" MODIFIED="1733765084522" TEXT="ein default TurnoutSystem mit Grund-Ausstattung"/>
<node CREATED="1733765092674" ID="ID_1865816766" MODIFIED="1733765118024">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
einen Satz Parameter an anderer Stelle platzieren und <i>anh&#228;ngen</i>
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1733765203927" ID="ID_39536680" MODIFIED="1733765221728" TEXT="Accessor f&#xfc;r einen Einzelwert bereitstellen"/>
<node CREATED="1733765657476" ID="ID_381368973" MODIFIED="1733765679248" TEXT="Zugriff per Accessor auf einer konkreten TurnoutSystem-Instanz"/>
<node CREATED="1733765766459" ID="ID_329973215" MODIFIED="1733766906645" TEXT="zur Laufzeit offen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Der Zugriff erfolgt unchecked, aber ein typsicherer Zugriff soll durch einen compile-time-Overlay gew&#228;hrleistet sein. Essentiell ist, da&#223; die typsicheren Accessoren erzeugt werden k&#246;nnen <b>bevor</b>&#160;die konkrete Storage-Adressen bekannt sind
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="yes"/>
</node>
</node>
<node CREATED="1733766910569" ID="ID_462136727" MODIFIED="1733766922508" TEXT="&#x27f9; gebraucht wird">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733766926415" ID="ID_1686613162" MODIFIED="1733767188149" TEXT="Library f&#xfc;r heterogene verkn&#xfc;pfte Storage-Bl&#xf6;cke">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1733767199547" ID="ID_22701741" MODIFIED="1733767216844" TEXT="Template HeteroData"/>
<node COLOR="#435e98" CREATED="1733767218786" ID="ID_121902085" MODIFIED="1733774871018" TEXT="HeteroData_test"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733766989087" ID="ID_1930665408" MODIFIED="1733767188150" TEXT="typsicheres compiletime-Overlay f&#xfc;r diese">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1733767025290" ID="ID_741129447" MODIFIED="1733767039637" TEXT="daraus sollen die Accessoren erzeugbar sein"/>
<node CREATED="1733767103376" ID="ID_36453586" MODIFIED="1733767123425" TEXT="w&#xfc;nschenswert: factory-Funktionen f&#xfc;r bestimmte Storage-Bl&#xf6;cke"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733767147610" ID="ID_966052237" MODIFIED="1733767188150" TEXT="Zugriff auf einzelne Datenwerte per Accessor">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733767161520" ID="ID_1853669534" MODIFIED="1733767188150" TEXT="Standard-Definition f&#xfc;r TurnoutSystem auf dieser Basis">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
</node>
</node>
@ -95016,6 +95357,10 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<arrowlink COLOR="#ff1551" DESTINATION="ID_1233624332" ENDARROW="Default" ENDINCLINATION="-1880;100;" ID="Arrow_ID_62498933" STARTARROW="None" STARTINCLINATION="4449;305;"/>
<linktarget COLOR="#8d0757" DESTINATION="ID_1123241919" ENDARROW="Default" ENDINCLINATION="-491;33;" ID="Arrow_ID_771540131" SOURCE="ID_1412088712" STARTARROW="None" STARTINCLINATION="-327;758;"/>
<icon BUILTIN="yes"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1733702233640" HGAP="34" ID="ID_1427414774" MODIFIED="1733702333091" TEXT="Node-Parameter k&#xf6;nnten gef&#xe4;hrlich werden" VSHIFT="35">
<arrowlink COLOR="#a5075a" DESTINATION="ID_1997478599" ENDARROW="Default" ENDINCLINATION="-1987;137;" ID="Arrow_ID_830705993" STARTARROW="None" STARTINCLINATION="118;7;"/>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1730486371054" HGAP="24" ID="ID_939499486" MODIFIED="1730487590452" TEXT="Node-Metadaten" VSHIFT="7">
@ -96849,8 +97194,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
per Default ist stets eine <i>absolute nominal Time</i>&#160;gegeben
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head/>
<body>