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

Activity-Lang: wire Job invocation in the activity::Term builder

Browse source
This commit is contained in:
Fischlurch 2023-08-29 04:19:19 +02:00
parent e98fe1e78b
commit ae89831275
8 changed files with 115 additions and 175 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
src/steam/mobject/session/sess-manager-impl.cpp
View file

@ -49,6 +49,7 @@
#include "common/query.hpp"
#include <memory>
#include <exception>
@ -77,9 +78,8 @@ namespace session {
}
catch (...)
{
ERROR (progress, "Unrecoverable Failure while creating the empty default session.");
throw lumiera::error::Fatal ( "Failure while creating the basic session object. System halted."
, LERR_(CREATE_SESSION));
ERROR (progress, "Unrecoverable Failure while creating the empty default session. System halted.");
std::terminate();
}
@ -295,7 +295,7 @@ namespace session {
* to several files (master file and edl files)
*/
void
SessManagerImpl::save (string stnapshotID)
SessManagerImpl::save (string snapshotID)
{
UNIMPLEMENTED ("save session (serialised)");
/////////////////////////////////////////////////TODO: need lock?

28
src/vault/gear/activity-term.hpp
View file

@ -60,7 +60,8 @@
namespace vault{
namespace gear {
using lib::time::Time;////////////WIP
using lib::time::Time;
using lib::time::TimeValue;
// using util::isnil;
// using std::string;
using std::move;
@ -93,6 +94,8 @@ namespace gear {
explicit
Term (AllocHandle&& allocHandle, Template kind, Time start, Time after, Job job)
: alloc_{move (allocHandle)}
, invoke_{setupInvocation (job)}
, post_{setupPost (start,after, invoke_)}
{ }
// virtual std::string
@ -112,6 +115,29 @@ namespace gear {
REQUIRE (post_, "Activity Term not yet fully configured");
return *post_;
}
private:
Activity*
setupInvocation (Job& job)
{
Activity& feed1 = alloc_.create (job.parameter.invoKey.code.w1
,job.parameter.invoKey.code.w2);
Activity& feed2 = alloc_.create (Activity::FEED); ///////////////////////////////////////TICKET #1295 : rework Job parameters to accommodate input / output info required for rendering
feed1.next = &feed2;
JobClosure* functor = static_cast<JobClosure*> (job.jobClosure); ////////////////////TICKET #1287 : fix actual interface down to JobFunctor (after removing C structs)
REQUIRE (functor);
Activity& invo = alloc_.create (*functor
, Time{TimeValue{job.parameter.nominalTime}}
, feed1); ///////////////////////////////////////////TICKET #1287 : get rid of C-isms in Job descriptor
return & invo;
}
Activity*
setupPost (Time start, Time after, Activity* followUp)
{
return & alloc_.create (start,after,followUp);
}
};

10
src/vault/gear/activity.hpp
View file

@ -242,8 +242,8 @@ namespace gear {
/** Payload data to provide */
struct Feed
{
size_t one;
size_t two;
uint64_t one;
uint64_t two;
};
/** Timing observation to propagate */
@ -320,7 +320,7 @@ namespace gear {
/* ==== special case initialisation ==== */
Activity (size_t o1, size_t o2) noexcept
Activity (uint64_t o1, uint64_t o2) noexcept
: Activity{FEED}
{
data_.feed.one = o1;
@ -437,8 +437,8 @@ namespace gear {
JobClosure& functor = static_cast<JobClosure&> (*data_.invocation.task); /////////////////////TICKET #1287 : fix actual interface down to JobFunctor (after removing C structs)
lumiera_jobParameter param;
param.nominalTime = _raw(Time{data_.invocation.time});
param.invoKey.part.a = next->data_.feed.one;
param.invoKey.part.b = next->data_.feed.two;
param.invoKey.code.w1 = next->data_.feed.one;
param.invoKey.code.w2 = next->data_.feed.two;
//////////////////////////////////////////////////////////////////////////////////TICKET #1295 : rework Job parameters to accommodate input / output info required for rendering
try {
functor.invokeJobOperation (param);

4
src/vault/gear/job.h
View file

@ -117,6 +117,10 @@ union InvocationInstanceID
struct { int32_t a,b;
int64_t t;
} part;
struct {
uint64_t w1;
uint64_t w2;
} code;
};

1
src/vault/gear/scheduler-diagnostics.hpp
View file

@ -27,6 +27,7 @@
** This allows to verify the operation of the scheduler from within unit-tests;
** typically doing so incurs a performance overhead.
**
** @deprecated 8/23 obsoleted by rework for »Playback Vertical Slice« //////////////////////////////////TICKET #1228
** @see SchedulerFrontend
** @see scheduler-interface-test.cpp
** @see EngineServiceMock

3
src/vault/gear/scheduler-frontend.hpp
View file

@ -25,7 +25,8 @@
** Scheduler service access point for higher layers.
** @todo WIP unfinished since 9/2013
** @warning as of 4/2023 Render-Engine integration work is underway ////////////////////////////////////////TICKET #1280
** @deprecated as of 7/2023 the scheduler API will likely draw upon the ActivityLang
** @deprecated 8/23 obsoleted by rework for »Playback Vertical Slice« //////////////////////////////////TICKET #1228
** @see activity-lang.hpp the emerging new interface
**
*/

2
tests/vault/gear/scheduler-activity-test.cpp
View file

@ -146,7 +146,7 @@ namespace test {
{
ActivityDetector detector;
size_t x1=rand(), x2=rand();
uint64_t x1=rand(), x2=rand();
Time nomTime = lib::test::randTime();
Activity feed{x1,x2};
Activity feed2{x1+1,x1+2};

234
wiki/thinkPad.ichthyo.mm
View file

@ -74737,9 +74737,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node CREATED="1685987531259" ID="ID_1014305317" MODIFIED="1685988022566" TEXT="minimal halten! f&#xfc;r Tests ist die ExitNode schei&#xdf;egal">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
ich gehe davon aus, da&#223; praktisch alle Tests, die dieses Mock-Framework verwenden, lediglich pr&#252;fen da&#223; eine gewisse Connection durchgereicht wurde
@ -74808,9 +74806,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1686264912495" ID="ID_1612660724" MODIFIED="1686270571978" TEXT="NEIN! das wird irre komplex mit den lokalen Scopes">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
ich will f&#252;r den ganzen Mock-Support eine L&#246;sung, die &#8222;einfach funktioniert&#8220; &#8212; sofern man mit einer Instanz von MockSegmentation bzw. MockDispatcher arbeitet (und sonst nichts beeinflu&#223;t)
@ -74827,9 +74823,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#338800" CREATED="1686265038081" ID="ID_889617435" MODIFIED="1686270657046" TEXT="(optional) explizit einen JobFunctor-Pointer in die ExitNode legen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn das entspricht noch am Meisten dem sp&#228;ter mal erwarteten Ablauf
@ -74859,9 +74853,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="broken-line"/>
<node CREATED="1686526201442" ID="ID_1473295586" MODIFIED="1686526249802" TEXT="Bei Traversierung werden weniger Nodes gefunden als erwartet">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<font face="Monospaced" color="#ae2828">FAIL___expectation___________ </font>
@ -74938,9 +74930,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1686532570287" ID="ID_1247471780" MODIFIED="1686532586636" TEXT="aktuelle Impl gibt back() zur&#xfc;ck">
<node CREATED="1686532587893" ID="ID_270597249" MODIFIED="1686532627829" TEXT="das ist tats&#xe4;chlich fehlerhaft programmiert">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...urspr&#252;nglich hatte ich n&#228;mlich per emplace_back() alloziert....
@ -74954,9 +74944,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1686536440412" ID="ID_516930810" MODIFIED="1686536567177" TEXT="das erkl&#xe4;rt auch das beobachtete Fehlverhalten">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
an der Stelle, wo die Referenz auf Objekt-33 zur&#252;ckgeliefert werden sollte, kommt tats&#228;chlich eine Referenz auf das zuletzt rekursiv erzeugte Objekt-44&#160;&#160;zur&#252;ck, und wird daher in die Liste der Prerequisites eingef&#252;gt.
@ -74978,9 +74966,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1686536684920" ID="ID_352953262" MODIFIED="1686581050434" TEXT="Holder-Buffer direkt selber implementieren">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
um den Lifecycle komplett kontrollieren zu k&#246;nnen
@ -75033,9 +75019,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#338800" CREATED="1685989471022" ID="ID_1045668645" MODIFIED="1686524466583" TEXT="erst einmal gen&#xfc;gt es, da&#xdf; jedes gemockte Segment da einen Eintrag hat">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...auf <i>irgend ein</i>&#160;Objekt...
@ -75049,9 +75033,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#435e98" CREATED="1686524492032" ID="ID_1332592177" MODIFIED="1686524561638" TEXT="ExitNode kann vorl&#xe4;ufig einfach so konstruiert werden">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...da aktuell noch keine Verbindung zum Render-Nodes-Network besteht...
@ -75124,9 +75106,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#435e98" CREATED="1686089592469" ID="ID_1688607797" MODIFIED="1686270559655" TEXT="Storage mu&#xdf; stabil + erweiterungsf&#xe4;hig sein">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
und das hei&#223;t im Klartext: <font face="Monospaced" color="#262a9c">std::deque</font>&#160;&#8212; sp&#228;ter kombiniert mit einem custom-Allocator, der auf den AllocationCluster delegiert
@ -75183,9 +75163,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1686436197019" ID="ID_1405705756" MODIFIED="1686436217710" TEXT="spezifisch &#x2261; kann nur JobTicket-Instanzen allozieren"/>
<node CREATED="1686436296914" ID="ID_1997952244" MODIFIED="1686436346538">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
aktuell w&#228;re spezifisch besser &#8212;
@ -75214,9 +75192,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1686439686598" ID="ID_1468838708" MODIFIED="1686440085274">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<b>Beschlu&#223;</b>: Allo &#8801; Funktor mit variadischen Argumenten
@ -75249,9 +75225,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1686449851892" ID="ID_96252432" MODIFIED="1686450255979" TEXT="der Allocator mu&#xdf; re-Entrance-f&#xe4;hig sein">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
exakt dieses Problem hatte ich schon vor einigen Wochen, bei der ersten (damals Mock)-Implementierung: da die Prerequisites private sind, gibt es keine andere L&#246;sung als sie aus dem &#252;bergeordneten ctor heraus zu konstruieren, und damit re-entrant aus dem JobTicket-ctor ein weiteres JobTicket zu allozieren. Vector und Deque k&#246;nnen das nicht hanhaben, und es kommt zu einem gef&#228;hrlichen Aliasing, bei dem das geschachtelte Ticket an der gleichen Stelle im Speicher steht wie das Haupt-Ticket, und damit dessen ctor-Aufruf korrumpiert
@ -75301,9 +75275,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#e0b7aa" COLOR="#690f14" CREATED="1686270985068" ID="ID_116441332" MODIFIED="1686271310159" STYLE="fork" TEXT="unm&#xf6;glich: rekursive Typ-Inferenz">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
damit sitz ich in der Falle...
@ -75361,9 +75333,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1686090919949" HGAP="27" ID="ID_929102409" MODIFIED="1686450462296" VSHIFT="10">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
bisherige Mock-L&#246;sung<br />nun darauf aufsetzen
@ -75371,9 +75341,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
nach dem <i>ersten Schreck</i>&#160;<font size="1" color="#70005e">(weil ich es doch grade erst neu programmiert hatte...)</font>&#160;zeigt sich, da&#223; die bisherige Mock-Implementierung bereits sehr gut ist, und strukturell direkt in die endg&#252;ltige Implementierung &#252;bersetzt werden kann; wir machen dann lediglich zweimal eine strukturgleiche rekursive Verarbeitung (GenNode &#10236; ExitNode-Struktur sowie dann ExitNode-Struktur &#10236; JobTicket)
@ -75385,9 +75353,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#338800" CREATED="1686498590686" ID="ID_383464116" MODIFIED="1686520395591" TEXT="R&#xfc;ckbau Differenzierung nach Channel">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
urspr&#252;nglich dachte ich, im Ticket w&#252;rde intern noch nach einer Channel-ID (f&#252;r Mehrkanal-Medien) differenziert; die Analyse im Detail ergab jedoch, da&#223; dies stets unter dem Konstrukt &#187;ModelPort&#171; subsummiert werden kann &#8212; viele interne Komplexit&#228;ten fallen damit weg
@ -75424,9 +75390,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1686361493991" ID="ID_423058577" MODIFIED="1686361526825" TEXT="tritt nicht bei jedem Lauf auf &#x27f9; vermutlich dangling pointer"/>
<node CREATED="1686361820600" ID="ID_780766515" MODIFIED="1686361835540">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Testfall: <b>retrieve_JobTicket</b>
@ -75442,9 +75406,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1686361606310" ID="ID_288594511" MODIFIED="1686361716351" TEXT="requirements_ Linked-List is corruped">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
head_ steam::engine::JobTicket::Provision * 0x2525252525252525
@ -75465,9 +75427,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="broken-line"/>
<node CREATED="1686364436691" ID="ID_462388515" MODIFIED="1686364452584">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<font face="Monospaced">provision.requirements.emplace(</font><font face="Monospaced" color="#e61919">preNode</font><font face="Monospaced">)</font>
@ -75478,9 +75438,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1686364460397" ID="ID_956048441" MODIFIED="1686364472840" TEXT="das alloziert eine struct Prerequisite"/>
<node CREATED="1686364475066" ID="ID_353638422" MODIFIED="1686364538445">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
und die nimmt im ctor ein <font face="Monospaced" color="#ef331d"><b>JobTicket const&amp;</b></font>
@ -75519,9 +75477,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#338800" CREATED="1686604218914" ID="ID_1822598563" MODIFIED="1686617174630" TEXT="besser direkt im Dispatcher implementieren">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn das ist nicht wirklich ein Belang der Segmentation (diese arbeitet stets mit den Model-Port-Indices), sondern hat ehr mit dem globalen Mapping auf eine Timeline zu tun &#8212; also etwas, was&#160;&#160;irgendwo in der RenderEnvironmentClosure verborgen liegt, denn wir wollen <i>definitiv nicht ein globales &#187;Timelines&#171;-Array durch die Hintert&#252;r einf&#252;hren.</i>&#160; Das High-Level-Model ist auf oberster Ebene ein Wald, und nicht eine einzige koh&#228;rente Struktur
@ -75538,9 +75494,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#338800" CREATED="1686590017562" ID="ID_1378616081" MODIFIED="1686590067746">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
neue Dispatcher-Operation: <font face="Monospaced"><b>size_t resolveModelPort(ModelPort)</b></font>
@ -75581,9 +75535,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="idea"/>
<node CREATED="1685803432791" ID="ID_612766289" MODIFIED="1685803491700" TEXT="das hei&#xdf;t: die Verklammerung macht der Expander selber">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn dieser hat nat&#252;rlicherweise beide Elemente in der Hand...
@ -75610,9 +75562,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1685840479768" ID="ID_1500115702" MODIFIED="1685840492596" TEXT="macht das Dependency-Schema formal einfach"/>
<node CREATED="1685840517829" ID="ID_255096122" MODIFIED="1685840750650" TEXT="l&#xf6;st das Problem mit dem &#xbb;beweglichen Teil&#xab; des JobFunctors">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Eigentlich k&#246;nnte das JobTicket f&#252;r ein ganzes Segment konstant sein, ggfs noch aufdifferenziert nach ModelPort &#8212; der eigentliche JobFunctor (im Ticket) w&#228;re vom Prinzip her in jedem Fall konstant und damit nur einmal alloziert. Aber jeder separate CalcStream braucht die Daten in einem anderen Ausgabe-Puffer, gegeben durch das DataSink-Handle.
@ -75624,9 +75574,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1685840443054" ID="ID_1482139155" MODIFIED="1685840444010" TEXT="con">
<node CREATED="1685840753973" ID="ID_1826791596" MODIFIED="1685840872613" TEXT="eigentlich war die Idee, da&#xdf; der top-level-Job direkt in den Ausgabepuffer rendert">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<ul>
<li>
@ -75701,9 +75649,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#338800" CREATED="1686705365836" ID="ID_138010755" MODIFIED="1686757687312" TEXT="Visualisierung f&#xfc;r das jeweils aktuelle JobTicket">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
also stets das 2.Element im Tupel. Bin n&#228;mlich zu faul, hier auch noch das Tupel irgendwie zu rendern. Das mach ich dann im n&#228;chsten Testfall...
@ -75718,9 +75664,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="broken-line"/>
<node CREATED="1686708460080" ID="ID_990579031" MODIFIED="1686708540153">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<font color="#801111" face="Monospaced" size="2">FAIL___expectation___________ </font>
@ -75790,9 +75734,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1685058150242" ID="ID_1251514808" MODIFIED="1685058160434" TEXT="ein Feed kann mehrere CalcStreams haben (vector)"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1685058172991" ID="ID_1595485074" MODIFIED="1685062339730" TEXT="RenderDrive is non-Copyable &#x27f9; mu&#xdf; irgendwo abgefangen werden">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<ul>
<li>
@ -75882,9 +75824,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_cancel"/>
<node CREATED="1685401954481" ID="ID_807804418" MODIFIED="1685402029862">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
bisher: <font face="Monospaced" size="2" color="#7b2b47">FrameCnt</font><font face="Monospaced" size="2">&#160;</font><font face="Monospaced" size="2" color="#cc2727">getNextAnchorPoint()</font>
@ -75928,9 +75868,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="flag-yellow"/>
<node CREATED="1685058050639" ID="ID_143173446" MODIFIED="1685058108822" TEXT="Sink ist ein Handle (ref-counting)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
lib::Handle&lt;OutputSlot::Connection&gt;
@ -75940,9 +75878,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1685062340977" ID="ID_1162744930" MODIFIED="1685062405034" TEXT="diese Info geh&#xf6;rt in den JobFunktor">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
denn die Inovcation mu&#223; in diese Sink rendern
@ -75955,9 +75891,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#338800" CREATED="1684984896696" FOLDED="true" HGAP="36" ID="ID_727075583" MODIFIED="1687228182161" VSHIFT="3">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Verh&#228;ltnis von JobPlanning
@ -76038,9 +75972,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#435e98" CREATED="1686874081293" ID="ID_1358950308" MODIFIED="1686964328409" TEXT="Zugriff sollte aber &#xfc;ber das JobTicket-API gef&#xfc;hrt werden">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
und zwar wegen <i>Separation of Concerns</i>&#160;&#160;&#160;&#8212;&#160;&#160;der JobFunctor ist kein Informations-Service (genau daf&#252;r haben wir ja das JobTicket geschaffen)
@ -76090,9 +76022,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1686965001287" ID="ID_1948616906" MODIFIED="1687137549677">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<u>Problem</u>&#160;: habe nur <b>JobTicket</b>&#160;des <i>unmittelbaren</i>&#160; Vorg&#228;ngers
@ -76120,9 +76050,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1687039436665" ID="ID_510256966" MODIFIED="1687039436665" TEXT="mu&#xdf; f&#xfc;r Job-Planning-Berechnung zug&#xe4;nglich sein"/>
<node CREATED="1687039484904" ID="ID_846229350" MODIFIED="1687039649451" TEXT="mu&#xdf; aber in der Expander-Funktion bereits vorliegen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
weil das die einzige Stelle ist in der zugleich Dependent und Dependency zug&#228;nglich sind
@ -76141,9 +76069,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1687042313601" ID="ID_891484053" MODIFIED="1687042479747" TEXT="redundante Storage f&#xfc;r die JobTIcket* f&#xe4;llt weg">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
da im JobPlanning nochmal eine JobTicket&amp; liegt, sind die zwei bisher im darunter liegenden Tupel gespeicherten JobTicket* eigentlich redundant und werden nur f&#252;r die Explorer-Mechanik gebraucht
@ -76153,9 +76079,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1687042241003" ID="ID_513934853" MODIFIED="1687042834774" TEXT="erheblicher Speicher-Mehrverbrauch im Explorer">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
weil nun auf jeder Ebene im Explorer-Stack eine JobPlanning-Instanz liegt, und zwar dort im ItemWrapper f&#252;r den jeweiligen TransformIterator (der die Explorer-Funktion implementiert)
@ -76169,9 +76093,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#5b280f" CREATED="1687042939750" ID="ID_573111234" MODIFIED="1687184137904" TEXT="l&#xe4;&#xdf;t sich abmildern &#x27f9; FrameCoord per Referenz nehmen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
....und das gilt aber auch f&#252;r die einzelnen Felder darin, nachdem nun <b>FrameCoord als Konzept aufgegeben</b>&#160;wurden: es sind nun zwei Referenzen statt einer, aber ich erwarte, da&#223; alle diese Referenzen vom Optimiser erkannt und ausgelassen werden...
@ -76181,9 +76103,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1687043326502" ID="ID_1349100996" MODIFIED="1687043610100" TEXT="nach Aussch&#xf6;pfen der Optimierung gar nicht mehr so schlimm">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Wenn man die Daten entsprechend reorganisiert und dadurch die Redundanzen in der Pipeline minimiert kann der Optimiser viel machen, da (private) Referenzen &#252;berhaupt nicht repr&#228;sentiert werden m&#252;ssen, sofern die referenzierte Quelle (wie hier) stabil im gleichen Objekt liegt. Wenn ich richtig sch&#228;tze, habe ich mit dem Umbau nur einen &#187;slot&#171; mehr Speicher verbraucht (weil drei redundante &#187;slots&#171; wegfallen k&#246;nnen)
@ -76202,9 +76122,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1687043695271" ID="ID_497206730" MODIFIED="1687137643989" TEXT="JobTicket-parent-Pointer in JobPlanning-parent verwandeln" VSHIFT="10">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<b><font color="#f32157">AUA</font></b>: dieser parent-Pointer war bisher sogar eine <i>dangling reference </i>&#8212; er zeigte n&#228;mlich auf einen Pointer im Stack-Frame des &#955;-Aufrufs, der aber gar nicht mehr existiert, wenn man den Transform-Iterator auswertet. Soschnellkannsgehen
@ -76215,9 +76133,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#5b280f" CREATED="1687043645122" ID="ID_1471106329" MODIFIED="1687131535956" TEXT="FrameCoord m&#xfc;ssen bereits in den TickGenerator">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn sonst m&#252;&#223;te ich sie in eine &#955;-Closure binden, was aber f&#252;r zwei der drei Felder redundate Storage w&#228;re; es macht auch sonst Sinn, wenn der Tick-Generator eben auf den FrameCoord arbeitet
@ -76231,9 +76147,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1687047139677" ID="ID_1123653637" MODIFIED="1687047160987" TEXT="es bl&#xe4;ht den TickGenerator auf und macht ihn asymetrisch"/>
<node COLOR="#4a4398" CREATED="1687047169092" ID="ID_1819824079" MODIFIED="1687137416207">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
dann m&#252;ssen die FrameCoord jetzt <b>sterben</b>
@ -76252,9 +76166,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node CREATED="1687047618686" ID="ID_1365656833" MODIFIED="1687047628283">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
verwendet nur absoluteNominalTime
@ -76285,9 +76197,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node CREATED="1687047995665" ID="ID_1960158539" MODIFIED="1687048015259">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
das ist die <i>einzige Verwendung</i>&#160;von zwei Feldern
@ -76300,9 +76210,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="info"/>
<node CREATED="1687048232475" ID="ID_564390430" MODIFIED="1687048406468" TEXT="PipelineBuilder::pullFrom()">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Das ist <i>genau der Grund warum sie jetzt zum Problem</i>&#160;werden: diese Funktion erzeugt FrameCoord, die irgendwo leben m&#252;ssen, und das blo&#223;, um den einen Aufruf zu machen. Das <b>best&#228;tigt die Enscheidung</b>, sie zur&#252;ckzubauen
@ -76366,9 +76274,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="smiley-angry"/>
<node CREATED="1687131919997" ID="ID_830496483" MODIFIED="1687132086162">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
leider ist das ziemlich <i>absch&#252;ssiges Gel&#228;nde</i>
@ -76376,9 +76282,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
....per SFINAE feststellen, da&#223; ein Asignment-Operator unterdr&#252;ckt wurde; lt. Standard sollte das gehen (das war eine sp&#228;te &#196;nderung zu C++11, da es in der Stdlib so viel Probleme gemacht hat) &#8212; aber in der Praxis wei&#223; ich, da&#223; das fragil ist, manchmal Fehler ausl&#246;sen kann (statt SFINAE), und da&#223; es Diskrepanzen zwischen den Compilern gibt. Ich hatte auch schon F&#228;lle, wo std::is_assignable rundweg versagt hat....
@ -76388,9 +76292,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1687133791082" ID="ID_76046380" MODIFIED="1687134081357">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
also k&#228;me erst mal nur in Frage, dort stets die alte Payload
@ -76404,9 +76306,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Der typische use-case, f&#252;r den dieser ItemWrapper geschaffen wurde, ist, ein beliebiges Lambda auszuwerten, und das Resultat dann im Puffer vorzuhalten; speziell wenn das Lambda ein neues Objekt konstruiert und per Value zur&#252;ckgibt, sorgt die RVO daf&#252;r, da&#223; dieses Objekt dann (per copy elision) sofort im Puffer im ItemWrapper konstruiert wird &#8212; in der Praxis ist das der h&#228;ufigste use-case und tritt im Besonderen in einem Transform-Iterator auf. Wenn andererseits die Payload ein POD oder einfacher Wert ist, dann sind Destruktor und Konstruktor ohnehin trivial...
@ -76459,9 +76359,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1687044201408" ID="ID_1507798641" MODIFIED="1687188666784" TEXT="die Deadline sollte man als Wert speichern (caching)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn sonst w&#252;rde es genau zu rekursiven kaskadierenden (quadratisch aufwendigen) Aufrufen der Deadline-Berechnungs-Logik kommen; um das Caching zu steuern, kann ich einen Marker-Wert Time::NEVER verwenden
@ -76477,9 +76375,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1687188700992" HGAP="30" ID="ID_1176783672" MODIFIED="1687188838995" TEXT="die ersten paar sind billig, und die Kosten sind nicht klar" VSHIFT="2">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Ich kann mir nicht vorstellen, da&#223; die gro&#223;e Mehrheit der Jobs mehr als eine Prerequisite bekommt...&#160;&#160;der Aufwand ist n/2 * (n+1), das bringt uns erst mal solange nicht um (bis es uns nachweislich umbringt...)
@ -78267,8 +78163,12 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1693178495964" ID="ID_807456413" MODIFIED="1693178500231" TEXT="Struktur-Bausteine">
<node CREATED="1693178501472" ID="ID_1503655415" MODIFIED="1693178503142" TEXT="stets">
<node CREATED="1693178507426" ID="ID_391129339" MODIFIED="1693178509638" TEXT="Post"/>
<node CREATED="1693178510554" ID="ID_530087254" MODIFIED="1693178514253" TEXT="Invoke + Feed"/>
<node COLOR="#338800" CREATED="1693178507426" ID="ID_391129339" MODIFIED="1693275201840" TEXT="Post">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1693178510554" ID="ID_530087254" MODIFIED="1693275201840" TEXT="Invoke + Feed">
<icon BUILTIN="button_ok"/>
</node>
</node>
<node CREATED="1693178622450" ID="ID_702953156" MODIFIED="1693178792128" TEXT="fallbezogen">
<node CREATED="1693178646683" ID="ID_1322750884" MODIFIED="1693178660593" TEXT="Klammer Workstart|stop"/>
@ -80372,8 +80272,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1689200547247" ID="ID_1506436785" MODIFIED="1693269217510" TEXT="termBuilder">
<arrowlink COLOR="#4e4671" DESTINATION="ID_469443507" ENDARROW="Default" ENDINCLINATION="-463;535;" ID="Arrow_ID_1203697100" STARTARROW="None" STARTINCLINATION="-890;-116;"/>
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693269179507" ID="ID_286775090" MODIFIED="1693269215395" TEXT="einfachst m&#xf6;glichen activity::Term konstruieren">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1693269179507" ID="ID_286775090" LINK="#ID_1334461256" MODIFIED="1693275234891" TEXT="einfachst m&#xf6;glichen activity::Term konstruieren">
<icon BUILTIN="pencil"/>
<node COLOR="#338800" CREATED="1693269232884" ID="ID_1940626454" MODIFIED="1693269393485" TEXT="ActivityDetector stellt auch Dummy-Job bereit">
<richcontent TYPE="NOTE"><html>
<head/>
@ -80390,17 +80290,25 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</li>
</ul>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1693275128994" ID="ID_901919286" MODIFIED="1693275153343" TEXT="Invocation-Parameter aus Job &#x27fc; INVOKE-Activity">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1693275156129" ID="ID_1778878124" MODIFIED="1693275162493" TEXT="POST-Activity anlegen">
<icon BUILTIN="button_ok"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693269199928" ID="ID_185134867" MODIFIED="1693269214903" TEXT="minimale Ausstattung verifizieren">
<icon BUILTIN="flag-yellow"/>
<node COLOR="#338800" CREATED="1693275251993" ID="ID_101711182" MODIFIED="1693275264459" TEXT="Ankerpunkt ist eine POST-Activity">
<icon BUILTIN="button_ok"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693269490081" ID="ID_815043128" MODIFIED="1693269501096" TEXT="POST hat das Timing-Window &#xfc;bernommen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693269535563" ID="ID_1083096028" MODIFIED="1693269624962" TEXT="Activities sind verlinkt">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693269535563" ID="ID_1083096028" MODIFIED="1693275264466" TEXT="Activities sind verlinkt">
<richcontent TYPE="NOTE"><html>
<head/>
<body>