Invocation: this »weaving-pattern« evolves into a default
Starting from a prototypical implementation, where each »slot« in the function is directly connected to the corresponding lead / port, the implementation of the `SimpleWeavingPattern` (as it was called previously) could be augmented and adapted gradually — and seems well suited to cover most standard cases of ''media processing'' So a name change is mandated, and the code is also extracted and relocated, possibly even to be combined with the code of the `InvocationAdapter`, thereby hopefully making the implementation more accessible Generally speaking, ''weaving patterns'' take on the role of the prime extension point regarding `Port` implementation.
This commit is contained in:
parent
42af5bc4e7
commit
991f0a31f4
5 changed files with 216 additions and 373 deletions
|
|
@ -54,29 +54,14 @@
|
|||
#include "steam/common.hpp"
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
#include "steam/engine/turnout-system.hpp"
|
||||
#include "steam/engine/feed-manifold.hpp"
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
//#include "vault/gear/job.h"
|
||||
//#include "steam/engine/exit-node.hpp"
|
||||
//#include "lib/time/timevalue.hpp"
|
||||
//#include "lib/linked-elements.hpp"
|
||||
#include "lib/several.hpp"
|
||||
//#include "lib/util-foreach.hpp"
|
||||
//#include "lib/iter-adapter.hpp"
|
||||
#include "lib/meta/function.hpp"
|
||||
//#include "lib/itertools.hpp"
|
||||
//#include "lib/util.hpp" ////////OOO wegen manifoldSiz<FUN>()
|
||||
|
||||
#include <utility>
|
||||
#include <array>
|
||||
//#include <stack>
|
||||
|
||||
|
||||
namespace steam {
|
||||
namespace engine {
|
||||
|
||||
using std::forward;
|
||||
using lib::Several;
|
||||
|
||||
|
||||
/**
|
||||
|
|
@ -97,98 +82,19 @@ namespace engine {
|
|||
}
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* 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<N>` to hold
|
||||
* + an array of input buffer pointers
|
||||
* + an array of output buffer pointers
|
||||
* + `INVO::MAX_SIZ` limits both arrays
|
||||
*/
|
||||
template<class INVO>
|
||||
struct SimpleWeavingPattern
|
||||
: INVO
|
||||
template<class PAT>
|
||||
constexpr bool
|
||||
_verify_usable_as_WeavingPattern()
|
||||
{
|
||||
using Feed = typename INVO::Feed;
|
||||
|
||||
static_assert (_verify_usable_as_InvocationAdapter<Feed>());
|
||||
|
||||
Several<PortRef> leadPort;
|
||||
Several<BuffDescr> outTypes;
|
||||
|
||||
uint resultSlot{0};
|
||||
|
||||
/** forwarding-ctor to provide the detailed input/output connections */
|
||||
template<typename...ARGS>
|
||||
SimpleWeavingPattern (Several<PortRef>&& pr
|
||||
,Several<BuffDescr>&& dr
|
||||
,uint resultIdx
|
||||
,ARGS&& ...args)
|
||||
: INVO{forward<ARGS>(args)...}
|
||||
, leadPort{move(pr)}
|
||||
, outTypes{move(dr)}
|
||||
, resultSlot{resultIdx}
|
||||
{ }
|
||||
|
||||
|
||||
Feed
|
||||
mount()
|
||||
{
|
||||
return INVO::buildFeed();
|
||||
using Feed = typename PAT::Feed;
|
||||
ASSERT_MEMBER_FUNCTOR (&PAT::mount, Feed());
|
||||
ASSERT_MEMBER_FUNCTOR (&PAT::pull, void(Feed&, TurnoutSystem&));
|
||||
ASSERT_MEMBER_FUNCTOR (&PAT::shed, void(Feed&, OptionalBuff));
|
||||
ASSERT_MEMBER_FUNCTOR (&PAT::weft, void(Feed&));
|
||||
ASSERT_MEMBER_FUNCTOR (&PAT::fix, BuffHandle(Feed&));
|
||||
return sizeof(PAT);
|
||||
}
|
||||
|
||||
void
|
||||
pull (Feed& feed, TurnoutSystem& turnoutSys)
|
||||
{
|
||||
for (uint i=0; i<leadPort.size(); ++i)
|
||||
{
|
||||
BuffHandle inputData = leadPort[i].get().weave (turnoutSys);
|
||||
feed.inBuff.createAt(i, move(inputData));
|
||||
}
|
||||
}
|
||||
|
||||
void
|
||||
shed (Feed& feed, OptionalBuff outBuff)
|
||||
{
|
||||
for (uint i=0; i<outTypes.size(); ++i)
|
||||
{
|
||||
BuffHandle resultData =
|
||||
i == resultSlot and outBuff? *outBuff
|
||||
: outTypes[i].lockBuffer();
|
||||
feed.outBuff.createAt(i, move(resultData));
|
||||
}
|
||||
feed.connect (leadPort.size(),outTypes.size());
|
||||
}
|
||||
|
||||
void
|
||||
weft (Feed& feed)
|
||||
{
|
||||
feed.invoke(); // process data
|
||||
}
|
||||
|
||||
BuffHandle
|
||||
fix (Feed& feed)
|
||||
{
|
||||
for (uint i=0; i<leadPort.size(); ++i)
|
||||
{
|
||||
feed.inBuff[i].release();
|
||||
}
|
||||
for (uint i=0; i<outTypes.size(); ++i)
|
||||
{
|
||||
feed.outBuff[i].emit(); // state transition: data ready
|
||||
if (i != resultSlot)
|
||||
feed.outBuff[i].release();
|
||||
}
|
||||
ENSURE (resultSlot < INVO::MAX_SIZ, "invalid result buffer configured.");
|
||||
return feed.outBuff[resultSlot];
|
||||
}
|
||||
|
||||
};
|
||||
|
||||
|
||||
/**
|
||||
|
|
@ -204,6 +110,8 @@ namespace engine {
|
|||
, public PAT
|
||||
// , util::MoveOnly
|
||||
{
|
||||
static_assert (_verify_usable_as_WeavingPattern<PAT>());
|
||||
|
||||
using Feed = typename PAT::Feed;
|
||||
|
||||
public:
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@
|
|||
** because the given _functor_ is constructed within a plug-in tailored to a specific
|
||||
** media processing library (e.g. FFmpeg) and thus can be a lambda to forward to the
|
||||
** actual function.
|
||||
** @note steam::engine::Turnout mixes-in the steam::engine::SimpleWeavingPattern, which in turn
|
||||
** @note steam::engine::Turnout mixes-in the steam::engine::MediaWeavingPattern, which in turn
|
||||
** inherits from an *Invocation Adapter* given as template parameter. So this constitutes
|
||||
** an *extension point* where other, more elaborate invocation schemes could be integrated.
|
||||
**
|
||||
|
|
@ -97,8 +97,8 @@
|
|||
//#include "vault/gear/job.h"
|
||||
#include "lib/several-builder.hpp"
|
||||
#include "steam/engine/proc-id.hpp"
|
||||
#include "steam/engine/turnout.hpp"
|
||||
#include "steam/engine/engine-ctx.hpp"
|
||||
#include "steam/engine/weaving-pattern.hpp"
|
||||
#include "steam/engine/buffer-provider.hpp"
|
||||
#include "steam/engine/buffhandle-attach.hpp" /////////////////OOO why do we need to include this? we need the accessAs<TY>() template function
|
||||
#include "lib/test/test-helper.hpp" ////////////////////////////OOO TODO added for test
|
||||
|
|
@ -347,7 +347,7 @@ namespace engine {
|
|||
|
||||
|
||||
template<uint N, class FUN>
|
||||
using SimpleDirectInvoke = SimpleWeavingPattern<DirectFunctionInvocation<N,FUN>>;
|
||||
using SimpleDirectInvoke = MediaWeavingPattern<DirectFunctionInvocation<N,FUN>>;
|
||||
|
||||
|
||||
/**
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@
|
|||
#define STEAM_ENGINE_WEAVING_PATTERN_H
|
||||
|
||||
#include "steam/common.hpp"
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
#include "steam/engine/turnout.hpp"
|
||||
#include "steam/engine/turnout-system.hpp"
|
||||
#include "steam/engine/feed-manifold.hpp"
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
|
@ -77,174 +77,6 @@ namespace engine {
|
|||
using std::forward;
|
||||
using lib::Several;
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
/**
|
||||
* Adapter to shield the ProcNode from the actual buffer management,
|
||||
* allowing the processing function within ProcNode to use logical
|
||||
* buffer IDs. StateAdapter is created on the stack for each pull()
|
||||
* call, using setup/wiring data preconfigured by the builder.
|
||||
* Its job is to provide the actual implementation of the Cache
|
||||
* push / fetch and recursive downcall to render the source frames.
|
||||
*/
|
||||
class StateAdapter
|
||||
: public StateClosure
|
||||
{
|
||||
protected:
|
||||
StateClosure& parent_;
|
||||
StateClosure& current_;
|
||||
|
||||
StateAdapter (StateClosure& callingProcess)
|
||||
: parent_ (callingProcess),
|
||||
current_(callingProcess.getCurrentImplementation())
|
||||
{ }
|
||||
|
||||
virtual StateClosure& getCurrentImplementation () { return current_; }
|
||||
|
||||
|
||||
|
||||
public: /* === proxying the StateClosure interface === */
|
||||
|
||||
virtual void releaseBuffer (BuffHandle& bh) { current_.releaseBuffer (bh); }
|
||||
|
||||
virtual void is_calculated (BuffHandle const& bh) { current_.is_calculated (bh); }
|
||||
|
||||
virtual BuffHandle fetch (FrameID const& fID) { return current_.fetch (fID); }
|
||||
|
||||
virtual BuffTableStorage& getBuffTableStorage() { return current_.getBuffTableStorage(); }
|
||||
|
||||
// note: allocateBuffer() is chosen specifically based on the actual node wiring
|
||||
|
||||
};
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* Invocation context state.
|
||||
* A ref to this type is carried through the chain of NEXT::step() functions
|
||||
* which form the actual invocation sequence. The various operations in this sequence
|
||||
* access the context via the references in this struct, while also using the inherited
|
||||
* public State interface. The object instance actually used as Invocation is created
|
||||
* on the stack and parametrised according to the necessities of the invocation sequence
|
||||
* actually configured. Initially, this real instance is configured without FeedManifold,
|
||||
* because the invocation may be short-circuited due to Cache hit. Otherwise, when
|
||||
* the invocation sequence actually prepares to call the process function of this
|
||||
* ProcNode, a buffer table chunk is allocated by the StateProxy and wired in.
|
||||
*/
|
||||
struct Invocation
|
||||
: StateAdapter
|
||||
{
|
||||
Connectivity const& wiring;
|
||||
const uint outNr;
|
||||
|
||||
FeedManifold* feedManifold;
|
||||
|
||||
protected:
|
||||
/** creates a new invocation context state, without FeedManifold */
|
||||
Invocation (StateClosure& callingProcess, Connectivity const& w, uint o)
|
||||
: StateAdapter(callingProcess),
|
||||
wiring(w), outNr(o),
|
||||
feedManifold(0)
|
||||
{ }
|
||||
|
||||
public:
|
||||
uint nrO() const { return wiring.nrO; }
|
||||
uint nrI() const { return wiring.nrI; }
|
||||
uint buffTabSize() const { return nrO()+nrI(); }
|
||||
|
||||
/** setup the link to an externally allocated buffer table */
|
||||
void setBuffTab (FeedManifold* b) { this->feedManifold = b; }
|
||||
|
||||
bool
|
||||
buffTab_isConsistent ()
|
||||
{
|
||||
return (feedManifold)
|
||||
&& (0 < buffTabSize())
|
||||
&& (nrO()+nrI() <= buffTabSize())
|
||||
&& (feedManifold->inBuff == &feedManifold->outBuff[nrO()] )
|
||||
&& (feedManifold->inHandle == &feedManifold->outHandle[nrO()])
|
||||
;
|
||||
}
|
||||
|
||||
|
||||
public:
|
||||
/** specialised version filling in the additional information, i.e
|
||||
* the concrete node id and the channel number in question */
|
||||
virtual FrameID const&
|
||||
genFrameID ()
|
||||
{
|
||||
return current_.genFrameID(wiring.nodeID, outNr);
|
||||
}
|
||||
|
||||
virtual FrameID const&
|
||||
genFrameID (NodeID const& nID, uint chanNo)
|
||||
{
|
||||
return current_.genFrameID (nID,chanNo);
|
||||
}
|
||||
|
||||
};
|
||||
|
||||
|
||||
////////////TICKET #249 this strategy should better be hidden within the BuffHandle ctor (and type-erased after creation)
|
||||
struct AllocBufferFromParent ///< using the parent StateAdapter for buffer allocations
|
||||
: Invocation
|
||||
{
|
||||
AllocBufferFromParent (StateClosure& sta, Connectivity const& w, const uint outCh)
|
||||
: Invocation(sta, w, outCh) {}
|
||||
|
||||
virtual BuffHandle
|
||||
allocateBuffer (const lumiera::StreamType* ty) { return parent_.allocateBuffer(ty); } ////////////TODO: actually implement the "allocate from parent" logic!
|
||||
};
|
||||
|
||||
struct AllocBufferFromCache ///< using the global current StateClosure, which will delegate to Cache
|
||||
: Invocation
|
||||
{
|
||||
AllocBufferFromCache (StateClosure& sta, Connectivity const& w, const uint outCh)
|
||||
: Invocation(sta, w, outCh) {}
|
||||
|
||||
virtual BuffHandle
|
||||
allocateBuffer (const lumiera::StreamType* ty) { return current_.allocateBuffer(ty); }
|
||||
};
|
||||
|
||||
|
||||
/**
|
||||
* The real invocation context state implementation. It is created
|
||||
* by the NodeWiring (Connectivity) of the processing node which
|
||||
* is pulled by this invocation, hereby using the internal configuration
|
||||
* information to guide the selection of the real call sequence
|
||||
*
|
||||
* \par assembling the call sequence implementation
|
||||
* Each ProcNode#pull() call creates such a StateAdapter subclass on the stack,
|
||||
* with a concrete type according to the Connectivity of the node to pull.
|
||||
* This concrete type encodes a calculation Strategy, which is assembled
|
||||
* as a chain of policy templates on top of OperationBase. For each of the
|
||||
* possible configurations we define such a chain (see bottom of nodeoperation.hpp).
|
||||
* The WiringFactory defined in nodewiring.cpp actually drives the instantiation
|
||||
* of all those possible combinations.
|
||||
*/
|
||||
template<class Strategy, class BufferProvider>
|
||||
class ActualInvocationProcess
|
||||
: public BufferProvider
|
||||
, private Strategy
|
||||
{
|
||||
public:
|
||||
ActualInvocationProcess (StateClosure& callingProcess, Connectivity const& w, const uint outCh)
|
||||
: BufferProvider(callingProcess, w, outCh)
|
||||
{ }
|
||||
|
||||
/** contains the details of Cache query and recursive calls
|
||||
* to the predecessor node(s), eventually followed by the
|
||||
* ProcNode::process() callback
|
||||
*/
|
||||
BuffHandle retrieve ()
|
||||
{
|
||||
return Strategy::step (*this);
|
||||
}
|
||||
};
|
||||
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1367 : Rebuild the Node Invocation
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
/**
|
||||
* Standard implementation for a _Weaving Pattern_ to connect
|
||||
|
|
@ -259,7 +91,7 @@ namespace engine {
|
|||
* + `INVO::MAX_SIZ` limits both arrays
|
||||
*/
|
||||
template<class INVO>
|
||||
struct SimpleWeavingPattern
|
||||
struct MediaWeavingPattern
|
||||
: INVO
|
||||
{
|
||||
using Feed = typename INVO::Feed;
|
||||
|
|
@ -273,7 +105,7 @@ namespace engine {
|
|||
|
||||
/** forwarding-ctor to provide the detailed input/output connections */
|
||||
template<typename...ARGS>
|
||||
SimpleWeavingPattern (Several<PortRef>&& pr
|
||||
MediaWeavingPattern (Several<PortRef>&& pr
|
||||
,Several<BuffDescr>&& dr
|
||||
,uint resultIdx
|
||||
,ARGS&& ...args)
|
||||
|
|
@ -339,46 +171,6 @@ namespace engine {
|
|||
};
|
||||
|
||||
|
||||
/**
|
||||
* Processing structure to activate a Render Node and produce result data.
|
||||
* @tparam PAT a _Weaving Pattern,_ which defines in detail how data is retrieved,
|
||||
* combined and processed to yield the results; actually this implementation
|
||||
* is assembled from several building blocks, in accordance to the specific
|
||||
* situation as established by the _Builder_ for a given render node.
|
||||
*/
|
||||
template<class PAT>
|
||||
class Turnout
|
||||
: public Port
|
||||
, public PAT
|
||||
// , util::MoveOnly
|
||||
{
|
||||
using Feed = typename PAT::Feed;
|
||||
|
||||
public:
|
||||
template<typename...INIT>
|
||||
Turnout (ProcID& id, INIT&& ...init)
|
||||
: Port{id}
|
||||
, PAT{forward<INIT> (init)...}
|
||||
{ }
|
||||
|
||||
/**
|
||||
* Entrance point to the next recursive step of media processing.
|
||||
* @param turnoutSys anchor context with parameters and services
|
||||
* @return a BuffHandle exposing the generated result data
|
||||
*/
|
||||
BuffHandle
|
||||
weave (TurnoutSystem& turnoutSys, OptionalBuff outBuff =std::nullopt) override
|
||||
{
|
||||
Feed feed = PAT::mount();
|
||||
PAT::pull(feed, turnoutSys);
|
||||
PAT::shed(feed, outBuff);
|
||||
PAT::weft(feed);
|
||||
return PAT::fix (feed);
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
|
||||
|
||||
}}// namespace steam::engine
|
||||
#endif /*STEAM_ENGINE_WEAVING_PATTERN_H*/
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@
|
|||
|
||||
#include "lib/test/run.hpp"
|
||||
//#include "lib/test/test-helper.hpp"
|
||||
#include "lib/meta/function.hpp"
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
#include "steam/engine/turnout.hpp"
|
||||
#include "steam/engine/turnout-system.hpp"
|
||||
|
|
|
|||
|
|
@ -23090,9 +23090,7 @@
|
|||
</node>
|
||||
<node COLOR="#338800" CREATED="1480780930115" HGAP="5" ID="ID_1156407347" MODIFIED="1576282358077" TEXT="Lösung: per Konstruktor festlegen" VSHIFT="6">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...nochmal zusammengefaßt
|
||||
|
|
@ -23471,9 +23469,7 @@
|
|||
<node CREATED="1666889733127" ID="ID_41491875" MODIFIED="1666889741033" TEXT="header-only"/>
|
||||
<node CREATED="1666889741894" ID="ID_176779607" MODIFIED="1666889777772" TEXT="generisch">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
direkten Bezug auf die Timeline vermeiden!
|
||||
|
|
@ -24234,9 +24230,7 @@
|
|||
<node CREATED="1611119659018" ID="ID_1000548254" MODIFIED="1611119678899" TEXT="folglich wären Inhalt und Bedeutung dynamisch vom Fokus abhängig"/>
|
||||
<node CREATED="1611119741841" ID="ID_383304836" MODIFIED="1611119880288" TEXT="hätte seinen Charme, wäre aber sehr anspruchsvoll umzusetzen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Das Schöne an diesem Ansatz wäre, daß er für den User komplett natürlich wirkt; solange man gleichartige Clips in einer Timeline liegen hat, würde sich dieses Konzept überaupt nicht auffällig bemerkbar machen; und ein weiterer Vorteil wäre, daß man es als Weiterentwicklung des 1. Lösungsansatzes betrachten kann...
|
||||
|
|
@ -24880,9 +24874,7 @@
|
|||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1611915794009" ID="ID_1622487643" MODIFIED="1611915845837" TEXT="duplizierte Daten sind zu vermeiden, da hier ein starker Hebel gegeben ist">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Clips dürften die häufigsten Entitäten in der Timeline-Anzeige werden. Es müssen tausende bis zehntausende Clips performant gehandhabt werden
|
||||
|
|
@ -26085,9 +26077,7 @@
|
|||
</node>
|
||||
<node CREATED="1575132218659" ID="ID_477189517" MODIFIED="1576282358067" TEXT="gar nicht notwendig, er hat sie schon">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
denn, wie sich herausgestellt hat, muß das Interface ViewHook hierarchisch heruntergebrochen werden
|
||||
|
|
@ -27828,9 +27818,7 @@
|
|||
</node>
|
||||
<node COLOR="#338800" CREATED="1678049635786" ID="ID_1684871223" MODIFIED="1678049681821" TEXT="sieht visuell korrekt aus">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
geprüft mit Screenshot in Gimp.
|
||||
|
|
@ -30375,9 +30363,7 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1566487213692" ID="ID_617175720" MODIFIED="1672867705882" TEXT="sollte eigentlich automatisch funktionieren">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -31429,9 +31415,7 @@
|
|||
<node CREATED="1562236776876" ID="ID_1339077118" MODIFIED="1562236788875" TEXT="und deren Ausprägung greift er sich aus dem bestehenden Theme"/>
|
||||
<node CREATED="1562236801137" ID="ID_1900227252" MODIFIED="1562236836324" TEXT="lumiera.css ist eigentlich nur ein normales Theme">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...welches aber lokal auf die Anwendung angewendet wird, mit höherer Priorität
|
||||
|
|
@ -34578,9 +34562,7 @@
|
|||
</node>
|
||||
<node CREATED="1479601765896" ID="ID_1632476975" MODIFIED="1557498707231">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
UI-Bus gilt nur für <b>globale Belange</b>
|
||||
|
|
@ -36846,9 +36828,7 @@
|
|||
</node>
|
||||
<node CREATED="1533385674860" ID="ID_204825661" MODIFIED="1576282358026" TEXT="minimale Verzögerung nach Prgrammstart ist gut">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...dann kann sich das Sytem erst mal <i>beruhigen</i>
|
||||
|
|
@ -37952,9 +37932,7 @@
|
|||
<node CREATED="1617471267594" ID="ID_1351328929" MODIFIED="1617471285896" TEXT="eigentlich kein Problem, sondern nur hässlich"/>
|
||||
<node CREATED="1617471305929" ID="ID_663980291" MODIFIED="1617471447147" TEXT="Steht im Widerspruch zum selbständig verwalteten Anzeigestil">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...und dadurch ensteht hier ein "linke-Tasche-rechte-Tasche-Spiel".
|
||||
|
|
@ -38848,9 +38826,7 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1619967266842" ID="ID_1478677945" MODIFIED="1619967373917">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...die konkrete Interpretation der Mausbewegung
|
||||
|
|
@ -39063,9 +39039,7 @@
|
|||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1621011155018" ID="ID_1965916269" MODIFIED="1621011188855" TEXT="Vorteil: Abbruch der Geste wäre einfach">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
nein.... nicht wirklich, weil man ja doch noch die Position korrigieren muß
|
||||
|
|
@ -39319,9 +39293,7 @@
|
|||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1618573871374" ID="ID_716003171" MODIFIED="1618574116896" TEXT="Ziel: Entwicklungspfad zur vollständigen Lösung">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Die Gesten-Controller sollen später einmal Teile eines umfangreicheren Frameworks werden; im Besonderen wollen wir abstrahierte Gesten, die verschiedene Eingabesysteme übergreifen können. Für dieses Ziel muß der konkrete Gesten-Controller soweit schematisiert sein, daß man im Zuge der weiteren Entwicklung sich ergebende Erweiterungspunkte einführen kann, auch in schon bestehende Implementierungen. Als naheliegendes Schema bietet sich die State-Machine an, da die Gesten-Erkennung auf theoretischer Ebene ohnehin ein (ggfs nichdeterministischer) FSA ist.
|
||||
|
|
@ -82974,7 +82946,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...d.h. die Planung steigt für einen Port ein, findet für dieses in Proc-Asset in einem bereits vorliegenden Prototypen der Connectivity, und kann für dieses Proc-Asset alle benötigten Inputs identifizieren und jeden von diesen einem anderen, ebenfalls bereits bekannten Vorläufer Proc-Asset zuordnen; diese Zuordnung wäre dann die Belegung eines Port, und das Proc-Asset würde zu einer geplanten Node. Im Besonderen ist durch diese Vorraussetzung festgelegt, daß alle diese Belegungen bereits eindeutig und entscheidbar sind; Zweideutigeiten und Unmöglichkeiten sind in den vorausgehenden Verarbeitungsschritten bereits aussortiert worden...
|
||||
...d.h. die Planung steigt für einen Port ein, findet für dieses ein Proc-Asset in einem bereits vorliegenden Prototypen der Connectivity, und kann für dieses Proc-Asset alle benötigten Inputs identifizieren und jeden von diesen einem anderen, ebenfalls bereits bekannten Vorläufer Proc-Asset zuordnen; diese Zuordnung wäre dann die Belegung eines Port, und das Proc-Asset würde zu einer geplanten Node. Im Besonderen ist durch diese Vorraussetzung festgelegt, daß alle diese Belegungen bereits eindeutig und entscheidbar sind; Zweideutigeiten und Unmöglichkeiten sind in den vorausgehenden Verarbeitungsschritten bereits aussortiert worden...
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
|
|
@ -83189,7 +83161,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Das bedeutet: wenn man auf dem default-konstruierten Builder die <font face="Monospaced" color="#2a0ca1">build()</font>-Metode ausführt, dann entsteht eine Node, die zwar alle erwarteten Ports hat, aber alle diese Ports liefern bei Aufruf ein NULL-Handle des jeweils eingesetzten BufferProviders liefert. (Selbstverständlich wäre es viel schöner, an dieser Stelle einen <i>leeren Frame</i> zu liefern, aber das ist nicht möglich, ohne das Format zu kennen, welches jedoch von der Domain-Façade geleistet werden muß)
|
||||
Das bedeutet: wenn man auf dem default-konstruierten Builder die <font color="#2a0ca1" face="Monospaced">build()</font>-Metode ausführt, dann entsteht eine Node, die zwar alle erwarteten Ports hat, aber alle diese Ports liefern bei Aufruf ein NULL-Handle des jeweils eingesetzten BufferProviders. (Selbstverständlich wäre es viel schöner, an dieser Stelle einen <i>leeren Frame</i> zu liefern, aber das ist nicht möglich, ohne das Format zu kennen, welches jedoch von der Domain-Façade geleistet werden muß)
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
|
|
@ -89820,7 +89792,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
<node CREATED="1719791322472" ID="ID_258494217" LINK="#ID_656569241" MODIFIED="1719791358411" TEXT="ich weiß nur: sie hat den Charakter einer Meta-Spec"/>
|
||||
<node CREATED="1719791364810" ID="ID_881885593" MODIFIED="1719791369910" TEXT="zwei Möglichkeiten">
|
||||
<node CREATED="1719791370908" ID="ID_1842583216" MODIFIED="1719791566361" TEXT="orientiert sich an der umschließenden Node">
|
||||
<node COLOR="#5b280f" CREATED="1719791370908" ID="ID_1842583216" MODIFIED="1734135039835" TEXT="orientiert sich an der umschließenden Node">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -89829,8 +89801,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
<node CREATED="1719791404025" ID="ID_1763025014" MODIFIED="1719883098869" TEXT="orientiert sich an der aufzurufenden Funktion">
|
||||
<node COLOR="#243d4f" CREATED="1719791404025" ID="ID_1763025014" MODIFIED="1734135060266" TEXT="orientiert sich an der aufzurufenden Funktion">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -89854,7 +89827,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
dann brauchen wir sowiso und stets irgend eine Struktur auf dem Stack, in dem die BuffHandles liegen; möglicherweise sogar über mehrere Stack-Frames hinweg durchgereicht
|
||||
</li>
|
||||
<li>
|
||||
andererseits kann eine Library <i>ganz gewiß nix mit Lumiera-BuffHandles anfangen,</i> sondern wird ein spezielles Datenformat wollen; das bedeutet, man muß das BuffHandle in jedem Fall belegen, dann dereferenzieren und den resultierenden Pointer irgendwohin kopieren, um die Zielfunktion aufrufen zu können (das war auch die Idee hinter der »BuffTable« im ersten Entwurf)
|
||||
andererseits kann eine Library <i>ganz gewiß nix mit Lumiera-BuffHandles anfangen,</i> sondern wird ein spezielles Datenformat wollen; das bedeutet, man muß das BuffHandle in jedem Fall belegen, dann dereferenzieren und den resultierenden Pointer irgendwohin kopieren, um die Zielfunktion aufrufen zu können (das war auch die Idee hinter der »BuffTable« im ersten Entwurf)
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
|
|
@ -89994,14 +89967,39 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
man bekommt von jeder Kopie den gleichen Zielpuffer, und auch die Lebenszyklus-Metoden lassen sich von jedem Handle aufrufen
|
||||
man bekommt von jeder Kopie den gleichen Zielpuffer, und auch die Lebenszyklus-Methoden lassen sich von jedem Handle aufrufen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719881210266" ID="ID_1626724421" MODIFIED="1719881489034" TEXT="Frage/Problem: könnte es zu Re-Entrance kommen? Sind Lebenszyklus-Aufrufe idempotent?">
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719881210266" ID="ID_1626724421" MODIFIED="1734137935526" TEXT="Frage/Problem: könnte es zu Re-Entrance kommen? Sind Lebenszyklus-Aufrufe idempotent?">
|
||||
<linktarget COLOR="#aa0f59" DESTINATION="ID_1626724421" ENDARROW="Default" ENDINCLINATION="-981;30;" ID="Arrow_ID_1208476495" SOURCE="ID_1378956447" STARTARROW="None" STARTINCLINATION="661;38;"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1734137316030" ID="ID_1187479921" MODIFIED="1734137404683" TEXT="Problem-1: ein Eingabepuffer ist bereits früher alloziert worden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...während ein Ausgabepuffer explizit im shed()-Schritt belegt wird, kurz vor dem Aufruf der Processing-Function
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1734137406946" ID="ID_1823040709" MODIFIED="1734137531743" TEXT="Problem-2: alle Eingabepuffer werden nach dem Funktionsaufruf freigegeben">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...während Ausgabepuffer zwar an der Stelle <i>committed</i> werden, aber »der« Ausgabepuffer wird noch nicht freigegeben, denn er ist ja Eingabepuffer der Nachfolger-Node
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1734137533539" ID="ID_253613495" MODIFIED="1734139667487" TEXT="beide Vorgänge müssen für einen In/Out-Buffer (in-place processing) unterbunden werden">
|
||||
<arrowlink COLOR="#e31763" DESTINATION="ID_1612398167" ENDARROW="Default" ENDINCLINATION="819;-857;" ID="Arrow_ID_166926203" STARTARROW="None" STARTINCLINATION="368;12;"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -91334,6 +91332,54 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1734060427954" ID="ID_714381100" MODIFIED="1734060440806" TEXT="draus dann ein Storage-Layout in der Render-Engine entwickelt"/>
|
||||
<node CREATED="1734060460509" ID="ID_1434138828" LINK="#ID_532258033" MODIFIED="1734060510084" TEXT="HetroData : Hilfskomponente zur Implementierung des Turnout-Systems"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734132938355" ID="ID_695632181" MODIFIED="1734133509735" TEXT="Umbauten">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734133041626" ID="ID_1421951599" MODIFIED="1734133516983" TEXT="Processing-Funktion kann Parameter verlangen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1734133105504" ID="ID_973419708" MODIFIED="1734133112328" TEXT="dann als 1.Paramter"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734133131750" ID="ID_1829249809" MODIFIED="1734133523576" TEXT="Varianten der Funktionsignatur erkennen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1734133526381" ID="ID_1466075416" MODIFIED="1734133534809" TEXT="Möglichkeiten">
|
||||
<node CREATED="1734133537741" ID="ID_1672200590" MODIFIED="1734133557814" TEXT="(bisher:) zwei homogene Arrays"/>
|
||||
<node CREATED="1734134261731" ID="ID_1882489689" MODIFIED="1734134267038" TEXT="Varianten für Buffer">
|
||||
<node CREATED="1734134268698" ID="ID_735163966" MODIFIED="1734134273269" TEXT="nur Output"/>
|
||||
</node>
|
||||
<node CREATED="1734133572817" ID="ID_1508896644" MODIFIED="1734133584594" TEXT="zusätzlicher 1.Parameter">
|
||||
<node CREATED="1734133597805" ID="ID_1336464816" MODIFIED="1734133717178" TEXT="als beliebiger einzel-Wert">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<i>Wert</i> ist wichtig — keine Referenzen, keine Pointer. Das ist eine einfache Regel um Parameter von Buffern unterscheiden zu können, und ansonsten keinerlei weitere Einschränkungen zu machen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1734133611115" ID="ID_140148557" MODIFIED="1734133616455" TEXT="als Tupel"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734133384146" ID="ID_250842155" MODIFIED="1734133516983" TEXT="Typ-Steuerung im Builder überarbeiten">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734132967020" ID="ID_1354544776" MODIFIED="1734133516984" TEXT="Param-Tuple in FeedManifold aufnehmen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734133400400" ID="ID_1364724277" MODIFIED="1734141875620" TEXT="zusätzlichen Funktor für die Parameter akzeptieren">
|
||||
<arrowlink COLOR="#c0023e" DESTINATION="ID_1127056731" ENDARROW="Default" ENDINCLINATION="-1257;-48;" ID="Arrow_ID_1717201620" STARTARROW="None" STARTINCLINATION="-908;50;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734133441531" ID="ID_109108903" MODIFIED="1734133509736" TEXT="Turnout-Sytem mit Storage implementieren">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734133474862" ID="ID_1734639141" MODIFIED="1734133509736" TEXT="MediaWeavingPattern intern anpassen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734133492043" ID="ID_901061219" MODIFIED="1734133509737" TEXT="ParamWeavingPattern hinzubauen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -92679,6 +92725,42 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1721061573297" ID="ID_1009592243" MODIFIED="1721061586060" TEXT="Variante: einzelne Buffer speziell konfigurieren">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1734139499409" ID="ID_383087571" MODIFIED="1734139513532" TEXT="Verschiedenartige Buffer-Typen unterstützen"/>
|
||||
<node BACKGROUND_COLOR="#dfbfac" COLOR="#65253b" CREATED="1734139527342" ID="ID_1142533084" MODIFIED="1734141834818" TEXT="In-place-Processing (In/Out-Buffer) ermöglichen">
|
||||
<linktarget COLOR="#ae4cec" DESTINATION="ID_1142533084" ENDARROW="Default" ENDINCLINATION="-441;1457;" ID="Arrow_ID_50529769" SOURCE="ID_332982184" STARTARROW="None" STARTINCLINATION="439;36;"/>
|
||||
<icon BUILTIN="bell"/>
|
||||
<node CREATED="1734139581455" ID="ID_379831076" MODIFIED="1734139612989">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
sollte <i>»im Prinzip«</i> auf das bestehende Schema aufgepflantzt werden
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1734139617787" ID="ID_1074190304" MODIFIED="1734139649100" TEXT="Es gibt zwei Gefahrenstellen bzgl. Buffer-Lebenszyklus">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1721238837562" HGAP="130" ID="ID_1612398167" MODIFIED="1734139881145" STYLE="bubble" TEXT="ungelöst: Kennzeichnung und Behandlung In/Out-Buffer" VSHIFT="22">
|
||||
<edge COLOR="#ff5d00" STYLE="sharp_linear"/>
|
||||
<arrowlink COLOR="#fe512a" DESTINATION="ID_1330725144" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_494242518" STARTARROW="None" STARTINCLINATION="-1703;73;"/>
|
||||
<linktarget COLOR="#e31763" DESTINATION="ID_1612398167" ENDARROW="Default" ENDINCLINATION="819;-857;" ID="Arrow_ID_166926203" SOURCE="ID_253613495" STARTARROW="None" STARTINCLINATION="368;12;"/>
|
||||
<linktarget COLOR="#e8225b" DESTINATION="ID_1612398167" ENDARROW="Default" ENDINCLINATION="-278;13;" ID="Arrow_ID_223430515" SOURCE="ID_1282095550" STARTARROW="None" STARTINCLINATION="-480;39;"/>
|
||||
<icon BUILTIN="bell"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1721239003353" HGAP="23" ID="ID_655919165" MODIFIED="1734138154823" STYLE="fork" TEXT="Es droht Fehlsteuerung des Buffer-Lebenszyklus" VSHIFT="15">
|
||||
<font NAME="SansSerif" SIZE="8"/>
|
||||
</node>
|
||||
<node CREATED="1721239003353" ID="ID_1392700153" MODIFIED="1734138114616" STYLE="fork" TEXT="vor Aufruf: es muß kein neuer Ausgabepuffer alloziert werden">
|
||||
<font NAME="SansSerif" SIZE="8"/>
|
||||
</node>
|
||||
<node CREATED="1721239003353" ID="ID_360997303" MODIFIED="1734138138237" STYLE="fork" TEXT="nach Aufruf: der Eingabepuffer darf keinesfalls freigegeben werden">
|
||||
<font NAME="SansSerif" SIZE="8"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728516089960" ID="ID_1274882287" MODIFIED="1728586526758" TEXT="Binding auf eine Funktion herstellen">
|
||||
|
|
@ -94019,6 +94101,16 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<arrowlink COLOR="#58858e" DESTINATION="ID_1890920364" ENDARROW="Default" ENDINCLINATION="-645;-1205;" ID="Arrow_ID_1530493323" STARTARROW="None" STARTINCLINATION="-445;27;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1734139756823" ID="ID_1282095550" MODIFIED="1734141689885" TEXT="Kennzeichnung für In/Out-Buffer">
|
||||
<arrowlink COLOR="#e8225b" DESTINATION="ID_1612398167" ENDARROW="Default" ENDINCLINATION="-278;13;" ID="Arrow_ID_223430515" STARTARROW="None" STARTINCLINATION="-480;39;"/>
|
||||
<linktarget COLOR="#5732c2" DESTINATION="ID_1282095550" ENDARROW="Default" ENDINCLINATION="-406;569;" ID="Arrow_ID_497899045" SOURCE="ID_35388918" STARTARROW="None" STARTINCLINATION="981;80;"/>
|
||||
<icon BUILTIN="hourglass"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734141168279" ID="ID_1127056731" MODIFIED="1734141875620" TEXT="Pram-Funktor in den Builder einführen">
|
||||
<arrowlink COLOR="#d90755" DESTINATION="ID_284201304" ENDARROW="Default" ENDINCLINATION="428;-33;" ID="Arrow_ID_1685749535" STARTARROW="None" STARTINCLINATION="-2201;158;"/>
|
||||
<linktarget COLOR="#c0023e" DESTINATION="ID_1127056731" ENDARROW="Default" ENDINCLINATION="-1257;-48;" ID="Arrow_ID_1717201620" SOURCE="ID_1364724277" STARTARROW="None" STARTINCLINATION="-908;50;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728870929451" ID="ID_1740846481" MODIFIED="1728870951984" TEXT="der Gebrauch des BuffHandle::accessAs<TY>() ist zweifelhaft">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
|
|
@ -94185,6 +94277,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734139914450" ID="ID_284201304" MODIFIED="1734141541281" TEXT="Steuerung der Parameter-Verarbeitung">
|
||||
<linktarget COLOR="#a71e73" DESTINATION="ID_284201304" ENDARROW="Default" ENDINCLINATION="-170;12;" ID="Arrow_ID_170732865" SOURCE="ID_616768316" STARTARROW="None" STARTINCLINATION="150;11;"/>
|
||||
<linktarget COLOR="#c33786" DESTINATION="ID_284201304" ENDARROW="Default" ENDINCLINATION="-149;10;" ID="Arrow_ID_1396373869" SOURCE="ID_1184999563" STARTARROW="None" STARTINCLINATION="335;-34;"/>
|
||||
<linktarget COLOR="#d90755" DESTINATION="ID_284201304" ENDARROW="Default" ENDINCLINATION="428;-33;" ID="Arrow_ID_1685749535" SOURCE="ID_1127056731" STARTARROW="None" STARTINCLINATION="-2201;158;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1734139929944" ID="ID_1156222347" MODIFIED="1734140153468" TEXT="Steuerung von In/Out-Buffer Varianten">
|
||||
<linktarget COLOR="#8f3ed0" DESTINATION="ID_1156222347" ENDARROW="Default" ENDINCLINATION="-157;11;" ID="Arrow_ID_143800943" SOURCE="ID_473579786" STARTARROW="None" STARTINCLINATION="326;-28;"/>
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1734141573122" ID="ID_241053951" MODIFIED="1734141582909" TEXT="brauche Metadaten">
|
||||
<node CREATED="1734141589472" ID="ID_332982184" MODIFIED="1734141779177" TEXT="Repräsentation im Weaving-Pattern">
|
||||
<arrowlink COLOR="#ae4cec" DESTINATION="ID_1142533084" ENDARROW="Default" ENDINCLINATION="-441;1457;" ID="Arrow_ID_50529769" STARTARROW="None" STARTINCLINATION="439;36;"/>
|
||||
</node>
|
||||
<node CREATED="1734141600723" ID="ID_35388918" MODIFIED="1734141689885" TEXT="Repräsentation im Weaving-Builder">
|
||||
<arrowlink COLOR="#5732c2" DESTINATION="ID_1282095550" ENDARROW="Default" ENDINCLINATION="-406;569;" ID="Arrow_ID_497899045" STARTARROW="None" STARTINCLINATION="981;80;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -94217,7 +94327,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733428913753" ID="ID_1660514427" MODIFIED="1733428922824" TEXT="zugehörige ParamAgent-Nodes">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733428924098" ID="ID_616768316" MODIFIED="1733428938654" TEXT="diese per Builder erzeugen können">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733428924098" ID="ID_616768316" MODIFIED="1734140026717" TEXT="diese per Builder erzeugen können">
|
||||
<arrowlink COLOR="#a71e73" DESTINATION="ID_284201304" ENDARROW="Default" ENDINCLINATION="-170;12;" ID="Arrow_ID_170732865" STARTARROW="None" STARTINCLINATION="150;11;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -94275,6 +94386,14 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#d10501" CREATED="1734140059798" ID="ID_1184999563" MODIFIED="1734140126632" TEXT="offen: Parameter">
|
||||
<arrowlink COLOR="#c33786" DESTINATION="ID_284201304" ENDARROW="Default" ENDINCLINATION="-149;10;" ID="Arrow_ID_1396373869" STARTARROW="None" STARTINCLINATION="335;-34;"/>
|
||||
<icon BUILTIN="bell"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#d10501" CREATED="1734140065909" ID="ID_473579786" MODIFIED="1734140162781" TEXT="offen: In/Out-Buffer">
|
||||
<arrowlink COLOR="#8f3ed0" DESTINATION="ID_1156222347" ENDARROW="Default" ENDINCLINATION="-157;11;" ID="Arrow_ID_143800943" STARTARROW="None" STARTINCLINATION="326;-28;"/>
|
||||
<icon BUILTIN="bell"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -96899,6 +97018,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<linktarget COLOR="#fe512a" DESTINATION="ID_190416286" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_304105897" SOURCE="ID_286044031" STARTARROW="None" STARTINCLINATION="-848;70;"/>
|
||||
<icon BUILTIN="bell"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1721238814245" ID="ID_1330725144" MODIFIED="1734139688131" TEXT="Aufgabe: Markierung und Spezialbehandlung für In/Out-Parameter">
|
||||
<linktarget COLOR="#fee2f8" DESTINATION="ID_1330725144" ENDARROW="Default" ENDINCLINATION="294;12;" ID="Arrow_ID_316718831" SOURCE="ID_194906054" STARTARROW="None" STARTINCLINATION="545;31;"/>
|
||||
<linktarget COLOR="#fe512a" DESTINATION="ID_1330725144" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_494242518" SOURCE="ID_1612398167" STARTARROW="None" STARTINCLINATION="-1703;73;"/>
|
||||
<icon BUILTIN="bell"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e2caa2" COLOR="#990000" CREATED="1729956600896" ID="ID_988254887" MODIFIED="1729956915005" STYLE="fork" TEXT="Probleme">
|
||||
<edge COLOR="#b14253" STYLE="sharp_linear"/>
|
||||
|
|
@ -97073,6 +97197,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</html></richcontent>
|
||||
<arrowlink COLOR="#aa0f59" DESTINATION="ID_1626724421" ENDARROW="Default" ENDINCLINATION="-981;30;" ID="Arrow_ID_1208476495" STARTARROW="None" STARTINCLINATION="661;38;"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734137812305" HGAP="33" ID="ID_194906054" MODIFIED="1734137917379" TEXT="für In/Out muß es eine Spezialbehandlung geben" VSHIFT="22">
|
||||
<arrowlink COLOR="#fee2f8" DESTINATION="ID_1330725144" ENDARROW="Default" ENDINCLINATION="294;12;" ID="Arrow_ID_316718831" STARTARROW="None" STARTINCLINATION="545;31;"/>
|
||||
<icon BUILTIN="bell"/>
|
||||
</node>
|
||||
<node CREATED="1734137827491" ID="ID_1604893451" MODIFIED="1734137854196">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
somit geht es vor allem darum,
|
||||
</p>
|
||||
<p>
|
||||
Folgeschäden eines redundanten Aufrufs zu bedenken
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1720574923303" ID="ID_284878377" MODIFIED="1720574930985" TEXT="Design und Code-Qualität">
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1720574616950" ID="ID_374254461" MODIFIED="1720574974390" TEXT="die inPlace-Storage-Lösung in Turnout ist gefährlich">
|
||||
|
|
|
|||
Loading…
Reference in a new issue