ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/core/steam/engine/mock-support-test.cpp

389 lines
18 KiB
C++
Raw Normal View History

Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
/*
MockSupport(Test) - verify test support for fixture and job dispatch
Copyright (C) Lumiera.org
2023, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
/** @file mock-support-test.cpp
** unit test \ref MockSupport_test
*/
#include "lib/test/run.hpp"
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
#include "lib/test/test-helper.hpp"
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
#include "steam/engine/mock-dispatcher.hpp"
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
#include "vault/engine/nop-job-functor.hpp"
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
#include "vault/engine/dummy-job.hpp"
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
2023-05-15 23:25:29 +02:00
#include "lib/iter-tree-explorer.hpp"
Library: extract helper for unloading a sequence into a tuple
2023-05-10 13:50:19 +02:00
#include "lib/util-tuple.hpp"
Segmentation: simple implementation of time-based access - introduce a JobTicket::NOP (null-object pattern) - assuming that the function splitSplice() will retain complete coverage allways Remark: `Fixture::getPlaylistForRender()` is a leftover from the very early implementation drafts. This function was more or less based on the way Cinelerra works; it is clear by now that Lumiera can not possibly work this way, given that we'll build a low-level model and dispatch precompiled render jobs....
2023-04-27 22:30:49 +02:00
#include "lib/util.hpp"
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
using test::Test;
Library: extract helper for unloading a sequence into a tuple
2023-05-10 13:50:19 +02:00
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
namespace steam {
namespace engine{
namespace test {
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
using steam::fixture::Segment;
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
using vault::engine::DummyJob;
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
2023-05-15 23:25:29 +02:00
using lib::singleValIterator;
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
using util::isSameObject;
using util::seqTuple;
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
/**********************************************************************//**
* @test validate test support for render job planning and dispatch.
* - creating and invoking mock render jobs
* - a mocked JobTicket, generating mock render jobs
* - configurable test setup for a mocked Segmentation datastructure
* @see JobPlanningSetup_test
* @see Dispatcher
* @see vault::engine::Job
* @see steam::fixture::Segmentation
*/
class MockSupport_test : public Test
{
virtual void
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
run (Arg)
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
{
simpleUsage();
verify_MockJob();
verify_MockJobTicket();
verify_MockSegmentation();
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
verify_MockPrerequisites();
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
}
/** @test simple usage example of the test helpers */
void
simpleUsage()
{
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
// Build a simple Segment at [10s ... 20s[
MockSegmentation mockSegs{MakeRec()
.attrib ("start", Time{0,10}
,"after", Time{0,20})
.genNode()};
CHECK (3 == mockSegs.size());
fixture::Segment const& seg = mockSegs[Time{0,15}]; // access anywhere 10s <= t < 20s
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
JobTicket const& ticket = seg.jobTicket(); ///////////////////////////////////////////////////TICKET #1297 : will need to pass a ModelPort number here (use the first one, i.e. 0)
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
FrameCoord coord;
coord.absoluteNominalTime = Time(0,15);
Job job = ticket.createJobFor(coord);
CHECK (MockJobTicket::isAssociated (job, ticket));
job.triggerJob();
CHECK (DummyJob::was_invoked (job));
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
}
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
/** @test document and verify usage of a mock render job */
void
verify_MockJob()
{
Time nominalTime = lib::test::randTime();
int additionalKey = rand() % 5000;
Job mockJob = DummyJob::build (nominalTime, additionalKey);
CHECK (mockJob.getNominalTime() == nominalTime);
CHECK (not DummyJob::was_invoked (mockJob));
mockJob.triggerJob();
Job-Planning: investigate invocation of jobs ...using the MockJobTicket setup as point of reference, since the actual invocation of render nodes will only be drafted later in this "Vertical Slice" integration effort...
2023-04-30 02:18:56 +02:00
CHECK (DummyJob::was_invoked (mockJob));
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
CHECK (RealClock::wasRecently (DummyJob::invocationTime (mockJob)));
CHECK (nominalTime == DummyJob::invocationNominalTime (mockJob) );
CHECK (additionalKey == DummyJob::invocationAdditionalKey(mockJob));
Job-Planning: investigate invocation of jobs ...using the MockJobTicket setup as point of reference, since the actual invocation of render nodes will only be drafted later in this "Vertical Slice" integration effort...
2023-04-30 02:18:56 +02:00
Time prevInvocation = DummyJob::invocationTime (mockJob);
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
mockJob.triggerJob();
CHECK (prevInvocation < DummyJob::invocationTime (mockJob)); // invoked again, recorded new invocation time
CHECK (nominalTime == DummyJob::invocationNominalTime (mockJob) ); // all other Job parameter recorded again unaltered
CHECK (additionalKey == DummyJob::invocationAdditionalKey(mockJob));
}
/** @test document and verify usage of a mock JobTicket for frame dispatch */
void
verify_MockJobTicket()
{
Job-Planning: provide stub implementation for NOP job (see #1296) - can now create a Job from JobTicket::NIL - on invocation this Job will to nothing Only when the first real output backend is implemented, we can decide if this simplistic implementation is enough, or if an empty output must be explicitly generated...
2023-05-01 01:48:36 +02:00
FrameCoord coord;
coord.absoluteNominalTime = lib::test::randTime();
// build a render job to do nothing....
Job nopJob = JobTicket::NOP.createJobFor(coord);
Job-Planning: simulate backing by specific JobTicket right now we're lacking a complete working implementation of render node invocation, and thus the Dispatcher implementation can only be verified with the help of mocked jobs. However, at least a preliminary implementation of tagging the invocation instance is available, and thus we're able to verify that a given job instance indeed belongs to and is "backed" by a specific JobTicket. This is prerequisite for building up a (likewise mocked) Fixture datastructure, and this in turn was meant to form the basis for attacking an actual Scheduler implementation, followed by a real render node invocation.
2023-05-01 14:07:21 +02:00
CHECK (INSTANCEOF (vault::engine::NopJobFunctor, static_cast<JobClosure*> (nopJob.jobClosure))); //////////TICKET #1287 : fix actual interface down to JobFunctor (after removing C structs)
Job-Planning: provide stub implementation for NOP job (see #1296) - can now create a Job from JobTicket::NIL - on invocation this Job will to nothing Only when the first real output backend is implemented, we can decide if this simplistic implementation is enough, or if an empty output must be explicitly generated...
2023-05-01 01:48:36 +02:00
CHECK (nopJob.parameter.nominalTime == coord.absoluteNominalTime);
Job-Planning: simulate backing by specific JobTicket right now we're lacking a complete working implementation of render node invocation, and thus the Dispatcher implementation can only be verified with the help of mocked jobs. However, at least a preliminary implementation of tagging the invocation instance is available, and thus we're able to verify that a given job instance indeed belongs to and is "backed" by a specific JobTicket. This is prerequisite for building up a (likewise mocked) Fixture datastructure, and this in turn was meant to form the basis for attacking an actual Scheduler implementation, followed by a real render node invocation.
2023-05-01 14:07:21 +02:00
InvocationInstanceID empty; ///////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs
CHECK (lumiera_invokey_eq (&nopJob.parameter.invoKey, &empty));
Job-Planning: provide stub implementation for NOP job (see #1296) - can now create a Job from JobTicket::NIL - on invocation this Job will to nothing Only when the first real output backend is implemented, we can decide if this simplistic implementation is enough, or if an empty output must be explicitly generated...
2023-05-01 01:48:36 +02:00
Job-Planning: investigate invocation of jobs ...using the MockJobTicket setup as point of reference, since the actual invocation of render nodes will only be drafted later in this "Vertical Slice" integration effort...
2023-04-30 02:18:56 +02:00
MockJobTicket mockTicket;
CHECK (mockTicket.discoverPrerequisites().empty());
Job-Planning: provide stub implementation for NOP job (see #1296) - can now create a Job from JobTicket::NIL - on invocation this Job will to nothing Only when the first real output backend is implemented, we can decide if this simplistic implementation is enough, or if an empty output must be explicitly generated...
2023-05-01 01:48:36 +02:00
Job mockJob = mockTicket.createJobFor (coord);
Job-Planning: simulate backing by specific JobTicket right now we're lacking a complete working implementation of render node invocation, and thus the Dispatcher implementation can only be verified with the help of mocked jobs. However, at least a preliminary implementation of tagging the invocation instance is available, and thus we're able to verify that a given job instance indeed belongs to and is "backed" by a specific JobTicket. This is prerequisite for building up a (likewise mocked) Fixture datastructure, and this in turn was meant to form the basis for attacking an actual Scheduler implementation, followed by a real render node invocation.
2023-05-01 14:07:21 +02:00
CHECK ( mockTicket.verify_associated (mockJob)); // proof by invocation hash : is indeed backed by this JobTicket
CHECK (not mockTicket.verify_associated (nopJob)); // ...while some random other job is not related
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
}
Job-Planning: verify and complete the build-up of mock structures (see #1294) The prototypical setup of data structures and test support components is largely complete by now — with the exception of the `MockDispatcher`, which will be completed while moving to the next steps pertaining the setup of a frame dispatch pipeline. * the existing `DummyJob` was augmented to allow verification of association between Job and `JobTicket` * the existing implementation of `JobTicket` was verified and augmented to allow coverage of the whole usage cycle * a `MockJobTicket` was implemented on top, which can be generated from a symbolical test specification (rather than from the real Fixture data structure) * a complete `MockSegmentation` was developed, allowing to establish all the aforementioned data structures without an actual backing Render Engine. Moreover, `MockSegmentation` can be generated from the aforementioned symbolic test specification. * as part of this work, an algorithm to split an existing Segmentation and to splice in new segments was developed and verified
2023-05-24 03:38:12 +02:00
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
/** @test document and verify usage of a complete mocked Segmentation
* to back frame dispatch
Job-Planning: verify and complete the build-up of mock structures (see #1294) The prototypical setup of data structures and test support components is largely complete by now — with the exception of the `MockDispatcher`, which will be completed while moving to the next steps pertaining the setup of a frame dispatch pipeline. * the existing `DummyJob` was augmented to allow verification of association between Job and `JobTicket` * the existing implementation of `JobTicket` was verified and augmented to allow coverage of the whole usage cycle * a `MockJobTicket` was implemented on top, which can be generated from a symbolical test specification (rather than from the real Fixture data structure) * a complete `MockSegmentation` was developed, allowing to establish all the aforementioned data structures without an actual backing Render Engine. Moreover, `MockSegmentation` can be generated from the aforementioned symbolic test specification. * as part of this work, an algorithm to split an existing Segmentation and to splice in new segments was developed and verified
2023-05-24 03:38:12 +02:00
* - default constructed: empty Segmentation
* - cover the whole axis with one segment
* - partition axis and verify the association of generated jobs
* - a fully defined segment within an otherwise empty axis
* - complex partitioning (using the »split-splice« mechanism
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
*/
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
void
verify_MockSegmentation()
{
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
FrameCoord coord;
Time someTime = lib::test::randTime();
coord.absoluteNominalTime = someTime;
Job-Planning: verify and complete the build-up of mock structures (see #1294) The prototypical setup of data structures and test support components is largely complete by now — with the exception of the `MockDispatcher`, which will be completed while moving to the next steps pertaining the setup of a frame dispatch pipeline. * the existing `DummyJob` was augmented to allow verification of association between Job and `JobTicket` * the existing implementation of `JobTicket` was verified and augmented to allow coverage of the whole usage cycle * a `MockJobTicket` was implemented on top, which can be generated from a symbolical test specification (rather than from the real Fixture data structure) * a complete `MockSegmentation` was developed, allowing to establish all the aforementioned data structures without an actual backing Render Engine. Moreover, `MockSegmentation` can be generated from the aforementioned symbolic test specification. * as part of this work, an algorithm to split an existing Segmentation and to splice in new segments was developed and verified
2023-05-24 03:38:12 +02:00
//
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
//-----------------------------------------------------------------/// Empty default Segmentation
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
{
MockSegmentation mockSeg;
CHECK (1 == mockSeg.size());
JobTicket const& ticket = mockSeg[someTime].jobTicket();
CHECK (util::isSameObject (ticket, JobTicket::NOP));
}
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
//-----------------------------------------------------------------/// Segmentation with one default segment spanning complete timeline
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
{
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
MockSegmentation mockSegs{MakeRec().genNode()};
CHECK (1 == mockSegs.size());
CHECK (Time::MIN == mockSegs[someTime].start());
CHECK (Time::MAX == mockSegs[someTime].after());
JobTicket const& ticket = mockSegs[someTime].jobTicket();
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
CHECK (not util::isSameObject (ticket, JobTicket::NOP));
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
Job someJob = ticket.createJobFor(coord); // JobTicket uses, but does not check the time given in FrameCoord
CHECK (someJob.parameter.nominalTime == _raw(coord.absoluteNominalTime));
CHECK (MockJobTicket::isAssociated (someJob, ticket)); // but the generated Job is linked to the Closure backed by the JobTicket
Segmentation: draft simple mock-based setup for tests - how to pass-in a specification given as GenNode - now this might be translated into a MockJobTicket allocated in the MockSegmentation Unimplemented: actually build the Segment with suitable start/end time
2023-05-01 17:02:11 +02:00
CHECK (not DummyJob::was_invoked (someJob));
someJob.triggerJob();
CHECK (DummyJob::was_invoked (someJob));
CHECK (RealClock::wasRecently (DummyJob::invocationTime (someJob)));
CHECK (someTime == DummyJob::invocationNominalTime (someJob));
}
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
//-----------------------------------------------------------------/// Segmentation with a segment spanning part of the timeline > 10s
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
{
// Marker to verify the job calls back into the right segment
int marker = rand() % 1000;
Job-Planning: verify and complete the build-up of mock structures (see #1294) The prototypical setup of data structures and test support components is largely complete by now — with the exception of the `MockDispatcher`, which will be completed while moving to the next steps pertaining the setup of a frame dispatch pipeline. * the existing `DummyJob` was augmented to allow verification of association between Job and `JobTicket` * the existing implementation of `JobTicket` was verified and augmented to allow coverage of the whole usage cycle * a `MockJobTicket` was implemented on top, which can be generated from a symbolical test specification (rather than from the real Fixture data structure) * a complete `MockSegmentation` was developed, allowing to establish all the aforementioned data structures without an actual backing Render Engine. Moreover, `MockSegmentation` can be generated from the aforementioned symbolic test specification. * as part of this work, an algorithm to split an existing Segmentation and to splice in new segments was developed and verified
2023-05-24 03:38:12 +02:00
//
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
// Build a Segmentation partitioned at 10s
MockSegmentation mockSegs{MakeRec()
.attrib ("start", Time{0,10}
,"mark", marker)
.genNode()};
CHECK (2 == mockSegs.size());
// since only start-time was given, the SplitSplice-Algo will attach
// the new Segment starting at 10s and expand towards +∞,
// while the left part of the axis is marked as NOP / empty
fixture::Segment const& seg1 = mockSegs[Time::ZERO]; // access anywhere < 10s
fixture::Segment const& seg2 = mockSegs[Time{0,20}]; // access anywhere >= 10s
CHECK ( util::isSameObject (seg1.jobTicket(), JobTicket::NOP));
CHECK (not util::isSameObject (seg2.jobTicket(), JobTicket::NOP));// this one is the active segment
Job job = seg2.jobTicket().createJobFor(coord);
CHECK (not MockJobTicket::isAssociated (job, seg1.jobTicket()));
CHECK ( MockJobTicket::isAssociated (job, seg2.jobTicket()));
CHECK (marker == job.parameter.invoKey.part.a);
job.triggerJob();
CHECK (DummyJob::was_invoked (job));
CHECK (RealClock::wasRecently (DummyJob::invocationTime (job)));
CHECK (marker == DummyJob::invocationAdditionalKey (job)); // DummyClosure is rigged such as to feed back the seed in `part.a`
// and thus we can prove this job really belongs to the marked segment
// create another job from the (empty) seg1
job = seg1.jobTicket().createJobFor (coord);
InvocationInstanceID empty; /////////////////////////////////////////////////////////////////////TICKET #1287 : temporary workaround until we get rid of the C base structs
Segmentation: verify standard cases.. Testcase: A simple Sementation with a single and bounded Segment As aside, figured out how to unpack an iterator such as to tie a fixed number of references through a structural binding: auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
2023-05-10 03:59:46 +02:00
CHECK (lumiera_invokey_eq (&job.parameter.invoKey, &empty)); // indicates that it's just a placeholder to mark a "NOP"-Job
CHECK (seg1.jobTicket().empty());
CHECK (seg1.empty());
CHECK (not seg2.empty());
}
//-----------------------------------------------------------------/// Segmentation with one delineated segment, and otherwise empty
{
int marker = rand() % 1000;
// Build Segmentation with one fully defined segment
MockSegmentation mockSegs{MakeRec()
.attrib ("start", Time{0,10}
,"after", Time{0,20}
,"mark", marker)
.genNode()};
CHECK (3 == mockSegs.size());
auto const& [s1,s2,s3] = seqTuple<3> (mockSegs.eachSeg());
CHECK (s1.empty());
CHECK (not s2.empty());
CHECK (s3.empty());
CHECK (isSameObject (s2, mockSegs[Time{0,10}]));
CHECK (Time::MIN == s1.start());
CHECK (Time(0,10) == s1.after());
CHECK (Time(0,10) == s2.start());
CHECK (Time(0,20) == s2.after());
CHECK (Time(0,20) == s3.start());
CHECK (Time::MAX == s3.after());
Job job = s2.jobTicket().createJobFor(coord);
job.triggerJob();
CHECK (marker == DummyJob::invocationAdditionalKey (job));
Segmentation: integrate SplitSplice and build mock-segmentation ...now able to build a mock segmentation which issues dummy jobs, and is wired such as to verify the right job is invoked for each segment. And this allows to build and verify the Dispatcher, without being able to invoke actual render jobs yet.
2023-05-05 03:46:42 +02:00
}
Segmentation: complete implementation of mock / test stub setup We are now able to build and refine a segmentation and to get distinct MockJobs from these segments and to verify invocation of a specific job
2023-05-10 14:57:41 +02:00
//-----------------------------------------------------------------/// Segmentation with several segments built in specific order
{
// Build Segmentation by partitioning in several steps
MockSegmentation mockSegs{MakeRec()
.attrib ("start", Time{0,20} // note: inverted segment definition is rectified automatically
,"after", Time{0,10}
,"mark", 1)
.genNode()
,MakeRec()
.attrib ("after", Time::ZERO
,"mark", 2)
.genNode()
,MakeRec()
.attrib ("start", Time{FSecs{-5}}
,"mark", 3)
.genNode()};
CHECK (5 == mockSegs.size());
auto const& [s1,s2,s3,s4,s5] = seqTuple<5> (mockSegs.eachSeg());
CHECK (not s1.empty());
CHECK (not s2.empty());
CHECK ( s3.empty());
CHECK (not s4.empty());
CHECK ( s5.empty());
CHECK (Time::MIN == s1.start()); // the second added segment has covered the whole negative axis
CHECK (-Time(0,5) == s1.after()); // ..up to the partitioning point -5
CHECK (-Time(0,5) == s2.start()); // ...while the rest was taken up by the third added segment
CHECK (Time(0, 0) == s2.after());
CHECK (Time(0, 0) == s3.start()); // an empty gap remains between [0 ... 10[
CHECK (Time(0,10) == s3.after());
CHECK (Time(0,10) == s4.start()); // here is the first added segment
CHECK (Time(0,20) == s4.after());
CHECK (Time(0,20) == s5.start()); // and the remaining part of the positive axis is empty
CHECK (Time::MAX == s5.after());
auto probeKey = [&](Segment const& segment)
{
if (segment.empty()) return 0;
Job job = segment.jobTicket().createJobFor(coord);
job.triggerJob();
CHECK (DummyJob::was_invoked (job));
CHECK (RealClock::wasRecently (DummyJob::invocationTime (job)));
return DummyJob::invocationAdditionalKey (job);
};
CHECK (2 == probeKey(s1)); // verify all generated jobs are wired back to the correct segment
CHECK (3 == probeKey(s2));
CHECK (0 == probeKey(s3));
CHECK (1 == probeKey(s4));
CHECK (0 == probeKey(s5));
}
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
}
Job-Ticket: consider how to deal with channels and prerequisites By reasoning and analysis I conclude that the differentiation into multiple channels is likely misplaced in JobTicket; it belongs ratther into the Segment and should provide a suitable JobTicket for each ModelPort Handling of prerequisites also needs to be reshaped entirely after switching to a pipeline builder for the Job-planning pipeline; as preliminary access point, just add an iterator over the immediate prerequisites, thereby shifting the exploration mechanism entirely out of the JobTicket implementation
2023-05-11 22:47:56 +02:00
/**
* @test build a Segment with additional prerequisites,
* resulting in additional JobTickets to explore and
* additional prerequisite Jobs to build for each frame.
*/
void
verify_MockPrerequisites()
{
FrameCoord coord;
//-----------------------------------------------------------------/// one Segment with one additional prerequisite
{
MockSegmentation mockSegs{MakeRec()
.attrib("mark", 11)
.scope(MakeRec()
.attrib("mark",23)
.genNode())
.genNode()};
CHECK (1 == mockSegs.size());
JobTicket const& ticket = mockSegs[Time::ZERO].jobTicket();
auto prereq = ticket.getPrerequisites();
CHECK (not isnil (prereq));
JobTicket const& preTicket = *prereq;
++prereq;
CHECK (isnil (prereq));
Job job1 = preTicket.createJobFor (coord);
Job job2 = ticket.createJobFor (coord);
job1.triggerJob();
job2.triggerJob();
CHECK (23 == DummyJob::invocationAdditionalKey (job1));
CHECK (11 == DummyJob::invocationAdditionalKey (job2));
}
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
//-----------------------------------------------------------------/// a tree of deep nested prerequisites
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
2023-05-15 23:25:29 +02:00
{
MockSegmentation mockSegs{MakeRec()
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
.attrib("mark", 11)
.scope(MakeRec()
.attrib("mark",33)
.scope(MakeRec()
.attrib("mark",55)
.genNode()
,MakeRec()
.attrib("mark",44)
.genNode()
)
.genNode()
,MakeRec()
.attrib("mark",22)
.genNode())
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
2023-05-15 23:25:29 +02:00
.genNode()};
Job-Planning: switch to processing references ...which uncovers further deeply nested problems, especially when referring to non-copyable types. Thus need to construct a common type that can be used both to refer to the source elements and the expanded elements, and use this common type as result type and also attempt to produce better diagnostic messages on type mismatch....
2023-05-23 01:06:22 +02:00
auto start = singleValIterator (mockSegs[Time::ZERO].jobTicket());
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
2023-05-15 23:25:29 +02:00
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
auto it = lib::explore(start)
.expand ([](JobTicket const& ticket)
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
2023-05-15 23:25:29 +02:00
{
Job-Planning: switch to processing references ...which uncovers further deeply nested problems, especially when referring to non-copyable types. Thus need to construct a common type that can be used both to refer to the source elements and the expanded elements, and use this common type as result type and also attempt to produce better diagnostic messages on type mismatch....
2023-05-23 01:06:22 +02:00
return ticket.getPrerequisites();
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
})
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
2023-05-15 23:25:29 +02:00
.expandAll()
Job-Planning: switch to processing references ...which uncovers further deeply nested problems, especially when referring to non-copyable types. Thus need to construct a common type that can be used both to refer to the source elements and the expanded elements, and use this common type as result type and also attempt to produce better diagnostic messages on type mismatch....
2023-05-23 01:06:22 +02:00
.transform ([&](JobTicket const& ticket)
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
2023-05-15 23:25:29 +02:00
{
Job-Planning: switch to processing references ...which uncovers further deeply nested problems, especially when referring to non-copyable types. Thus need to construct a common type that can be used both to refer to the source elements and the expanded elements, and use this common type as result type and also attempt to produce better diagnostic messages on type mismatch....
2023-05-23 01:06:22 +02:00
return ticket.createJobFor(coord).parameter.invoKey.part.a;
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
2023-05-15 23:25:29 +02:00
});
Job-Planning: finally complete the MockSegmentation tests Last testcase: add deeply nested Prerequisites. Turns out that the allocator must be able to handle re-entrant allocations, which std::deque can not fulfil. Thus using std::list here for the Mock implementation. In the end, the real allocations will be done by our custom allocator (AllocationCluster), which can be arranged easily to support re-entrant allocation calls (since the whole point is to just place those objects into a pre-allocated large block and only de-allocate them later in one sway. Thus the allocator does not need to wait for the object constructor to finish, which trivially allows for re-entrant calls)
2023-05-23 06:40:18 +02:00
CHECK (util::join(it,"-") == "11-22-33-44-55"_expect);
} // Note: Prerequisites are prepended (LinkedElements)
} // thus at each level the last ones appear first
Segmentation: consider preliminary data structure ...and consider how that can be extended later into the full structure, which has to support a transactional switch
2023-04-27 19:38:37 +02:00
};
/** Register this test class... */
LAUNCHER (MockSupport_test, "unit engine");
}}} // namespace steam::engine::test
Reference in a new issue Copy permalink