From 90593776f682df714d42d8d4bb7aa3c9513a20fe Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 25 Apr 2023 13:40:20 +0200 Subject: [PATCH] Segmentation: a plan to bootstrap into the required structure The idea is to escape a "design deadlock" by using a test-driven prototype implementation of the data structure to back a further development of the Dispatcher and Scheduler implementation, which then can be used to gradually elaborate and switch over to an actual implementation data structure --- src/steam/mobject/session/segmentation.cpp | 6 +- src/steam/mobject/session/segmentation.hpp | 9 +- .../steam/engine/job-planning-setup-test.cpp | 2 + tests/core/steam/engine/mock-dispatcher.hpp | 26 +++ wiki/thinkPad.ichthyo.mm | 156 +++++++++++++++++- 5 files changed, 192 insertions(+), 7 deletions(-) diff --git a/src/steam/mobject/session/segmentation.cpp b/src/steam/mobject/session/segmentation.cpp index b7e4e9237..9f5fd0608 100644 --- a/src/steam/mobject/session/segmentation.cpp +++ b/src/steam/mobject/session/segmentation.cpp @@ -47,6 +47,8 @@ namespace session { // lib::OptionalRef ModelPortRegistry::theGlobalRegistry; + Segmentation::~Segmentation() { } // emit VTable here... + /** access the globally valid registry instance. * @throw error::State if this global registry is * already closed or not yet initialised. */ @@ -58,7 +60,7 @@ namespace session { // return theGlobalRegistry(); // // throw error::State ("global model port registry is not accessible" -// , LERR_(BUILDER_LIFECYCLE)); +// , LERR_(BUILDER_LIFECYCLE)); //} @@ -68,7 +70,7 @@ namespace session { // ModelPortRegistry::contains (ID key) const // { // return bool(key) -// && util::contains (transaction_, key); +// && util::contains (transaction_, key); // } diff --git a/src/steam/mobject/session/segmentation.hpp b/src/steam/mobject/session/segmentation.hpp index 7d5ffb290..32bcf0e71 100644 --- a/src/steam/mobject/session/segmentation.hpp +++ b/src/steam/mobject/session/segmentation.hpp @@ -60,14 +60,15 @@ namespace session { /** - * For the purpose of building and rendering, the fixture (for each timeline) - * is partitioned such that each segment is structurally constant. - * The Segmentation defines and maintains this partitioning. Further, + * For the purpose of building and rendering, the fixture (for each timeline) + * is partitioned such that each segment is _structurally constant._ + * The Segmentation defines and maintains this partitioning. Furthermore, * it is the general entry point for accessing the correct part of the engine * responsible for a given timeline time point. * @see SegmentationTool actually calculating the Segmentation * * @todo 1/2012 Just a Placeholder. The real thing is not yet implemented. + * @todo 4/2023 now about to bootstrap into the implementation structure step by step (WIP) * @see http://lumiera.org/wiki/renderengine.html#Fixture */ class Segmentation @@ -77,6 +78,8 @@ namespace session { /** segments of the engine in ordered sequence. */ list segments_; + public: + virtual ~Segmentation(); ///< this is an interface }; diff --git a/tests/core/steam/engine/job-planning-setup-test.cpp b/tests/core/steam/engine/job-planning-setup-test.cpp index 439f48f9d..2246d10cc 100644 --- a/tests/core/steam/engine/job-planning-setup-test.cpp +++ b/tests/core/steam/engine/job-planning-setup-test.cpp @@ -106,6 +106,8 @@ namespace test { MockJobTicket mockTick; CHECK (mockTick.discoverPrerequisites().empty()); + + MockSegmentation mockSeg; UNIMPLEMENTED ("how to mock and fake"); /////////////////////////////////////////////////////////////////////////////TODO: extract from DispatcherInterface_test /////////////////////////////////////////////////////////////////////////////TODO: design a job-ticket-mock diff --git a/tests/core/steam/engine/mock-dispatcher.hpp b/tests/core/steam/engine/mock-dispatcher.hpp index 20d7db8a4..e71c058ec 100644 --- a/tests/core/steam/engine/mock-dispatcher.hpp +++ b/tests/core/steam/engine/mock-dispatcher.hpp @@ -31,6 +31,7 @@ ////#include "steam/engine/procnode.hpp" //#include "steam/play/dummy-play-connection.hpp" +#include "steam/mobject/session/segmentation.hpp" #include "steam/mobject/model-port.hpp" #include "steam/engine/dispatcher.hpp" #include "steam/engine/job-ticket.hpp" @@ -38,6 +39,7 @@ #include "lib/time/timevalue.hpp" ////#include "lib/time/timequant.hpp" ////#include "lib/format-cout.hpp" +#include "lib/diff/gen-node.hpp" #include "lib/depend.hpp" #include "lib/itertools.hpp" //#include "lib/util-coll.hpp" @@ -50,6 +52,7 @@ //#include //#include #include +#include //using test::Test; //using util::isnil; @@ -66,6 +69,8 @@ namespace steam { namespace engine { namespace test { + using lib::diff::GenNode; + using lib::diff::MakeRec; // using lib::time::FrameRate; // using lib::time::Duration; // using lib::time::Offset; @@ -75,6 +80,9 @@ namespace test { // using mobject::ModelPort; // using play::Timings; using std::make_tuple; + using std::deque; + ///////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1294 : organisation of namespaces / includes?? + using steam::mobject::session::Segmentation; namespace { // used internally @@ -167,6 +175,24 @@ namespace test { }; + class MockSegmentation + : public Segmentation + { + std::deque tickets_; + + public: + MockSegmentation() + : MockSegmentation{MakeRec().genNode()} + { } + + MockSegmentation (std::initializer_list specs) + : tickets_{} + { + UNIMPLEMENTED ("populate mock sequence structure"); + } + }; + + /** */ diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 386d60fc7..99a1c7041 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -69639,15 +69639,104 @@ - + - + + + + + + + + + + + + + +

+ ich steck mit dem Entwurf fest, +

+
    +
  • + weil ein deduktives Interface-Design gefährlich wäre +
    • +
  • + aber ich keine ausgearbeiteten Details für einen induktiven Zugang habe +
    • +
+

+ Daher gehe ich von der bis jetzt entwickelten Architekturskizze aus, und baue zunächst ein System von Mock-Implementierungen bottom-up; auf dieser Basis kann ich dann (hoffentlich) in die Konstruktion der Engine eindringen, um so erst die Basis zu schaffen für eine realistische Beurteilung der Möglichkeiten und Anforderungen +

+ + + + + + + + + + + + + + + + + + + + + + + + + +

+ Das mache ich ganz bewußt, um die Notation intuitiver lesbar zu machen. Tatsächlich ist der Unterschied zwischen Segment und zugehörigem JobTicket nur formaler oder systematischer Natur; es sind eben zwei verschiedene Entitäten, aber sie korrelieren 1:1 und repräsentieren lediglich eine unterschiedliche Sicht auf die gleiche Sache — denn ein Segmeint ist genau dadurch definiert, daß die Verarbeitungs-Pipeline konstant ist +

+ + + + + + + + + +

+ ...die Sache so einfach wie möglich halten, und keine spezielle ID-Logik nur für die Tests erfinden! +

+ + + + + + + + + + + + + + + + +

+ Ich bin weiterhin noch nicht davon überzeugt, daß die Differenzierung in Channel überhaupt notwendig und hilfreich ist; aber ich kann das derzeit nicht belegen ⟹ daher spiele ich das Thema erst mal herunter +

+ + + + @@ -69691,6 +69780,66 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ das erlaubt flexibles Hinzufügen, ohne daß Addressen invalidiert werden. Die Tickets selber müssen NonCopyable sein +

+ + + + + + + + + + + + + + + + + + +

+ Ich kann an dieser Stelle noch nicht auf die tatsächiche Implementierung vorgreifen, sonst wird das alles ein undurchdringbares Knäuel. Die eigentliche Implementierung muß stark auf Performance optimiert sein, und daher ist die Datenstruktur vermutlich schwierig zu navigieren. Also baue ich hier ganz bewußt erst mal eine Fake-Variante auf, mit einer anderen Implementierung und einer bequemen Datenstruktur +

+ + + + + + @@ -70318,6 +70467,9 @@ + + +