From 67468f15d57a299ca0431578133d4ae791f97fc0 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Mon, 15 May 2023 23:25:29 +0200 Subject: [PATCH] Job-Planning: Attempt to build a prerequisite-Pipeline failed -- investigate why To complete the mock setup, the next step would be to extend the GenNode-based spec langage to allow defining prerequisite Mock-JobTickets. Setting this up seems rather straight forward -- however, defining a simple testcase to cover this extension runs into surprisingly tricky problems.. - for one, the singleValIterator from Itertools has serious difficulties handling references - but even more surprising, it seems impossible to make the "prerequisites iterator" fit into the Tree-Explorer framework (which I intend to use as replacement for the monadic approach) after some extended analysis of generic types and template instances, it seems that not TreeExplorer as such is the primary problem, but rather there is a conceptual mismatch somewhere deep down in Itertools or Iter-Adapter --- src/lib/meta/trait.hpp | 8 + src/steam/engine/job-ticket.hpp | 2 +- tests/core/steam/engine/mock-support-test.cpp | 64 +++ wiki/thinkPad.ichthyo.mm | 527 +++++++++++++++++- 4 files changed, 594 insertions(+), 7 deletions(-) diff --git a/src/lib/meta/trait.hpp b/src/lib/meta/trait.hpp index 96729145d..bd93801da 100644 --- a/src/lib/meta/trait.hpp +++ b/src/lib/meta/trait.hpp @@ -282,6 +282,14 @@ namespace meta { typedef TY value_type; }; + template + struct RefTraits + { + typedef TY* pointer; + typedef TY& reference; + typedef TY value_type; + }; + diff --git a/src/steam/engine/job-ticket.hpp b/src/steam/engine/job-ticket.hpp index f956e671b..41e37e97a 100644 --- a/src/steam/engine/job-ticket.hpp +++ b/src/steam/engine/job-ticket.hpp @@ -152,7 +152,7 @@ using lib::LUID; getPrerequisites (uint slotNr =0) const { return lib::transformIterator (provision_[slotNr].requirements.begin() - ,[](Prerequisite& prq) -> JobTicket& + ,[](Prerequisite& prq) -> JobTicket const& { return prq.descriptor; }); diff --git a/tests/core/steam/engine/mock-support-test.cpp b/tests/core/steam/engine/mock-support-test.cpp index ce0479d2e..73302f130 100644 --- a/tests/core/steam/engine/mock-support-test.cpp +++ b/tests/core/steam/engine/mock-support-test.cpp @@ -29,18 +29,29 @@ #include "steam/engine/mock-dispatcher.hpp" #include "vault/engine/nop-job-functor.hpp" #include "vault/engine/dummy-job.hpp" +#include "lib/iter-tree-explorer.hpp" #include "lib/util-tuple.hpp" #include "lib/util.hpp" +#include "lib/format-cout.hpp" +#include "lib/test/test-helper.hpp" using test::Test; +///////////////////////////////////////////////////////TODO WIP for investigation +namespace lib { +namespace iter_explorer { + template + using DecoTraits = _DecoratorTraits; +}} +///////////////////////////////////////////////////////TODO WIP for investigation namespace steam { namespace engine{ namespace test { using steam::fixture::Segment; using vault::engine::DummyJob; + using lib::singleValIterator; using util::isSameObject; using util::seqTuple; @@ -329,6 +340,59 @@ namespace test { CHECK (23 == DummyJob::invocationAdditionalKey (job1)); CHECK (11 == DummyJob::invocationAdditionalKey (job2)); } + //-----------------------------------------------------------------/// deep nested prerequisite + { + MockSegmentation mockSegs{MakeRec() + .attrib("mark", 11) + .scope(MakeRec() + .attrib("mark",23) + .genNode()) + .genNode()}; + + using RTick = std::reference_wrapper; + auto start = singleValIterator (& util::unConst(mockSegs[Time::ZERO].jobTicket())); + + using SrC = lib::iter_explorer::BaseAdapter >; + + auto bunny = [](JobTicket* ticket) + { + return lib::transformIterator(ticket->getPrerequisites() + ,[](JobTicket const& preq) -> JobTicket* + { return unConst(&preq); } + ); + }; + using ExIt = decltype(bunny(std::declval())); + // ergibt: lib::TransformIter::IterationState>, const steam::engine::JobTicket&>, steam::engine::JobTicket*> + + using Funny = std::function; + Funny funny = bunny; + + using ExpandedChildren = typename lib::iter_explorer::_FunTraits::Res; + +// using ResCore = lib::iter_explorer::Expander; + + using ResIter = typename lib::iter_explorer::DecoTraits::SrcIter; + using ResIterVal = typename ResIter::value_type; + using SrcIterVal = typename SrC::value_type; +// lib::test::TypeDebugger buggy; +// lib::test::TypeDebugger bugggy; + + +#if false /////////////////////////////////////////////////////////////////////////////////////////////////////////////UNIMPLEMENTED :: TICKET #1294 + auto it = lib::explore(start) +// .transform ([](RTick t) -> JobTicket const& +// { +// return t.get(); +// }) + .expand (funny) + .expandAll() + .transform ([&](JobTicket const& ticket) + { + return ticket.createJobFor(coord).parameter.invoKey.part.a; + }); + cout << util::join(it,"-") < - + @@ -69889,9 +69889,512 @@ - - + + + + + + + + + + + + + + + + + + + + + + + + + +

+ FUN = std::function<lib::TransformIter< +

+

+                         lib::TransformIter< +

+

+                             lib::IterStateWrapper< +

+

+                                 steam::engine::JobTicket::Prerequisite, +

+

+                                 LinkedElements<JobTicket::Prerequisite>::IterationState +

+

+                             >, +

+

+                             const steam::engine::JobTicket& +

+

+                         >, +

+

+                         steam::engine::JobTicket* +

+

+                                       >(steam::engine::JobTicket*) +

+

+                    >& +

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

+ src/lib/iter-tree-explorer.hpp:632 +

+ + + + + + + + + + +

+ src/lib/iter-tree-explorer.hpp:513 +

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

+ Er geht über die Instantiierung des Expander-Typs -> _DecoratorTraits<RES>::SrcIter +

+
    +
  • + wobei RES der sichtbare Ergebnis-Typ des Expand-Funktors ist, also ein Iterator. +
    • +
  • + mir fällt auf, daß die Auswertung von shall_wrap_STL_Iter<RES> geht +
    • +
  • + etwas sonderbar ist, daß dieser Auswertungspfad als Call-Stack für die Assertion-Failure auftaucht (könnte aber einfach der Arbeitsweise des Compilers geschuldet sein) +
    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ...insofern wurde es erst sichtbar, als ich angefangen habe, den Aufruf zu de/re-konstruieren +

+ + + + + + + + + + +

+ ...der dafür sorgen soll, daß aus dem Expand-Funktor ein JobTicket* rauskommt +

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

+ FUN = std::function< +

+

+     TransformIter<TransformIter<IterStateWrapper<JobTicket::Prerequisite, LinkedElements<JobTicket::Prerequisite>::IterationState> +

+

+                                ,engine::JobTicket const&> +

+

+                  ,engine::JobTicket*>(steam::engine::JobTicket*) +

+

+                    >&; +

+

+ SRC = iter_explorer::BaseAdapter<SingleValIter<engine::JobTicket*> > +

+ + + + + + + + + +

+ per TypeDebugger verifiziert: die explizit angeschriebene Variable 'start' hat den richtigen Typ +

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

+ TransformIter<TransformIter<IterStateWrapper<engine::JobTicket::Prerequisite +

+

+                                             ,LinkedElements<engine::JobTicket::Prerequisite>::IterationState> +

+

+                            ,engine::JobTicket const& +

+

+                            > +

+

+              ,steam::engine::JobTicket* +

+

+              > +

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

+ lib::iter_explorer::Expander<lib::iter_explorer::BaseAdapter<lib::SingleValIter<steam::engine::JobTicket*> >, lib::TransformIter<lib::TransformIter<lib::IterStateWrapper<steam::engine::JobTicket::Prerequisite, lib::LinkedElements<steam::engine::JobTicket::Prerequisite>::IterationState>, const steam::engine::JobTicket&>, steam::engine::JobTicket*> > +

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

+ Expander<SrC, ExpandedChildren> +

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

+ ResIter::value_type ≡ JobTIcket +

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

+ was wäre an der Stelle logisch korrekt ? +

+ + + + + + + + + + +

+ die Frage lautet: +

+

+  „können die Expanded-Results verwendet werden, +

+

+   an Stellen, wo SRC-Results erwartet werden“  +

+ + + + + + + + + + +

+ für die Expanded-Results klar: brauche exakt den Ergebnis-Typ  des Iterators +

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

+ ...denn das ergibt sich erst im Aufrufkontext; man denke z.B. an rvalue/lvalue-Probleme und temporaries, und das alles noch mit constness gemischt. Auf weia +

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

+ Und zwar erscheint mir die STL zugleich als zu komplex und zu offen; sie verleitet zu einem Low-level-Geknobel. Genau deshalb habe ich die gesamte Iteratoren- und Konzept-Hierarchie der STL beiseite geschoben, und ein »Lumiera Forward Iterator«-Concept neu definiert. +

+ + + + + + + + + + +

+ Denn ganz bewußt habe ich es abgelehnt, mit Lumiera ein universelles Framework zu schaffen (wiewohl eine Tendenz dorthin nicht zu verleugnen ist). Vielmehr geht es mit allen Konventionen und Definitionen um eine Gründung, also darum, einen Raum zu schaffen, in dem sich etwas Neues von einem wohl bestimmten Charakter entwickeln kann. Ich richte mich also nicht nach dem Vorhandenen und ich muß nicht dem Vorhandenen in allen seinen Weiterungen und Verzweigungen entsprechen.  Diese Haltung entspricht jedoch auch meinem Charakter: meine Fähigkeiten zum Erfassen und Sortieren vorgegebener Normen und Gepflogenheiten waren (und sind) gering, wenn ich mich auf einen solchen Anspruch einlasse, stehe ich schnell kräftemäßig mit dem Rücken zur Wand. Anders die meisten meiner Kollegen, die blühen da gradezu auf. +

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

+ der Implementator möchte mit den Typedefs die Signaturen aufbauen +

+ + + + + + + + + +

+ der Nutzer möchte wissen, wie er mit Resultaten umgehen kann +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -69941,7 +70444,7 @@ - + @@ -70048,7 +70551,7 @@ - + @@ -70645,6 +71148,9 @@ + + + @@ -70988,12 +71494,21 @@ - + + + + + + + + + +