diff --git a/tests/core/steam/engine/node-devel-test.cpp b/tests/core/steam/engine/node-devel-test.cpp index d7e207d12..a72f8330c 100644 --- a/tests/core/steam/engine/node-devel-test.cpp +++ b/tests/core/steam/engine/node-devel-test.cpp @@ -318,7 +318,6 @@ namespace test { BufferProvider& provider = DiagnosticBufferProvider::build(); BuffHandle buffHandle = provider.lockBuffer (provider.getDescriptorFor(sizeof(TestFrame))); - uint port{0}; CHECK (not buffHandle.accessAs().isSane()); @@ -338,22 +337,28 @@ namespace test { makeSrcNode (ont::FraNo frameNr, ont::Flavr flavour) { auto spec = testRand().setupGenerator(); -SHOW_EXPR(spec.nodeID()) return prepareNode(spec.nodeID()) -// ProcNode n{prepareNode(spec.nodeID()) .preparePort() .invoke(spec.procID(), spec.makeFun()) .setParam(frameNr,flavour) .completePort() .build(); -//SHOW_EXPR(watch(n).getNodeName() ); -// return move(n); } + /** @test use the »TestRand«-framework to setup a filter node - * + * - implementation is backed by the ont::manipulateFrame() function + * - it thus operates on \ref TestFrame data and results can be verified + * - the generated spec-recod provides a processing-functor binding and node-spec + * - can build and wire a Node processing chain with a source node and a »filter« + * node based on this data manipulation, which exactly reproduces the data + * content generated by the stand-alone invocation. + * @remark such a test-setup thus not only allows to prove that the function was invoked, + * but also the order in which the processing took place, due to hash-chaining + * applied to every single data word in the `TestFrame` buffer. + * @see NodeLink_test::trigger_node_port_invocation() */ void testRand_buildFilterNode() @@ -390,9 +395,6 @@ SHOW_EXPR(spec.nodeID()) // Build a node using this processing-functor... ProcNode nSrc = makeSrcNode (frameNr,flavour); -SHOW_EXPR(watch(nSrc).getNodeName() ); - ProcID& px = ProcID::describe("Test:generate","(TestFrame)"); -SHOW_EXPR(px.genNodeName()) ProcNode nFilt{prepareNode(spec.nodeID()) .preparePort() .invoke(spec.procID(), procFun) @@ -403,9 +405,25 @@ SHOW_EXPR(px.genNodeName()) CHECK (watch(nSrc).isSrc()); CHECK (not watch(nFilt).isSrc()); -SHOW_EXPR(watch(nSrc).getNodeSpec() ); -SHOW_EXPR(watch(nFilt).getNodeSpec() ); -SHOW_EXPR(watch(nFilt).getPortSpec(0) ); + CHECK (watch(nSrc).getNodeSpec() == "Test:generate-◎"_expect ); + CHECK (watch(nFilt).getNodeSpec() == "Test:manipulate◁—Test:generate-◎"_expect ); + CHECK (watch(nFilt).getPortSpec(0) == "manipulate(TestFrame)"_expect ); + + // prepare to invoke this Node chain... + BufferProvider& provider = DiagnosticBufferProvider::build(); + BuffHandle buffHandle = provider.lockBuffer (provider.getDescriptorFor(sizeof(TestFrame))); + uint port{0}; + + CHECK (not buffHandle.accessAs().isValid()); + + // Trigger Node invocation... + buffHandle = nFilt.pull (port, buffHandle, Time::ZERO, ProcessKey{0}); + + TestFrame& result = buffHandle.accessAs(); + CHECK ( result.isValid()); + CHECK (not result.isPristine()); + CHECK (result == *buff); + buffHandle.release(); } diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 3cbe625f8..783cd45d6 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -91978,7 +91978,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + @@ -92252,11 +92252,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + - + @@ -103213,6 +103213,10 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + @@ -104299,8 +104303,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - - + + @@ -104325,27 +104329,30 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + + - + + + + - - - +

...denn in der Policy steckt die Vorgschichte des jeweiligen Build-Vorgangs — und auch der Allokator!

- - + - - - +

die DomainOntology muß jeweils nur einige Aspekte beitragen @@ -104370,15 +104377,13 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - - + - + + - - - +

...vor allem für Src-Nodes könnte die TestRand-Ontology gleich eine fertige ProcNode liefern.... @@ -104392,17 +104397,17 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - - - + + + + + - - - +

wie viele Fälle sind das jetzt tatsächlich @@ -104411,6 +104416,25 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) + + + + +

+ ...müßte dazu viel mehr über den Builder wissen.... +

+ + + + + + + + + + + + @@ -105088,20 +105112,20 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - - + + - - + + - - + + - - + + @@ -105115,8 +105139,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - - + + @@ -105236,18 +105260,16 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - + - + - - - +

Puh... @@ -105256,8 +105278,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) ...endlos mit dem Debugger beobachtet, sieht immer alles völlig sauber aus; konnte schließlich belegen daß es nicht die de-duplzierten Strings selber sind ⟹ das hat mich dann auf die richtige Fährte gebracht: es muß einer der dazwischen liegenden String-Views sein, der in transientem Speicher liegt — und tatsächlich: in den Builder-λ erzeugen wir eine Proc-ID per Value, binden sie dann aber per Referenz in den neuen Port....

- - + + @@ -105846,7 +105868,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension) - +