Invocation: anchor data frame in TurnoutSystem
So this is a design sketch how a `ParamBuildSpec` descriptor could be created, which in turn would provide the foundation to implement a ''Parameter Weaving Pattern...'' __Note__: since this is an extension for advanced usage, yet relies on a storage layout defined to allow for extensions like this use case here, the anchor type is now defined to reside in the `TurnoutSystem` in the form of a ''standard parameter block''. Those standard invocation parameters are fixed and thus can be hard coded.
This commit is contained in:
parent
7d8c0c5753
commit
3406b6abf5
5 changed files with 185 additions and 164 deletions
|
|
@ -1,8 +1,7 @@
|
|||
/*
|
||||
PARAM-WEAVING-PATTERN.hpp - Base patterns to organise data connections and render processing invocation
|
||||
PARAM-WEAVING-PATTERN.hpp - Pattern to carry out special parameter computations
|
||||
|
||||
Copyright (C)
|
||||
2008, Hermann Vosseler <Ichthyostega@web.de>
|
||||
2024, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
||||
**Lumiera** is free software; you can redistribute it and/or modify it
|
||||
|
|
@ -14,116 +13,22 @@
|
|||
|
||||
|
||||
/** @file param-weaving-pattern.hpp
|
||||
** Construction set to assemble and operate a data processing scheme within a Render Node.
|
||||
** Together with turnout.hpp, this header provides the "glue" which holds together the
|
||||
** typical setup of a Render Node network for processing media data. A MediaWeavingPattern
|
||||
** implements the sequence of steps — as driven by the Turnout — to combine the invocation
|
||||
** of media processing operations from external Libraries with the buffer- and parameter
|
||||
** management provided by the Lumiera Render Engine. Since these operations are conducted
|
||||
** concurrently, all invocation state has to be maintained in local storage on the stack.
|
||||
** Construction kit to establish a set of parameters pre-computed prior to invocation
|
||||
** of nested nodes. This arrangement is also known as »Parameter Agent Node« (while actually
|
||||
** it is a Weaving Patter residing within some Node's Port). The use-case is to provide a set
|
||||
** of additional parameter values, beyond what can be derived directly by a parameter-functor
|
||||
** based on the _absolute-nominal-Time_ of the invocation. The necessity for such a setup may
|
||||
** arise when additional context or external state must be combined with the nominal time into
|
||||
** a tuple of data values, which shall then be consumed by several follow-up evaluations further
|
||||
** down into a recursive invocation tree _for one single render job._ The solution provided by
|
||||
** the Parameter Agent Node relies on placing those additional data values into a tuple stored
|
||||
** directly in the render invocation stack frame, prior to descending into further recursive
|
||||
** Node evaluations. Notably, parameter-functors within the scope of this evaluation tree can
|
||||
** then access these additional parameters through the TurnoutSystem of the overall invocation.
|
||||
**
|
||||
** # Integration with media handling Libraries
|
||||
**
|
||||
** A Render invocation originates from a [Render Job](\ref render-invocation.hpp), which first
|
||||
** establishes a TurnoutSystem and then enters into the recursive Render Node activation by
|
||||
** invoking Port::weave() for the »Exit Node«, as defined by the job's invocation parameters.
|
||||
** The first step in the processing cycle, as established by the Port implementation (\ref Turnout),
|
||||
** is to build a »Feed instance«, from the invocation of `mount(TurnoutSystem&)`.
|
||||
**
|
||||
** Generally speaking, a `Feed` fulfils the role of an _Invocation Adapter_ and a _Manifold_ of
|
||||
** data connections. The standard implementation, as given by MediaWeavingPattern, relies on a
|
||||
** combination of both into a \ref FeedManifold. This is a flexibly configured data adapter,
|
||||
** directly combined with an embedded _adapter functor_ to wrap the invocation of processing
|
||||
** operations provided by an external library.
|
||||
**
|
||||
** Usually some kind of internal systematics is assumed and applied within such a library.
|
||||
** Operations can be exposed as plain function to invoke, or through some configuration and
|
||||
** builder notion. Function arguments tend to follow a common arrangement and naming scheme,
|
||||
** also assuming specific arrangement and data layout for input and output data. This kind of
|
||||
** schematism is rooted in something deeper: exposing useful operations as a library collection
|
||||
** requires a common ground, an understanding about the _order of things_ to be treated — at least
|
||||
** for those kind of things, which fall into a specific _domain,_ when tasks related to such a
|
||||
** domain shall be supported by the Library. Such an (implicit or explicit) framework of structuring
|
||||
** is usually designated as a **Domain Ontology** (in contrast to the questions pertaining Ontology
|
||||
** in general, which are the subject of philosophy proper). Even seemingly practical matters like
|
||||
** processing media data do rely on fundamental assumptions and basic premises regarding what is
|
||||
** at stake and what shall be subject to treatment, what fundamental entities and relationships
|
||||
** to consider within the domain. Incidentally, many of these assumptions are positive in nature
|
||||
** and not necessarily a given — which is the root of essential incompatibilities between Libraries
|
||||
** targeting a similar domain: due to such fundamental differences, they just can not totally agree
|
||||
** upon what kinds of things to expect and where to draw the line of distinction.
|
||||
**
|
||||
** The Lumiera Render Engine and media handling framework is built in a way _fundamentally agnostic_
|
||||
** to the specific presuppositions of this or that media handling library. By and large, decisions,
|
||||
** distinctions and qualifications are redirected back into the scope of the respective library, by
|
||||
** means of a media-library adapter plug-in. Assuming that the user _in fact understands_ the meaning
|
||||
** of and reasoning behind employing a given library, the _mere handling_ of the related processing
|
||||
** can be reduced to a small set of organisational traits. For sake of consistency, you may label
|
||||
** these as a »Render Engine Ontology«. In all brevity,
|
||||
** - We assume that the library provides distinguishable processing operations
|
||||
** that can be structured and classified and managed as _processing assets,_
|
||||
** - we assume that processing is applied to sources or »media« and that
|
||||
** the result of processing is again a source that can be processed further;
|
||||
** - specific operations can thus be conceptualised as processing-stages or _Nodes,_
|
||||
** interconnected by _media streams,_ which can be tagged with a _stream type._
|
||||
** - At implementation level, such streams can be represented in entirety as data buffers
|
||||
** of a specific layout, filled with some »frame« or chunk of data
|
||||
** - and the single processing step or operation can be completely encapsulated
|
||||
** as a pure function (referentially transparent, without side effects);
|
||||
** - all state and parametrisation can be represented either as some further data stream in/out,
|
||||
** or as parameters-of-processing, which can be passed as a set of values to the function
|
||||
** prior of invocation, thereby completely determining the observable behaviour.
|
||||
**
|
||||
** # composition of the Invocation State
|
||||
**
|
||||
** By means of this positing, the attachment point to an external library can be reduced into a small
|
||||
** number of connector links. Handling the capabilities of a library within the Session and high-level Model
|
||||
** will require some kind of _registration,_ which is beyond the scope of this discussion here. As far as
|
||||
** the Render Engine and the low-level-Model is concerned, any usage of the external libraries capabilities
|
||||
** can be reduced into...
|
||||
** - Preparing an adapter functor, designated as **processing-functor**. This functor takes three kinds of
|
||||
** arguments, each packaged as a single function call argument, which may either be a single item, or
|
||||
** possibly be structured as a tuple of heterogeneous elements, or an array of homogeneous items.
|
||||
** + an output data buffer or several such buffers are always required
|
||||
** + (optionally) an input buffer or several such buffers need to be supplied
|
||||
** + (optionally) also a parameter value, tuple or array can be specified
|
||||
** - Supplying actual parameter values (if necessary); these are drawn from the invocation
|
||||
** of a further functor, designated as **parameter-functor**, and provided from within
|
||||
** the internal framework of the Lumiera application, either to deliver fixed parameter
|
||||
** settings configured by the user in the Session, or by evaluating _Parameter Automation,_
|
||||
** or simply to supply some technically necessary context information, most notably the
|
||||
** frame number of a source to retrieve.
|
||||
** - Preparing buffers filled with input data, in a suitable format, one for each distinct
|
||||
** item expected in the input data section of the processing-functor; filling these
|
||||
** input buffers requires the _recursive invocation_ of further Render Nodes...
|
||||
** - Allocating buffers for output data, sized and typed accordingly, likewise one for
|
||||
** each distinct item detailed in the output data argument of the processing-functor.
|
||||
**
|
||||
** The FeedManifold template, which (as mentioned above) is used by this standard implementation
|
||||
** of media processing in the form of the MediaWeavingPattern, is configured specifically for each
|
||||
** distinct signature of a processing-functor to match the implied structural requirements. If a
|
||||
** functor is output-only, no input buffer section is present; if it expects processing parameters,
|
||||
** storage for an appropriate data tuple is provided and a parameter-functor can be configured.
|
||||
** A clone-copy of the processing-functor itself is also stored as clone-copy alongside within
|
||||
** the FeedManifold, and thus placed into stack memory, where it is safe even during deeply nested
|
||||
** recursive invocation sequences, while rendering in general is performed massively in parallel.
|
||||
**
|
||||
** In the end, the actual implementation code of the weaving pattern has to perform the connection
|
||||
** and integration between the »recursive weaving scheme« and the invocation structure implied by
|
||||
** the FeedManifold. It has to set off the recursive pull-invocation of predecessor ports, retrieve
|
||||
** the result data buffers from these and configure the FeedManifold with the \ref BuffHandle entries
|
||||
** retrieved from these recursive calls. Buffer handling in general is abstracted and codified thorough
|
||||
** the [Buffer Provider framework](\ref buffer-provider.hpp), which offers the means to allocate further
|
||||
** buffers and configure them into the FeedManifold for the output data. The »buffer handling protocol«
|
||||
** also requires to invoke BuffHandle::emit() at the point when result data can be assumed to be placed
|
||||
** into the buffer, and to release buffers not further required through a BuffHandle::release() call;
|
||||
** Notably this applies to the input buffers are completion of the processing-functor invocation, and
|
||||
** is required also for secondary (and in a way, superfluous) result buffers, which are sometimes
|
||||
** generated as a by-product of the processing function invocation, but are actually not passed
|
||||
** as output up the node invocation chain.
|
||||
**
|
||||
** @see feed-manifold.hpp
|
||||
** @see node-builder.hpp
|
||||
** @see weaving-pattern-builder.hpp
|
||||
** @see NodeFeed_test::feedParamNode()
|
||||
** @see \ref proc-node.hpp "Overview of Render Node structures"
|
||||
**
|
||||
** @warning WIP as of 12/2024 first complete integration round of the Render engine ////////////////////////////TICKET #1367
|
||||
|
|
@ -137,7 +42,7 @@
|
|||
#include "steam/common.hpp"
|
||||
#include "steam/engine/turnout.hpp"
|
||||
#include "steam/engine/turnout-system.hpp"
|
||||
#include "steam/engine/feed-manifold.hpp"
|
||||
#include "steam/engine/feed-manifold.hpp" ////////////TODO wegdamit
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
//#include "vault/gear/job.h"
|
||||
//#include "steam/engine/exit-node.hpp"
|
||||
|
|
@ -151,27 +56,39 @@
|
|||
//#include "lib/util.hpp" ////////OOO wegen manifoldSiz<FUN>()
|
||||
|
||||
//#include <stack>
|
||||
#include <tuple>
|
||||
#include <utility>
|
||||
|
||||
|
||||
namespace steam {
|
||||
namespace engine {
|
||||
|
||||
using lib::Several;
|
||||
using std::move;
|
||||
using std::tuple;
|
||||
using lib::Several;////TODO RLY?
|
||||
|
||||
|
||||
template<class ANK, typename...FUNZ>
|
||||
struct ParamBuildSpec
|
||||
{
|
||||
using Functors = tuple<FUNZ...>;
|
||||
|
||||
Functors functors_;
|
||||
|
||||
ParamBuildSpec (Functors&& funz)
|
||||
: functors_{move (funz)}
|
||||
{ }
|
||||
};
|
||||
|
||||
auto
|
||||
buildParamSpec()
|
||||
{
|
||||
return ParamBuildSpec<TurnoutSystem::FrontBlock>{tuple<>{}};
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* Standard implementation for a _Weaving Pattern_ to connect
|
||||
* the input and output data feeds (buffers) into a processing function.
|
||||
* @tparam INVO a configuration / policy base class to _adapt for invocation_
|
||||
* @note assumptions made regarding the overall structure
|
||||
* - `INVO::Feed` defines an _invocation adapter_ for the processing function
|
||||
* - `INVO::buildFeed()` is a functor to (repeatedly) build `Feed` instances
|
||||
* - the _invocation adapter_ in turn embeds a `FeedManifold<FUN>` to hold
|
||||
* + a setup of output buffer pointers (single, tuple or array)
|
||||
* + (optionally) a similar setup for input buffer pointers
|
||||
* + (optionally) a parameter or parameter tuple
|
||||
* + storage to configure BuffHandle entries for each «slot»
|
||||
* + storage to hold the actual processing functor
|
||||
* Implementation for a _Weaving Pattern_ to conduct extended parameter evaluation.
|
||||
*/
|
||||
template<class INVO>
|
||||
struct ParamWeavingPattern
|
||||
|
|
|
|||
|
|
@ -50,13 +50,6 @@ namespace engine {
|
|||
using lib::time::Time;
|
||||
using ProcessKey = uint64_t;
|
||||
|
||||
template<typename VAL>
|
||||
class ParamStorageFrame
|
||||
: util::NonCopyable
|
||||
{
|
||||
|
||||
};
|
||||
|
||||
|
||||
/**
|
||||
* Communication hub to coordinate and activate the »Render Node Network« performance.
|
||||
|
|
@ -65,12 +58,18 @@ namespace engine {
|
|||
* and initiates the recursive pull()-call into the render node network as attached for this call.
|
||||
*/
|
||||
class TurnoutSystem
|
||||
: util::NonCopyable
|
||||
{
|
||||
/////////////////////////////////////////////////////////OOO Storage: ich brauche Overflow-Buckets. KISS ==> erst mal intrusive linked List
|
||||
public:
|
||||
using FrontBlock = lib::HeteroData<Time,ProcessKey>;
|
||||
|
||||
private:
|
||||
FrontBlock invoParam_;
|
||||
|
||||
public:
|
||||
TurnoutSystem (Time absoluteNominalTime, ProcessKey procKey =0)
|
||||
: invoParam_{FrontBlock::build (absoluteNominalTime,procKey)}
|
||||
{ }
|
||||
// this is a copyable front-end object
|
||||
};
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -20,6 +20,7 @@
|
|||
#include "steam/engine/proc-node.hpp"
|
||||
#include "steam/engine/node-builder.hpp"
|
||||
#include "steam/engine/media-weaving-pattern.hpp"
|
||||
#include "steam/engine/param-weaving-pattern.hpp"
|
||||
#include "steam/engine/turnout-system.hpp"
|
||||
#include "steam/engine/turnout.hpp"
|
||||
#include "steam/engine/diagnostic-buffer-provider.hpp"
|
||||
|
|
@ -104,7 +105,8 @@ namespace test {
|
|||
void
|
||||
feedParamNode()
|
||||
{
|
||||
TODO ("implement the logic for the TurnoutSystem --> node-base-test.cpp");
|
||||
auto spec = buildParamSpec();
|
||||
SHOW_TYPE(decltype(spec))
|
||||
TODO ("implement a simple Builder for ParamAgent-Node");
|
||||
TODO ("then use both together to demonstrate a param data feed here");
|
||||
}
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ namespace test{
|
|||
/** @test demonstrate elaborate storage layout with several chain frames
|
||||
* - follow-up frames shall be built using constructor types
|
||||
* - these can be defined prior to any data allocation
|
||||
* - individual data elements can be accessed type-safe through accessor functors
|
||||
* - individual data elements can be accessed through type-safe accessor functors
|
||||
* @warning as demonstrated, this is a dangerous bare-bone memory layout without runtime checks!
|
||||
*/
|
||||
void
|
||||
|
|
|
|||
|
|
@ -29309,9 +29309,7 @@
|
|||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1560304911496" ID="ID_241280957" MODIFIED="1560305044856" TEXT="macht nämlich drei Indirektionen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<ol>
|
||||
<li>
|
||||
|
|
@ -30903,9 +30901,7 @@
|
|||
</node>
|
||||
<node CREATED="1612027859654" ID="ID_1866609580" MODIFIED="1612027898972">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<b><font color="#6d2828">Konvention</font></b>: Clips mit start==Time::NEVER werden verborgen
|
||||
|
|
@ -31325,9 +31321,7 @@
|
|||
</node>
|
||||
<node COLOR="#338800" CREATED="1562970409637" ID="ID_156221819" MODIFIED="1563033490587" TEXT="ihm den Pfad zuweisen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
 void set_path(const WidgetPath& path);
|
||||
|
|
@ -31728,9 +31722,7 @@
|
|||
</body>
|
||||
</html></richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
denn was passiert, wenn sich durch das Setzen einer neuen Größe der sichtbare Bereich ändert? Löst das dann nicht erneut einen draw()-Aufruf aus??
|
||||
|
|
@ -82274,8 +82266,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
Beachte: es handelt sich um einen Erweiterungspunkt von <i>theoretischer Relevanz...</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -82312,8 +82303,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
⟹ folglich braucht es eine vorgelagerte <b><font face="Monospaced" color="#1c0b4e">ParamBuildSpec</font></b>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1735350499597" ID="ID_499331038" MODIFIED="1735350817902" TEXT="sonstiges Layout ist implizit">
|
||||
<node CREATED="1735350823586" ID="ID_1873404429" MODIFIED="1735351601621" TEXT="in der ParamBuildSpec....">
|
||||
|
|
@ -88258,8 +88248,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
der PortBuilder kann einen Adapter für klassische Parameter-Automation bauen; dieser muß intern auf die <i>absolute-nominal-Time</i>  zugreifen können
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1735319814705" ID="ID_1191574208" MODIFIED="1735321333153" TEXT="Zugang zu Chain-Datablock Typ-Konstruktor aus dem NodeBuilder">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -88295,8 +88284,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
die konkreten Accessoren werden als spezielle Typisierung in einen privaten Kontext in ein invocation-λ eingebettet, so daß sie nur aus dem Scope der tatsächlichen Invocation heraus sichtbar sind; solange dieser Scope lebt, ist <i>per Definitionem</i> auch zumindest dieser Chain-Block valide und zugreifbar.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -91307,8 +91295,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1720546521352" ID="ID_1680202759" MODIFIED="1735415902955" TEXT="ein einfaches WeavingPattern für einen 1:1 Aufruf">
|
||||
<linktarget COLOR="#ff6936" DESTINATION="ID_1680202759" ENDARROW="Default" ENDINCLINATION="-884;1900;" ID="Arrow_ID_1934503032" SOURCE="ID_313412689" STARTARROW="None" STARTINCLINATION="789;48;"/>
|
||||
<linktarget COLOR="#4033e3" DESTINATION="ID_1680202759" ENDARROW="Default" ENDINCLINATION="-2222;-127;" ID="Arrow_ID_607031123" SOURCE="ID_882727048" STARTARROW="None" STARTINCLINATION="2266;131;"/>
|
||||
<linktarget COLOR="#ff6936" DESTINATION="ID_1680202759" ENDARROW="Default" ENDINCLINATION="-884;1900;" ID="Arrow_ID_1934503032" SOURCE="ID_313412689" STARTARROW="None" STARTINCLINATION="789;48;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1720567224202" ID="ID_933061351" MODIFIED="1720567366517" TEXT="Buffer-Konstruktor-Spec bereitstellen">
|
||||
<arrowlink COLOR="#6555a4" DESTINATION="ID_33806321" ENDARROW="Default" ENDINCLINATION="-432;713;" ID="Arrow_ID_1589842372" STARTARROW="None" STARTINCLINATION="-186;-18;"/>
|
||||
|
|
@ -94171,12 +94159,130 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1720546521352" ID="ID_348960119" MODIFIED="1735416007612" TEXT="ein WeavingPattern für erweiterte Parameter-Auswertung">
|
||||
<linktarget COLOR="#9b505d" DESTINATION="ID_348960119" ENDARROW="Default" ENDINCLINATION="116;-502;" ID="Arrow_ID_967296024" SOURCE="ID_1908488051" STARTARROW="None" STARTINCLINATION="78;483;"/>
|
||||
<linktarget COLOR="#4033e3" DESTINATION="ID_348960119" ENDARROW="Default" ENDINCLINATION="-2228;-103;" ID="Arrow_ID_1086551966" SOURCE="ID_1769136387" STARTARROW="None" STARTINCLINATION="1977;97;"/>
|
||||
<linktarget COLOR="#ff6936" DESTINATION="ID_348960119" ENDARROW="Default" ENDINCLINATION="-641;1944;" ID="Arrow_ID_1163958018" SOURCE="ID_311704401" STARTARROW="None" STARTINCLINATION="1383;132;"/>
|
||||
<linktarget COLOR="#9b505d" DESTINATION="ID_348960119" ENDARROW="Default" ENDINCLINATION="116;-502;" ID="Arrow_ID_967296024" SOURCE="ID_1908488051" STARTARROW="None" STARTINCLINATION="78;483;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1735416170297" ID="ID_736958022" MODIFIED="1735416236279" TEXT="brauche ParamBuildSpec">
|
||||
<linktarget COLOR="#bb1f2e" DESTINATION="ID_736958022" ENDARROW="Default" ENDINCLINATION="-25;-162;" ID="Arrow_ID_44922252" SOURCE="ID_1577179744" STARTARROW="None" STARTINCLINATION="32;153;"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1735422554816" ID="ID_197118422" MODIFIED="1735422583207" TEXT="Aufgabe: schrittweise aufbauenbar">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1735422591091" ID="ID_1649575055" MODIFIED="1735422735480" TEXT="Diskrepanz zu den HeteroData Chain-Blocks">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Zur Erinnerung: HeteroData ist ein low-level Daten-Layout, das ich speziell für den Anwendungsfall im Turnout mir ausgedacht habe; es beruht auf einer single-linked-List von Datenblöcken, in denen jeweils ein Datentupel sitzt. Und hier liegt das Problem: diese Chain-Blöcke sollen nun schrittweise über eine Builder-Notation aufgebaut werden — aber die Konstruktor-Funktion in HeteroData erwartet die Angabe des <i>ganzen Tupel-Typs auf einmal.</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
<node CREATED="1735428828881" ID="ID_144632434" MODIFIED="1735428918508" TEXT="soll aber aus konkreten Funktoren schrittweise erstellt werden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
daher scheidet ein Typ-Konstruktor als Einstiegspunkt aus; man kann nämlich i.d.R. vom User nicht erwerten, daß der jeweilige Funktor-Typ explizit anggebbar ist
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1735428922213" ID="ID_1087023158" MODIFIED="1735429043231" TEXT="der Chain-Block exisiert noch nicht ⟹ Variadische Sequenz erweitern">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
man baut ja schrittweise diese ParamBuildSpec auf ⟹ also muß es nicht gleich <i>der final korrekte</i> Tupel-Typ sein; erst wenn man damit tatsächlich alloziert, legen wir uns fest.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1735429416834" ID="ID_1663817849" MODIFIED="1735429437587" TEXT="vorgeschalteter cons-Builder mit std::tuple_cat">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1735430700235" ID="ID_1331974543" MODIFIED="1735430805737" TEXT="Startpunkt setzt direkt auf TurnoutSystem auf">
|
||||
<arrowlink COLOR="#637488" DESTINATION="ID_870944737" ENDARROW="Default" ENDINCLINATION="310;0;" ID="Arrow_ID_1871378220" STARTARROW="None" STARTINCLINATION="145;9;"/>
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1735430768108" ID="ID_1744058203" MODIFIED="1735430784322" TEXT="cross-builder-Funktionen in ParamBuildSpec selber">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1735424043425" ID="ID_1762182807" MODIFIED="1735424060122" TEXT="Anforderungen in der Verwendung">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1735424265508" ID="ID_1814686800" MODIFIED="1735424277302" TEXT="speichert ein Tupel von parameter-Funktoren"/>
|
||||
<node CREATED="1735424284183" ID="ID_318636546" MODIFIED="1735424295714" TEXT="daraus ergibt sich auch der Parameter-Tupel-Typ"/>
|
||||
<node CREATED="1735426958276" ID="ID_803365380" MODIFIED="1735426990030" TEXT="außerdem möchte man konkrete Accessoren via TurnoutSystem"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1735427341106" ID="ID_29906476" MODIFIED="1735427368610" TEXT="Lösung aufbauen...">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1735427377686" ID="ID_1047293090" MODIFIED="1735427389228" TEXT="Typisierung">
|
||||
<node CREATED="1735427448052" ID="ID_1835841396" MODIFIED="1735427511976" TEXT="muß komplett explizit sein">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
also ein Instanz-Typ allein legt alles fest; keine Indirektion oder Virtualisierung
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1735427390364" ID="ID_986815728" MODIFIED="1735427699072" TEXT="die Funktor-Typen müssen wir speichern">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
damit liegt das unumgängliche Minimum an Information bereits fest; insofern wir explizit getypte Funktoren durch das System grundsätzlich durchreichen können wollen (nicht bloß std::function-Instanzen), bleibt keine Alternative, als diese Typen in ein Tupel zu packen....
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1735427701004" ID="ID_1334845068" MODIFIED="1735427819216" TEXT="außerdem einen Prefix-Chain-Typ">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...weil wir allein mit einer solchen ParamBuildSpec auf ein TurnoutSystem losgehen wollen; eine Hetero-Data prefix-Chain ist damit notwendig, als Anker-Punkt um einen konkreten Konstruktor für einen Chain-Block zu generieren, den wir in den aktuellen StackFrame legen wollen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1735427835239" ID="ID_162062555" MODIFIED="1735427854369" TEXT="alle anderen Infos lassen sich ableiten">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1735428034560" ID="ID_1142877751" MODIFIED="1735428275201">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
also <font color="#0e08bb" face="Monospaced"><b>ParamBuildSpec</b><</font><font color="#5208bb" face="Monospaced">ANK, FUNZ...</font><font color="#0e08bb" face="Monospaced">></font>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1735428301318" ID="ID_220200650" MODIFIED="1735428312686" TEXT="Abhängigkeiten...">
|
||||
<node CREATED="1735428349062" ID="ID_238393105" MODIFIED="1735428359713" TEXT="ist eine spezielle Erweiterung"/>
|
||||
<node CREATED="1735428361549" ID="ID_276493065" MODIFIED="1735428374655" TEXT="wird daher auf TurnoutSytem aufgesetzt"/>
|
||||
<node CREATED="1735428381258" ID="ID_1505593640" MODIFIED="1735428395972" TEXT="kann also nicht direkt in TurnoutSystem integriert sein"/>
|
||||
<node CREATED="1735428433826" ID="ID_870944737" MODIFIED="1735430805738">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
⟹ Ankerpunkt muß ein nested type <font color="#320bca" face="Monospaced">TurnoutSystem::FrontBlock </font>sein
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<linktarget COLOR="#637488" DESTINATION="ID_870944737" ENDARROW="Default" ENDINCLINATION="310;0;" ID="Arrow_ID_1871378220" SOURCE="ID_1331974543" STARTARROW="None" STARTINCLINATION="145;9;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1735416468553" ID="ID_1257939291" MODIFIED="1735416600613" TEXT="dient als Basis für einen ParamNode-Builder">
|
||||
<arrowlink COLOR="#5747d2" DESTINATION="ID_329885446" ENDARROW="Default" ENDINCLINATION="-844;-25;" ID="Arrow_ID_1824926310" STARTARROW="None" STARTINCLINATION="-633;42;"/>
|
||||
</node>
|
||||
|
|
@ -97610,8 +97716,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1735416494813" ID="ID_329885446" MODIFIED="1735417263442" TEXT="Builder für dedizierte ParamNode">
|
||||
<linktarget COLOR="#5747d2" DESTINATION="ID_329885446" ENDARROW="Default" ENDINCLINATION="-844;-25;" ID="Arrow_ID_1824926310" SOURCE="ID_1257939291" STARTARROW="None" STARTINCLINATION="-633;42;"/>
|
||||
<linktarget COLOR="#482c86" DESTINATION="ID_329885446" ENDARROW="Default" ENDINCLINATION="-553;-36;" ID="Arrow_ID_1024921689" SOURCE="ID_921902157" STARTARROW="None" STARTINCLINATION="598;1114;"/>
|
||||
<linktarget COLOR="#5747d2" DESTINATION="ID_329885446" ENDARROW="Default" ENDINCLINATION="-844;-25;" ID="Arrow_ID_1824926310" SOURCE="ID_1257939291" STARTARROW="None" STARTINCLINATION="-633;42;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1735416968791" HGAP="28" ID="ID_1420751527" MODIFIED="1735417275282" STYLE="bubble" VSHIFT="20">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
|
|
@ -97624,8 +97730,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<font face="Monospaced">NodeFeed_test::</font><font color="#990000" face="Monospaced"><b>feedParamNode</b>()</font>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<edge COLOR="#3495a4"/>
|
||||
<arrowlink COLOR="#53a3b5" DESTINATION="ID_1559115287" ENDARROW="Default" ENDINCLINATION="-116;8;" ID="Arrow_ID_35370272" STARTARROW="None" STARTINCLINATION="-39;-6;"/>
|
||||
</node>
|
||||
|
|
@ -97701,8 +97806,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
Über das Prototyping hat eine Art Normierung stattgefunden; ich bin jetzt sicher, daß die allermeisten Aufgaben zur Medien-Berechnung in dieses Standard-Pattern abgebildet werden können, vor allem durch die stark erweiterte Flexibilität des Buffer- und Parameter-Bindings
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#4b5f94" DESTINATION="ID_1436882221" ENDARROW="Default" ENDINCLINATION="114;-2;" ID="Arrow_ID_1816177660" STARTARROW="None" STARTINCLINATION="-320;14;"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -100010,8 +100114,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
Für die Parameter-Behandlung <i>sind komplexe Spezialfälle vorhersehbar, </i>welche die Pasis-Parameter, den Kontext-Zugriff über einen Prozeß-Key, sowie weitere, kontextuell zugängliche Zustandsdaten in einen erweiterten Satz konkreter Steuerparameter synthetisieren, um diese dann an anderer Stelle, rekursiv tiefer im Invocation-Tree, zur Parametrisierung der Medien-Berechnung heranzuziehen. Ein solches Muster ist in der Tat „speziell“ und ohne im Moment für mich erkennbaren konkreten Bezug; ich leite diese Möglichkeit lediglich aus allgemeinen Überlegungen zur Struktur her, und ziehe den Schluß, <i>zumindest die Ansatzpunkte hierfür</i> schaffen zu müssen....
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
|
||||
<arrowlink COLOR="#6c6489" DESTINATION="ID_1650778246" ENDARROW="Default" ENDINCLINATION="-274;1070;" ID="Arrow_ID_1212360945" STARTARROW="None" STARTINCLINATION="1789;61;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
|
|
|
|||
Loading…
Reference in a new issue