Test List

Member _Pragma ("GCC diagnostic push") _Pragma("GCC diagnostic ignored \\"-Woverloaded-virtual\\"") namespace lib

check the helpers for dealing with lists-of-types. Build an interface and an implementation class by inheriting template instantiations for a collection of classes

Class AbstractTangible_test

cover the basic operations of any tangible UI element, with the help of a mock UI element.

• creation
• destruction
• command invocation
• state mark
• state mark replay
• message casting
• error state indication
• structural changes by MutationMessage

Member AbstractTangible_test::markState ()

mark interface state. This test case performs an elementary UI operation, namely to expand / collapse an element, to verify both directions of state marking. Here »state marking« is a mechanism, where UI state changes get recorded at some central StateManager, to be able to restore interface state later. Thus, when we'll expand and collapse the mock, we expect the corresponding "state mark" notifications to appear at the UI-Bus.

Member AbstractTangible_test::mutate ()

mutate the mock element through diff messages This test performs the basic mechanism used to populate the UI or to change structure or settings within individual elements. This is done by sending a MutationMessage via UI-Bus, which is handled and applied to the receiver by Lumiera's diff framework.

Member AbstractTangible_test::notify ()

receive various kinds of notifications. Send message, error and flash messages via Bus to the element and verify the doMsg, doErr or doFlash handlers were invoked.

Member AbstractTangible_test::revealer ()

configure a handler for the (optional) "reveal yourself" functionality. We install a lambda to supply the actual implementation action, which can then either be triggered by a signal/slot invocation, or by sending a "state mark".

Member AbstractTangible_test::verify_mockManipulation ()

verify the UI widget unit test support framework. The generic backbone of the Lumiera UI offers a mock UI element, with the ability to stand-in for actual elements present in the real GUI. This allows us to rig an emulated test user interface to cover interactions involving some communication from or to interface elements. After setting up a mock UI-element with a suitable name / ID, we're able to operate this element programmatically and to send messages and responses from the core "up" to this mocked interface. And since this mock element embodies an event log, the unit test code can verify the occurrence of expected events, invocations and responses.

Class AccessCasted_test

verify a helper template for accessing values either through conversion or (dynamic) downcast. Typically, this helper is used in value holder containers or variant-like data structures, where the actual type is given at instantiation time of the template and possibly erased.

Class ActivityDetector_test

verify instrumentation setup to watch scheduler Activities.

Member ActivityDetector_test::insert_ActivationTap ()

inject (prepend) an ActivationTap into existing wiring

Member ActivityDetector_test::simpleUsage ()

demonstrate a simple usage scenario of this test support facility

Member ActivityDetector_test::verifyFakeExeContext ()

faked execution context to perform Activity activation

• wired internally to report each invocation into the EventLog
• by default response of post and tick is PASS, but can be reconfigured
• invocation sequence can be verified by matching internally logged events

Member ActivityDetector_test::verifyFakeInvocation ()

verify a variation of the instrumented functor to call into a custom provided fake implementation.

Member ActivityDetector_test::verifyMockInvocation ()

verify the setup and detection of instrumented invocations

• a sequence number is embedded into the ActivityDetector
• this sequence number is recorded into an attribute at each invocation
• a DSL for verification is provided (based on the EventLog)
• arguments and sequence numbers can be explicitly checked

Member ActivityDetector_test::verifyMockJobFunctor ()

diagnostic setup to detect a JobFunctor activation

• the ActivityDetector provides specifically rigged JobFunctor instances
• these capture all invocations, based on generic invocation logging
• special match qualifier to verify the job's nominal invocation time parameter
• event verification can be combined with other verifications to cover complex invocation sequences

Member ActivityDetector_test::watch_ActivationProbe ()

a rigged diagnostic probe to detect Activity activation

Member ActivityDetector_test::watch_ActivationTap ()

diagnostic adaptor to detect and pass-through Activity activation

Member ActivityDetector_test::watch_gate ()

diagnostic setup to watch Activity::GATE activation

• when applied, Tap will be inserted before and after the instrumented GATE-Activity
• it can thus be traced when the Gate is activated, but also when the Gate condition is met and the next Activity after the Gate is activated
• for this unit-test, a Gate and a follow-up Activity is invoked directly, to verify the generated log entries

Member ActivityDetector_test::watch_notification ()

diagnostic setup to detect and watch passing a notification

• setup a chain-Activity (here: a TICK) protected by a GATE
• configure the GATE to require one notification
• connect a NOTIFY-Activity to trigger the GATE
• inject a diagnostics Tap into the notification-connection
• dispatch of the notification can be verified
• notification has been passed through the Tap to the GATE
• GATE has been decremented to zero and triggers chain
• finally the chained TICK-Activity calls into the executionCtx

Class AddClip_test

adding an test clip to the Model/Session.

Class AdviceBasics_test

proof-of-concept for the Advice collaboration. Advice allows data exchange without coupling the participants tightly. This test demonstrates the basic expected behaviour in a simple but typical situation: two unrelated entities exchange a piece of data just by referring to a symbolic topic ID.

Member AdviceBasics_test::createCollaboration ()

multiple ways how to initiate the advice collaboration

Member AdviceBasics_test::overwriting_and_retracting ()

changing the provided advice, finally retracting it, causing fallback on the default value. Any given advisor can connect to the advice system with multiple bindings consecutively. The connection has no identity beside this binding, so another server (advisor) can step into an existing connection and overwrite or retract the advice. Unless retracted, advice remains in the system, even after the advisor is gone.

Member AdviceBasics_test::simpleExchange ()

the very basic usage situation: the advisor sets an information value and the advised entity picks it up.

Class AdviceBindingPattern_test

the pattern matching machinery used to find an Advice solution. Each advice::Provision and advice::Request specifies a binding, used to discern various pieces of advice. Whenever patterns on the two sides match, an Advice channel is created, causing the advice provision to get visible to the advised entity.

Member AdviceBindingPattern_test::verifyDynamicMatch ()

match against patterns containing variables, verify the created solution arguments

Class AdviceConfiguration_test

this is a collection of tests to cover the configuration options available as policy arguments when establishing the collaboration.

• default advice values, or blocking or throwing
• using activation signals on both sides
• dispatch without locking (TODO any chance we can cover this by test??)
• more to come....

Member AdviceConfiguration_test::blockOnAdvice ()

instead of allowing default advice values, both sides may enter a blocking wait until an advice solution is available. This is implemented as special case of using signals

Member AdviceConfiguration_test::checkDefaultAdvice ()

typically, advice is a default constructible value, so there is a natural fallback in case no active advice provision exists. Alternatively we may specify to throw.

Member AdviceConfiguration_test::checkSignals ()

when opening the advice collaboration, both sides may independently install a signal (callback functor) to be invoked when the actual advice solution gets established.

Class AdviceIndex_test

the Advice system uses an index datastructure to support matching the bindings to get pairs of participants to connect by an individual advice channel.

Class AdviceMultiplicity_test

stress test for the Advice system: Concurrently add a multitude of advice provisions and check correct matching and dispatch of all advice.

Member AdviceMultiplicity_test::check_highLoadSimpleMatch ()

run simple pairs of collaborators in multiple threads. Intentionally, there should be just a single match per pair, but the timings of provision and pickup are chosen randomly

Member AdviceMultiplicity_test::check_multipleMatch ()

here, one advice might reach multiple advised entities and one entity may receive multiple pieces of advice, overwriting previous advice provisions. The receiving clients (advised entities) are polling irregularly, but finally should each pick up the correct value. To check this, advice values are generated with a specific pattern, which can be check summed

Member AdviceMultiplicity_test::check_unlockedDispatch ()

when dispatching Advice, some of the locking can be left out. Obviously this means we can't be sure anymore the client will see the newly dispatched piece of advice. But the main focus of this test is to ensure the advice system itself is working properly even without complete locking. To verify the results, each thread performs a kind of "flush" (actually creates a memory barrier) before picking up the final value

Class AdviceSituations_test

documentation of the fundamental usage scenarios envisioned in the Advice concept. This test will be augmented and completed as the Lumiera application matures.

Member AdviceSituations_test::pattern01_justPickAndBeHappy ()

usage pattern 01: simply consume Advice – irrespective if set explicitly.

Member AdviceSituations_test::pattern02_pickIfPresent ()

usage pattern 01: detect if specific advice was given.

Member AdviceSituations_test::pattern03_installOnlyOnce ()

usage pattern 01: .

Class AllocationCluster_test

verify the proper workings of our custom allocation scheme managing families of interconnected objects for the segments of the low-level model.

Member AllocationCluster_test::checkLifecycle ()

Allocation cluster grows when adding objects, but discards all objects at once when going out of scope, optionally also invoking (or not invoking) destructors.

Member AllocationCluster_test::dynamicAdjustment ()

verify the ability to adjust the latest allocation dynamically.

Member AllocationCluster_test::use_as_Allocator ()

demonstrate use as Standard-Allocator

• define a vector, string and set to use the AllocationCluster as backend
• fill the vector with numbers and the set with random strings

Member AllocationCluster_test::verifyInternals ()

cover some tricky aspects of the low-level allocator

Member Appconfig_test::fetchSetupValue ()

accessing a value from setup.ini

Class ArgumentTupleAccept_test

Build a test object, which accepts a bind(...) call with specifically typed arguments.

Class AssetCategory_test

checking the properties of Asset Category structs. They are included in the Asset::Ident identification tuple of Assets and can be used to organize Assets into a tree like structure

Class BasicPipe_test

basic properties of Pipe (structural) Assets.

Class BlockFlow_test

document the memory management scheme used by the Scheduler.

Member BlockFlow_test::adjustEpochs ()

load based regulation of Epoch spacing

• on overflow, capacity is boosted by a fixed factor
• on clean-up, a moving average of (in hindsight) optimal length is computed and used as the new Epoch spacing

Member BlockFlow_test::announceLoad ()

announce additional load to reserve additional capacity up-front.

Member BlockFlow_test::handleEpoch ()

cover properties and handling of Epochs (low-level)

• demonstrate that each Epoch is placed into an Extent
• verify that both Extent and Epoch access the same memory block
• demonstrate the standard setup and initialisation of an Epoch
• allocate some Activities into the storage and observe free-managment
• detect when the Epoch is filled up
• verify alive / dead decision relative to given deadline

Member BlockFlow_test::placeActivity ()

place Activity record into storage

• new Activity without any previously established Epoch
• place Activity into future, expanding the Epoch grid
• locate Activity relative to established Epoch grid
• fill up existing Epoch, causing overflow to next one
• exhaust multiple adjacent Epochs, overflowing to first free one
• exhaust last Epoch, causing setup of new Epoch, with reduced spacing
• use this reduced spacing also for subsequently created Epochs
• clean up obsoleted Epochs, based on given deadline

Member BlockFlow_test::simpleUsage ()

demonstrate a simple usage scenario

• open new Epoch to allocate an Activity
• clean-up at a future time point

Member BlockFlow_test::storageFlow ()

investigate progression of epochs under realistic load

• expose the allocator to a load of 200fps for simulated 3 Minutes
• assuming 10 Activities per frame, this means a throughput of 360000 Activities
• run this load exposure under saturation for performance measurement
• use a planning to deadline delay of 500ms, but with ±200ms random spread
• after 250ms (500 steps), »invoke« by accessing and adding the random checksum
• run a comparison of all-pre-allocated ⟷ heap allocated ⟷ Refcount ⟷ BlockFlow

Class BranchCase_test

verify a Sum Type to hold alternative model types for several result branches of an evaluation.

Member BranchCase_test::demonstrateStorage ()

demonstrate expected storage layout...

• the selector field always coincides with the object itself
• the storage buffer starts after the size_t selector

Member BranchCase_test::simpleUsage ()

create one alternative and access embedded model value.

Member BranchCase_test::verifyCopyAssignment ()

verify selector and payload instances are properly handled on copy, clone, assignment and swap.

Class BufferMetadata_test

verify the properties of the BufferMetadata records used internally within BufferProvider to attach additional organisational data to the exposed buffers.

Member BufferMetadata_test::verifyStandardCase ()

simulate a standard buffer provider usage cycle

Class BufferMetadataKey_test

verify calculation and relations of Buffer metadata type keys. These are used internally within the standard implementation of BufferProvider to keep track of various kinds of buffers, to provide a service for attaching metadata, e.g. a state flag. These metadata key entries are based on chained hash values, thus forming sort-of a "type" hierarchy.

• the actual BufferProvider instance-ID is the top level
• second level is the size of the buffer required
• optionally, custom ctor/dtor functions can be registered
• also optionally, implementation might attach an private-ID

Class BufferProviderProtocol_test

verify and demonstrate the usage cycle of data buffers for the engine based on the BufferProvider interface. This is kind of a "dry run" for documentation purposes, because the BufferProvider implementation used here is just a diagnostics facility, allowing to investigate the state of individual buffers even after "releasing" them.

Class BuilderQualifierSupport_test

Demonstrate a technique to supply additional descriptive ctor arguments in a type safe way.

• target and receiver may be some configurable Strategy etc.
• the idea is to provide friend functors, which might tweak or reset internal settings;
• these functors are packaged into free standing friend functions with intuitive naming...
• which, on call-site, look like algebraic expressions/data-types.

Class BuilderTool_test

the generic visitor pattern specialised for treating MObjects in the builder. Besides using existing MObject types (at the moment session::Clip), we create a yet-unknown new MObject subclass. When passing such to any BuilderTool subclass, the compiler enforces the definition of a catch-all function, which is called, when there is no other applicable treat(MO&) function. Note further, within the specific treat-functions we get direct references, without interfering with Placements and memory management. But from within the treat() function, we may access the wrapper object (i.e. shared_ptr, or lumiera::P or Placement) used when invoking the BuilderTool by using the protected interface on BuilderTool.

Class BuildSegment_test

the builder core functionality: create a render pipeline for a given segment of the Session/Timeline.

Class BusTerm_test

cover the standard node element (terminal element) within the UI-Bus, with the help of an attached mock UI element. Contrary to the related ui-element test, here we focus on the bus side of the standard interactions.

Member BusTerm_test::attachNewBusTerm ()

build a new BusTerm and verify connectivity. Every tangible UI-element bears an embedded BusTerm member. Since the latter requires another, up-link BusTerm on construction, connection to the UI-Bus is structurally ensured. Moreover, when hooking up a new UI-element, the initialisation of the embedded BusTerm will cause a down-link connection to be installed into the central routing table within the Nexus, the hub of the UI-Bus. Routing and addressing is based on the UI-element's unique EntryID, destruction of the element, through invocation of BusTerm's dtor, will ensure deregistration from the Hub.

Member BusTerm_test::captureStateMark ()

collect state mark notifications from bus We use a test version of the PresentationStateManager, based on the same building blocks as the real thing

Member BusTerm_test::clearStates ()

broadcast various degrees of state reset

Member BusTerm_test::commandInvocation ()

perform the full command binding and invocation protocol

Member BusTerm_test::pushDiff ()

integration test of mutation by diff message. Since this test focuses on the bus side of standard interactions, it seems indicated to simulate the complete invocation situation, which involves passing thread boundaries. The main thread running this test shall enact the role of the UI event thread (since the UI-Bus in the real application is confined to this UI thread). Thus we'll start another thread to enact the role of the Session, to produce diff messages and "cast" them towards the UI.

Member BusTerm_test::replayStateMark ()

replay previously captured state information" </dd> <dt> \_setscope stage::model::test::BusTerm_test Member \_internalref classstage_1_1model_1_1test_1_1BusTerm__test#a08cfefabd0d8b4a7802f4a3f53968dff "BusTerm_test::verifyNotifications" ()</dt><dd> \anchor _test000673 send notifications to a distinct element, or as broadcast. </dd> <dt> \_setscope steam::engine::test::CalcStream_test Class \_internalref classsteam_1_1engine_1_1test_1_1CalcStream__test "CalcStream_test" </dt><dd> \anchor _test000109 detailed coverage of the various CalcStream flavours supported by the render engine interface.</dd> <dt> \_setscope lib::test::CallQueue_test Class \_internalref classlib_1_1test_1_1CallQueue__test "CallQueue_test" </dt><dd> \anchor _test000001 verify a helper component for dispatching functors through a threadsafe queue. - simple usage - enqueue and dequeue several functors - multithreaded load test </dd> <dt> \_setscope lib::test::CallQueue_test Member \_internalref classlib_1_1test_1_1CallQueue__test#a3f61d2f20755eaff1341aa1500d2700b "CallQueue_test::verify_Consistency" ()</dt><dd> \anchor _test000005 consistency of queue data handling - functors of various types can be mixed - entries are moved in and out of the queue - no copying whatsoever happens - each entry gets invoked - all entries are invoked in order - enqueuing and dequeuing can be interspersed - no memory leaks in bound argument data </dd> <dt> \_setscope lib::test::CallQueue_test Member \_internalref classlib_1_1test_1_1CallQueue__test#ab1eafcb6e5efbc86870ba35bd39b82c5 "CallQueue_test::verify_ThreadSafety" ()</dt><dd> \anchor _test000007 torture the CallQueue by massively multithreaded dispatch - start #NUM_OF_THREADS (e.g. 50) threads in parallel - each of those has a randomised execution pattern to add new functors and dispatch other thread's functors </dd> <dt> \_setscope stage::model::test::CanvasHook_test Class \_internalref classstage_1_1model_1_1test_1_1CanvasHook__test "CanvasHook_test" </dt><dd> \anchor _test000650 verify the mechanism to attach widgets to a canvas, while keeping the canvas implementation itself opaque. - manage the attachment and detach automatically - ability to adjust the location parameter of an existing attachment - ability to re-attach existing attachments in a new sequence order </dd> <dt> \_setscope stage::model::test::CanvasHook_test Member \_internalref classstage_1_1model_1_1test_1_1CanvasHook__test#a3d413e5e3b72e01034101a0eb8f5acec "CanvasHook_test::attach2canvas" ()</dt><dd> \anchor _test000654 attach several widgets with distinct coordinates and verify automated detaching on destruction. </dd> <dt> \_setscope stage::model::test::CanvasHook_test Member \_internalref classstage_1_1model_1_1test_1_1CanvasHook__test#ae52926379d5d3e101db00e31b2f1ad94 "CanvasHook_test::relocateWidget" ()</dt><dd> \anchor _test000655 hook a widget at a specific position and then later relocate it on the canvas through the ViewHook front-end. </dd> <dt> \_setscope stage::interact::test::CmdContext_test Class \_internalref classstage_1_1interact_1_1test_1_1CmdContext__test "CmdContext_test" </dt><dd> \anchor _test000643 verify the front-end for context bound commands, command argument binding and invocation state from within the UI structures.</dd> <dt> \_setscope lib::test::CmdlineWrapper_test Class \_internalref classlib_1_1test_1_1CmdlineWrapper__test "CmdlineWrapper_test" </dt><dd> \anchor _test000303 for lib::Cmdline, wrapping various example cmdlines </dd> <dt> \_setscope lib::test::CmdlineWrapper_test Member \_internalref classlib_1_1test_1_1CmdlineWrapper__test#a83f859fcb4211dfbe0e64ae5ed2ba9b0 "CmdlineWrapper_test::testStandardCmdlineformat" ()</dt><dd> \anchor _test000304 wrapping a (albeit faked) standard commandline given as (argc, argv[]) </dd> <dt> \_setscope steam::control::test::CommandArgument_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandArgument__test "CommandArgument_test" </dt><dd> \anchor _test000083 Check storage handling of the command parameters and state memento.</dd> <dt> \_setscope steam::control::test::CommandArgument_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandArgument__test#a2a94f501bfa42aa72149d8aaa3634237 "CommandArgument_test::createTuples" (ArgTuples &tup)</dt><dd> \anchor _test000088 create various argument tuples and re-access their contents </dd> <dt> \_setscope steam::control::test::CommandArgument_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandArgument__test#a428752516663bdc2357957dcaf4b306b "CommandArgument_test::serialiseArgTuples" (ArgTuples &tup)</dt><dd> \anchor _test000089 serialise and de-serialise each tuple and check validity <p></dd> <dt> \_setscope steam::control::test::CommandArgument_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandArgument__test#a73114ec2a9b282dab9e8a93920359ca4 "CommandArgument_test::simulateCmdLifecycle" ()</dt><dd> \anchor _test000091 simulate a complete command lifecycle with regards to the storage handling of the command parameters and state memento. </dd> <dt> \_setscope steam::control::test::CommandBasic_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandBasic__test "CommandBasic_test" </dt><dd> \anchor _test000076 basic usage of the Steam-Layer command dispatch system. Shows how to define a simple command inline and how to trigger execution and UNDO. Verifies the command action takes place and is reverted again by the UNDO function.</dd> <dt> \_setscope steam::control::test::CommandBinding_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandBinding__test "CommandBinding_test" </dt><dd> \anchor _test000077 coverage for some specific situations when binding command arguments.</dd> <dt> \_setscope steam::control::test::CommandCloneBuilder_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandCloneBuilder__test "CommandCloneBuilder_test" </dt><dd> \anchor _test000082 check creation of a command implementation clone from top level, without disclosing specific type information about the involved closure. This includes verifying sane allocation management. </dd> <dt> \_setscope steam::control::test::CommandCloneBuilder_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandCloneBuilder__test#a34eacd205cc63bfd9d4a5c24e35b57fe "CommandCloneBuilder_test::verifySeparation" (PCmdImpl orig, PCmdImpl copy)</dt><dd> \anchor _test000084 verify the two command implementation frames are indeed separate objects without interconnection. Performing an simulated command execution-undo cycle on both instances and verify difference. </dd> <dt> \_setscope steam::control::test::CommandEquality_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandEquality__test "CommandEquality_test" </dt><dd> \anchor _test000079 cover command equality detection. Two commands are deemed equivalent, if they are based on the same CommandImpl record. This means, we only rely on the <em>identity</em> of those commands, but do not check the <em>equivalence</em> of their backing implementations. The latter can not be possibly implemented in a totally airtight fashion, and for this reason, the C++ standard decided not to support comparison between std::function objects.</dd> <dt> \_setscope steam::control::test::CommandInstanceManager_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandInstanceManager__test "CommandInstanceManager_test" </dt><dd> \anchor _test000120 CommandInstanceManager is responsible for providing individual clone copies from a basic command definition, to be bound with actual arguments and finally handed over to the SteamDispatcher for invocation.</dd> <dt> \_setscope steam::control::test::CommandInstanceManager_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandInstanceManager__test#a6e406e907f3b750bcd43c5aa7d4c1c7c "CommandInstanceManager_test::verify_duplicates" ()</dt><dd> \anchor _test000130 there can be only one active "opened" instance The CommandInstanceManager opens (creates) a new instance by cloning from the prototype. Unless this instance is dispatched, it does not allow to open a further instance (for the same instanceID). But of course it allows to open a different instance from the same prototype, but with a different invocationID and hence a different instanceID </dd> <dt> \_setscope steam::control::test::CommandInstanceManager_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandInstanceManager__test#aabb287cab42db8981a6f1e4495f1bffe "CommandInstanceManager_test::verify_extendedUsage" ()</dt><dd> \anchor _test000127 demonstrate the complete command instance usage pattern. </dd> <dt> \_setscope steam::control::test::CommandInstanceManager_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandInstanceManager__test#aabef21765bc23a64b267c6af335b1060 "CommandInstanceManager_test::verify_fallback" ()</dt><dd> \anchor _test000134 the instance manager automatically falls back on globally registered commands, when the given ID is not and was not known locally </dd> <dt> \_setscope steam::control::test::CommandInstanceManager_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandInstanceManager__test#a7bb24285da7d475c444787970b37f899 "CommandInstanceManager_test::verify_instanceIdentity" ()</dt><dd> \anchor _test000129 relation of command, instanceID and concrete instance The CommandInstanceManager provides the notion of a <em>current instance,</em> which can then be used to bind arguments. When done, it will be <em>dispatched,</em> and then go through the SteamDispatcher's CommandQueue (in this test, we use just a dummy Fixture, which only enqueues the dispatched commands.</dd> <dt> \_setscope steam::control::test::CommandInstanceManager_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandInstanceManager__test#abe11de6c4494209eafb3aeb0159de204 "CommandInstanceManager_test::verify_lifecycle" ()</dt><dd> \anchor _test000132 verify sane command lifecycle is enforced - instance need to be opened (created) prior to access - can not dispatch an instance not yet created - can not create new instance before dispatching the existing one - can not dispatch an instance before binding its arguments - can not access an instance already dispatched </dd> <dt> \_setscope steam::control::test::CommandInstanceManager_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandInstanceManager__test#a0f67b19bc1b6b0b6d891b5beffa0c631 "CommandInstanceManager_test::verify_simpleUsage" ()</dt><dd> \anchor _test000126 demonstrate the transparent instance generation (»fire and forget«) - when just specifying a global commandID and arguments, an anonymous instance will be created on-the-fly, bound and dispatched, without leaving any traces in the global or local registry - when dispatching a global commandID, where the corresponding prototype entry is already fully bound and ready for execution, likewise an anonymous clone copy is created and dispatched. </dd> <dt> \_setscope steam::control::test::CommandMessageBinding_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandMessageBinding__test "CommandMessageBinding_test" </dt><dd> \anchor _test000078 verify the simple standard usage pattern, where command arguments for binding are passed via UI-Bus message with GenNode elements. This is a simplified demonstration, but covers some tricky aspects. - commands may define arguments of arbitrary type, and at runtime these are initialised from the set of standard types allowed within GenNode elements. Here the Duration is initialised from a TimeSpan object - we support immutable argument types, which means the command binding machinery works without (re)assignment, only copy construction of argument holders into an inline buffer. - likewise we support to use an immutable type as captured state memento, which is demonstrated by capturing a Time value</dd> <dt> \_setscope steam::control::test::CommandMutation_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandMutation__test#a6c81d23b5b4d6b57e54258a7f391d47b "CommandMutation_test::checkMutation" ()</dt><dd> \anchor _test000085 check the Mutation functor which is bound to our <tt>testFunc(int)</tt>. Then create a argument closure and use this to invoke the Mutation and verify actually \c testFunc(param) is executed. </dd> <dt> \_setscope steam::control::test::CommandMutation_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandMutation__test#ae9895d5f73edfd487e9228c2cb0f64ca "CommandMutation_test::checkStateCapturingMechanism" ()</dt><dd> \anchor _test000087 check the undo memento capturing mechanism in isolation </dd> <dt> \_setscope steam::control::test::CommandMutation_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandMutation__test#a038f98c49810e5846de7a9efd8278100 "CommandMutation_test::checkUndoMutation" ()</dt><dd> \anchor _test000086 check the special Mutation which is used to \em undo a command. This time, we use our \c testFunc(int) as implementation of the "undo" function; thus its parameter has now the meaning of an captured state value. Consequently this time the \em operation which is to be undone would have the signature \c void(void) . Obviously this is a rather silly "undo" function, but it is easy to check for unit testing. To carry out this test, we first have to trigger the state capturing mechanism; after that, invoking the UndoMutation will call the testFunc with the previously captured state. </dd> <dt> \_setscope steam::control::test::CommandQueue_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandQueue__test "CommandQueue_test" </dt><dd> \anchor _test000081 verify proper working of queue management used within SteamDispatcher. - can enqueue and dequeue command messages - handling of priority messages </dd> <dt> \_setscope steam::control::test::CommandRegistry_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandRegistry__test "CommandRegistry_test" </dt><dd> \anchor _test000090 verify sane behaviour of the relevant operations on the CommandRegistry interface. Add/remove a command instance to the index, allocate an CommandImpl frame and verify it is removed properly on ref count zero. </dd> <dt> \_setscope steam::control::test::CommandRegistry_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandRegistry__test#a33a8add1cbcc01826332c3c65c2dcf11 "CommandRegistry_test::checkAllocation" (CommandRegistry &registry)</dt><dd> \anchor _test000094 verify the allocation/de-allocation handling as embedded into the CommandRegistry operation. Simulates on low level what normally happens during command lifecycle. </dd> <dt> \_setscope steam::control::test::CommandRegistry_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandRegistry__test#a4f319537ba4c58664c7a615fddf8220f "CommandRegistry_test::checkRegistration" (CommandRegistry &registry)</dt><dd> \anchor _test000093 verify the index operation. Add, search, remove, store copy. </dd> <dt> \_setscope steam::cmd::test::CommandSetup_test Class \_internalref classsteam_1_1cmd_1_1test_1_1CommandSetup__test "CommandSetup_test" </dt><dd> \anchor _test000095 cover the behaviour of the CommandSetup helper intended for inserting actual command definitions into the Session.</dd> <dt> \_setscope steam::cmd::test::CommandSetup_test Member \_internalref classsteam_1_1cmd_1_1test_1_1CommandSetup__test#a5279f8a41e40815a617fe89db66272bb "CommandSetup_test::verify_DefinitionRegistration" ()</dt><dd> \anchor _test000099 actually issue the definitions captured as side-effect of the preceding test. </dd> <dt> \_setscope steam::cmd::test::CommandSetup_test Member \_internalref classsteam_1_1cmd_1_1test_1_1CommandSetup__test#a64fad03e80638cda888f39986d124d0e "CommandSetup_test::verify_DefinitionSetup" ()</dt><dd> \anchor _test000098 create some command definitions inline and verify their properties. </dd> <dt> \_setscope steam::cmd::test::CommandSetup_test Member \_internalref classsteam_1_1cmd_1_1test_1_1CommandSetup__test#a5177c031967d8c95052dec2e8ef4b1f1 "CommandSetup_test::verify_standardUsage" ()</dt><dd> \anchor _test000103 demonstrate the standard usage pattern of command definition setup - static CommandSetup instances are created "somewhere" - when the ON_GLOBAL_INIT \ref lifecycle.h "lifecycle event" is issued, all command definitions collected thus far are invoked and thus inserted into the steam::control::CommandRegistry - from this point on, we may access a control::Command handle corresponding to these definitions, and we may create derived instances to bind parameters and invoke the operation. </dd> <dt> \_setscope steam::control::test::CommandUse1_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandUse1__test "CommandUse1_test" </dt><dd> \anchor _test000100 command usage aspects I: defining commands in various ways, then re-accessing those definitions, create instances, invoke them and undo the effect. Clean up finally. </dd> <dt> \_setscope steam::control::test::CommandUse2_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandUse2__test "CommandUse2_test" </dt><dd> \anchor _test000096 command usage aspects II: patterns of command invocation.</dd> <dt> \_setscope steam::control::test::CommandUse2_test Member \_internalref classsteam_1_1control_1_1test_1_1CommandUse2__test#a11a36b4af475304aad5babdc86aa90fa "CommandUse2_test::check_DispatcherInvocation" ()</dt><dd> \anchor _test000102 simplified integration test of command dispatch - performs the minimal actions necessary to start the session loop thread - then issues a test command, which will be queued and dispatched by the SteamDispatcher. Like in the real application, the command executions happens in the dedicated session loop thread, and thus we have to wait a moment, after which execution can be verified. - finally the SteamDispatcher is signalled to shut down. </dd> <dt> \_setscope steam::control::test::CommandUse3_test Class \_internalref classsteam_1_1control_1_1test_1_1CommandUse3__test "CommandUse3_test" </dt><dd> \anchor _test000092 command usage aspects III: elaborate handling patterns, like e.g. asynchronous or repeated invocation and command sequence bundles.</dd> <dt> \_setscope steam::asset::test::CompoundMedia_test Member \_internalref classsteam_1_1asset_1_1test_1_1CompoundMedia__test#a77137024b31ff8b5db2334a270cf675b "CompoundMedia_test::buildCompound" ()</dt><dd> \anchor _test000072 building a compound media asset by using a special factory, normally intended for loading existing sessions. </dd> <dt> \_setscope steam::asset::test::CompoundMedia_test Member \_internalref classsteam_1_1asset_1_1test_1_1CompoundMedia__test#a15d570e0c8692a173008a7a12040147e "CompoundMedia_test::modifyCompound" ()</dt><dd> \anchor _test000074 adding and removing elementary media. </dd> <dt> \_setscope steam::asset::test::CompoundMedia_test Member \_internalref classsteam_1_1asset_1_1test_1_1CompoundMedia__test#abd272f82cb5f48d3e2e52d2941c23952 "CompoundMedia_test::verifyClipStructure" ()</dt><dd> \anchor _test000075 create a (compound) clip from some compound media asset and verify the clip mirrors the media asset's structure </dd> <dt> \_setscope steam::asset::test::CreateAsset_test Class \_internalref classsteam_1_1asset_1_1test_1_1CreateAsset__test "CreateAsset_test" </dt><dd> \anchor _test000057 creating new Assets and registering them with the AssetManager. </dd> <dt> \_setscope steam::asset::test::CreateAsset_test Member \_internalref classsteam_1_1asset_1_1test_1_1CreateAsset__test#ac7c4b6115930616a184daf0d97401de6 "CreateAsset_test::createMedia" ()</dt><dd> \anchor _test000063 Creating and automatically registering Asset instances. Re-Retrieving the newly created objects from AssetManager. Checking AssetManager access functions, esp. getting different kinds of Assets by ID, querying with the wrong Category and querying unknown IDs. </dd> <dt> \_setscope steam::asset::test::CreateAsset_test Member \_internalref classsteam_1_1asset_1_1test_1_1CreateAsset__test#ad47df9e418f7006138ba5d63802adc7e "CreateAsset_test::factoryVariants" ()</dt><dd> \anchor _test000065 different variants of calling the MediaFactory, with focus on the behaviour of the basic Asset creation machinery. Covers filling out Asset's datafields, amending missing pieces of information. </dd> <dt> \_setscope lib::test::CustomSharedPtr_test Class \_internalref classlib_1_1test_1_1CustomSharedPtr__test "CustomSharedPtr_test" </dt><dd> \anchor _test000286 assure correct behaviour of lumiera's custom shared-ptr, including ADL of operators, shared ownership, typing and ordering </dd> <dt> \_setscope lib::test::CustomSharedPtr_test Member \_internalref classlib_1_1test_1_1CustomSharedPtr__test#acfd63edbed977d04f5062f4f8dea8917 "CustomSharedPtr_test::check_ordering" ()</dt><dd> \anchor _test000295 equality and ordering operators forwarded to pointee </dd> <dt> \_setscope lib::test::CustomSharedPtr_test Member \_internalref classlib_1_1test_1_1CustomSharedPtr__test#a281cb8ef9dbc9e7b2f995a8b81379395 "CustomSharedPtr_test::check_refcounting" ()</dt><dd> \anchor _test000290 smart-ptr basic behaviour </dd> <dt> \_setscope lib::test::CustomSharedPtr_test Member \_internalref classlib_1_1test_1_1CustomSharedPtr__test#a8a1c2720cbb4c9aa487104435f0fd15d "CustomSharedPtr_test::check_shared_ownership" ()</dt><dd> \anchor _test000293 cooperation with other shared-ptr types </dd> <dt> \_setscope lib::test::CustomSharedPtr_test Member \_internalref classlib_1_1test_1_1CustomSharedPtr__test#abed03cc2b539964bc38b8818aca6bd66 "CustomSharedPtr_test::check_type_relations" ()</dt><dd> \anchor _test000294 building type relationships on smart-ptrs </dd> <dt> \_setscope lib::stat::test::DataCSV_test Class \_internalref classlib_1_1stat_1_1test_1_1DataCSV__test "DataCSV_test" </dt><dd> \anchor _test000548 Document and verify a data table component to maintain measurement data series, backed by CSV storage. </dd> <dt> \_setscope lib::stat::test::DataCSV_test Member \_internalref classlib_1_1stat_1_1test_1_1DataCSV__test#aa5b62fabf78711a45307910d45823cb2 "DataCSV_test::demonnstrate_CSV_Notation" ()</dt><dd> \anchor _test000561 simplified notation of inline CSV data for tests </dd> <dt> \_setscope lib::stat::test::DataCSV_test Member \_internalref classlib_1_1stat_1_1test_1_1DataCSV__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "DataCSV_test::simpleUsage" ()</dt><dd> \anchor _test000554 add rows and data to a table without filename. </dd> <dt> \_setscope lib::stat::test::DataCSV_test Member \_internalref classlib_1_1stat_1_1test_1_1DataCSV__test#aee1d8a401183d3fd8d38f66b3edee59a "DataCSV_test::verify_CSV_Format" ()</dt><dd> \anchor _test000556 validate the simple CSV conversion functions used by DataTable </dd> <dt> \_setscope lib::stat::test::DataCSV_test Member \_internalref classlib_1_1stat_1_1test_1_1DataCSV__test#a34771b4669bcc03ff9e864f0036bee3d "DataCSV_test::verify_persistentDataFile" ()</dt><dd> \anchor _test000559 verify a table backed by persistent CSV data </dd> <dt> \_setscope steam::mobject::session::test::DefsManager_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1DefsManager__test "DefsManager_test" </dt><dd> \anchor _test000215 basic behaviour of the defaults manager ("the big picture") - retrieving a "default" object repeatedly - retrieving a more constrained "default" object - failure registers a new "default" - instance management</dd> <dt> \_setscope steam::mobject::session::test::DefsManagerImpl_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1DefsManagerImpl__test "DefsManagerImpl_test" </dt><dd> \anchor _test000212 verify some general assumptions regarding implementation details of the the defaults manager. </dd> <dt> \_setscope lumiera::query::test::DefsRegistryImpl_test Class \_internalref classlumiera_1_1query_1_1test_1_1DefsRegistryImpl__test "DefsRegistryImpl_test" </dt><dd> \anchor _test000218 build an registry table (just for this test) configured for some artificial test Types. Register some entries and verify the intended behaviour of the storage structure. </dd> <dt> \_setscope steam::asset::test::DeleteAsset_test Class \_internalref classsteam_1_1asset_1_1test_1_1DeleteAsset__test "DeleteAsset_test" </dt><dd> \anchor _test000054 deleting an Asset includes removing all dependent Assets and all MObjects relying on these. Especially this means breaking all links between the involved Objects, so the shared-ptrs can do the actual cleanup. </dd> <dt> \_setscope steam::mobject::session::test::DeleteClip_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1DeleteClip__test "DeleteClip_test" </dt><dd> \anchor _test000211 removing a test clip from the Session/Model. </dd> <dt> \_setscope lib::test::DelStash_test Class \_internalref classlib_1_1test_1_1DelStash__test "DelStash_test" </dt><dd> \anchor _test000282 create a bunch of objects with varying type and size, memorising how to kill them properly. Verify everyone is dead after mass-kill. Use a checksum not only to verify the number of objects created and destroyed, but also the individual (random) contents of the data within the objects, to ensure that the correct destructor actually is invoked for each type.</dd> <dt> \_setscope lib::test::DelStash_test Member \_internalref classlib_1_1test_1_1DelStash__test#a91f5014e20eb37dfc1348b258ffffe4f "DelStash_test::checkCustomKill" ()</dt><dd> \anchor _test000284 use a custom-provided deleter function </dd> <dt> \_setscope lib::test::DependencyConfiguration_test Class \_internalref classlib_1_1test_1_1DependencyConfiguration__test "DependencyConfiguration_test" </dt><dd> \anchor _test000010 verify the various modes of creating dependencies. - standard case is singleton creation - configuration of a specific subclass for the singleton - expose a service with explicit lifecycle - use of a custom factory function - injection of a mock implementation for unit tests</dd> <dt> \_setscope lib::test::DependencyConfiguration_test Member \_internalref classlib_1_1test_1_1DependencyConfiguration__test#a5881a101d42405c51b0cf938721bee1c "DependencyConfiguration_test::verify_automaticReplacement" ()</dt><dd> \anchor _test000014 injecting test mocks temporarily </dd> <dt> \_setscope lib::test::DependencyConfiguration_test Member \_internalref classlib_1_1test_1_1DependencyConfiguration__test#ad867660d841d20485951878c44a6980b "DependencyConfiguration_test::verify_customFactory" ()</dt><dd> \anchor _test000015 instance creation can be preconfigured with a closure. Both Singleton and Test-Mock creation can optionally be performed through a user provided Lambda or Functor. To demonstrate this, we use a <tt>Veryspecial</tt> local class, which takes an <tt>int\&</tt> as constructor parameter &ndash; and we create the actual instance through a lambda, which happens to capture a local variable by reference. </dd> <dt> \_setscope lib::test::DependencyConfiguration_test Member \_internalref classlib_1_1test_1_1DependencyConfiguration__test#a1cf2fbb2e2c847281a4a13b3e1c5b36f "DependencyConfiguration_test::verify_expose_Service_with_Lifecycle" ()</dt><dd> \anchor _test000013 expose a dedicated service instance, which can be shut down </dd> <dt> \_setscope lib::test::DependencyConfiguration_test Member \_internalref classlib_1_1test_1_1DependencyConfiguration__test#a2c6ee1dd470dd84ac97bc74ebd4946be "DependencyConfiguration_test::verify_Singleton" ()</dt><dd> \anchor _test000011 without special configuration, singletons are injected as dependency </dd> <dt> \_setscope lib::test::DependencyConfiguration_test Member \_internalref classlib_1_1test_1_1DependencyConfiguration__test#a1d04b3cbc2ef9c60d57eb5bf8d14b365 "DependencyConfiguration_test::verify_SubclassSingleton" ()</dt><dd> \anchor _test000012 preconfigure a specific subclass to be injected as singleton dependency </dd> <dt> \_setscope lib::test::DependencyFactory_test Class \_internalref classlib_1_1test_1_1DependencyFactory__test "DependencyFactory_test" </dt><dd> \anchor _test000003 verify the various modes of creating dependencies. - standard case is singleton creation - configuration of a specific subclass for the singleton - use of a custom factory function - injection of a mock implementation for unit tests</dd> <dt> \_setscope steam::asset::test::DependentAssets_test Class \_internalref classsteam_1_1asset_1_1test_1_1DependentAssets__test "DependentAssets_test" </dt><dd> \anchor _test000056 the handling of Assets dependent on other Assets and the enabling/disabling of Assets. </dd> <dt> \_setscope steam::asset::test::DependentAssets_test Member \_internalref classsteam_1_1asset_1_1test_1_1DependentAssets__test#a624d5aaa4feadacd1ef8771022692c64 "DependentAssets_test::checkDependencyMechanics" ()</dt><dd> \anchor _test000058 check operation of basic asset dependency support </dd> <dt> \_setscope steam::asset::test::DependentAssets_test Member \_internalref classsteam_1_1asset_1_1test_1_1DependentAssets__test#afbe5c148ed8f2adfb35f6a63835dc852 "DependentAssets_test::checkEnablementPropagation" ()</dt><dd> \anchor _test000060 enabling and disabling an asset should propagate to dependant assets </dd> <dt> \_setscope steam::asset::test::DependentAssets_test Member \_internalref classsteam_1_1asset_1_1test_1_1DependentAssets__test#ae0f6a0d6689bde8c9d17f735321cb220 "DependentAssets_test::checkRealAssetDependencyRegistration" ()</dt><dd> \anchor _test000062 each real world asset subclass has to care for registering and deregistering any additional dependencies. Here we collect some more prominent examples (and hopefully don't fail to cover any important special cases...) </dd> <dt> \_setscope steam::asset::test::DependentAssets_test Member \_internalref classsteam_1_1asset_1_1test_1_1DependentAssets__test#a36287e55bd7481bda2fb35a610eb390e "DependentAssets_test::checkUnlinking" ()</dt><dd> \anchor _test000059 unlink operation removing inter asset links </dd> <dt> \_setscope lib::test::DiagnosticContext_test Class \_internalref classlib_1_1test_1_1DiagnosticContext__test "DiagnosticContext_test" </dt><dd> \anchor _test000002 verify a diagnostic facility to collect and access contextual information. DiagnosticContext frames are placed into automatic storage (as local variable within some function scope). Based on thread-local storage, the next reachable frame can be accessed from anywhere within the callstack. This feature is useful for collecting information regarding features cross-cutting the usual dependency hierarchy. </dd> <dt> \_setscope lib::test::DiagnosticContext_test Member \_internalref classlib_1_1test_1_1DiagnosticContext__test#adb8b46b8383bb481a7505a22add21956 "DiagnosticContext_test::verify_heavilyParallelUsage" ()</dt><dd> \anchor _test000006 verify the thread local property of ContextStack. Create several threads, each of which processes a sequence of numbers starting from a random initial value down to one. Whenever a simple division by two leads to an odd value, this value is placed onto the ContextStack. At recursion end, we take a snapshot of the full ContextStack and then unwind. Thus the captured numbers must from a decreasing sequence of odd values. </dd> <dt> \_setscope lib::test::DiagnosticContext_test Member \_internalref classlib_1_1test_1_1DiagnosticContext__test#a6f7a7047208640161e08758130452729 "DiagnosticContext_test::verify_simpleAccess" ()</dt><dd> \anchor _test000004 create nested scopes and place a DiagnosticContext frame into each. Access the next reachable frame. </dd> <dt> \_setscope lib::diff::test::DiffComplexApplication_test Class \_internalref classlib_1_1diff_1_1test_1_1DiffComplexApplication__test "DiffComplexApplication_test" </dt><dd> \anchor _test000300 Demonstration: apply a structural change to unspecified private data structures, with the help of an \ref TreeMutator "dynamic adapter" - we use private data classes, defined right here in the test fixture to represent "just some" pre-existing data structure. - we re-assign some attribute values - we add, re-order and delete child "elements", without knowing what these elements actually are and how they are to be handled. - we recurse into mutating such an _"unspecified"_ child element.</dd> <dt> \_setscope lib::diff::test::DiffIgnoreChanges_test Class \_internalref classlib_1_1diff_1_1test_1_1DiffIgnoreChanges__test "DiffIgnoreChanges_test" </dt><dd> \anchor _test000292 Special case: build a TreeMutator to accept any change and do nothing.</dd> <dt> \_setscope lib::diff::test::DiffIgnoreChanges_test Member \_internalref classlib_1_1diff_1_1test_1_1DiffIgnoreChanges__test#af5baa4ebad482c4cb6c445a95796b1ce "DiffIgnoreChanges_test::fail_or_ignore" ()</dt><dd> \anchor _test000297 fail or ignore, depending on toggle. - the TreeMutator default implementation produces a failure, when it actually has to handle some diff verb - yet a custom TreeMutator can be configured to <tt>ignoreAllChanges()</tt>, in which case it will consume any diff without effect. This test also demonstrates that the actual TreeMutator is built anew for each diff application (TreeMutator is meant to be disposable). Thus we may alter the behaviour of the diff binding dynamically. </dd> <dt> \_setscope lib::diff::test::DiffIgnoreChanges_test Member \_internalref classlib_1_1diff_1_1test_1_1DiffIgnoreChanges__test#a0540c712efb45c62d4f776a29b9949ba "DiffIgnoreChanges_test::fish_for_content" ()</dt><dd> \anchor _test000298 fish some content and ignore everything else. While the BlackHoleMutation binding generated by <tt>ignoreAllChanges()</tt> must be used as bottom layer of a custom TreeMutator, it is possible to layer a partial diff binding on top. This test demonstrates this with a single attribute binding, which just "fishes" any value mentioned in the diff for that specific attribute. Any other changes are silently ignored non the less... </dd> <dt> \_setscope lib::diff::test::DiffIndexTable_test Class \_internalref classlib_1_1diff_1_1test_1_1DiffIndexTable__test "DiffIndexTable_test" </dt><dd> \anchor _test000291 Cover a simple lookup table helper, used to support diff generation. The IndexTable takes a snapshot of generic sequence data on construction. After that, it is immutable and supports lookup by element as key and membership check.</dd> <dt> \_setscope lib::diff::test::DiffListApplication_test Class \_internalref classlib_1_1diff_1_1test_1_1DiffListApplication__test "DiffListApplication_test" </dt><dd> \anchor _test000289 Demonstration/Concept: a description language for list differences. The representation is given as a linearised sequence of verb tokens. This test demonstrates the application of such a diff representation to a given source list, transforming this list to hold the intended target list contents.</dd> <dt> \_setscope lib::diff::test::DiffListGeneration_test Class \_internalref classlib_1_1diff_1_1test_1_1DiffListGeneration__test "DiffListGeneration_test" </dt><dd> \anchor _test000296 Demonstration/Concept: how to derive a list diff representation from the comparison of two sequences. The changes necessary to transform one sequence into the other one are given as a linear sequence of elementary mutation operations.</dd> <dt> \_setscope lib::diff::test::DiffTreeApplication_test Class \_internalref classlib_1_1diff_1_1test_1_1DiffTreeApplication__test "DiffTreeApplication_test" </dt><dd> \anchor _test000306 Demonstration/Concept: a description language for tree differences. The representation is given as a linearised sequence of verb tokens. In addition to the verbs used for list diffing, here we additionally have to deal with nested scopes, which can be entered thorough a bracketing construct \c mut(ID)...emu(ID). This test demonstrates the application of such diff sequences - in the first step, an empty root #Record<GenNode> is populated with a type-ID, three named attribute values, three child values and a nested child-Record. - the second step demonstrates various diff language constructs to alter, reshape and mutate this data structure After applying those two diff sequences, we verify that the mutated data is indeed in the reordered shape. </dd> <dt> \_setscope lib::diff::test::DiffTreeApplicationSimple_test Class \_internalref classlib_1_1diff_1_1test_1_1DiffTreeApplicationSimple__test "DiffTreeApplicationSimple_test" </dt><dd> \anchor _test000299 Demonstration/Concept: apply a "tree diff" to reshape structured data. - the demo_one() constructs a "GenNode object", which is then mutated by applying a diff. - the demo_two() uses a STL collection (vector) as <em>opaque data structure,</em> establishes a <em>diff binding</em> to that structure and then applies basically the same diff to mutate the target data. </dd> <dt> \_setscope lib::diff::test::DiffTreeApplicationSimple_test Member \_internalref classlib_1_1diff_1_1test_1_1DiffTreeApplicationSimple__test#a7dd8e67cea2d2fd30f5cc011fc9a55fb "DiffTreeApplicationSimple_test::demo_one" ()</dt><dd> \anchor _test000301 mutate a Record<GenNode> by applying the \ref #someDiff "sample diff" </dd> <dt> \_setscope lib::diff::test::DiffTreeApplicationSimple_test Member \_internalref classlib_1_1diff_1_1test_1_1DiffTreeApplicationSimple__test#a0042a533b4cfe83ee4e55eec56260c9b "DiffTreeApplicationSimple_test::demo_two" ()</dt><dd> \anchor _test000302 mutate a STL collection opaquely by applying the sample diff </dd> <dt> \_setscope lib::diff::test::DiffTreeMutationListener_test Class \_internalref classlib_1_1diff_1_1test_1_1DiffTreeMutationListener__test "DiffTreeMutationListener_test" </dt><dd> \anchor _test000305 When creating a TreeMutator binding, a listener (lambda) can be attached, to be invoked on structural changes... - inserting, removing and reordering of children counts as "structural" change - whereas assignment of a new value will only trigger <tt>onLocalChange()</tt> - mutation of nested scopes does not trigger any of these listeners, since (within the existing framework) there is no simple way to intercept also the child mutation stream to check for relevance. </dd> <dt> \_setscope lib::time::test::Digxel_test Class \_internalref classlib_1_1time_1_1test_1_1Digxel__test "Digxel_test" </dt><dd> \anchor _test000028 verify correct behaviour of an display "Digxel": A self-contained numeric element to support building displays. - build a Digxel - set a value - retrieve formatted display - verify comparisons and increments - performing side-effects from the setter-functor - formatted value caching </dd> <dt> \_setscope lib::time::test::Digxel_test Member \_internalref classlib_1_1time_1_1test_1_1Digxel__test#a87ff6dc30a519ba2a81ba207422e0d15 "Digxel_test::checkDisplayOverrun" ()</dt><dd> \anchor _test000032 Digxel should be protected against display buffer overrun </dd> <dt> \_setscope lib::time::test::Digxel_test Member \_internalref classlib_1_1time_1_1test_1_1Digxel__test#a07dfad7627ad44148369c547ffdbd923 "Digxel_test::timingMeasurements" ()</dt><dd> \anchor _test000033 perform several timing measurements and especially verify the effect of caching formatted values. Digxel avoids reformatting unchanged values; besides that it is possible to install a "mutator" functor for invoking all kinds of special behaviour on value changes. Of course doing so comes with a (considerable) price tag.... </dd> <dt> \_setscope lib::time::test::Digxel_test Member \_internalref classlib_1_1time_1_1test_1_1Digxel__test#afcb9265b691c93686bfaad104f0a0a0f "Digxel_test::verifyAssignMutatingOperators" ()</dt><dd> \anchor _test000031 verify the self-assigning increment/decrement operators. </dd> <dt> \_setscope lib::time::test::DigxelConfigurations_test Class \_internalref classlib_1_1time_1_1test_1_1DigxelConfigurations__test "DigxelConfigurations_test" </dt><dd> \anchor _test000017 verify correctness of the predefined standard Digxels. Some widely used standard configurations, including - default Digxel for int and double values - sexagesimal Digxel - hex byte Digxel - ...more to come <p></dd> <dt> \_setscope steam::engine::test::DispatcherInterface_test Class \_internalref classsteam_1_1engine_1_1test_1_1DispatcherInterface__test "DispatcherInterface_test" </dt><dd> \anchor _test000113 document and verify the engine::Dispatcher interface, used to translate a CalcStream into individual node jobs. This test covers the definition of the interface itself, together with the supporting types and the default implementation of the basic operations. It uses a mock Dispatcher implementation. </dd> <dt> \_setscope steam::engine::test::DispatcherInterface_test Member \_internalref classsteam_1_1engine_1_1test_1_1DispatcherInterface__test#a7fa6a627e59e443eae318e0c8e42d5cf "DispatcherInterface_test::accessJobTicket" ()</dt><dd> \anchor _test000118 the dispatcher knows how to pick the right JobTicket for each point on the timeline, and thus how to access the proper part of the render nodes responsible for rendering this part of the timeline </dd> <dt> \_setscope steam::engine::test::DispatcherInterface_test Member \_internalref classsteam_1_1engine_1_1test_1_1DispatcherInterface__test#a4ee9e05ff9e25de46f960a9dfd538e28 "DispatcherInterface_test::pipelineBuilder" ()</dt><dd> \anchor _test000119 for the actual use case, the dispatcher acts as entrance point to a job-planning pipeline builder, which in the end is an iterator to pull render jobs from </dd> <dt> \_setscope steam::engine::test::DispatcherInterface_test Member \_internalref classsteam_1_1engine_1_1test_1_1DispatcherInterface__test#a43b3650aff48f712d39d6e582ae3789c "DispatcherInterface_test::resolveModelPort" ()</dt><dd> \anchor _test000114 the dispatcher can resolve a known ModelPort into the internal index number used on the Segmentation for the corresponding timeline (which exposes this ModelPort) </dd> <dt> \_setscope steam::control::test::DispatcherLooper_test Class \_internalref classsteam_1_1control_1_1test_1_1DispatcherLooper__test "DispatcherLooper_test" </dt><dd> \anchor _test000108 verify encapsulated control logic of SteamDispatcher. - fusing of conditions for the pthread waiting condition - detection and handling of work states - management of builder run triggers</dd> <dt> \_setscope steam::control::test::DispatcherLooper_test Member \_internalref classsteam_1_1control_1_1test_1_1DispatcherLooper__test#afa61857ce1b091ff0f58189fb412e05b "DispatcherLooper_test::verifyBuilderStart" ()</dt><dd> \anchor _test000110 logic to trigger the builder over a complete simulated lifecycle. - when Looper::requireAction is true, the thread does not go into wait state - in the loop body * either when <tt>runBuild()</tt> is true, the builder run is triggered * or when <tt>isWorking()</tt> is true, the next command is processed - after that, Looper::markStateProcessed proceeds the state machine </dd> <dt> \_setscope lib::meta::test::DuckDetector_test Class \_internalref classlib_1_1meta_1_1test_1_1DuckDetector__test "DuckDetector_test" </dt><dd> \anchor _test000404 verify building predicates to detect properties of a type at compile time. Especially, this allows us to detect if a type in question - has a nested type with a specific name - has a member with a specific name - defines a function with a specific signature </dd> <dt> \_setscope lib::meta::test::DuckDetectorExtension_test Class \_internalref classlib_1_1meta_1_1test_1_1DuckDetectorExtension__test "DuckDetectorExtension_test" </dt><dd> \anchor _test000405 demonstrate some details regarding detection of functions within a type. The purpose of these metaprogramming techniques is to write generic containers, handlers, iterators etc, which automatically adapt themselves to the abilities of their payload type. To give an example, we may investigate the argument type of a functor or lambda, and then compose it with a suitable adapter or converter to work with the given data.</dd> <dt> \_setscope lib::meta::test::DuckDetectorExtension_test Member \_internalref classlib_1_1meta_1_1test_1_1DuckDetectorExtension__test#aaae96a92d1b679b4eb2a2ee1b4181060 "DuckDetectorExtension_test::detect_freeFunctionADL_ExtensionPoint" ()</dt><dd> \anchor _test000414 detect the presence of a free function extension point at compile time. It is a common idiom in C++ to expose an extension point through a free function, which is expected to be picked up by ADL. To mention a prominent example, any type can offer the ability to be <em>iterated</em> by injecting free functions <tt>begin(TY)</tt> and <tt>end(TY)</tt>, to yield a STL compatible iterator.</dd> <dt> \_setscope lib::meta::test::DuckDetectorExtension_test Member \_internalref classlib_1_1meta_1_1test_1_1DuckDetectorExtension__test#acd3aa50e82c8e0117bc6388560d58379 "DuckDetectorExtension_test::detect_memberFunctionVariations" ()</dt><dd> \anchor _test000416 cover variations of member function detection - detect an explicitly given full signature - detect just the presence of a function <em>name</em> - distinguish this from detecting a <em>member</em> - detect especially a member function without arguments </dd> <dt> \_setscope steam::play::test::DummyPlayConnection_test Class \_internalref classsteam_1_1play_1_1test_1_1DummyPlayConnection__test "DummyPlayConnection_test" </dt><dd> \anchor _test000247 verify the OutputSlot interface and base implementation by performing full data exchange cycle. This is a kind of "dry run" for documentation purposes, both the actual OutputSlot implementation as the client using this slot are Mocks. </dd> <dt> \_setscope stage::model::test::ElementAccess_test Class \_internalref classstage_1_1model_1_1test_1_1ElementAccess__test "ElementAccess_test" </dt><dd> \anchor _test000651 verify the usage pattern of low-level UI element access, based on a mock implementation of the accessor directory. <p></dd> <dt> \_setscope stage::model::test::ElementAccess_test Member \_internalref classstage_1_1model_1_1test_1_1ElementAccess__test#a6f7a7047208640161e08758130452729 "ElementAccess_test::verify_simpleAccess" ()</dt><dd> \anchor _test000652 simple access to an existing element designated by coordinates </dd> <dt> \_setscope stage::model::test::ElementAccess_test Member \_internalref classstage_1_1model_1_1test_1_1ElementAccess__test#a5177c031967d8c95052dec2e8ef4b1f1 "ElementAccess_test::verify_standardUsage" ()</dt><dd> \anchor _test000653 the standard use case is to create one new child node below an existing path (widget) within the UI </dd> <dt> \_setscope steam::engine::test::EngineInterface_test Class \_internalref classsteam_1_1engine_1_1test_1_1EngineInterface__test "EngineInterface_test" </dt><dd> \anchor _test000112 cover the basic service exposed at the engine interface: create a calculation stream and verify the translation into individual jobs.</dd> <dt> \_setscope lib::idi::test::EntryID_test Class \_internalref classlib_1_1idi_1_1test_1_1EntryID__test "EntryID_test" </dt><dd> \anchor _test000067 proof-of-concept test for a combined symbolic and hash based ID. - create some symbolic IDs - check default assignment works properly - check comparisons - check hashing - use the embedded hash ID (LUID) as hashtable key</dd> <dt> \_setscope lib::idi::test::EntryID_test Member \_internalref classlib_1_1idi_1_1test_1_1EntryID__test#af4c531aeaa4ac5e4b9ae284e58f85039 "EntryID_test::buildHashtable" ()</dt><dd> \anchor _test000070 build a hashtable, using EntryID as key, thereby using the embedded hash-ID </dd> <dt> \_setscope lib::idi::test::EntryID_test Member \_internalref classlib_1_1idi_1_1test_1_1EntryID__test#a957a69418830df4e95e3af5b4df89858 "EntryID_test::checkErasure" ()</dt><dd> \anchor _test000069 handling of EntryIDs through their common base class, which means erasing the specific type information. While this type information can't be recovered after erasure, we can try to upcast back to a known type; this upcast is safe, because the embedded hash-ID is based on the type info. </dd> <dt> \_setscope lib::test::test::EventLog_test Class \_internalref classlib_1_1test_1_1test_1_1EventLog__test "EventLog_test" </dt><dd> \anchor _test000592 verify a logging facility, which can be used to ensure some events happened while running test code. - various kinds of events or function calls are logged via the logging API. - within the test code, a match is performed against the contents of the log, using a DSL to represent matches relative to other matches - when a match fails, additional diagnostics are printed to STDERR </dd> <dt> \_setscope lib::test::test::EventLog_test Member \_internalref classlib_1_1test_1_1test_1_1EventLog__test#a596cd90cf98d98d9f9dd0ec3c6d7a018 "EventLog_test::verify_logJoining" ()</dt><dd> \anchor _test000602 combining several logs The EventLog objects are actually just lightweight front-end handles, while the actual log lives on the Heap. This allows to have several handles hold onto the same actual log; this way, we can access and verify logs even after the managing object is destroyed.</dd> <dt> \_setscope lumiera::test::ExceptionError_test Member \_internalref classlumiera_1_1test_1_1ExceptionError__test#a6a58275978be6c5d43c2a415d83b97c3 "ExceptionError_test::checkErrorFlagPropagation" ()</dt><dd> \anchor _test000315 verify throwing of Exceptions based on a non-cleared C error flag </dd> <dt> \_setscope lumiera::test::ExceptionError_test Member \_internalref classlumiera_1_1test_1_1ExceptionError__test#a6c01a7be77da81cdcc1f0ff744e2d760 "ExceptionError_test::checkRootCauseChaining" ()</dt><dd> \anchor _test000317 the chaining of lumiera::Exception objects and the retrieval of the original root cause. </dd> <dt> \_setscope lumiera::test::ExceptionError_test Member \_internalref classlumiera_1_1test_1_1ExceptionError__test#adbaf9bdb23cb0453ef889e6814960103 "ExceptionError_test::doubleNestedTh" (string msg)</dt><dd> \anchor _test000314 repeated repackaging and rethrowing </dd> <dt> \_setscope lumiera::test::ExceptionError_test Member \_internalref classlumiera_1_1test_1_1ExceptionError__test#aba1639fe27cd4abbef5be48ca05bd909 "ExceptionError_test::nestedThrower" (string msg)</dt><dd> \anchor _test000313 catching, repackaging and rethrowing of errors. This feature is important for passing exceptions transparently over several layers. The nested operation will throw an error::External, which we are able to catch because it is derived from std::exception. We don't need to know the exact type, but we can classify the error situation as a "state error" and throw an error::State, passing on the root cause. Some levels up, this error get caught and the root cause can be extracted successfully. </dd> <dt> \_setscope lumiera::test::ExceptionError_test Member \_internalref classlumiera_1_1test_1_1ExceptionError__test#a0c99a84bcd958e96355da2220b747822 "ExceptionError_test::throwSpecial" (string)</dt><dd> \anchor _test000312 simply throw some exception and pass context info </dd> <dt> \_setscope vault::mem::test::ExtentFamily_test Class \_internalref classvault_1_1mem_1_1test_1_1ExtentFamily__test "ExtentFamily_test" </dt><dd> \anchor _test000767 document and verify a memory management scheme to maintain a flexible set of <em>»memory extents«</em> for cyclic usage. </dd> <dt> \_setscope vault::mem::test::ExtentFamily_test Member \_internalref classvault_1_1mem_1_1test_1_1ExtentFamily__test#ab7876fd28e8bdd3617eb3c2cd3425cbb "ExtentFamily_test::iteration" ()</dt><dd> \anchor _test000771 verify access to the extents by iteration, thereby possibly claiming the next extents </dd> <dt> \_setscope vault::mem::test::ExtentFamily_test Member \_internalref classvault_1_1mem_1_1test_1_1ExtentFamily__test#a821f2c326cacd2b347fb020594d951d6 "ExtentFamily_test::reuseUnclean" ()</dt><dd> \anchor _test000772 verify that neither constructors nor destructors are invoked automatically when discarding or re-using extents. </dd> <dt> \_setscope vault::mem::test::ExtentFamily_test Member \_internalref classvault_1_1mem_1_1test_1_1ExtentFamily__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "ExtentFamily_test::simpleUsage" ()</dt><dd> \anchor _test000769 demonstrate a simple usage scenario </dd> <dt> \_setscope vault::mem::test::ExtentFamily_test Member \_internalref classvault_1_1mem_1_1test_1_1ExtentFamily__test#ace4902febf6ffb8871435f885048bfbf "ExtentFamily_test::use_and_drop" ()</dt><dd> \anchor _test000770 verify claiming new and discarding old slots </dd> <dt> \_setscope vault::mem::test::ExtentFamily_test Member \_internalref classvault_1_1mem_1_1test_1_1ExtentFamily__test#af2f9fe63ff47ac09c140a51bf44a0673 "ExtentFamily_test::wrapAround" ()</dt><dd> \anchor _test000773 verify in detail how iteration wraps around to also reuse previously dropped extents, possibly rearranging the internal management-vector to allow growing new extents at the end. - existing allocations are re-used cyclically - this may lead to a »wrapped« internal state - necessitating to expand allocations in the middle - yet all existing Extent addresses remain stable </dd> <dt> \_setscope lib::stat::test::FileSupport_test Class \_internalref classlib_1_1stat_1_1test_1_1FileSupport__test "FileSupport_test" </dt><dd> \anchor _test000309 verify supplemental helper functions for file-handling support, provided to complement the C++ <tt>\<filesystem\></tt> library. </dd> <dt> \_setscope lib::stat::test::FileSupport_test Member \_internalref classlib_1_1stat_1_1test_1_1FileSupport__test#aea2662ef0b141b9c18eb215bdf399224 "FileSupport_test::homedirectoryExpansion" ()</dt><dd> \anchor _test000311 verify <em>consolidated path</em> - retrieves and expands the POSIX home directory - transforms into canonical, absolute path </dd> <dt> \_setscope steam::fixture::test::FixtureChangeDetector_test Class \_internalref classsteam_1_1fixture_1_1test_1_1FixtureChangeDetector__test "FixtureChangeDetector_test" </dt><dd> \anchor _test000190 planned test for detecting changes in a given segmentation <p></dd> <dt> \_setscope steam::fixture::test::FixtureSegment_test Class \_internalref classsteam_1_1fixture_1_1test_1_1FixtureSegment__test "FixtureSegment_test" </dt><dd> \anchor _test000213 Verify properties and behaviour of a single Segment in the Segmentation - construction of a mocked Segment - on-demand allocation of a JobTicket for a ModelPort(index) </dd> <dt> \_setscope steam::fixture::test::FixtureSegment_test Member \_internalref classsteam_1_1fixture_1_1test_1_1FixtureSegment__test#a76ca1dd9edabc8ce5ed1e802728c69e4 "FixtureSegment_test::fabricate_MockSegment" ()</dt><dd> \anchor _test000214 setup a properly structured ExitNode graph using the specification scheme supported by MockSegmentation </dd> <dt> \_setscope steam::fixture::test::FixtureSegment_test Member \_internalref classsteam_1_1fixture_1_1test_1_1FixtureSegment__test#a4462f723c40c76103d7ad20627005d24 "FixtureSegment_test::retrieve_JobTicket" ()</dt><dd> \anchor _test000216 on-demand generate a JobTicket from an existing NodeGraphAttachment </dd> <dt> \_setscope util::test::FormatCOUT_test Class \_internalref classutil_1_1test_1_1FormatCOUT__test "FormatCOUT_test" </dt><dd> \anchor _test000316 How to build generic string conversion into <tt>ostream::operator\<\<</tt>. This task (#985) was actually a conglomerate of several chores: - sanitise and segregate the type-traits usage - disentangle the existing util::str() conversion helper - extract a basic form from this helper, which can be placed into a header with minimal dependencies. After some consideration, I decided to allow <tt>\<typeinfo\></tt> in this category, which allows us at least to show a type name as fallback - distill an essential version of <tt>enable_if</tt>, which can be inlined. This allowed us to get rid of <tt>boost::enable_if</tt> finally. - build a sensible <tt>operator string()</tt> for our <tt>lib::P</tt> based on this - and <em>finally</em>, to come up with a templated version of the <tt>ostream</tt> inserter <tt>operator\<\<</tt>, which does not cause too much havoc when used by default. The greatest challenge here is to avoid ambiguous overloads, yet also to deal with references, <tt>void</tt> and arrays.</dd> <dt> \_setscope util::test::FormatHelper_test Class \_internalref classutil_1_1test_1_1FormatHelper__test "FormatHelper_test" </dt><dd> \anchor _test000321 verifies the proper working of some string-formatting helper functions. - util::toString() provides a failsafe to-String conversion, preferring an built-in conversion, falling back to just a type string. - util::join() combines elements from arbitrary containers or iterators into a string, relying on aforementioned generic string conversion </dd> <dt> \_setscope util::test::FormatHelper_test Member \_internalref classutil_1_1test_1_1FormatHelper__test#a78c03e2a74ae905dcc136b604f995135 "FormatHelper_test::check2String" ()</dt><dd> \anchor _test000327 verify a failsafe to-string conversion. </dd> <dt> \_setscope util::test::FormatHelper_test Member \_internalref classutil_1_1test_1_1FormatHelper__test#a7a4c58d1f9e6e817f3f42f36b72aa6b0 "FormatHelper_test::checkPrefixSuffix" ()</dt><dd> \anchor _test000333 convenience helpers to deal with prefixes and suffixes </dd> <dt> \_setscope util::test::FormatHelper_test Member \_internalref classutil_1_1test_1_1FormatHelper__test#ad292fb6448e66c5703186d33169759f9 "FormatHelper_test::checkStringify" ()</dt><dd> \anchor _test000328 inline to-string converter function - can be used as transforming iterator - alternatively accept arbitrary arguments </dd> <dt> \_setscope util::test::FormatHelper_test Member \_internalref classutil_1_1test_1_1FormatHelper__test#afccd3b3ec9a67ef432fbaa15905830fb "FormatHelper_test::checkStringJoin" ()</dt><dd> \anchor _test000332 verify delimiter separated joining of arbitrary collections. - the first test uses a STL container, which means we need to wrap into a lib::RangeIter. Moreover, lexical_cast is used to convert the double numbers into strings. - the second test uses an inline transforming iterator to build a series of AutoCounter objects, which provide a custom string conversion function. Moreover, since the transforming iterator conforms to the Lumiera Forward Iterator concept, we can just move the rvalue into the formatting function without much ado </dd> <dt> \_setscope util::test::FormatString_test Class \_internalref classutil_1_1test_1_1FormatString__test "FormatString_test" </dt><dd> \anchor _test000330 verifies our front-end for printf-style format string based formatting. - the implementation is based on boost::format - we create a wrapper-object on-the fly, which is able to hold the result of a partial invocation, until all parameters are given. - explicit specialisations feed all primitive types directly down into the implementation level. If possible, a custom operator string() will be used for formatting. - exceptions will be logged, but handled gracefully</dd> <dt> \_setscope lib::time::format::test::FormatSupport_test Class \_internalref classlib_1_1time_1_1format_1_1test_1_1FormatSupport__test "FormatSupport_test" </dt><dd> \anchor _test000022 check how support for a specific timecode format can be enabled and detected. Actually this test verifies a simple metaprogramming facility, which allows to check type support at runtime. </dd> <dt> \_setscope lib::meta::test::FunctionClosure_test Class \_internalref classlib_1_1meta_1_1test_1_1FunctionClosure__test "FunctionClosure_test" </dt><dd> \anchor _test000429 building a function closure for a given function or functor, while arguments are passed in as tuple - accessing signatures as typelists - bind free function to tuple - bind functor to tuple </dd> <dt> \_setscope lib::meta::test::FunctionComposition_test Class \_internalref classlib_1_1meta_1_1test_1_1FunctionComposition__test "FunctionComposition_test" </dt><dd> \anchor _test000435 this test covers some extensions and variations on function closures: - partial application of a function, returning a partial closure - variation: binding an arbitrary term, might even be a nested binder - chaining of two functions with suitable arguments ("composition") </dd> <dt> \_setscope lib::meta::test::FunctionComposition_test Member \_internalref classlib_1_1meta_1_1test_1_1FunctionComposition__test#a394ba7811b6e562dddf3e4247db963e1 "FunctionComposition_test::verify_referenceHandling" ()</dt><dd> \anchor _test000447 ensure reference types and arguments are handled properly </dd> <dt> \_setscope lib::meta::test::FunctionErasure_test Class \_internalref classlib_1_1meta_1_1test_1_1FunctionErasure__test "FunctionErasure_test" </dt><dd> \anchor _test000430 Create specifically typed functor objects and then wrap them into common holder objects, thereby discarding the specific signature type information. Later on, the concrete functor can be re-accessed, given the exact and specific type.</dd> <dt> \_setscope lib::meta::test::FunctionSignature_test Class \_internalref classlib_1_1meta_1_1test_1_1FunctionSignature__test "FunctionSignature_test" </dt><dd> \anchor _test000433 verify metaprogramming trait to pick up function signature types. - ability to handle <em>function like</em> entities uniformly - can handle function references, function pointers, member pointer to function, functor objects, <tt>std::function</tt> and lambdas - supports arbitrary number of arguments </dd> <dt> \_setscope lib::test::FunHashDispatch_test Class \_internalref classlib_1_1test_1_1FunHashDispatch__test "FunHashDispatch_test" </dt><dd> \anchor _test000320 Verify generic helper to provide a hash-based function dispatch table. - instances are tied to one specific function signature - entries are keyed by a hash-ID - given that ID, the registered functions can be invoked - once enrolled, entries can not be replaced </dd> <dt> \_setscope lib::meta::test::GeneratorCombinations_test Class \_internalref classlib_1_1meta_1_1test_1_1GeneratorCombinations__test "GeneratorCombinations_test" </dt><dd> \anchor _test000431 check utilities for generating case combinations. - verify the Cartesian product is built properly - instantiate a two-parameter test template for all those cases, as given by the Cartesian product of two Type collections </dd> <dt> \_setscope lib::idi::test::GenericIdFunction_test Class \_internalref classlib_1_1idi_1_1test_1_1GenericIdFunction__test "GenericIdFunction_test" </dt><dd> \anchor _test000335 cover a standard scheme to generate type and instance identifiers.</dd> <dt> \_setscope lib::diff::test::GenericRecord_test Class \_internalref classlib_1_1diff_1_1test_1_1GenericRecord__test "GenericRecord_test" </dt><dd> \anchor _test000308 Verify properties of a special collection type meant for external representation of object-like data, especially for symbolic representation in diff messages. - there is a type meta attribute - a Record can have attributes (by key) and contents (ordered list of values) - various kinds of iterators are provided - besides the regular constructor, which explicitly takes a type, a collection of attributes, and a collection of contents, there is a convenience constructor especially for literal notation and data definition. This one figures out the break between attributes and contents automatically; a type meta attribute is recognised and the first element without a given key or ID ends the attributes and starts the content scope - Record elements are conceived as values and equality is defined in terms of their contents, including the order (no normalisation, no sorting) - they are \em immutable after construction. But we provide a Mutator for remoulding a given element, enabling object builder notation. - a reference wrapper for handling of large structures is provided. </dd> <dt> \_setscope lib::diff::test::GenNode_test Class \_internalref classlib_1_1diff_1_1test_1_1GenNode__test "GenNode_test" </dt><dd> \anchor _test000403 Verify properties of a special collection type shaped for external representation of object-like data. - GenNode elements can be created "right away", picking up the given type, assumed that the payload is one of the supported basic types. - optionally, GenNode elements can be named - unnamed elements get a marker ID plus unique number extension - object-like elements can be represented by using a diff:Record<GenNode> as payload. Obviously, the resulting data structure type is recursive. - a shortcut is provided to simplify defining empty baseline objects - a special notation is provided to create "id references", which can be used to stand-in for an "object" (Record). This shortcut notation is relevant for the tree diff language &ndash; used within Lumiera as "External Tree Description" of object networks.</dd> <dt> \_setscope lib::diff::test::GenNode_test Member \_internalref classlib_1_1diff_1_1test_1_1GenNode__test#ae550e29f6909bf3a1d97417d89da4aeb "GenNode_test::convenienceRecAccess" ()</dt><dd> \anchor _test000427 simplified notation for access to nested record properties. This is a somewhat questionable shorthand, insofar it allows to "probe" the contents of a GenNode to some limited extent. Generally speaking, we'd prefer if the code using GenNode operates based on precise structural knowledge, instead of peeking into the data. </dd> <dt> \_setscope lib::test::GnuplotGen_test Class \_internalref classlib_1_1test_1_1GnuplotGen__test "GnuplotGen_test" </dt><dd> \anchor _test000324 verify data visualisation by generated Gnuplot scripts - generate a simple pot - generate a scatter plot with regression line </dd> <dt> \_setscope lib::test::GnuplotGen_test Member \_internalref classlib_1_1test_1_1GnuplotGen__test#a31900225f7c2e7d34121f5deacfc0dce "GnuplotGen_test::plot_scatter_regression" ()</dt><dd> \anchor _test000326 Create a (x,y) scatter plot with regression line - in the simple case, there is only one diagram - use the <tt>stats</tt> command to let Gnuplot calculate the linear regression - draw a regression line as function representing the regression model </dd> <dt> \_setscope lib::test::GnuplotGen_test Member \_internalref classlib_1_1test_1_1GnuplotGen__test#abff38d063e657977406b388029ba00f9 "GnuplotGen_test::simpeUsage" ()</dt><dd> \anchor _test000325 Create simple (x,y) data point visualisation </dd> <dt> \_setscope lib::test::GnuplotGen_test Member \_internalref classlib_1_1test_1_1GnuplotGen__test#a729d0fa55e70d96f7cc46dcb13291c22 "GnuplotGen_test::verify_customisation" ()</dt><dd> \anchor _test000329 various customisations through additional parameters - a custom defined regression line - use a specific output »term« and specify canvas size - define the common horizontal data range and x-tic spacing - define display ranges for 3 different Y-axis - define custom labels for all axes </dd> <dt> \_setscope steam::control::test::HandlingPatternBasics_test Class \_internalref classsteam_1_1control_1_1test_1_1HandlingPatternBasics__test "HandlingPatternBasics_test" </dt><dd> \anchor _test000104 operate and verify a simple dummy command handling pattern. </dd> <dt> \_setscope steam::control::test::HandlingPatternBasics_test Member \_internalref classsteam_1_1control_1_1test_1_1HandlingPatternBasics__test#aee1e3e61e987a99c9443110eb074b20f "HandlingPatternBasics_test::checkExec" (PCommandImpl com)</dt><dd> \anchor _test000105 verify the Handling pattern API: execute a command </dd> <dt> \_setscope steam::control::test::HandlingPatternBasics_test Member \_internalref classsteam_1_1control_1_1test_1_1HandlingPatternBasics__test#ab2692ea4cc490531196d683e07a62e8c "HandlingPatternBasics_test::checkUndo" (PCommandImpl com)</dt><dd> \anchor _test000106 verify the Handling pattern API: undo a command </dd> <dt> \_setscope steam::control::test::HandlingPatternBasics_test Member \_internalref classsteam_1_1control_1_1test_1_1HandlingPatternBasics__test#a39ec0cc7d88396eb1ceb4af009860605 "HandlingPatternBasics_test::useCustomHandler" (PCommandImpl com)</dt><dd> \anchor _test000107 use custom implementation of the HandlingPattern interface, rigged to verify the functions are actually invoked. </dd> <dt> \_setscope steam::control::test::HandlingPatternStandardImpl_test Class \_internalref classsteam_1_1control_1_1test_1_1HandlingPatternStandardImpl__test "HandlingPatternStandardImpl_test" </dt><dd> \anchor _test000097 verify correct behaviour of all the command handling patterns provided by the default configuration of a lumiera session. - executing quasi synchronous - the throw-on-error variant - background execution - ...? <p></dd> <dt> \_setscope lib::test::HashGenerator_test Class \_internalref classlib_1_1test_1_1HashGenerator__test "HashGenerator_test" </dt><dd> \anchor _test000323 cover various detail aspects regarding hash value generation - weakness of boost::hash</dd> <dt> \_setscope lib::test::HashGenerator_test Member \_internalref classlib_1_1test_1_1HashGenerator__test#ae01540c2ca64a4f6c30af34031fe64cd "HashGenerator_test::demonstrate_boost_hash_weakness" ()</dt><dd> \anchor _test000367 demonstrate a serious weakness of boost::hash for strings. When hashing just the plain string representation of integers, we get collisions already with small numbers below 100000. This is counter-intuitive, as the generated hash values are 17 digits long and could span much wider scale.</dd> <dt> \_setscope lib::test::HashGenerator_test Member \_internalref classlib_1_1test_1_1HashGenerator__test#a9e9e977f0ff46b1c0099df6a1043c8a5 "HashGenerator_test::verify_Knuth_workaround" ()</dt><dd> \anchor _test000372 verify a well-known pragmatic trick to help with unevenly spaced hash values. The boost::hash function is known to perform poorly on strings with common prefix plus running number. The mentioned trick (attributed to Donald Knuth) is spread the input numbers by something below the full domain, best close to the golden ratio; bonus points if this number is also a prime. An additional factor of 2 does not hurt (so in case of 64bit platform).</dd> <dt> \_setscope lib::test::HashIndexed_test Class \_internalref classlib_1_1test_1_1HashIndexed__test "HashIndexed_test" </dt><dd> \anchor _test000322 proof-of-concept test for a generic hash based and typed ID struct. - check the various ctors - check default assignment works properly - check assumptions about memory layout - check equality comparison - extract LUID and then cast LUID back into ID - use the embedded hash ID (LUID) as hashtable key</dd> <dt> \_setscope lib::test::HashStandardToBoostBridge_test Class \_internalref classlib_1_1test_1_1HashStandardToBoostBridge__test "HashStandardToBoostBridge_test" </dt><dd> \anchor _test000331 document and verify an automatic bridge to integrate boost-style hash functions with the new \c std::hash template. Currently (as of 2014) this requires us to "hijack" the standard library definition to defeat a static assertion, which otherwise would defeat any attempts based on SFINAE</dd> <dt> \_setscope lumiera::test::HelloBug_test Class \_internalref classlumiera_1_1test_1_1HelloBug__test "HelloBug_test" </dt><dd> \anchor _test000619 cover known regressions </dd> <dt> \_setscope lumiera::test::HelloWorld_test Class \_internalref classlumiera_1_1test_1_1HelloWorld__test "HelloWorld_test" </dt><dd> \anchor _test000334 demo of using the test framework </dd> <dt> \_setscope lib::test::HeteroData_test Class \_internalref classlib_1_1test_1_1HeteroData__test "HeteroData_test" </dt><dd> \anchor _test000346 maintain a sequence of data tuples in local storage, providing pre-configured type-safe data access. - the initial block is just a tuple of data in local storage - but further extension segments can be created <em>elsewhere</em> and attached to an existing chain - a compile-time »overlay« of constructor- and accessor-functors is provided as <em>guard rails</em> to prevent out-of bounds access. </dd> <dt> \_setscope lib::test::HeteroData_test Member \_internalref classlib_1_1test_1_1HeteroData__test#a0e81c85bb2bf4f6d4b7f4ad38600f8f0 "HeteroData_test::verify_Accessors" ()</dt><dd> \anchor _test000354 demonstrate elaborate storage layout with several chain frames - follow-up frames shall be built using constructor types - these can be defined prior to any data allocation - individual data elements can be accessed through type-safe accessor functors </dd> <dt> \_setscope lib::test::HeteroData_test Member \_internalref classlib_1_1test_1_1HeteroData__test#a3540339ca4c0ae80e4835f723513e343 "HeteroData_test::verify_ChainBlock" ()</dt><dd> \anchor _test000353 construct a follow-up data tuple block and hook it into the chain </dd> <dt> \_setscope lib::test::HeteroData_test Member \_internalref classlib_1_1test_1_1HeteroData__test#a5eb9b1130b4f960844320671007cfa9b "HeteroData_test::verify_FrontBlock" ()</dt><dd> \anchor _test000352 build a free standing data tuple block to start a chain </dd> <dt> \_setscope steam::asset::test::IdentityOfAssets_test Class \_internalref classsteam_1_1asset_1_1test_1_1IdentityOfAssets__test "IdentityOfAssets_test" </dt><dd> \anchor _test000061 creating several Assets and checking object identity, detection of duplicates and version handling. </dd> <dt> \_setscope steam::asset::test::IdentityOfAssets_test Member \_internalref classsteam_1_1asset_1_1test_1_1IdentityOfAssets__test#a865fb78aa6a78b023d85db63471b8159 "IdentityOfAssets_test::createDuplicate" ()</dt><dd> \anchor _test000064 produce an ID clash. documents the current behaviour of the code as of 9/07 <p></dd> <dt> \_setscope lib::test::IncidenceCount_test Class \_internalref classlib_1_1test_1_1IncidenceCount__test "IncidenceCount_test" </dt><dd> \anchor _test000341 verify recording and evaluation of concurrent invocations of a piece of code instrumented for investigation. </dd> <dt> \_setscope lib::test::IncidenceCount_test Member \_internalref classlib_1_1test_1_1IncidenceCount__test#a65d2c4b883b981525b3a1a7e68cc0956 "IncidenceCount_test::demonstrate_usage" ()</dt><dd> \anchor _test000343 watch time spent in code bracketed by measurement calls. </dd> <dt> \_setscope lib::test::IncidenceCount_test Member \_internalref classlib_1_1test_1_1IncidenceCount__test#a68b798e64a8f51a587f562926c5c3a3f "IncidenceCount_test::perform_multithreadStressTest" ()</dt><dd> \anchor _test000349 verify thread-safe operation under pressure. </dd> <dt> \_setscope lib::test::IncidenceCount_test Member \_internalref classlib_1_1test_1_1IncidenceCount__test#a23b511cd9b3f643f447bb33ce67335d9 "IncidenceCount_test::verify_concurrencyStatistic" ()</dt><dd> \anchor _test000347 verify observation of concurrency degree. </dd> <dt> \_setscope lib::test::IncidenceCount_test Member \_internalref classlib_1_1test_1_1IncidenceCount__test#ad6bc3708d707612dbbd1d339ff27a0f2 "IncidenceCount_test::verify_incidentCount" ()</dt><dd> \anchor _test000345 verify proper counting of possibly overlapping incidences. </dd> <dt> \_setscope lib::test::IndexIter_test Class \_internalref classlib_1_1test_1_1IndexIter__test "IndexIter_test" </dt><dd> \anchor _test000342 verify adapter to iterate and navigate over array-like content, that can be accessed through subscript operator and <tt>size()</tt> function.</dd> <dt> \_setscope lib::test::IndexIter_test Member \_internalref classlib_1_1test_1_1IndexIter__test#ac6a6c01573c9d7e34cf89f7c2e6a9a33 "IndexIter_test::iterTypeVariations" ()</dt><dd> \anchor _test000350 verify possible variations of this iterator template, using a const container or maintaining shared ownership. </dd> <dt> \_setscope lib::test::IndexIter_test Member \_internalref classlib_1_1test_1_1IndexIter__test#acd8789790d65c0d5740c04e25a0acfa0 "IndexIter_test::simpleIteration" ()</dt><dd> \anchor _test000344 just iterate in various ways. </dd> <dt> \_setscope lib::test::IndexIter_test Member \_internalref classlib_1_1test_1_1IndexIter__test#abd854b2ce5502cc19524c38b0578ed56 "IndexIter_test::verify_randomAccess" ()</dt><dd> \anchor _test000348 verify the ability of IndexIter to access and manipulate the current index position, which can be done any time, while in the middle of iteration, and even after iteration end. That means, even an exhausted iterator can be „reanimated“. This manipulation is not allowed on a default constructed IndexIter, though. </dd> <dt> \_setscope lib::test::IndexIter_test Member \_internalref classlib_1_1test_1_1IndexIter__test#ac45fb25c9c148fc7503042895191c2cb "IndexIter_test::verifyComparisons" (IT const &ii)</dt><dd> \anchor _test000351 verify equality handling and NIL detection for the given iterator/wrapper handed in. </dd> <dt> \_setscope util::test::IosSavepoint_test Class \_internalref classutil_1_1test_1_1IosSavepoint__test "IosSavepoint_test" </dt><dd> \anchor _test000336 verifies capturing and restoring of std::ostream formatting state. </dd> <dt> \_setscope util::test::IosSavepoint_test Member \_internalref classutil_1_1test_1_1IosSavepoint__test#ab90ec361a6b28e7d8b59122349c3afeb "IosSavepoint_test::nested" ()</dt><dd> \anchor _test000339 verify usage in nested scopes </dd> <dt> \_setscope util::test::IosSavepoint_test Member \_internalref classutil_1_1test_1_1IosSavepoint__test#a2ec437fbe1c114a3349a824466dbe45b "IosSavepoint_test::restoreAfterException" ()</dt><dd> \anchor _test000340 verify clean-up happens even in case of an exception </dd> <dt> \_setscope util::test::IosSavepoint_test Member \_internalref classutil_1_1test_1_1IosSavepoint__test#a94e902c375bfa5a395b9e5a1e1ef3a1d "IosSavepoint_test::setFill" ()</dt><dd> \anchor _test000338 verify that a custom fill character is cleared </dd> <dt> \_setscope util::test::IosSavepoint_test Member \_internalref classutil_1_1test_1_1IosSavepoint__test#aa30fbd296a0895aa47b4bc6710d3cba7 "IosSavepoint_test::switchToHex" ()</dt><dd> \anchor _test000337 verify that hexadecimal output is cleared <br> </dd> <dt> \_setscope lib::wrapper::test::ItemWrapper_test Class \_internalref classlib_1_1wrapper_1_1test_1_1ItemWrapper__test "ItemWrapper_test" </dt><dd> \anchor _test000356 use the ItemWrapper to define inline-storage holding values, pointers and references. Verify correct behaviour in each case, including (self)assignment, empty check, invalid dereferentiation.</dd> <dt> \_setscope lib::wrapper::test::ItemWrapper_test Member \_internalref classlib_1_1wrapper_1_1test_1_1ItemWrapper__test#a8691b6a15c24d856fd2d42a9d87d0add "ItemWrapper_test::verifyFunctionRefResult" ()</dt><dd> \anchor _test000361 verify an extension built on top of the ItemWrapper: a function which remembers the last result. Here we use a test function, which picks a member of an vector and returns a \em reference to it. Thus the cached "result" can be used to access and change the values within the original vector. In a real world usage scenario, such a function could be an (expensive) data structure access. </dd> <dt> \_setscope lib::wrapper::test::ItemWrapper_test Member \_internalref classlib_1_1wrapper_1_1test_1_1ItemWrapper__test#aa949960559d154e4a27233e1dbe30e5e "ItemWrapper_test::verifyFunctionResult" ()</dt><dd> \anchor _test000360 verify an extension built on top of the ItemWrapper: a function which remembers the last result. As a simple test, we bind a static helper function to produce a random value and remember the result returned last. </dd> <dt> \_setscope lib::wrapper::test::ItemWrapper_test Member \_internalref classlib_1_1wrapper_1_1test_1_1ItemWrapper__test#a5459ac33574ff19a815e66e75045547d "ItemWrapper_test::verifySaneInstanceHandling" ()</dt><dd> \anchor _test000357 verify that ctor and dtor calls are balanced, even when assigning and self-assigning. </dd> <dt> \_setscope lib::wrapper::test::ItemWrapper_test Member \_internalref classlib_1_1wrapper_1_1test_1_1ItemWrapper__test#a0d62224d455aef10b6ca319a92a26a02 "ItemWrapper_test::verifySaneMoveHandling" ()</dt><dd> \anchor _test000358 proper handling of move and rvalue references </dd> <dt> \_setscope lib::wrapper::test::ItemWrapper_test Member \_internalref classlib_1_1wrapper_1_1test_1_1ItemWrapper__test#a6d446f047558531ca038f2d9b0e8d429 "ItemWrapper_test::verifyWrappedRef" ()</dt><dd> \anchor _test000359 verify especially that we can wrap and handle a reference "value" in a pointer-like manner </dd> <dt> \_setscope lib::meta::test::IterableClassification_test Class \_internalref classlib_1_1meta_1_1test_1_1IterableClassification__test "IterableClassification_test" </dt><dd> \anchor _test000434 verify the (static) classification/detection of iterables. Currently (1/10) we're able to detect the following - a STL like container with \c begin() and \c end() - a Lumiera Forward Iterator This test just retrieves the results of a compile time execution of the type detection; thus we just define types and then access the generated meta function value. </dd> <dt> \_setscope lib::test::IterAdapter_test Class \_internalref classlib_1_1test_1_1IterAdapter__test "IterAdapter_test" </dt><dd> \anchor _test000365 set up example implementations based on the iterator-adapter templates and verify the behaviour in accordance to the concept "lumiera forward iterator"</dd> <dt> \_setscope lib::test::IterAdapter_test Member \_internalref classlib_1_1test_1_1IterAdapter__test#a8895b7736c266a9ffb74da5d797de2fe "IterAdapter_test::enumerate" ()</dt><dd> \anchor _test000382 enumerate all number within a range </dd> <dt> \_setscope lib::test::IterAdapter_test Member \_internalref classlib_1_1test_1_1IterAdapter__test#a5682064de175d1fcd4eae77a29c195c0 "IterAdapter_test::exposeDataAddresses" ()</dt><dd> \anchor _test000387 build an iterator to expose the address of underlying data elements </dd> <dt> \_setscope lib::test::IterAdapter_test Member \_internalref classlib_1_1test_1_1IterAdapter__test#a4cde9780a6c276efbea727893d376e43 "IterAdapter_test::iterTypeVariations" (TestContainer &elms)</dt><dd> \anchor _test000385 verify the const and dereferencing variants, which can be created based on IterAdapter </dd> <dt> \_setscope lib::test::IterAdapter_test Member \_internalref classlib_1_1test_1_1IterAdapter__test#a1a91f160f3ce54a2dc7a86947ea09a1f "IterAdapter_test::simpleUsage" (CON &elms)</dt><dd> \anchor _test000384 use the IterAdapter as if it was a STL iterator </dd> <dt> \_setscope lib::test::IterAdapter_test Member \_internalref classlib_1_1test_1_1IterAdapter__test#ac9dcab830431d3dcba2e21db70eba226 "IterAdapter_test::verifyComparisons" (TestContainer &elms)</dt><dd> \anchor _test000388 iterator comparison, predicates and operators </dd> <dt> \_setscope lib::test::IterAdapter_test Member \_internalref classlib_1_1test_1_1IterAdapter__test#abaf092c8a6b66090bb7da33f7186a3fe "IterAdapter_test::wrapIterRange" ()</dt><dd> \anchor _test000383 usage scenario, where we allow the client to access a range of elements given by STL iterators, without any specific iteration behaviour. </dd> <dt> \_setscope lib::test::IterAdapterSTL_test Class \_internalref classlib_1_1test_1_1IterAdapterSTL__test "IterAdapterSTL_test" </dt><dd> \anchor _test000355 verify some of the adapters to expose typical container usage patterns as Lumiera Forward Iterators. - distinct values from a sequence - keys and values of a map / multimap - distinct keys from a multimap - multimap values associated with a given key - snapshot of an iterator, to be retrieved as iterator</dd> <dt> \_setscope lib::iter::test::IterChainSearch_test Class \_internalref classlib_1_1iter_1_1test_1_1IterChainSearch__test "IterChainSearch_test" </dt><dd> \anchor _test000362 verify a setup for consecutive searches with backtracking. - demonstrate simple consecutive matches and iterator behaviour - clear the filter underway and thus return to simple iteration - set up two conditions, the second one capturing state at the point where the first one matches - wrap a lib::IterCursor, which allows to toggle the search direction underway; this creates a situation where the first options picked do not lead to a successful solution, so the search has to track back, try further options and in each case re-apply all the following consecutive search conditions.</dd> <dt> \_setscope lib::iter::test::IterChainSearch_test Member \_internalref classlib_1_1iter_1_1test_1_1IterChainSearch__test#a5ca4d980d08741d6ec15a4755b7d59c7 "IterChainSearch_test::backtracking" ()</dt><dd> \anchor _test000370 verify a complex search with backtracking. This becomes relevant when a given search condition can be "too greedy" for the complete chain to succeed. Most notably this is the case when the search is fundamentally reconfigured in some steps, e.g. by switching the search orientation. To demonstrate this, we use a "gear switching" iterator, which allows us to reverse the direction and to search backwards from the current position. We configure the second condition in the chain such that it can not succeed when starting from the first match on the first condition </dd> <dt> \_setscope lib::iter::test::IterChainSearch_test Member \_internalref classlib_1_1iter_1_1test_1_1IterChainSearch__test#a5590c99f5ae503faf7bff53501d34a93 "IterChainSearch_test::chainedIteration" ()</dt><dd> \anchor _test000366 verify consecutive application of several functors on the underlying filter. In the general case, each step in the chain is a function working on a copy of the current filter state. Since each such step configures its own copy of the complete pipeline, it may reconfigure this filter pipeline in arbitrary ways. After exhausting the last layer, the evaluation returns to the previous layer, but immediately re-applies the configuration step on the then next element. </dd> <dt> \_setscope lib::iter::test::IterChainSearch_test Member \_internalref classlib_1_1iter_1_1test_1_1IterChainSearch__test#a33ec36b3ae8267f558d09571673283fd "IterChainSearch_test::simpleSearch" ()</dt><dd> \anchor _test000364 simple basic use case. </dd> <dt> \_setscope lib::test::IterCoreAdapter_test Class \_internalref classlib_1_1test_1_1IterCoreAdapter__test "IterCoreAdapter_test" </dt><dd> \anchor _test000363 cover the concept of a »state core«, which is used in Lumiera for various aspects of data generation and iteration. </dd> <dt> \_setscope lib::test::IterCoreAdapter_test Member \_internalref classlib_1_1test_1_1IterCoreAdapter__test#a6521e010dc850efd35934db8b852539e "IterCoreAdapter_test::checked_and_protected" ()</dt><dd> \anchor _test000373 additional wrappers to add safety checks or to encapsulate the state core altogether </dd> <dt> \_setscope lib::test::IterCoreAdapter_test Member \_internalref classlib_1_1test_1_1IterCoreAdapter__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "IterCoreAdapter_test::simpleUsage" ()</dt><dd> \anchor _test000368 build a »Lumiera Forward Iterator« to transition a State-Core towards it final state. </dd> <dt> \_setscope lib::test::IterCoreAdapter_test Member \_internalref classlib_1_1test_1_1IterCoreAdapter__test#a64af389261faa63ee708e2995b8a28cc "IterCoreAdapter_test::stateManipulation" ()</dt><dd> \anchor _test000371 state of a decorated un-checked core can be manipulated </dd> <dt> \_setscope lib::test::IterCoreAdapter_test Member \_internalref classlib_1_1test_1_1IterCoreAdapter__test#a7247e4c6c6113cf7e577ae9fa7db1768 "IterCoreAdapter_test::value_and_reference_yield" ()</dt><dd> \anchor _test000375 adapters can (transparently) handle a core which yields values - demonstrate how cores can be augmented by decoration... - the decorated core here yields by-value, not by-ref. - Both CheckedCore and IterableDecorator can cope with that - the result is then also delivered by-value from the iterator. </dd> <dt> \_setscope lib::test::IterCoreAdapter_test Member \_internalref classlib_1_1test_1_1IterCoreAdapter__test#ac49760e607062f7f2b0e181710aba894 "IterCoreAdapter_test::verify_TypeReconciliation" ()</dt><dd> \anchor _test000377 construction of a common result type. - based on <tt>std::common_type</tt> - so there must be some common ground - if any of the types is by-value, the result is - if any of the types is const, the result is const </dd> <dt> \_setscope lib::test::IterCursor_test Class \_internalref classlib_1_1test_1_1IterCursor__test "IterCursor_test" </dt><dd> \anchor _test000369 demonstrate and cover the properties of IterCursor. This wrapper allows to change between iterating forward and backwards.</dd> <dt> \_setscope lib::test::IterCursor_test Member \_internalref classlib_1_1test_1_1IterCursor__test#ac6a6c01573c9d7e34cf89f7c2e6a9a33 "IterCursor_test::iterTypeVariations" ()</dt><dd> \anchor _test000379 verify variant created from a const_iterator, based on the const-ness of the underlying STL iterator </dd> <dt> \_setscope lib::test::IterCursor_test Member \_internalref classlib_1_1test_1_1IterCursor__test#acd8789790d65c0d5740c04e25a0acfa0 "IterCursor_test::simpleIteration" ()</dt><dd> \anchor _test000376 just iterate in various ways. </dd> <dt> \_setscope lib::test::IterCursor_test Member \_internalref classlib_1_1test_1_1IterCursor__test#a1986c5afa4a9350654c61d1e08b254db "IterCursor_test::switchDirection" ()</dt><dd> \anchor _test000378 verify the ability of IterCursor to switch the direction of the iteration. This "gear switch" can be done any time, while in the middle of iteration, and even after iteration end. That means, even an exhausted iterator can be "turned back". This does not work on a default constructed IterCursor, though. </dd> <dt> \_setscope lib::test::IterCursor_test Member \_internalref classlib_1_1test_1_1IterCursor__test#ac45fb25c9c148fc7503042895191c2cb "IterCursor_test::verifyComparisons" (IT const &ii)</dt><dd> \anchor _test000380 verify equality handling and NIL detection for the given iterator/wrapper handed in. </dd> <dt> \_setscope lib::test::IterExplorer_test Class \_internalref classlib_1_1test_1_1IterExplorer__test "IterExplorer_test" </dt><dd> \anchor _test000452 use a simple source iterator yielding numbers to build various functional evaluation pipelines, based on the \ref IterExplorer template. - the adapter to wrap the source, which can either \ref verify_wrappedState() "be a state core", or can \ref verify_wrappedIterator() "be a Lumiera Forward Iterator" - the defining use case for IterExplorer is to build a \ref verify_expandOperation() "pipeline for depth-first exploration" of a (functional) tree structure. This "tree" is created by invoking a "expand functor", which can be defined in various ways. - the usual building blocks for functional evaluation pipelines, that is \ref verify_FilterIterator() "filtering" and \ref verify_transformOperation() "transforming" of the elements yielded by the wrapped source iterator. - building complex pipelines by combining the aforementioned building blocks - using an opaque source, hidden behind the IterSource interface, and an extension (sub interface) to allow for "tree exploration" without any knowledge regarding the concrete implementation of the data source.</dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a1193e3d2c5420cb5d54c00741f2c691f "IterExplorer_test::demonstrate_LayeredEvaluation" ()</dt><dd> \anchor _test000525 Demonstration how to build complex algorithms by layered tree expanding iteration </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#ad9a038d5ab18805d95a30585821f634d "IterExplorer_test::verify_aggregatingGroupItration" ()</dt><dd> \anchor _test000499 another form of grouping, where groups are formed by a derived property thereby passing each element in the group to an aggregator function, working on an accumulator per group. Downstream, the resulting, accumulated value is exposed for each group, while consuming all source values belonging to this group. - in the simple form, all members of a group are "added" together - the elaborate form allows to provide a custom aggregation function, which takes the »accumulator« as first argument by reference; the type of this argument implicitly defines what is instantiated for each group and yielded as result. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#ab5e5fad61a157ad5ea1d8f03376b421d "IterExplorer_test::verify_asIterSource" ()</dt><dd> \anchor _test000517 package the resulting Iterator as automatically managed, polymorphic opaque entity implementing the IterSource interface. The builder operations on IterExplorer each generate a distinct, implementation defined type, which is meant to be captured by <tt>auto</tt>. However, the terminal builder function <tt>asIterSource()</tt> moves the whole compound iterator object, as generated by preceding builder steps, into a heap allocation and exposes a simplified front-end, which is only typed to the result value type. Obviously, the price to pay comes in terms of virtual function calls for iteration, delegating to the pipeline backend. - thus a variable typed to that front-end, <tt>IterSource\<VAL\></tt> is polymorphic and can be reassigned at runtime with an entirely different pipeline. - but this structure also has the downside, that the implementation no longer resides directly within the iterator: several front-end copies share the same back-end. Note however that the behaviour of iterators copied this way is <em>implementation defined</em> anyway. There is never a guarantee that a clone copy evolves with state independent from its ancestor; it just happens to work this way in many simple cases. You should never use more than one copy of a given iterator at any time, and you should discard it, when done with iteration. - actually, the returned front-end offers an extended API over plain vanilla <tt>IterSource\<T\>\::iterator</tt>, to expose the <tt>expandChildren()</tt> operation. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a4cf15ef90b46ed7c5f2f66b853e12534 "IterExplorer_test::verify_combinedExpandTransform" ()</dt><dd> \anchor _test000501 combine the recursion into children with a tail mapping operation. Wile basically this is just the layering structure of IterExplorer put into action, you should note one specific twist: the iter_explorer::Expander::expandChildren() call is meant to be issued from `&lsquo;downstream&rsquo;', from the consumer side. Yet the consumer at that point might well see the items as processed by a transforming step layered on top. So what the consumer sees and thinks will be expanded need not actually be what will be processed by the <em>expand functor</em>. This may look like a theoretical or cosmetic issue &ndash; yet in fact it is this tiny detail which is crucial to make abstraction of the underlying data source actually work in conjunction with elaborate searching and matching algorithms. Even more so, when other operations like filtering are intermingled; in that case it might even happen that the downstream consumer does not even see the items resulting from child expansion, because they are evaluated and then filtered away by transformers and filters placed in between. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a7e8fdd7b154b6cef67a51936860b30b4 "IterExplorer_test::verify_customProcessingLayer" ()</dt><dd> \anchor _test000503 extension point to inject a client-defined custom processing layer This special builder function allows to install a template, which needs to wrap a source iterator and expose a <em>state core like</em> interface. We demonstrate this extension mechanism here by defining a processing layer which skips each other element. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a5d89a5dc4fd32ad90d61d92cf1d47214 "IterExplorer_test::verify_dedup" ()</dt><dd> \anchor _test000513 verify to deduplicate the iterator's results into a std::set </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a2adf744fc63d7d90e88d6639a647203e "IterExplorer_test::verify_depthFirstExploration" ()</dt><dd> \anchor _test000523 use a preconfigured exploration scheme to expand depth-first until exhaustion. This is a simple extension where all elements are expanded automatically. In fact, the <tt>expandChildren()</tt> operation implies already an iteration step, namely to dispose of the parent element before injecting the expanded child elements. Based on that observation, when we just replace the regular iteration step by a call to <tt>expandChildren()</tt>, we'll encounter first the parent element and then delve depth-first into exploring the children. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a369ee591cc2f2a82b0777acdac9ab610 "IterExplorer_test::verify_effuse" ()</dt><dd> \anchor _test000511 verify <em>terminal operation</em> to append all results into a container. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a575f20d51d35f7c2f0a90ca1628246e6 "IterExplorer_test::verify_elementGroupingOperation" ()</dt><dd> \anchor _test000497 package elements from the source pipeline into fixed-sized groups. These groups are implemented as std::array and initialised with the values yielded consecutively from the underlying source pipeline. The main iterator then yields a reference to this data (which can be unpacked conveniently by a structured binding, or processed as a STL container. Moreover, there is a secondary interface, allowing to iterate over the values stored in this group; this is also exposed for the rest, which did not suffice to fill a full group. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#ae3edbde2b866809b50958c2ccf88800b "IterExplorer_test::verify_expand_rootCurrent" ()</dt><dd> \anchor _test000487 special feature of the Expander to lock into current child sequence. This feature was added to support a specific use-case in the IterChainSearch component. After expanding several levels deep into a tree, it allows to turn the <em>current child sequence</em> into a new root sequence and discard the whole rest of the tree, including the original root sequence. It is implemented by moving the current child sequence down into the root sequence. We demonstrate this behaviour with the simple standard setup from #verify_expandOperation() </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#abd68de9e572e22bd9e4158eb26956cd0 "IterExplorer_test::verify_expandOperation" ()</dt><dd> \anchor _test000484 use a preconfigured "expand" functor to recurse into children. The <tt>expand()</tt> builder function predefines a way how to <em>expand</em> the current head element of the iteration. However, expansion does not happen automatically, rather, it needs to be invoked by the client, similar to increment of the iterator. When expanding, the current head element is consumed and fed into the expand functor; the result of this functor invocation is injected instead into the result sequence, and consequently this result needs to be again an iterable with compatible value type. Conceptually, the evaluation <em>forks into the children of the expanded element</em>, before continuing with the successor of the expansion point. Obviously, expansion can be applied again on the result of the expansion, possibly leading to a tree of side evaluations.</dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#ac70b7c9894b1364cc021fd31c9069135 "IterExplorer_test::verify_FilterChanges" ()</dt><dd> \anchor _test000508 a special filter layer which can be re-configured on the fly </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a5257cd2ad7fc13487b68a27b78a528c3 "IterExplorer_test::verify_FilterIterator" ()</dt><dd> \anchor _test000506 add a filtering predicate into the pipeline. As in all the previously demonstrated cases, also the <em>filtering</em> is added as decorator, wrapping the source and all previously attached decoration layers. And in a similar way, various kinds of functors can be bound, and will be adapted automatically to work as a predicate to approve the elements to yield. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a82e7d94700995e1be19dd0b8133576f6 "IterExplorer_test::verify_IterSource" ()</dt><dd> \anchor _test000520 ability to wrap and handle IterSource based iteration. Contrary to the preceding test case, here the point is to <em>base the whole pipeline</em> on a data source accessible through the IterSource (VTable based) interface. The notable point with this technique is the ability to use some <em>extended sub interface of IterSource</em> and to rely on this interface to implement some functor bound into the IterExplorer pipeline. Especially this allows to delegate the "child expansion" through such an interface and just return a compatible IterSource as result. This way, the opaque implementation gains total freedom regarding the concrete implementation of the "child series" iterator. In fact, it may even use a different implementation on each level or even on each individual call; only the result type and thus the base interface need to match. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a6cb4111e81c81650765eac596a147c75 "IterExplorer_test::verify_reduceVal" ()</dt><dd> \anchor _test000509 verify <em>terminal operation</em> to sum or reduce all values from the pipeline. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#aed34e91f9f3175c072bb882585e0cc99 "IterExplorer_test::verify_scheduledExpansion" ()</dt><dd> \anchor _test000504 child expansion can be scheduled to happen on next iteration. As such, _"child expansion"_ happens right away, thereby consuming a node and replacing it with its child sequence. Sometimes, when building search and matching algorithms, we rather just want to <em>plan</em> a child expansion to happen on next increment. Such is especially relevant when searching for a locally or global maximal solution, which is rather simple to implement with an additional filtering layer &ndash; and this approach requires us to deliver all partial solutions for the filter layer to act on. Obviously this functionality leads to additional state and thus is provided as optional layer in the IterExplorer builder. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a402f289d0bea1a87ed1d418aa6830d04 "IterExplorer_test::verify_transformOperation" ()</dt><dd> \anchor _test000492 pipe each result through a transformation function. The <em>transforming iterator</em> is added as a decorator, wrapping the original iterator, TreeEplorer or state core. As you'd expect, the given functor is required to accept compatible argument types, and a generic lambda is instantiated to take a reference to the embedded iterator's value type. Several transformation steps can be chained, and the resulting entity is again a Lumiera Forward Iterator with suitable value type. The transformation function is invoked only once per step and the result produced by this invocation is placed into a holder buffer embedded within the iterator. </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#aeed828246245bbcf03337c6d0ff17cfc "IterExplorer_test::verify_untilStopTrigger" ()</dt><dd> \anchor _test000505 control end of iteration by a stop condition predicate. When decorating the pipeline with this adapter, iteration end depends not only on the source iterator, but also on the end condition; once the condition flips, the overall pipeline iterator is exhausted and can never be re-activated again (unless some special trickery is done by conspiring with the data source) </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a265e3c48923910c957a66a1d284d22c5 "IterExplorer_test::verify_wrappedIterator" ()</dt><dd> \anchor _test000481 IterExplorer is able to wrap any <em>Lumiera Forward Iterator</em> </dd> <dt> \_setscope lib::test::IterExplorer_test Member \_internalref classlib_1_1test_1_1IterExplorer__test#a0a2eb22cbcd535e6a4d26cd4139a7570 "IterExplorer_test::verify_wrappedState" ()</dt><dd> \anchor _test000480 without using any extra functionality, IterExplorer just wraps an iterable state. </dd> <dt> \_setscope lib::test::IterQueue_test Class \_internalref classlib_1_1test_1_1IterQueue__test "IterQueue_test" </dt><dd> \anchor _test000381 cover an easy to use queue, built as convenience wrapper on top of \c std::deque and allowing element retrieval by iteration. - iterable according to the Lumiera Forward Iterator concept - can enqueue and dequeue elements repeatedly - can be loaded through an generic builder API.</dd> <dt> \_setscope lib::test::IterSource_test Class \_internalref classlib_1_1test_1_1IterSource__test "IterSource_test" </dt><dd> \anchor _test000389 create some (opaque) data sources, and then pull the data out by iteration. Demonstrates simple usage of the IterSource interface</dd> <dt> \_setscope lib::test::IterSource_test Member \_internalref classlib_1_1test_1_1IterSource__test#adf0da918af0749e487247c2d2748e375 "IterSource_test::verify_singleValIter" ()</dt><dd> \anchor _test000395 an IterSouce which returns just a single value once </dd> <dt> \_setscope lib::test::IterSource_test Member \_internalref classlib_1_1test_1_1IterSource__test#a8bee621054ad22462d87c5ec9ad26202 "IterSource_test::verify_transformIter" ()</dt><dd> \anchor _test000393 verify transforming an embedded iterator This test not only wraps a source iterator and packages it behind the abstracting interface IterSource, but in addition also applies a function to each element yielded by the source iterator. As demo transformation we use the values from our custom container (\ref WrappedList) to build a time value in quarter seconds</dd> <dt> \_setscope lib::test::IterStack_test Class \_internalref classlib_1_1test_1_1IterStack__test "IterStack_test" </dt><dd> \anchor _test000386 cover behaviour of a convenience class built by using a \c std::deque as "state core" of an Lumiera IterStateWrapper. - iterable according to the Lumiera Forward Iterator concept - can push and pop values repeatedly - iterating and push / pop can be mixed - empty state detected consistently</dd> <dt> \_setscope lib::test::IterTools_test Class \_internalref classlib_1_1test_1_1IterTools__test "IterTools_test" </dt><dd> \anchor _test000397 build combined and filtering iterators with the help of lib::IterTool. Check correct behaviour of the resulting iterators and verify they fulfil the Lumiera Forward Iterator concept</dd> <dt> \_setscope lib::test::IterTools_test Member \_internalref classlib_1_1test_1_1IterTools__test#a1800be26d4bb18337801cf50fd9f0c15 "IterTools_test::buildWrappedSingleElement" ()</dt><dd> \anchor _test000400 wrap an arbitrary single element as pseudo-iterator </dd> <dt> \_setscope lib::test::IterTools_test Member \_internalref classlib_1_1test_1_1IterTools__test#a70d83faa26253ff9d7c48c93910089e5 "IterTools_test::verify_filterExtension" ()</dt><dd> \anchor _test000398 verify the ability to extend a filter condition while in the middle of an ongoing iteration. Typically this means sharpening the filter condition and thus making the filter more restrictive, filtering away more elements of the source stream. But through the ability to add disjunctive and negated clauses, it is also possible to weaken the filter condition </dd> <dt> \_setscope lib::test::IterTools_test Member \_internalref classlib_1_1test_1_1IterTools__test#ac185e89d65419f76e7fb4b7f7b3fe04c "IterTools_test::verify_filterRepetitions" ()</dt><dd> \anchor _test000399 verify the helper to filter duplicate elements emitted by an source iterator. This test creates a sequence of numbers with random repetitions. </dd> <dt> \_setscope lib::test::IterTools_test Member \_internalref classlib_1_1test_1_1IterTools__test#ac45fb25c9c148fc7503042895191c2cb "IterTools_test::verifyComparisons" (IT const &ii)</dt><dd> \anchor _test000401 verify equality handling and NIL detection for the given iterator/wrapper handed in </dd> <dt> \_setscope lib::test::IterZip_test Class \_internalref classlib_1_1test_1_1IterZip__test "IterZip_test" </dt><dd> \anchor _test000408 demonstrate construction and verify behaviour of a combined-iterator builder. - construction from arbitrary arguments by tuple-mapping a builder function - defining the operation on the product type by lifting individual operations - use the library building blocks to construct a zip-iter-builder - iterate a mix of source iterators and containers - apply additional processing logic by pipelining </dd> <dt> \_setscope lib::test::IterZip_test Member \_internalref classlib_1_1test_1_1IterZip__test#a011014411dae152578b8d1b860bc10ac "IterZip_test::demo_construction" ()</dt><dd> \anchor _test000422 demonstrate how a tuple-zipping iterator can be constructed </dd> <dt> \_setscope lib::test::IterZip_test Member \_internalref classlib_1_1test_1_1IterZip__test#a0fc438bbfeead55e28141d7fc8ab20ee "IterZip_test::demo_mapToTuple" ()</dt><dd> \anchor _test000420 demonstrate to apply a function to tuple contents </dd> <dt> \_setscope lib::test::IterZip_test Member \_internalref classlib_1_1test_1_1IterZip__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "IterZip_test::simpleUsage" ()</dt><dd> \anchor _test000417 demonstrate combined iteration </dd> <dt> \_setscope lib::test::IterZip_test Member \_internalref classlib_1_1test_1_1IterZip__test#a9d11cca307913b06f85d53bfd9f5b080 "IterZip_test::test_Fixture" ()</dt><dd> \anchor _test000419 demonstrate how the test Fixture is used </dd> <dt> \_setscope lib::test::IterZip_test Member \_internalref classlib_1_1test_1_1IterZip__test#adcaa15cb7a728aa97a180d7059337698 "IterZip_test::verify_exploration" ()</dt><dd> \anchor _test000428 verify the interplay of <em>child expansion</em> and tuple-zipping. </dd> <dt> \_setscope lib::test::IterZip_test Member \_internalref classlib_1_1test_1_1IterZip__test#a44afb040adb719d5a357916385ed340f "IterZip_test::verify_iteration" ()</dt><dd> \anchor _test000423 create various product (tuple) iterators from mixed source iterators and verify basic iteration. </dd> <dt> \_setscope lib::test::IterZip_test Member \_internalref classlib_1_1test_1_1IterZip__test#a8de8439ba179cd7842ea75bb8c6c644b "IterZip_test::verify_pipelining" ()</dt><dd> \anchor _test000426 the result is actually an IterExplorer pipeline builder, which can be used to attach further processing downstream. </dd> <dt> \_setscope lib::test::IterZip_test Member \_internalref classlib_1_1test_1_1IterZip__test#ab6d12503230ff57fe1f1c9cac05b25d5 "IterZip_test::verify_references" ()</dt><dd> \anchor _test000425 verify pass-through of references </dd> <dt> \_setscope steam::engine::test::JobHash_test Class \_internalref classsteam_1_1engine_1_1test_1_1JobHash__test "JobHash_test" </dt><dd> \anchor _test000116 verify the basic properties of the job and job descriptor struct; especially verify that job data is passed properly back to the closure and that a identity can be constructed based on a hash of the job's data.</dd> <dt> \_setscope steam::engine::test::JobPlanning_test Class \_internalref classsteam_1_1engine_1_1test_1_1JobPlanning__test "JobPlanning_test" </dt><dd> \anchor _test000128 document and verify the data aggregation and the calculations necessary to prepare render jobs for scheduling. </dd> <dt> \_setscope steam::engine::test::JobPlanning_test Member \_internalref classsteam_1_1engine_1_1test_1_1JobPlanning__test#a8b1a0a5eb7d42c6db04de1063c5ba698 "JobPlanning_test::calculateDeadline" ()</dt><dd> \anchor _test000133 verify the timing calculations to establish the scheduling deadline of a simple render job </dd> <dt> \_setscope steam::engine::test::JobPlanning_test Member \_internalref classsteam_1_1engine_1_1test_1_1JobPlanning__test#ab3bc0b983e288f906c313596b52d0bdc "JobPlanning_test::setupDependentJob" ()</dt><dd> \anchor _test000135 verify the setup of a prerequisite job in relation to the master job depending on this prerequisite </dd> <dt> \_setscope steam::engine::test::JobPlanning_test Member \_internalref classsteam_1_1engine_1_1test_1_1JobPlanning__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "JobPlanning_test::simpleUsage" ()</dt><dd> \anchor _test000131 demonstrate a simple usage scenario </dd> <dt> \_setscope steam::engine::test::JobPlanningPipeline_test Class \_internalref classsteam_1_1engine_1_1test_1_1JobPlanningPipeline__test "JobPlanningPipeline_test" </dt><dd> \anchor _test000136 demonstrate interface, structure and setup of the job-planning pipeline. - using a frame step as base tick - invoke the dispatcher to retrieve the top-level JobTicket - expander function to explore prerequisite JobTickets - integration: generate a complete sequence of (dummy)Jobs - scaffolding and mocking used for this test </dd> <dt> \_setscope steam::engine::test::JobPlanningPipeline_test Member \_internalref classsteam_1_1engine_1_1test_1_1JobPlanningPipeline__test#a2936b4c799de30c102b3d277fbbeb371 "JobPlanningPipeline_test::accessTopLevelJobTicket" ()</dt><dd> \anchor _test000139 use the base tick to access the corresponding JobTicket through the Dispatcher interface (mocked here). </dd> <dt> \_setscope steam::engine::test::JobPlanningPipeline_test Member \_internalref classsteam_1_1engine_1_1test_1_1JobPlanningPipeline__test#ab9c43646416921b776df4d9732620510 "JobPlanningPipeline_test::buildBaseTickGenerator" ()</dt><dd> \anchor _test000138 use the Dispatcher interface (mocked) to generate a frame »beat« - demonstrate explicitly the mapping of a (frame) number sequence onto a sequence of time points with the help of time quantisation - use the Dispatcher API to produce the same frame time sequence </dd> <dt> \_setscope steam::engine::test::JobPlanningPipeline_test Member \_internalref classsteam_1_1engine_1_1test_1_1JobPlanningPipeline__test#a9ae4ba0e27e7fb8f38637eb47757eff7 "JobPlanningPipeline_test::demonstrateScaffolding" ()</dt><dd> \anchor _test000137 document and verify the mock setup used for this test </dd> <dt> \_setscope steam::engine::test::JobPlanningPipeline_test Member \_internalref classsteam_1_1engine_1_1test_1_1JobPlanningPipeline__test#aeafa7030301c0368c9674ddc6df90182 "JobPlanningPipeline_test::exploreJobTickets" ()</dt><dd> \anchor _test000140 build and verify the exploration function to discover job prerequisites - use a setup where the master ExitNode requires a prerequisite ExitNode to be pulled - mark the pipeline-IDs, so that both nodes can be distinguished in the resulting Jobs - the <tt>expandPrerequisites()</tt> builder function uses JobTicket::getPrerequisites() - and this »expander« function is unfolded recursively such that first the source appears in the iterator, and as next step the child prerequisites, possibly to be unfolded further recursively - by design of the iterator pipeline, it is always possible to access the <tt>PipeFrameTick</tt> - this corresponds to the top-level JobTicket, which will produce the final frame - putting all these information together, proper working can be visualised. </dd> <dt> \_setscope steam::engine::test::JobPlanningPipeline_test Member \_internalref classsteam_1_1engine_1_1test_1_1JobPlanningPipeline__test#a607410c3c2ad7067d8e70efbf7bc2733 "JobPlanningPipeline_test::integration" ()</dt><dd> \anchor _test000141 Job-planning pipeline integration test - use the MockDispatcher to define a fake model setup - define three levels of prerequisites - also define a second segment with different structure - build a complete Job-Planning pipeline - define a visualisation to expose generated job parameters - iterate the Job-Planning pipeline and apply the visualisation </dd> <dt> \_setscope lib::meta::test::LateBindInstance_test Class \_internalref classlib_1_1meta_1_1test_1_1LateBindInstance__test "LateBindInstance_test" </dt><dd> \anchor _test000436 verify a scheme to supply the actual instance for member function invocation. </dd> <dt> \_setscope lib::meta::test::LateBindInstance_test Member \_internalref classlib_1_1meta_1_1test_1_1LateBindInstance__test#a32cbccb29abce413084f77945404f9b1 "LateBindInstance_test::demonstrateUsage" ()</dt><dd> \anchor _test000440 demonstrate the usage of lib::meta::lateBindInstance(): - construct an argument tuple - mark the position of the <tt>this</tt>-ptr with a placeholder - rewrite the arguments later when the actual instance is known - member function can now be invoked, since the instance was injected. </dd> <dt> \_setscope lib::meta::test::LateBindInstance_test Member \_internalref classlib_1_1meta_1_1test_1_1LateBindInstance__test#a57851c8461ff2a608cd4fed6759bd20b "LateBindInstance_test::verify_cornerCases" ()</dt><dd> \anchor _test000443 replacement happens uniformly on all kinds of tuples </dd> <dt> \_setscope lib::meta::test::LateBindInstance_test Member \_internalref classlib_1_1meta_1_1test_1_1LateBindInstance__test#a94f646ac7dc096ea00ae6191943bbf27 "LateBindInstance_test::verify_forwarding" ()</dt><dd> \anchor _test000442 verify that the rewriting process does not incur unnecessary data copies </dd> <dt> \_setscope lib::test::LazyInit_test Class \_internalref classlib_1_1test_1_1LazyInit__test "LazyInit_test" </dt><dd> \anchor _test000402 Verify a mix-in to allow for lazy initialisation of complex infrastructure tied to a std::function; the intention is to have a »trap« hidden in the function itself to trigger on first use and perform the one-time initialisation, then finally lock the object at a fixed place. </dd> <dt> \_setscope lib::test::LazyInit_test Member \_internalref classlib_1_1test_1_1LazyInit__test#a3bb3c2e5863e3b032becfa98c64e097c "LazyInit_test::verify_complexUsageWithCopy" ()</dt><dd> \anchor _test000415 use an elaborately constructed example to cover more corner cases - the function to manage and initialise lazily is <em>a member</em> of the <em>derived class</em> - the initialisation routine <em>adapts</em> this function and links it with the current object location; thus, invoking this function on a copy would crash / corrupt memory. - however, as long as initialisation has not been triggered, LazyDemo instances can be copied; they may even be assigned to existing instances, overwriting their state. - a second given function will be chained behind the first one; this happens immediately if the first function was already invoked (and this initialised) - but when however both functions are attached immediately, prior to invocation, then an elaborate chain of initialisers is setup behind the scenes and played back in definition order once lazy initialisation is triggered - all the intermediary state is safe to copy and move and fork </dd> <dt> \_setscope lib::test::LazyInit_test Member \_internalref classlib_1_1test_1_1LazyInit__test#a5eeeab67500cb2b1cfac2ad2ba2218f8 "LazyInit_test::verify_inlineStorage" ()</dt><dd> \anchor _test000409 verify that std::function indeed stores a simple functor inline. </dd> <dt> \_setscope lib::test::LazyInit_test Member \_internalref classlib_1_1test_1_1LazyInit__test#a98467373ff8ba68742d7ee74fa84ef1b "LazyInit_test::verify_lazyInitialisation" ()</dt><dd> \anchor _test000412 demonstrate a basic usage scenario </dd> <dt> \_setscope lib::test::LazyInit_test Member \_internalref classlib_1_1test_1_1LazyInit__test#ad4a118483a70cf91a1361c693bd6ff4c "LazyInit_test::verify_TargetRelocation" ()</dt><dd> \anchor _test000410 verify navigating an object structure by applying known offsets consecutively from a starting point within an remote instance </dd> <dt> \_setscope lib::test::LazyInit_test Member \_internalref classlib_1_1test_1_1LazyInit__test#a2e96bb8c4f28b4ecd9360537e06bcf84 "LazyInit_test::verify_triggerMechanism" ()</dt><dd> \anchor _test000411 demonstrate the trigger mechanism in isolation </dd> <dt> \_setscope lib::test::LazyInit_test Member \_internalref classlib_1_1test_1_1LazyInit__test#abb99b4eae8b07ed9ff664106fd80177d "LazyInit_test::verify_trojanLambda" ()</dt><dd> \anchor _test000406 verify construction of the »trap« front-end eventually to trigger initialisation - this test does not involve any std::function, rather a heap-allocated copy of a λ </dd> <dt> \_setscope lumiera::test::LifeCycle_test Class \_internalref classlumiera_1_1test_1_1LifeCycle__test "LifeCycle_test" </dt><dd> \anchor _test000391 the global lifecycle hooks got registered, the ON_BASIC_INIT hook has been already called, while our custom callback can be triggered at our will </dd> <dt> \_setscope lib::test::LinkedElements_test Class \_internalref classlib_1_1test_1_1LinkedElements__test "LinkedElements_test" </dt><dd> \anchor _test000407 cover our custom single linked list template, in combination with Lumiera Forward Iterators and the usage of a custom allocator. </dd> <dt> \_setscope lib::test::LinkedElements_test Member \_internalref classlib_1_1test_1_1LinkedElements__test#a422238c09e07bc904c0a5496aa85a849 "LinkedElements_test::verify_customAllocator" ()</dt><dd> \anchor _test000424 use custom allocator to create list elements - a dedicated policy allows to refer to an existing AllocationCluster and to arrange for all object destructors to be called when this cluster goes out of scope - a C++ standard allocator can also be used; as an example, again an AllocationCluster is used, but this time with the default adapter, which places objects tight and skips invocation of destructors; however, since the LinkedElements destructor is called, it walks all elements and delegates through std::allocator_traits, which will invoke the (virtual) base class destructors. </dd> <dt> \_setscope lib::test::LinkedElements_test Member \_internalref classlib_1_1test_1_1LinkedElements__test#afadb56d92d54f6bf17be912ac697e296 "LinkedElements_test::verify_nonOwnership" ()</dt><dd> \anchor _test000418 add some node elements to the LinkedElements list but without taking ownership or performing any memory management. This usage pattern is helpful when the node elements are already managed elsewhere. </dd> <dt> \_setscope lib::test::LinkedElements_test Member \_internalref classlib_1_1test_1_1LinkedElements__test#abaf91090ab274f06bbb850ed2c9a0186 "LinkedElements_test::verify_RAII_safety" ()</dt><dd> \anchor _test000421 to support using LinkedElements within RAII-style components, all the elements might be added in one sway, by pulling them from a Lumiera Forward Iterator. In case this is done in the ctor, any exception while doing so will trigger cleanup of all elements (and then failure of the ctor altogether) </dd> <dt> \_setscope steam::asset::test::MakeClip_test Class \_internalref classsteam_1_1asset_1_1test_1_1MakeClip__test "MakeClip_test" </dt><dd> \anchor _test000066 creating a Clip MObject and an associated Clip Asset from a given asset::Media. </dd> <dt> \_setscope vault::test::MediaAccessMock_test Class \_internalref classvault_1_1test_1_1MediaAccessMock__test "MediaAccessMock_test" </dt><dd> \anchor _test000270 inject a Mock object replacing the backend_interface::MediaAccessFacade. Verify if the Mock object behaves as expected when calling the Facade. </dd> <dt> \_setscope steam::control::test::MementoTie_test Class \_internalref classsteam_1_1control_1_1test_1_1MementoTie__test "MementoTie_test" </dt><dd> \anchor _test000101 Verify the state capturing mechanism (memento), which is used to implement the Undo() functionality for Steam-Layer commands. Bind an undo function and a state capturing function and wire up both to store and retrieve a memento value. Verify that after closing the functions, actually state is captured by each invocation.</dd> <dt> \_setscope lib::meta::test::MetaUtils_test Class \_internalref classlib_1_1meta_1_1test_1_1MetaUtils__test "MetaUtils_test" </dt><dd> \anchor _test000437 verify basic type trait and metaprogramming helpers. - marker types to tell which overload the compiler picks - simple trait to detect the possibility of a string conversion - trait to detect (possibly) structured types (»tuple-like«) - trait to detect a typelist type </dd> <dt> \_setscope lib::meta::test::MetaUtils_test Member \_internalref classlib_1_1meta_1_1test_1_1MetaUtils__test#a57c1953d00d55676e32c18fea57f9b00 "MetaUtils_test::verify_basicTypeProbing" ()</dt><dd> \anchor _test000439 demonstrate the basic type trait detection technique: - we have two overloads with differing return type - we form a function call expression - by investigating the return type, we can figure out which overload the compiler picks. </dd> <dt> \_setscope steam::mobject::test::MObjectInterface_test Class \_internalref classsteam_1_1mobject_1_1test_1_1MObjectInterface__test "MObjectInterface_test" </dt><dd> \anchor _test000201 cover the common behaviour of all MObjects. </dd> <dt> \_setscope steam::mobject::test::MObjectRef_test Class \_internalref classsteam_1_1mobject_1_1test_1_1MObjectRef__test "MObjectRef_test" </dt><dd> \anchor _test000209 properties and behaviour of the external reference-mechanism for MObjects placed into the session. We create a simple, simulated "session" (no real session datastructure) and a mock PlacementIndex. Then we add two Placements, which can be used then to build MObjectRef instances to validate their behaviour. </dd> <dt> \_setscope steam::engine::test::MockSupport_test Class \_internalref classsteam_1_1engine_1_1test_1_1MockSupport__test "MockSupport_test" </dt><dd> \anchor _test000142 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 - configurable setup of a complete frame Dispatcher </dd> <dt> \_setscope steam::engine::test::MockSupport_test Member \_internalref classsteam_1_1engine_1_1test_1_1MockSupport__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "MockSupport_test::simpleUsage" ()</dt><dd> \anchor _test000143 simple usage example of the test helpers </dd> <dt> \_setscope steam::engine::test::MockSupport_test Member \_internalref classsteam_1_1engine_1_1test_1_1MockSupport__test#a8913d8d37bc32a695a51f5b1435a2b9c "MockSupport_test::verify_MockDispatcherSetup" ()</dt><dd> \anchor _test000149 verify setup of a mocked Dispatcher instance - by default, MockDispatcher generates a single segment to span the whole Time-axis and with some random yet valid pipeline-ID, so that a single job ticket can be generated for each port everywhere - in addition, it is possible to use the same specification language as for Segmentation to define a more complex (mock)processing graph </dd> <dt> \_setscope steam::engine::test::MockSupport_test Member \_internalref classsteam_1_1engine_1_1test_1_1MockSupport__test#ad55bfbb5262f9d1450d9477a8acbb95b "MockSupport_test::verify_MockJob" ()</dt><dd> \anchor _test000144 document and verify usage of a mock render job </dd> <dt> \_setscope steam::engine::test::MockSupport_test Member \_internalref classsteam_1_1engine_1_1test_1_1MockSupport__test#a717a260d963974a24157107380fb57c2 "MockSupport_test::verify_MockJobTicket" ()</dt><dd> \anchor _test000145 document and verify usage of a mock JobTicket for frame dispatch </dd> <dt> \_setscope steam::engine::test::MockSupport_test Member \_internalref classsteam_1_1engine_1_1test_1_1MockSupport__test#a602e73b8faaa9d026e44ab2a073c2ad6 "MockSupport_test::verify_MockPrerequisites" ()</dt><dd> \anchor _test000148 build a Segment with additional prerequisites, resulting in additional JobTickets to explore and additional prerequisite Jobs to build for each frame. </dd> <dt> \_setscope steam::engine::test::MockSupport_test Member \_internalref classsteam_1_1engine_1_1test_1_1MockSupport__test#a10c32db4d4e62939fb67c29ed92cd45c "MockSupport_test::verify_MockSegmentation" ()</dt><dd> \anchor _test000146 document and verify usage of a complete mocked Segmentation to back frame dispatch - 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 </dd> <dt> \_setscope steam::fixture::test::ModelPortRegistry_test Class \_internalref classsteam_1_1fixture_1_1test_1_1ModelPortRegistry__test "ModelPortRegistry_test" </dt><dd> \anchor _test000198 create a standalone model port registry to verify the behaviour of model ports, accessed through reference handles. This test provides an example setup detached from the real usage situation within the builder. The ModelPortRegistry management interface is used to create and track a set of model ports, to be made visible by an atomic, transactional switch. The access for client code through the ModelPort frontend is then verified.</dd> <dt> \_setscope lib::test::MultiFact_test Class \_internalref classlib_1_1test_1_1MultiFact__test "MultiFact_test" </dt><dd> \anchor _test000471 verify the basic usage patterns of the configurable factory template. - Depending on the concrete fabrication signature, the factory can produce "things" by invoking suitable fabrication functions. These functions are to be installed beforehand, and can be addressed through an ID. - these fabrication functions are installed per instance of the factory. Such a concrete factory configuration can be copied - optionally each created product can be passed through a wrapper function - there is a preconfigured wrapper for creating refcounting smart ptrs. - it is possible to define a custom wrapper function on factory setup. </dd> <dt> \_setscope lib::test::MultiFactArgument_test Class \_internalref classlib_1_1test_1_1MultiFactArgument__test "MultiFactArgument_test" </dt><dd> \anchor _test000462 define a MultiFact (factory with dynamic registration), which accepts additional arguments and passes them through to the registered factory function(s). </dd> <dt> \_setscope lib::test::MultiFactSingleton_test Class \_internalref classlib_1_1test_1_1MultiFactSingleton__test "MultiFactSingleton_test" </dt><dd> \anchor _test000466 verify the use of the MultiFact template to access Singletons. While generally speaking the MultiFact allows us to address and invoke several "production lines" by ID, an obvious use case would be to access a "family" of singletons through this mechanism. And indeed, \c MultiFact::Singleton is a preconfigured shortcut for this use case. The actual singleton access factories are placed into a static context (here in the anonymous namespace above) and their access operation is wired as "factory function". - we use a hierarchy of test dummy objects - we set up a singleton factory for several subclasses - the registration happens automatically in the ctor - we verify that we indeed get the correct flavour.</dd> <dt> \_setscope lib::diff::test::MutationMessage_test Class \_internalref classlib_1_1diff_1_1test_1_1MutationMessage__test "MutationMessage_test" </dt><dd> \anchor _test000310 properties of a container to transport a diff from an abstracted source generator to an abstracted consumer. - this covers a standard usage scenario within Lumiera, where some producer in the Session core detects changes in session structure and sends a message to make the UI conform to the new structure - diff messages are hard to debug and test, since they are designed as opaque sequences to be consumed only once. Thus for we provide a snapshot decorator to offer diagnostic facilities - moreover we provide a simplified builder function to create hard wired diff messages in a concise way - and finally this test repeats the scenario of DiffTreeApplication_test, but this time the diff sequences are encapsulated as MutationMessage. </dd> <dt> \_setscope lib::diff::test::MutationMessage_test Member \_internalref classlib_1_1diff_1_1test_1_1MutationMessage__test#ae9d66aeffce26bcef5a619232c783033 "MutationMessage_test::demonstrate_standardUsage" ()</dt><dd> \anchor _test000318 demonstrate the intended usage pattern - a diff generation context is allocated - the MutationMessage takes ownership - and exposes the generated diff sequence - which is pulled during iteration </dd> <dt> \_setscope lib::diff::test::MutationMessage_test Member \_internalref classlib_1_1diff_1_1test_1_1MutationMessage__test#a47057b952a2df079a8064dc0d4023ff4 "MutationMessage_test::demonstrate_treeApplication" ()</dt><dd> \anchor _test000319 use MutationMessage to transport and apply changes to target data </dd> <dt> \_setscope steam::engine::test::NodeBase_test Class \_internalref classsteam_1_1engine_1_1test_1_1NodeBase__test "NodeBase_test" </dt><dd> \anchor _test000195 basic render node structure and building blocks. This test documents and verifies some fundamental Render Node structures, looking at intricate technical details, which are usually hidden below the NodeBuidler. - #verify_NodeStructure is a demonstration example to show fundamentals of node construction and invocation, using a dummy implementation. - the following cases cover extremely technical details of the FeedManifold, which serves as junction point between Render Node and external library functions. - in a similar style, \ref NodeFeed_test covers the various parameter- and data connections of Nodes in a »clean-room« setting - much more high-level is NodeLink_test, covering the construction of a Render Node network - NodeBuilder_test focuses on aspects of node generation, as packaged into the NodeBuilder. </dd> <dt> \_setscope steam::engine::test::NodeBase_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBase__test#a695d1462d88468805554c6c0e62f5418 "NodeBase_test::verify_FeedManifold" ()</dt><dd> \anchor _test000202 the FeedManifold as adapter between Engine and processing library... - bind local λ with various admissible signatures - construct specifically tailored FeedManifold types - use the DiagnosticBufferProvider for test buffers - create FeedManifold instance, passing the λ and additional parameters - connect BuffHandle for these buffers into the FeedManifold instance - trigger invocation of the function - look into the buffers and verify effect </dd> <dt> \_setscope steam::engine::test::NodeBase_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBase__test#ac29bf9acfc70a06ebc03b58c98ef7cb8 "NodeBase_test::verify_FeedPrototype" ()</dt><dd> \anchor _test000204 Setup of a FeeManifold to attach parameter-functors </dd> <dt> \_setscope steam::engine::test::NodeBase_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBase__test#afa5f9a90278a5da548acdc57ec4d5f85 "NodeBase_test::verify_NodeStructure" ()</dt><dd> \anchor _test000200 very basic structure of a Render Node. - All render processing happens in \ref Port implementations - here we use a dummy port, which just picks up a parameter from the TurnoutSystem and writes it into the output buffer; no further recursive call happens — so this is a source node. - To <em>incorporate</em> this Port implementation into a Render Node, the <em>connectivity</em> of the node network must be defined: + each node has a list of »Leads« (predecessor nodes) + and an array of port implementation (here just one port) - note that data placement relies on lib::Several, which can be configured to use a custom allocator to manage storage - furthermore, a node gets some ID descriptors, which are used to generate processing metadata (notably a hash key for caching) - for the actual invocation, foremost we need a <em>buffer provider</em> - and we need to supply the most basic parameters, like the nominal timeline time and a proccess-Key. These will be embedded into the TurnoutSystem, to be accessible throughout the complete recursive node-pull invocation. - This test verifies that the actual invocation indeed happened and placed a random parameter-value into the output buffer. </dd> <dt> \_setscope steam::engine::test::NodeBase_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBase__test#aecdb67e142225709e95c7b4839717a60 "NodeBase_test::verify_TurnoutSystem" ()</dt><dd> \anchor _test000199 the TurnoutSystem as transient connection hub for node invocation - for most invocations, just the nominal timeline time and an arbitrary process indentification-key is placed into fixed «slots« within the TurnoutSystem, from where these parameters can be retrieved by actual processing functions; - for some special cases however, additional storage blocks can be chained up, to allow accessing arbitrary parameters through the TurnoutSystem as front-end. </dd> <dt> \_setscope steam::engine::test::NodeBuilder_test Class \_internalref classsteam_1_1engine_1_1test_1_1NodeBuilder__test "NodeBuilder_test" </dt><dd> \anchor _test000167 creating and configuring various kinds of Render Nodes. </dd> <dt> \_setscope steam::engine::test::NodeBuilder_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBuilder__test#ab6027203582a14260a1c4f50f9db6710 "NodeBuilder_test::build_connectedNodes" ()</dt><dd> \anchor _test000175 build a chain with three connected Nodes - have two source nodes, which accept a parameter - but configure them differently: one gets a constant, while the other draws a random number - the third node takes two input buffers and and one output; it retrieves the input values, and sums them together - use the »simplified 1:1 wiring«, which connects consecutively each input slot to the next given node on the same port number; here we only use port#0 on all three nodes. <p></dd> <dt> \_setscope steam::engine::test::NodeBuilder_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBuilder__test#afbc8e5e1ae479322679b666b24fc4319 "NodeBuilder_test::build_Node_adaptedParam" ()</dt><dd> \anchor _test000173 build a node and <em>adapt the parameters</em> for invocation. - again use a processing function which takes a parameter - but then <em>decorate</em> this functor, so that it takes different arguments - attach parameter handling to supply these adapted arguments <p></dd> <dt> \_setscope steam::engine::test::NodeBuilder_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBuilder__test#aac8fa468c13e839a0d8196d3051fb9dd "NodeBuilder_test::build_Node_closedParam" ()</dt><dd> \anchor _test000174 build a node and partially close (≙ predefine) some parameters, while leaving other parameters open to be set on invocation through a parameter-functor. - define a processing-function which takes an array of parameters, which will be handled similar as a tuple with uniform types. - demonstrate that several partial-closures can be cascaded; first close one parameter given by index, then close staring from the front and then aligned to the end - now a single param «slot» remains open, which can be wired to receive automation data (note: 1-tuple generated automatically) </dd> <dt> \_setscope steam::engine::test::NodeBuilder_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBuilder__test#a0d8bb86ce474f2edf7f705abc70ddfaa "NodeBuilder_test::build_Node_dynamicParam" ()</dt><dd> \anchor _test000172 build a Node with dynamically generated parameter - use a processing function which takes a parameter - use an <em>automation functor,</em> which just quantises the time into an implicitly defined grid - install both into a render node - set a random <em>nominal time</em> for invocation <p></dd> <dt> \_setscope steam::engine::test::NodeBuilder_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBuilder__test#aeb7541a80b843d308f65408d93ca701e "NodeBuilder_test::build_Node_fixedParam" ()</dt><dd> \anchor _test000171 build a Node with a fixed invocation parameter <p></dd> <dt> \_setscope steam::engine::test::NodeBuilder_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBuilder__test#aaf50f0e5cb05253ce152b34d512a06a8 "NodeBuilder_test::build_ParamNode" ()</dt><dd> \anchor _test000177 demonstrate the setup of a »Param Agent Node« - perform effectively the same computation as the preceding test - but use two new custom parameters in the Param Agent Node - pick them up from the nested source nodes by accessor-functors <p></dd> <dt> \_setscope steam::engine::test::NodeBuilder_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeBuilder__test#ad603846fe1128982bafee734cebff476 "NodeBuilder_test::build_simpleNode" ()</dt><dd> \anchor _test000169 build a simple output-only Render Node <p></dd> <dt> \_setscope steam::engine::test::NodeDevel_test Class \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test "NodeDevel_test" </dt><dd> \anchor _test000147 verify support for developing Render Node functionality. - raw processing functions to generate and manipulate \ref TestFrame data, including hash chaining. - a »TestRand-Ontology«, which is a test helper framework, and mimics a real <em>Domain Ontology</em> (as would be accessible through the adapter plug-in of a specific media handling library. - some convenience shortcuts to build test-nodes </dd> <dt> \_setscope steam::engine::test::NodeDevel_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test#a8f016dda5658113f58b455aa7568c458 "NodeDevel_test::processing_combineFrames" ()</dt><dd> \anchor _test000157 function to mix two test data frames </dd> <dt> \_setscope steam::engine::test::NodeDevel_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test#ae461ae9338ca9438920edc0a6c3d43c4 "NodeDevel_test::processing_duplicateMultichan" ()</dt><dd> \anchor _test000154 clone copy of multichannel test data </dd> <dt> \_setscope steam::engine::test::NodeDevel_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test#a13f401563efa8b28c6502d8ba672f3ee "NodeDevel_test::processing_generateFrame" ()</dt><dd> \anchor _test000151 function to generate random test data frames </dd> <dt> \_setscope steam::engine::test::NodeDevel_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test#ae74169df4d9ae1bf43d64546fde32c43 "NodeDevel_test::processing_generateMultichan" ()</dt><dd> \anchor _test000152 function to generate an array of random test data frames for consecutive channels </dd> <dt> \_setscope steam::engine::test::NodeDevel_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test#af8bf3b000f3ef2e5d9d6c182abd29777 "NodeDevel_test::processing_manipulateFrame" ()</dt><dd> \anchor _test000156 function to apply a numeric computation to test data frames; </dd> <dt> \_setscope steam::engine::test::NodeDevel_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test#a27f25edb149e9bdef1be9a0fd6bfb436 "NodeDevel_test::processing_manipulateMultichan" ()</dt><dd> \anchor _test000155 multichannel data hash-chain manipulation - use multichannel pseudo random input data - store away a clone copy before manipulation - the #manipulateMultichan() operates in-place in the buffers - each buffer has been marked with a new checksum afterwards - and each buffer now differs from original state - verify that corresponding data points over all channels have been linked by a hashcode-chain, seeded with the <tt>param</tt> and then consecutively hashing in data from each channel. </dd> <dt> \_setscope steam::engine::test::NodeDevel_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test#a2abf1ec6d10ff07194a185967fe7bd28 "NodeDevel_test::testRand_buildFilterNode" ()</dt><dd> \anchor _test000160 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. </dd> <dt> \_setscope steam::engine::test::NodeDevel_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test#a94ac7ac3ebaa63eada93f7583edbb1c2 "NodeDevel_test::testRand_buildMixNode" ()</dt><dd> \anchor _test000164 use the »TestRand«-framework to setup a two-chain mixer node - demonstrate convenience setup to package the ont::combineFrames() as »mix« Node - this time, we need two source chains, both generating \ref TestFrame data - complete processing with all steps can be verified by performing similar computations directly and comparing the result checksum. </dd> <dt> \_setscope steam::engine::test::NodeDevel_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeDevel__test#a16dfb19cf824fd2bb6e5d6d4a62dcbdf "NodeDevel_test::testRand_simpleUsage" ()</dt><dd> \anchor _test000158 demonstrate simple usage of test-render setup - access the TestRandOntology as singleton - create a Spec record - retrieve a functor bound suitably to invoke data processing code from the TestRandOntology </dd> <dt> \_setscope steam::engine::test::NodeFeed_test Class \_internalref classsteam_1_1engine_1_1test_1_1NodeFeed__test "NodeFeed_test" </dt><dd> \anchor _test000150 demonstrate how to feed data into, through and out of render nodes. <p></dd> <dt> \_setscope steam::engine::test::NodeFeed_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeFeed__test#ac6c84b49819eab2a45c0f2f97a510c2c "NodeFeed_test::feedParam" ()</dt><dd> \anchor _test000159 demonstrate internal setup to invoke a simple output-only function, passing an additional invocation parameter generated from a parameter-functor - embed the processing-functor and parameter-functor into a FeedPrototype - construct the type of the »Weaving Pattern« to use for invocation - setup an empty wiring (output-only, thus no predecessor ports) - setup a single BuffDesrc for a result puffer to pass to the processing-functor - create a Turnout, which implements the Port interface, using the Weaving-Pattern - for the actual invocation, setup a TurnoutSystem, initialised with a nominal time - invoke the Port::weave() function and retrieve the result from the buffer. </dd> <dt> \_setscope steam::engine::test::NodeFeed_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeFeed__test#a83ae5e8ef5331ac8e9fa23b7f3bee21a "NodeFeed_test::feedParamNode" ()</dt><dd> \anchor _test000162 create extended parameter data for use in recursive Node invocation. - demonstrate the mechanism of param-functor invocation, and how a Param-Spec is built to create and hold those functors - then instantiate an actual TurnoutSystem, as is done for a Node invocation, with an embedded »absolute nominal time« parameter value - can then invoke the param-functors and materialise results into a Param-Data-Block - which then can be linked internally to be reachable through the TurnoutSystem - other code further down the call-stack can thus access those parameter values. - The second part of the test uses the same scheme embedded into a Param(Agent)Node </dd> <dt> \_setscope steam::fixture::test::NodeGraphAttachment_test Class \_internalref classsteam_1_1fixture_1_1test_1_1NodeGraphAttachment__test "NodeGraphAttachment_test" </dt><dd> \anchor _test000192 Verify the facade object used to connect from the Segments in the Fixture into the actual render nodes network - construction of ExitNode - composition of the NodeGraphAttachment including prerequisites - generation of a complete setup of fake ExitNodes from a test spec. </dd> <dt> \_setscope steam::fixture::test::NodeGraphAttachment_test Member \_internalref classsteam_1_1fixture_1_1test_1_1NodeGraphAttachment__test#ac71113098f3e2af64035244b47a8138a "NodeGraphAttachment_test::access_ExitNodeTree" ()</dt><dd> \anchor _test000194 access to ExitNode and fall back on ExitNode::NIL when undefined - verify ExitNode::NIL - build a simple ExitNode without prerequisites - use this as prerequisite(s) for another ExitNode - put a third ExitNode(id=13) also into the same collection - use this to construct a NodeGraphAttachment - access existing and non-existing index positions </dd> <dt> \_setscope steam::fixture::test::NodeGraphAttachment_test Member \_internalref classsteam_1_1fixture_1_1test_1_1NodeGraphAttachment__test#a5295b8e37ca6dc6c9a277d6b4dfbec86 "NodeGraphAttachment_test::fabricate_MockExitNode" ()</dt><dd> \anchor _test000196 setup a properly structured ExitNode graph using the specification scheme supported by MockSegmentation </dd> <dt> \_setscope steam::engine::test::NodeLink_test Class \_internalref classsteam_1_1engine_1_1test_1_1NodeLink__test "NodeLink_test" </dt><dd> \anchor _test000176 demonstrate and document how \ref proc-node.hpp "render nodes" are connected into a processing network, allowing to <em>invoke</em> a \ref Port on a node to pull-generate a render result. - Nodes can be built and ID metadata can be inspected - several Nodes can be linked into a render graph - connectivity can be verified to match definition - TestFrame data can be computed in a complex processing network - parameters can be derived from time and fed into the nodes. </dd> <dt> \_setscope steam::engine::test::NodeLink_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeLink__test#a7723f4ebc97e5deecd6cce091504f330 "NodeLink_test::build_connected_nodes" ()</dt><dd> \anchor _test000183 Build more elaborate Render Nodes linked into a connectivity network - verify nodes with several ports; at exit-level, 3 ports are available - using two different source nodes, one with two, one with three ports - the 2-port source is linearly chained to a 2-port filter node - the exit-level is a mix node, combining data from both chains - apply the automatic wiring of ports with the same number, whereby the first port connects to the first port on the lead, and so on. - yet for the 3rd port at the mix node, on one side the port number must be given explicitly, since the »A-side« chain offers only two ports. <p></dd> <dt> \_setscope steam::engine::test::NodeLink_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeLink__test#a749f8ce640932711442b7db69ff9ac21 "NodeLink_test::build_simple_node" ()</dt><dd> \anchor _test000180 Build Node Port for simple function and verify observable properties of a Render Node <p></dd> <dt> \_setscope steam::engine::test::NodeLink_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeLink__test#acc7740812bc3c7edf23465aa02716c5a "NodeLink_test::trigger_node_port_invocation" ()</dt><dd> \anchor _test000186 Invoke some render nodes as linked together. - use exactly the same topology as in the preceding test - but this time use TestFrame (random data) and configure hash-chaining operations provided by »Test Random« - setup various automation functions, based on the frame-# - use a pre-computation step to <em>quantise</em> time into frame-# - install this pre-computation as »Param Agent Node« - configure individual parameters to consume precomputed frame-# - use <em>partial closure</em> to supply the source-»flavour« parameter - also rebuild the expected computations by direct invocation - sample various test runs with randomly chosen time and port-# - verify computed data checksums match with expected computation. <p></dd> <dt> \_setscope steam::engine::test::NodeMeta_test Class \_internalref classsteam_1_1engine_1_1test_1_1NodeMeta__test "NodeMeta_test" </dt><dd> \anchor _test000179 Render node metadata and hash identity keys. <p></dd> <dt> \_setscope steam::engine::test::NodeMeta_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeMeta__test#aa0300b9f6be3b8f8dbe8d4ec719da8d5 "NodeMeta_test::verify_ID_connectivity" ()</dt><dd> \anchor _test000187 validate the interplay of node connectivity with reported properties at the ProcID and demonstrate tools to check connectivity. - Build a 3-node network with dummy operations, which however are built to mimic the very common situation where two sources are mixed - at exit side, three different »flavours« can be produced, which implies that there are three Ports. - the source at the »A-side« provided only two flavours, and thus an explicit wiring has to be made for the A-side connection of the third chain - In real usage, the node specification strings will be provided from the Media-Lib adapter plug-in. Here it is hard wired, and defined in a way to reflect structure. - various ways to drill-down into the structure are explored by verifying the ProcID specification visible at each point. - then the tools for verifying connectivity are demonstrated and covered with relevant positive and negative combinations. <p></dd> <dt> \_setscope steam::engine::test::NodeMeta_test Member \_internalref classsteam_1_1engine_1_1test_1_1NodeMeta__test#a660d127e5f9ee0da2c976bc997f28170 "NodeMeta_test::verify_ID_specification" ()</dt><dd> \anchor _test000184 evaluation of processing-spec for a ProcID <p></dd> <dt> \_setscope steam::engine::test::NodeOpera_test Class \_internalref classsteam_1_1engine_1_1test_1_1NodeOpera__test "NodeOpera_test" </dt><dd> \anchor _test000153 check render node operation modes and collaboration. </dd> <dt> \_setscope steam::engine::test::NodeStorage_test Class \_internalref classsteam_1_1engine_1_1test_1_1NodeStorage__test "NodeStorage_test" </dt><dd> \anchor _test000163 creating and wiring various kinds of render nodes. </dd> <dt> \_setscope lib::test::NullValue_test Class \_internalref classlib_1_1test_1_1NullValue__test "NullValue_test" </dt><dd> \anchor _test000467 Access "NIL values" just by type, verify these are actually singletons and are indeed created on demand.</dd> <dt> \_setscope lib::test::OpaqueHolder_test Class \_internalref classlib_1_1test_1_1OpaqueHolder__test "OpaqueHolder_test" </dt><dd> \anchor _test000473 use the OpaqueHolder inline buffer to handle objects of a family of types through a common interface, without being forced to use heap storage or a custom allocator.</dd> <dt> \_setscope lib::test::OpaqueHolder_test Member \_internalref classlib_1_1test_1_1OpaqueHolder__test#a421425fe92d49854dd053cc91164b5c3 "OpaqueHolder_test::checkHandling" (TestList &objs)</dt><dd> \anchor _test000519 cover the basic situations of object handling, especially copy operations and re-assignments </dd> <dt> \_setscope lib::test::OpaqueHolder_test Member \_internalref classlib_1_1test_1_1OpaqueHolder__test#a6234c738d709e16da8d949a4b13a7683 "OpaqueHolder_test::checkSpecialSubclass" ()</dt><dd> \anchor _test000522 Moreover, if the concrete class has a custom operator bool(), it will be invoked automatically from OpaqueHolder's operator bool()<p> \anchor _test000521 OpaqueHolder with additional storage for subclass. When a subclass requires more storage than the base class or Interface, we need to create a custom OpaqueHolder, specifying the actually necessary storage. Such a custom OpaqueHolder behaves exactly like the standard variant, but there is protection against accidentally using a standard variant to hold an instance of the larger subclass.</dd> <dt> \_setscope lib::test::OpaqueUncheckedBuffer_test Class \_internalref classlib_1_1test_1_1OpaqueUncheckedBuffer__test "OpaqueUncheckedBuffer_test" </dt><dd> \anchor _test000472 use an inline buffer to place objects of a subclass, without any checks. - InPlaceBuffer only provides minimal service, to be covered here, including automatic dtor invocation and smart-ptr style access. - A PlantingHandle can be exposed through some API, thereby allowing an external entity to implant some implementation subclass. </dd> <dt> \_setscope lib::test::OptionalRef_test Class \_internalref classlib_1_1test_1_1OptionalRef__test "OptionalRef_test" </dt><dd> \anchor _test000470 verify a reference-like wrapper class, used to provide a switchable link to an already existing object. - bottom ref can be detected by bool check - access to bottom ref raises exception - refs can be compared - refs can be changed and copied - access to refs is secure even after destructor invocation</dd> <dt> \_setscope steam::asset::test::OrderingOfAssets_test Class \_internalref classsteam_1_1asset_1_1test_1_1OrderingOfAssets__test "OrderingOfAssets_test" </dt><dd> \anchor _test000071 validate the equality and order relations of Asset::Ident and Asset objects. </dd> <dt> \_setscope steam::mobject::test::OutputMapping_test Class \_internalref classsteam_1_1mobject_1_1test_1_1OutputMapping__test "OutputMapping_test" </dt><dd> \anchor _test000217 create a synthetic / example mapping to verify generic mapping behaviour. We're creating a custom mapping type here, for this test only: The struct DummyDef provides a "definition context" for this custom mapping - there is a function to retrieve the actual target object for any target pipe stored in the mapping. In this case, we just extract the name-ID string from the pipe as result - as an additional sideeffect, this DummyDef::output functor also defines the Target type of this custom mapping to be std::string - DummyDef::buildQuery provides a template query, to be issued whenever a yet nonexistent mapping is requested. In this special case here we query for a pipe with the name "master_XXX", where XXX denotes the stream-type of the source pipe to be mapped.</dd> <dt> \_setscope steam::engine::test::OutputProxyProvider_test Class \_internalref classsteam_1_1engine_1_1test_1_1OutputProxyProvider__test "OutputProxyProvider_test" </dt><dd> \anchor _test000166 verify the design of OutputSlot and BufferProvider by implementing a delegating BufferProvider to expose output data buffers provided from <em>some implementation.</em> <p></dd> <dt> \_setscope steam::play::test::OutputSlotProtocol_test Class \_internalref classsteam_1_1play_1_1test_1_1OutputSlotProtocol__test "OutputSlotProtocol_test" </dt><dd> \anchor _test000253 verify the OutputSlot interface and base implementation by performing full data exchange cycle. This is a kind of "dry run" for documentation purposes, both the actual OutputSlot implementation as the client using this slot are Mocks. </dd> <dt> \_setscope lib::test::PathArray_test Class \_internalref classlib_1_1test_1_1PathArray__test "PathArray_test" </dt><dd> \anchor _test000524 verify abstraction wrapper to handle some char pointers in the way of a standard sequence container with iteration and range checks.</dd> <dt> \_setscope lib::test::PathArray_test Member \_internalref classlib_1_1test_1_1PathArray__test#a0b8f6c989c347fe716aaae7719938ac3 "PathArray_test::verify_boundaries" ()</dt><dd> \anchor _test000528 cover some tricky corner cases of the bound checks and normalisation routine. </dd> <dt> \_setscope lib::test::PathArray_test Member \_internalref classlib_1_1test_1_1PathArray__test#a531d49bd6703114e15d905e649b5d7b7 "PathArray_test::verify_comparisons" ()</dt><dd> \anchor _test000530 verify equality comparison Equality of PathArray is based on overall size, position and <em>normalised</em> content. </dd> <dt> \_setscope steam::mobject::session::test::PlacementBasic_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementBasic__test "PlacementBasic_test" </dt><dd> \anchor _test000205 basic behaviour of Placements and access to MObjects. </dd> <dt> \_setscope steam::mobject::session::test::PlacementHierarchy_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementHierarchy__test "PlacementHierarchy_test" </dt><dd> \anchor _test000206 creating placements specifically typed, forming an hierarchy of placement types which loosely mirrors the hierarchy of the pointee types. Assignments between placement of differing type, while still sharing ownership. </dd> <dt> \_setscope steam::mobject::session::test::PlacementIndex_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementIndex__test "PlacementIndex_test" </dt><dd> \anchor _test000230 basic behaviour of the index mechanism used to keep track of individual Placements as added to the current Session. </dd> <dt> \_setscope steam::mobject::session::test::PlacementIndex_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementIndex__test#af3382b721baeda36e4369d7a89d7ab7e "PlacementIndex_test::checkContentsEnumeration" (Idx index)</dt><dd> \anchor _test000233 drill down into the tree-like structure and enumerate the contents of each element, if any </dd> <dt> \_setscope steam::mobject::session::test::PlacementIndexQuery_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementIndexQuery__test "PlacementIndexQuery_test" </dt><dd> \anchor _test000219 accessing the PlacementIndex through the generic query interface, for discovering scope contents and containing scope.</dd> <dt> \_setscope steam::mobject::test::PlacementObjectIdentity_test Class \_internalref classsteam_1_1mobject_1_1test_1_1PlacementObjectIdentity__test "PlacementObjectIdentity_test" </dt><dd> \anchor _test000208 verify correct handling of object identity. Create test objects, add placements to a dummy index/session, then create PlacementRef and MObjectRef handles. Finally do cross comparisons.</dd> <dt> \_setscope steam::mobject::session::test::PlacementRef_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementRef__test "PlacementRef_test" </dt><dd> \anchor _test000210 properties and behaviour of the reference-mechanism for Placements. We create an mock placement index and install it to be used by all PlacementRef instances while conducting this test. Then we add two dummy placements and create some references to conduct placement operations through these references. </dd> <dt> \_setscope steam::mobject::session::test::PlacementScope_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementScope__test "PlacementScope_test" </dt><dd> \anchor _test000221 basic behaviour of the nested placement search scopes. Using a pseudo-session (actually just a PlacementIndex), this test creates some nested scopes and then... - discovers the scope of a placement - finds the parent scope - enumerates a scope path up to root</dd> <dt> \_setscope steam::mobject::session::test::PlacementScope_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementScope__test#a34cf990b6665941e5c8c289a6184980d "PlacementScope_test::verifyEquality" ()</dt><dd> \anchor _test000228 equality of scopes is based on the ID of the scope top (Placement) </dd> <dt> \_setscope steam::mobject::session::test::PlacementScope_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementScope__test#a75f40f400a901928c17ac5972a4d6322 "PlacementScope_test::verifyLookup" (PPIdx sess)</dt><dd> \anchor _test000226 for each Placement in our test "session", find the scope and verify it's in line with the index </dd> <dt> \_setscope steam::mobject::session::test::PlacementScope_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1PlacementScope__test#a44994c2850e6e7345efdaf3281e791ff "PlacementScope_test::verifyNavigation" (PPIdx sess)</dt><dd> \anchor _test000229 for each element in our test session, establish the scope and retrieve the path to root, verifying the parent relationships as we go up. </dd> <dt> \_setscope lib::test::PolymorphicValue_test Class \_internalref classlib_1_1test_1_1PolymorphicValue__test "PolymorphicValue_test" </dt><dd> \anchor _test000483 build a bunch of PolymorphicValue objects. Handle them like copyable value objects, without knowing the exact implementation type; moreover execute implementation internals only disclosed to the concrete subtype. Verify correctness through checksums. </dd> <dt> \_setscope lib::test::PolymorphicValue_test Member \_internalref classlib_1_1test_1_1PolymorphicValue__test#a8a655add884cdf0a0e12e70f65aa20ba "PolymorphicValue_test::verifyCopySupportDetectionMetafunctions" ()</dt><dd> \anchor _test000500 internally, PolymorphicValue uses some metafunctions to pick a suitable code path, based on the presence of helper functions on the API of the embedded objects. Default is no support by these objects, which then requires to use a more expensive implementation. Sometimes it's desirable to support <em>cloning only</em> (copy ctor), but no assignment after the fact. In this special case, a support API with only a <tt>cloneInto()</tt> member can be implemented, causing the PolymorphicValue container to raise an exception in case the copy operator is invoked. </dd> <dt> \_setscope lib::time::test::QuantiserBasics_test Class \_internalref classlib_1_1time_1_1test_1_1QuantiserBasics__test "QuantiserBasics_test" </dt><dd> \anchor _test000025 cover the basic Quantiser API. This test uses a standalone quantiser implementation to demonstrate and verify the basic behaviour and the usage corner cases of a quantiser.</dd> <dt> \_setscope steam::mobject::session::test::QueryFocus_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1QueryFocus__test "QueryFocus_test" </dt><dd> \anchor _test000223 handling of current query focus when navigating a system of nested scopes. Using a pseudo-session (actually just a PlacementIndex), this test accesses some nested scopes and then checks moving the "current scope". Moreover a (stack-like) sub-focus is created, temporarily moving aside the current focus and returning later on.</dd> <dt> \_setscope steam::mobject::session::test::QueryFocus_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1QueryFocus__test#ae3e16e06af89375c75c77281fd2c16d3 "QueryFocus_test::checkNavigation" (QueryFocus &focus)</dt><dd> \anchor _test000225 move the current focus to different locations and discover contents there. </dd> <dt> \_setscope steam::mobject::session::test::QueryFocus_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1QueryFocus__test#af98b9188c87240c4ffabf7cf942c2c2b "QueryFocus_test::manipulate_subFocus" ()</dt><dd> \anchor _test000227 side-effect free manipulation of a sub-focus, while the original focus is pushed aside (stack) </dd> <dt> \_setscope steam::mobject::session::test::QueryFocusStack_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1QueryFocusStack__test "QueryFocusStack_test" </dt><dd> \anchor _test000224 behaviour of the stack of focus location paths. Basically this is just a stack, but has a somewhat unusual behaviour on pop(), as it considers the (intrusive) ref-count maintained within the stack frames (ScopePath instances) and cleans up unused frames. Similar to the ScopePath_test, we use a pseudo-session to create some path frames to play with. </dd> <dt> \_setscope lumiera::test::QueryResolver_test Class \_internalref classlumiera_1_1test_1_1QueryResolver__test "QueryResolver_test" </dt><dd> \anchor _test000222 verify the mechanism for issuing typed queries through a generic interface, without disclosing the facility actually answering those queries. Results are to be retrieved through a Lumiera Forward Iterator.</dd> <dt> \_setscope lib::test::QueryText_test Class \_internalref classlib_1_1test_1_1QueryText__test "QueryText_test" </dt><dd> \anchor _test000476 cover basic properties of the generic syntactical query representation. - build from query string</dd> <dt> \_setscope lib::query::test::QueryUtils_test Class \_internalref classlib_1_1query_1_1test_1_1QueryUtils__test "QueryUtils_test" </dt><dd> \anchor _test000485 check the various small helpers and utilities we utilise for dealing with ConfigQuery </dd> <dt> \_setscope lib::query::test::QueryUtils_test Member \_internalref classlib_1_1query_1_1test_1_1QueryUtils__test#a0c9572457ebd3d2917683afbbc4d390d "QueryUtils_test::check_countPred" ()</dt><dd> \anchor _test000495 counting of predicates in a query (currently 4/08 regexp based...) </dd> <dt> \_setscope lib::query::test::QueryUtils_test Member \_internalref classlib_1_1query_1_1test_1_1QueryUtils__test#aa1a3544cb4acb1997e6892f817c441d3 "QueryUtils_test::check_extractID" ()</dt><dd> \anchor _test000491 the simple regexp extracting a parameter token </dd> <dt> \_setscope lib::query::test::QueryUtils_test Member \_internalref classlib_1_1query_1_1test_1_1QueryUtils__test#ac2517e39187f7d792eff94c2e6111a70 "QueryUtils_test::check_normaliseID" ()</dt><dd> \anchor _test000489 sanitising and normalising various tokens </dd> <dt> \_setscope lib::query::test::QueryUtils_test Member \_internalref classlib_1_1query_1_1test_1_1QueryUtils__test#ada5157f5758e32a9923f83c648da6782 "QueryUtils_test::check_removeTerm" ()</dt><dd> \anchor _test000493 the regexp based cutting of a term with given symbol </dd> <dt> \_setscope lib::test::Random_test Class \_internalref classlib_1_1test_1_1Random__test "Random_test" </dt><dd> \anchor _test000510 demonstrate simple access to random number generation, as well as the setup of controlled random number sequences. </dd> <dt> \_setscope lib::test::Random_test Member \_internalref classlib_1_1test_1_1Random__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "Random_test::simpleUsage" ()</dt><dd> \anchor _test000515 demonstrate usage of default random number generators. </dd> <dt> \_setscope lib::test::Random_test Member \_internalref classlib_1_1test_1_1Random__test#a5261278521f83cad2eb9687ad9b3278d "Random_test::verify_distributionVariants" ()</dt><dd> \anchor _test000516 properties of predefined distributions provided for convenience - the upper bound for <tt>rani(bound)</tt> is exclusive - uniform distributions are sufficiently uniform - spread of normal distribution is within expected scale </dd> <dt> \_setscope lib::test::Random_test Member \_internalref classlib_1_1test_1_1Random__test#a1a09b283fb89acc0d123cf4e38019c6e "Random_test::verify_reproducibleSequence" ()</dt><dd> \anchor _test000518 demonstrate that random number sequences can be reproduced - use a rigged SeedNucleus, always returning a fixed sees - build two distinct random sequence generators, yet seeded from the same source; they will produce the same sequence - sequences can be re-shuffled by a seed value, so that the following random numbers will start to differ - but even this re-shuffling is deterministic </dd> <dt> \_setscope lib::test::RandomConcurrent_test Class \_internalref classlib_1_1test_1_1RandomConcurrent__test "RandomConcurrent_test" </dt><dd> \anchor _test000502 demonstrate simple access to random number generation, as well as the setup of controlled random number sequences. </dd> <dt> \_setscope lib::test::RandomConcurrent_test Member \_internalref classlib_1_1test_1_1RandomConcurrent__test#a152dd951b1591dc43f8a47c95dbf79bc "RandomConcurrent_test::benchmark_random_gen" ()</dt><dd> \anchor _test000507 microbenchmark of various random number generators </dd> <dt> \_setscope lib::test::RandomConcurrent_test Member \_internalref classlib_1_1test_1_1RandomConcurrent__test#aa42222ab51904972dc6b10f1ab97c555 "RandomConcurrent_test::investigate_concurrentAccess" ()</dt><dd> \anchor _test000514 examine behaviour of PRNG under concurrency stress - running a 32bit generator single threaded should not trigger alarms - while under concurrent pressure several defect numbers should be produced - even the 64bit generator will show uneven distribution due to corrupted state - the 32bit generator capped to its valid range exhibits skew only occasionally </dd> <dt> \_setscope lib::test::RandomDraw_test Class \_internalref classlib_1_1test_1_1RandomDraw__test "RandomDraw_test" </dt><dd> \anchor _test000538 Verify a flexible builder for random-value generators; using a config template, these can be outfitted to use a suitable source of randomness and to produce values from a desired target type and limited range. - for this test, generated result values are ∈ [-2 .. 0 .. +2] - no actual randomness is used; rather a <tt>size_t</tt> challenge is sent in to verify precisely deterministic numeric results. </dd> <dt> \_setscope lib::test::RandomDraw_test Member \_internalref classlib_1_1test_1_1RandomDraw__test#afc5266254239335bfad4271a1f08576f "RandomDraw_test::simpleUse" ()</dt><dd> \anchor _test000549 demonstrate a basic usage scenario </dd> <dt> \_setscope lib::test::RandomDraw_test Member \_internalref classlib_1_1test_1_1RandomDraw__test#a786a44b858897b5a67d9fda07d9a1ce2 "RandomDraw_test::verify_adaptMapping" ()</dt><dd> \anchor _test000560 bind custom mapping transformation functions. - use different translation into positional values as input for the actual result value mapping; - use a mapping function with different arguments, which is wired by the appropriate Adapter from the Policy; - moreover, the concrete Policy may tap into the context, which is demonstrated here by accessing a global variable. In practice, this capability allows to accept custom types as data source. </dd> <dt> \_setscope lib::test::RandomDraw_test Member \_internalref classlib_1_1test_1_1RandomDraw__test#a47cac4f2446ed654c00dc27fa5f19ff2 "RandomDraw_test::verify_dynamicChange" ()</dt><dd> \anchor _test000563 change the generation profile dynamically, based on current input; in the example here, the probability is manipulated in each cycle. </dd> <dt> \_setscope lib::test::RandomDraw_test Member \_internalref classlib_1_1test_1_1RandomDraw__test#a9ab44cdbec6ecfb2e196ae7415775e01 "RandomDraw_test::verify_numerics" ()</dt><dd> \anchor _test000553 verify random number transformations. - use a Draw instance with result values <tt>[-2..0..+2]</tt> - values are evenly distributed within limits of quantisation - the probability parameter controls the amount of neutral results - maximum and minimum value settings will be respected - the interval [min..max] is independent from neutral value - probability defines the cases within [min..max] \ neutral - all other cases <tt>q = 1 - p</tt> will yield the neutral value - implausible max/min settings will be corrected automatically </dd> <dt> \_setscope lib::test::RandomDraw_test Member \_internalref classlib_1_1test_1_1RandomDraw__test#a481c1fc74fadb6789503e2e8a5f3dead "RandomDraw_test::verify_policy" ()</dt><dd> \anchor _test000552 verify configuration through policy template - use the default policy, which takes no input values, but rather directly generates a random number; in this case here, input values are ∈ [0 .. 5] - define another policy template, to produce char values, while always requiring two input data values <tt>(char,uint)</tt>; moreover, define the <tt>defaultSrc()</tt> directly to produce the raw mapping values (double) using a custom formula; the resulting RandomDraw instance is now a function with two input arguments, producing char values. </dd> <dt> \_setscope util::test::Rational_test Class \_internalref classutil_1_1test_1_1Rational__test "Rational_test" </dt><dd> \anchor _test000531 cover some aspects of working with fractional numbers. - demonstrate some basics, as provided by <tt>boost::rational</tt> - check for possibly dangerous values - re-quantise a rational number </dd> <dt> \_setscope util::test::Rational_test Member \_internalref classutil_1_1test_1_1Rational__test#a9964265984f43f8774fbc3da76abe930 "Rational_test::demonstrate_basics" ()</dt><dd> \anchor _test000532 demonstrate fundamental properties of rational arithmetics as provided by boost::rational - represent rational fractions precisely - convert to other types and then perform the division - our typedef <tt>Rat = boost::rational\<int64_t\></tt> - our user-defined literal "_r" to simplify notation - string conversion to reveal numerator and denominator - automatic normalisation and reduction - some typical fractional calculation examples. </dd> <dt> \_setscope util::test::Rational_test Member \_internalref classutil_1_1test_1_1Rational__test#a383877e79a736212418aa6aa83753a7f "Rational_test::verify_intLog2" ()</dt><dd> \anchor _test000535 an optimised implementation of integer binary logarithm - basically finds the highest bit which is set - can be used with various integral types - performs better than using the floating-point solution <p></dd> <dt> \_setscope util::test::Rational_test Member \_internalref classutil_1_1test_1_1Rational__test#afea444dbf084763782fd92db25ec3837 "Rational_test::verify_limits" ()</dt><dd> \anchor _test000533 demonstrate the limits and perils of rational fractions - largest and smallest number representable - numeric overflow due to normalisation - predicates to check for possible trouble </dd> <dt> \_setscope util::test::Rational_test Member \_internalref classutil_1_1test_1_1Rational__test#ad752826bc307040631598ceba35fa599 "Rational_test::verify_requant" ()</dt><dd> \anchor _test000537 helper to re-quantise a rational fraction - recast a number in terms of another denominator - this introduces an error of known limited size - and is an option to work around "poisonous" fractions </dd> <dt> \_setscope steam::mobject::session::test::RebuildFixture_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1RebuildFixture__test "RebuildFixture_test" </dt><dd> \anchor _test000220 (re)building the ExplicitPlacement objects from the objects placed into the Session/Model. </dd> <dt> \_setscope util::test::RemoveFromSet_test Member \_internalref classutil_1_1test_1_1RemoveFromSet__test#afd4b22a9141301ef1f2e2c1ab46d9d56 "RemoveFromSet_test::test_remove" (string elems_to_remove)</dt><dd> \anchor _test000512 populate a test set, remove the denoted elements and print the result... <br> </dd> <dt> \_setscope steam::test::RenderSegment_test Class \_internalref classsteam_1_1test_1_1RenderSegment__test "RenderSegment_test" </dt><dd> \anchor _test000254 create a render process from a given segment of the Session. Basically this includes cooperation of all parts of the Lumiera Steam Layer. For a prepared test-Session we invoke the controller to create a render process. This includes building the render pipeline. Finally, we analyse all the created Structures. </dd> <dt> \_setscope lib::test::Result_test Class \_internalref classlib_1_1test_1_1Result__test "Result_test" </dt><dd> \anchor _test000526 Verify an intermediary »Either« type, to embody either a successful result, or document a failure with encountered exception. - when given a value, the Result captures it and is in »left« state - various value types can be picked up by perfect forwarding - when given an exception, the result is in »right« state - option-style <tt>or-else</tt> usage - can invoke arbitrary <em>callable</em> and capture result or exception caught - invocation also works with void functors, and likewise captures failure </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Class \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test "SchedulerActivity_test" </dt><dd> \anchor _test000719 verify behaviour of the Scheduler <em>Activity Language.</em> </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#ae2130f6d27a0f348edbceb785fc245ab "SchedulerActivity_test::dispatchChain" ()</dt><dd> \anchor _test000750 verify the ability to <em>dispatch and perform</em> a chain of activities. - use a directly wired, arbitrary chain - dispatch will activate all Activities - however, when the Gate is configured to be blocked (waiting on prerequisites), then the rest of the chain is not activated. - the dispatch function also handles the notifications; when a notification towards the Gate is dispatched, the Gate is decremented and thereby opened; activation of the rest of the chain is then planned (but not executed synchronously in the same call) </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a268896f09fbab6c1b51b1886caebfb38 "SchedulerActivity_test::scenario_IOJob" ()</dt><dd> \anchor _test000758 usage scenario: Activity graph for an async Job - use a simple \ref #scenario_RenderJob "calculation job term" as follow-up receiver - build an activity Term based on the »Async Load Job« wiring and link it to the receiver - also retrieve the Activity record used as re-entrance point after completing async IO </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a047ae59bb29cfe4de093fe3d82ac1f01 "SchedulerActivity_test::scenario_MetaJob" ()</dt><dd> \anchor _test000762 usage scenario: Activity graph for administrative job - by default, neither Gate, nor start/stop notification used - rather, the <tt>INVOKE</tt> and the argument-<tt>FEED</tt> is posted directly </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a6b197cbe67816407b3e6b3811499379b "SchedulerActivity_test::scenario_Notification" ()</dt><dd> \anchor _test000754 usage scenario: Notification from prerequisite Jobs within time window - build \ref #scenario_RenderJob "similar" »CalculationJob« wiring - configure extended dependency notification capabilities - Case-1 : a Notification decreases the latch, but blocks otherwise - Case-2 : when the primary chain is activated after the Notification, then the tail chain behind the Gate is dispatched </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#ac44a7bc6e60804c0d397374eb93e1680 "SchedulerActivity_test::scenario_RenderJob" ()</dt><dd> \anchor _test000752 usage scenario: Activity graph for a simple render job - build an activity term based on the »CalculationJob« wiring template - dispatch the generated Activity chain and verify sequence of invocations </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "SchedulerActivity_test::simpleUsage" ()</dt><dd> \anchor _test000738 demonstrate simple Activity usage </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a32bb32ce8d15006453148fd21ec98523 "SchedulerActivity_test::termBuilder" ()</dt><dd> \anchor _test000749 verify the Activity term builder - use the builder syntax to define a simple Activity chain - verify the basic outfitting and sane connectivity - verify values reported by the BlockFlow allocator - ensure the defined Job can be properly invoked </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a9a11452437d3ddd67800b5a127ec786e "SchedulerActivity_test::verifyActivity_Gate_block" ()</dt><dd> \anchor _test000745 behaviour of Activity::GATE: the count-down condition determines if activation <em>passes;</em> otherwise the Gate will just return activity::SKIP </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a03e16fbd37c95e4f7588c0e0dc4c5975 "SchedulerActivity_test::verifyActivity_Gate_dead" ()</dt><dd> \anchor _test000744 behaviour of Activity::GATE: the rest of the chain is just skipped in case of deadline violation </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a676faaa3b27a0a89e2e17202c9da47d9 "SchedulerActivity_test::verifyActivity_Gate_notify" ()</dt><dd> \anchor _test000747 behaviour of Activity::GATE: - if it is <em>dispatched</em> as new chain, instead of just <em>activating</em> it of part of an ongoing chain, the Gate will receive a <em>notification</em> - this results in <em>decrementing</em> the prerequisite latch in the Gate - what happens then depends on current state; in this test case the Gate is decremented yet remains closed </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#ad10581cc77628e2de7f2bd5e78c23ff3 "SchedulerActivity_test::verifyActivity_Gate_opened" ()</dt><dd> \anchor _test000748 behaviour of Activity::GATE on notification - Gate configured initially such that it blocks (without violating deadline) - thus a regular activation signals to skip the chain. - when receiving a notification, the latch is decremented - if this causes the Gate to open, the follow-up chain will be activated immediately, but the Gate also locked forever - neither a further activation, nor a further notification has any effect after this point... </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#afdf26ae5ee4f4bb68d33c8e0010c7228 "SchedulerActivity_test::verifyActivity_Gate_pass" ()</dt><dd> \anchor _test000743 behaviour of Activity::GATE: if conditions are met, the activation is just passed, so the executor (in the Scheduler) will just invoke the chain </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a893ff66e0f688022f8e46d7e91a32614 "SchedulerActivity_test::verifyActivity_Invoke" ()</dt><dd> \anchor _test000741 behaviour of Activity::INVOKE - setup requires two FEED-Activities to be chained up as arguments - use the rigged execution context provided by ActivityDetector - can verify this way that the activation leads to JobFunctor invocation </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#a28fff080b8bee2bc772d3b35c9d1f816 "SchedulerActivity_test::verifyActivity_Notify" ()</dt><dd> \anchor _test000742 behaviour of Activity::NOTIFY when <em>activated</em> - notification is dispatched as special message to an indicated target Activity - when activated, a <tt>NOTIFY</tt>-Activity invokes the λ-post <em>with its target,</em> - in the actual setup (Scheduler) this leads to \ref Activity::dispatch "dispatching" of said target Activity - what happens then depends on the target; usually the target is a <tt>GATE</tt> - in first example here, we just use a <tt>TICK</tt>-Activity - for a <tt>GATE</tt> there is special treatment to inject the <em>timing window of the target</em> into the CTX-post invocation; this is essential to handle long notification-chains properly. </dd> <dt> \_setscope vault::gear::test::SchedulerActivity_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerActivity__test#acfc83d8c9f51fa50508c28ae8c9e705f "SchedulerActivity_test::verifyActivity_Post" ()</dt><dd> \anchor _test000740 behaviour of Activity::POST - invoke the λ-post to dispatch the chain through the queue - the chain to be executed is given as <tt>next</tt> - time window for scheduling as data field - the start time from this window becomes the <tt>when</tt> parameter - the <tt>now</tt> parameter from the activation is thus ignored </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Class \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test "SchedulerCommutator_test" </dt><dd> \anchor _test000696 Scheduler Layer-2: coordination of Activity execution. </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test#a2c36f803c25e76304a385a5e7da34915 "SchedulerCommutator_test::demonstrateSimpleUsage" ()</dt><dd> \anchor _test000709 demonstrate a simple usage scenario </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test#aa792fef3b75e88b147264bd5cf055e88 "SchedulerCommutator_test::integratedWorkCycle" ()</dt><dd> \anchor _test000729 step-wise perform the typical sequence of planning and worker activation - use the Render-Job scenario from SchedulerActivity_test::scenario_RenderJob() - use similar instrumentation to trace Activities - specifically rig the diagnostic executionCtx to drop the GroomingToken at λ-work - Step-1 : schedule the Activity-term - Step-2 : later search for work, retrieve and dispatch the term - verify the expected sequence of Activities actually occurred </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test#a3f430ea9e0fd0008072274fa846a0502 "SchedulerCommutator_test::torture_GroomingToken" ()</dt><dd> \anchor _test000715 ensure the GroomingToken mechanism indeed creates mutual exclusion to protected against concurrent corruption. </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test#a866cc8b1853ca305ef8df68ea1351445 "SchedulerCommutator_test::verify_dispatch" ()</dt><dd> \anchor _test000726 verify basic functionality to dequeue and dispatch entries. </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test#a223c81ea341ec2f691ff9357f056e12d "SchedulerCommutator_test::verify_findWork" ()</dt><dd> \anchor _test000718 verify logic of queue updates and work prioritisation. </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test#a9524a649e1f994620cae8c8036450078 "SchedulerCommutator_test::verify_GroomingGuard" ()</dt><dd> \anchor _test000713 verify extended logic to protect a scope - if the thread already holds the grooming token, nothing happens - otherwise, it is acquired (blocking) and dropped on exit </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test#a134414d8361e69fe2fc6561c20d221e6 "SchedulerCommutator_test::verify_GroomingToken" ()</dt><dd> \anchor _test000711 verify logic to control concurrent execution </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test#a80b36876a845d0abdbb396552c7f8c4f "SchedulerCommutator_test::verify_postChain" ()</dt><dd> \anchor _test000723 verify entrance point for performing an Activity chain. </dd> <dt> \_setscope vault::gear::test::SchedulerCommutator_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerCommutator__test#afea31f21cb01521a62ae204d28d5a2da "SchedulerCommutator_test::verify_Significance" ()</dt><dd> \anchor _test000721 verify that obsoleted or rejected entries are dropped transparently - add entries providing extra information regarding significance - verify that missing the deadline is detected - entries past deadline will be dropped when pulling for work - entries tagged with an ManifestationID can be disabled and will be automatically disposed. - an entry marked as <em>compulsory</em> will block that process when missing it's deadline </dd> <dt> \_setscope vault::gear::test::SchedulerInterface_test Class \_internalref classvault_1_1gear_1_1test_1_1SchedulerInterface__test "SchedulerInterface_test" </dt><dd> \anchor _test000168 verify and demonstrate the organisation of the high-level interface for defining jobs to be invoked by the scheduler.</dd> <dt> \_setscope vault::gear::test::SchedulerInterface_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerInterface__test#a6a8e7aba0663b0140859aa1e27b0ee8a "SchedulerInterface_test::demonstrate_nested_job_specification" (SchedulerFrontend &scheduler)</dt><dd> \anchor _test000170 demonstrate how a tree of dependent render jobs can be handed over to the scheduler within a single "transaction"</dd> <dt> \_setscope vault::gear::test::SchedulerInvocation_test Class \_internalref classvault_1_1gear_1_1test_1_1SchedulerInvocation__test "SchedulerInvocation_test" </dt><dd> \anchor _test000692 Scheduler Layer-1: queue processing and invocation by priority. </dd> <dt> \_setscope vault::gear::test::SchedulerInvocation_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerInvocation__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "SchedulerInvocation_test::simpleUsage" ()</dt><dd> \anchor _test000695 demonstrate a simple usage scenario of data passing </dd> <dt> \_setscope vault::gear::test::SchedulerInvocation_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerInvocation__test#a7bad8802629fffdbda6e72d11608e585 "SchedulerInvocation_test::verify_isDue" ()</dt><dd> \anchor _test000702 the entry appearing at head <em>is due</em> when its time is at or before current time. </dd> <dt> \_setscope vault::gear::test::SchedulerInvocation_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerInvocation__test#ab3d54129290b1290159f8d595b19e1f0 "SchedulerInvocation_test::verify_Queuing" ()</dt><dd> \anchor _test000697 verify records are passed properly through the queues - add multiple elements to the instruct queue - after <tt>feedPrioritisation</tt> these appear as output </dd> <dt> \_setscope vault::gear::test::SchedulerInvocation_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerInvocation__test#afea31f21cb01521a62ae204d28d5a2da "SchedulerInvocation_test::verify_Significance" ()</dt><dd> \anchor _test000704 verify extended classification data and information functions at scheduler head - add entries providing extra information regarding significance - verify that missing the deadline is detected - entries past deadline are marked <em>outdated</em> (will be dropped by Layer-2) - entries can be tagged with an ManifestationID, allowing to enable or disable visibility for a »family« of schedule entries - use the flag for <em>compulsory</em> entries, allowing to detect a fatal <em>jammed</em> situation where the head entry is out of time, while marked mandatory to process. </dd> <dt> \_setscope vault::gear::test::SchedulerInvocation_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerInvocation__test#aa88f86fbc644cd9a6374b3cf45ed1d76 "SchedulerInvocation_test::verify_stability" ()</dt><dd> \anchor _test000701 sort order is not necessarily stable if using identical time specs on entrance </dd> <dt> \_setscope vault::gear::test::SchedulerInvocation_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerInvocation__test#ad8d1309492adb405b48e2bee9947db58 "SchedulerInvocation_test::verify_WaterLevel" ()</dt><dd> \anchor _test000699 verify the given time point is utilised for prioritisation - order at output is determined by the time spec - even later added elements can push back previously visible elements at head </dd> <dt> \_setscope vault::gear::test::SchedulerLoadControl_test Class \_internalref classvault_1_1gear_1_1test_1_1SchedulerLoadControl__test "SchedulerLoadControl_test" </dt><dd> \anchor _test000746 verify behaviour patterns relevant for Scheduler load control. </dd> <dt> \_setscope vault::gear::test::SchedulerLoadControl_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerLoadControl__test#a05b2100c8ce97fcb6627be6830c8f212 "SchedulerLoadControl_test::classifyCapacity" ()</dt><dd> \anchor _test000796 verify allocation decision for free capacity - due and overdue Activities are prioritised - keep spinning when next Activity to schedule is very close - otherwise, priority is to tend for the next known Activity - beyond that, free capacity is redistributed according to horizon - for incoming free capacity there is a preference to keep it sleeping, to allow for disposing of excess capacity after extended sleep time </dd> <dt> \_setscope vault::gear::test::SchedulerLoadControl_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerLoadControl__test#aa9a9f4668b55fa3c5632defc14d32586 "SchedulerLoadControl_test::classifyHorizon" ()</dt><dd> \anchor _test000793 verify classification of time horizon for scheduling. - if the next planned Activity lies beyond the SLEEP_HORIZON, then the current thread can be considered part of the <em>idle capacity</em> - in a similar way, WORK_HORIZON delineates the zone of repeated incoming Activities from the zone considered part of current active operation - Activities within the NOW_HORIZON can be awaited by yield-spinning - and any event from current into the past will be scheduled right away </dd> <dt> \_setscope vault::gear::test::SchedulerLoadControl_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerLoadControl__test#a897458230ba68e6ed00547dd505822a1 "SchedulerLoadControl_test::indicateAverageLoad" ()</dt><dd> \anchor _test000798 verify fusion of sampled observations to guess average scheduler load - use a rigged wiring of the load controller to verify calculation based on known values of current <em>concurrency</em> and <em>schedule pressure</em> - scheduling on average 200µs behind nominal schedule is considered the regular balanced state and thus defined as 100% schedule pressure - if congestion builds up to 1/10 of WORK_HORIZON, 200% overload is indicated - on the other hand, if workers appear on average 200µs before the typical balanced state, the resulting headroom is defined to constitute 50% pressure - the pressure value is multiplied with the degree of concurrency - the pressure is sampled from the lag (distance of current time to the next activity to schedule), which is observed whenever a worker calls in to retrieve more work. These calls happen randomly. </dd> <dt> \_setscope vault::gear::test::SchedulerLoadControl_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerLoadControl__test#ab2d26c9b9d93ac9b18fbed3a10b4c628 "SchedulerLoadControl_test::scatteredReCheck" ()</dt><dd> \anchor _test000797 verify the re-distribution of free capacity by targeted delay - the implementation uses the next-tended start time as anchor point - capacity classes which should be scheduled right away will actually never call this function — yet still a sensible value is returned here - capacity targeted at current work will be redistributed behind the next-tended time, and within a time span corresponding to the work realm - capacity targeted towards more future work will be distributed within the horizon defined by the sleep-cycle - especially for capacity sent to sleep, this redistribution works without being shifted behind the next-tended time, since in that case the goal is to produce a random distribution of the »sleeper« callbacks. - the offset is indeed randomised, using current time for randomisation </dd> <dt> \_setscope vault::gear::test::SchedulerLoadControl_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerLoadControl__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "SchedulerLoadControl_test::simpleUsage" ()</dt><dd> \anchor _test000753 TODO demonstrate a simple usage scenario <p></dd> <dt> \_setscope vault::gear::test::SchedulerLoadControl_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerLoadControl__test#a93a5899c0e068ffbce5b69d8ebba86a1 "SchedulerLoadControl_test::tendNextActivity" ()</dt><dd> \anchor _test000794 verify the mark for <em>tended next head</em> Activity. </dd> <dt> \_setscope vault::gear::test::SchedulerService_test Class \_internalref classvault_1_1gear_1_1test_1_1SchedulerService__test "SchedulerService_test" </dt><dd> \anchor _test000786 Scheduler component integration test: use the service API for state control and to add Jobs and watch processing patterns. </dd> <dt> \_setscope vault::gear::test::SchedulerService_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerService__test#a2386bfa3f4d0bffe4fdfd26c4b7b5fa7 "SchedulerService_test::invokeWorkFunction" ()</dt><dd> \anchor _test000791 verify visible behaviour of the \ref Scheduler::doWork "work-pulling function" - use a rigged Activity probe to capture the schedule time on invocation - additionally perform a timing measurement for invoking the work-function - invoking the Activity probe itself costs 50...150µs, Scheduler internals < 50µs - this implies we can show timing-delay effects in the millisecond range - demonstrated behaviour + an Activity already due will be dispatched immediately by post() + an Activity due at the point when invoking the work-function is dispatched + while queue is empty, the work-function returns immediately, indicating sleep + invoking the work-function, when there is still some time span up to the next planned Activity, will cause a targeted sleep, returning shortly after the next schedule. Entering then again will cause dispatch of that activity. + if the work-function dispatches an Activity while the next entry is planned for some time ahead, the work-function will likewise go into a targeted sleep and only return at or shortly after that next planned time entry + after dispatching an Activity in a situation with no follow-up work, the work-function inserts a targeted sleep of random duration, to re-shuffle the rhythm of sleep cycles + when the next planned Activity was already »tended for« (by placing another worker into a targeted sleep), further workers entering the work-function will be re-targeted by a random sleep to focus capacity into a time zone behind the next entry. </dd> <dt> \_setscope vault::gear::test::SchedulerService_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerService__test#a601443c1dd272b62dbd7850e977654c8 "SchedulerService_test::processSchedule" ()</dt><dd> \anchor _test000795 schedule and process a complete work load - use a complex computation structure generated by TestChainLoad - dispatch 64 jobs, each depending more or less on its predecessors - processing proceeds first in two parallel chains, then joins and forks again into a massive overload towards the end. - each <em>level of jobs</em> is scheduled 1ms apart - some jobs use a <em>computation weight</em> ranging form 500µs to 1.5ms - at the end, both a single threaded computation and the computation processed by the scheduler must yield the same result hash, which is computed for each job by combining its predecessor hashes. </dd> <dt> \_setscope vault::gear::test::SchedulerService_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerService__test#a0df8d50b63b12fd69bb668f64f011a69 "SchedulerService_test::scheduleRenderJob" ()</dt><dd> \anchor _test000792 Schedule a render job through the high-level Job-builder API. - use the mock Job-Functor provided by the ActivityDetector - manipulate the WorkForce to prevent it from scaling up - this allows us to investigate the queue entry created through the public regular API for scheduling Render Jobs - after that, the test manually invokes the work-pulling function and verifies the mock Job-Functor has been invoked - note however that this time a complete Activity chain was created, including a Gate and all state transitions, since we used the high-level API of the SchedulerService </dd> <dt> \_setscope vault::gear::test::SchedulerService_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerService__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "SchedulerService_test::simpleUsage" ()</dt><dd> \anchor _test000787 demonstrate a simple usage scenario </dd> <dt> \_setscope vault::gear::test::SchedulerService_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerService__test#a9c9f55455a278d0823a11a95dc38f502 "SchedulerService_test::verify_LoadFactor" ()</dt><dd> \anchor _test000789 verify the scheduler processes scheduled events, indicates current load and winds down automatically when falling empty. - schedule short bursts of single FEED-Activities - these actually do nothing and can be processed typically < 5µs - placing them spaced by 1µs, so the scheduler will build up congestion - since this Activity does not drop the »grooming-token«, actually only a single worker will process all Activities in a single peak - after the peak is done, the load indicator will drop again - when reaching the scheduler »tick«, the queue should be empty and the scheduler will stop active processing - the main thread (this test) polls every 50µs to observe the load - after 2 seconds of idle-sleeping, the WorkForce is disengaged - verify the expected load pattern </dd> <dt> \_setscope vault::gear::test::SchedulerService_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerService__test#ae8a614995c4b94c43a1fbc38718ae14c "SchedulerService_test::verify_StartStop" ()</dt><dd> \anchor _test000788 get the scheduler into running state </dd> <dt> \_setscope vault::gear::test::SchedulerStress_test Class \_internalref classvault_1_1gear_1_1test_1_1SchedulerStress__test "SchedulerStress_test" </dt><dd> \anchor _test000790 Investigate and verify non-functional characteristics of the Scheduler. </dd> <dt> \_setscope vault::gear::test::SchedulerStress_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerStress__test#a55b94222c8f421edb02596469e3a5b50 "SchedulerStress_test::investigateWorkProcessing" ()</dt><dd> \anchor _test000804 use an extended load pattern to emulate a typical high work load - using 4-step linear chains, interleaved such that each level holds 4 nodes - the structure overall spans out to 66 levels, leading to ∅3.88 nodes/level - load on each node is 5ms, so the overall run would take ~330ms back to back - this structure is first performed on the bench::BreakingPoint - in the second part, a similar structure with 4-times the size is performed as a single run, but this time with planning and execution interleaved. - this demonstrates the Scheduler can sustain stable high load performance </dd> <dt> \_setscope vault::gear::test::SchedulerStress_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerStress__test#a87bbde594fc1ea31f903b7e992fa0d14 "SchedulerStress_test::search_breaking_point" ()</dt><dd> \anchor _test000802 determine the breaking point towards scheduler overload - use the integrated StressRig - demonstrate how parameters can be tweaked - perform a run, leading to a binary search for the breaking point </dd> <dt> \_setscope vault::gear::test::SchedulerStress_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerStress__test#a52fa985b360732a4d6c16ea0badb63c7 "SchedulerStress_test::setup_systematicSchedule" ()</dt><dd> \anchor _test000800 build a scheme to adapt the schedule to expected runtime. - as in many other tests, use the massively forking load pattern - demonstrate how TestChainLoad computes an idealised level expense - verify how schedule times are derived from this expense sequence </dd> <dt> \_setscope vault::gear::test::SchedulerStress_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerStress__test#a9dfc8c60f76fd07c13cd1ca8c3bebe3b "SchedulerStress_test::smokeTest" ()</dt><dd> \anchor _test000799 demonstrate test setup for sustained operation under load </dd> <dt> \_setscope vault::gear::test::SchedulerStress_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerStress__test#adcb5d128df4b32d811373034dc6bae58 "SchedulerStress_test::verify_instrumentation" ()</dt><dd> \anchor _test000801 verify capability for instrumentation of job invocations </dd> <dt> \_setscope vault::gear::test::SchedulerStress_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerStress__test#af1c95f18d47a22c4d40bfbe1ffa3b355 "SchedulerStress_test::watch_expenseFunction" ()</dt><dd> \anchor _test000803 Investigate the relation of run time (expense) to input length. - again use the integrated StressRig - this time overload the scheduler with a peak of uncorrelated jobs and watch the time and load required to work through this challenge - conduct a series of runs with random number of jobs (within bounds) - collect the observed data (as CSV), calculate a <strong>linear regression model</strong> - optionally generate a <strong>Gnuplot</strong> script for visualisation </dd> <dt> \_setscope vault::gear::test::SchedulerUsage_test Class \_internalref classvault_1_1gear_1_1test_1_1SchedulerUsage__test "SchedulerUsage_test" </dt><dd> \anchor _test000728 Ensure expected Scheduler functionality in standard usage situations. </dd> <dt> \_setscope vault::gear::test::SchedulerUsage_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerUsage__test#ae9db69bd8fe7c750a57808016a211cb3 "SchedulerUsage_test::setupLalup" ()</dt><dd> \anchor _test000733 TODO </dd> <dt> \_setscope vault::gear::test::SchedulerUsage_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerUsage__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "SchedulerUsage_test::simpleUsage" ()</dt><dd> \anchor _test000731 TODO demonstrate a simple usage scenario </dd> <dt> \_setscope vault::gear::test::SchedulerUsage_test Member \_internalref classvault_1_1gear_1_1test_1_1SchedulerUsage__test#a477b004f7f838671c6c2288dc173d6eb "SchedulerUsage_test::walkingDeadline" ()</dt><dd> \anchor _test000732 TODO </dd> <dt> \_setscope lib::test::ScopedCollection_test Class \_internalref classlib_1_1test_1_1ScopedCollection__test "ScopedCollection_test" </dt><dd> \anchor _test000534 ScopedCollection manages a fixed set of objects, but these child objects are noncopyable, may be polymorphic, an can be created either all at once or chunk wise. The API is similar to a vector and allows for element access and iteration. </dd> <dt> \_setscope lib::test::ScopedCollection_test Member \_internalref classlib_1_1test_1_1ScopedCollection__test#aa78e9c4ab773eb727f60ba1b56028185 "ScopedCollection_test::building_RAII_Style" ()</dt><dd> \anchor _test000541 using the ScopedCollection according to the RAII pattern. For this usage style, the collection is filled right away, during construction. If anything goes wrong, the whole collection is cleared and invalidated. Consequently there is no tangible "lifecycle" at the usage site. Either the collection is fully usable, or not at all. This requires the client to provide a functor (callback) to define the actual objects to be created within the ScopedCollection. These may as well be subclasses of the base type I, provided the general element storage size #siz was chosen sufficiently large to hold those subclass instances.</dd> <dt> \_setscope lib::test::ScopedCollection_test Member \_internalref classlib_1_1test_1_1ScopedCollection__test#a5e0839f00cfcf3fbdba42104652f06c5 "ScopedCollection_test::building_StackStyle" ()</dt><dd> \anchor _test000540 using the ScopedCollection to hold a variable and possibly increasing number of elements, within the fixed limits of the maximum capacity defined by the ctor parameter. Any new elements will be created behind the already existing objects. In case of failure while creating an element, only this element gets destroyed, the rest of the container remains intact. </dd> <dt> \_setscope lib::test::ScopedCollection_test Member \_internalref classlib_1_1test_1_1ScopedCollection__test#a2b9f877db427fc928777af1313c674a0 "ScopedCollection_test::verify_defaultPopulator" ()</dt><dd> \anchor _test000543 for using ScopedCollection in RAII style, several pre-defined "populators" are provided. The most obvious one being just to fill the collection with default constructed objects. </dd> <dt> \_setscope lib::test::ScopedCollection_test Member \_internalref classlib_1_1test_1_1ScopedCollection__test#a2e622d7c748fae6a1f65d75b72773f58 "ScopedCollection_test::verify_embeddedCollection" ()</dt><dd> \anchor _test000545 simulate the typical situation of a manager owning some embedded components. Here, our ManagerDemo instance owns a collection of numbers 50..1. They are created right while initialising the manager, and this initialisation is done by invoking a member function of the manager </dd> <dt> \_setscope lib::test::ScopedPtrVect_test Class \_internalref classlib_1_1test_1_1ScopedPtrVect__test "ScopedPtrVect_test" </dt><dd> \anchor _test000529 ScopedPtrVect manages the lifecycle of a number of objects. The API is similar to a vector and allows for element access and iteration. Individual elements can be detached and thus removed from the responsibility of the container. </dd> <dt> \_setscope steam::mobject::session::test::ScopePath_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1ScopePath__test "ScopePath_test" </dt><dd> \anchor _test000241 properties and behaviour of the path of nested scopes. Using a pseudo-session (actually just a PlacementIndex), this test creates some nested scopes, builds scope paths and executes various comparisons navigation moves on them. Especially detection of invalid scopes and paths and the special handling of empty and root paths is covered. </dd> <dt> \_setscope steam::mobject::session::test::ScopePath_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1ScopePath__test#a06d42b96c34a670d917218f54ca05615 "ScopePath_test::check_RefcountProtection" (PMO &refPlacement)</dt><dd> \anchor _test000243 the embedded refcount is handled sensibly when it comes to copying. (This refcount is used by QueryFocusStack) </dd> <dt> \_setscope steam::mobject::session::test::ScopePath_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1ScopePath__test#a4835e8c42257c9111756642e47b3653d "ScopePath_test::navigate" (const ScopePath refPath, PPIdx index)</dt><dd> \anchor _test000244 modify a path by \em navigating it. - move one step above the current leaf - move up to the root element - move back to the parent and verify we're just above the leaf - attach a new sibling node and move the path down to there - extract the common prefix, which should again point to the parent - find a placement in a completely separate branch (only sharing the root node). Navigate to there and verify root is the common prefix. </dd> <dt> \_setscope steam::mobject::session::test::ScopeQuery_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1ScopeQuery__test "ScopeQuery_test" </dt><dd> \anchor _test000231 how to discover contents or location of a container-like part of the high-level model. As this container-like object is just a concept and actually implemented by the PlacementIndex, this means querying the index for elements registered with a given scope or finding the enclosing scopes. The discovered elements will be filtered by a runtime type check.</dd> <dt> \_setscope lib::test::SearchPathSplitter_test Class \_internalref classlib_1_1test_1_1SearchPathSplitter__test "SearchPathSplitter_test" </dt><dd> \anchor _test000527 verify splitting a search path specification and retrieving the components by iteration. Embedded \c $ORIGIN tokens get resolved to the absolute path of this executable. </dd> <dt> \_setscope steam::fixture::test::SegmentationIntegration_test Class \_internalref classsteam_1_1fixture_1_1test_1_1SegmentationIntegration__test "SegmentationIntegration_test" </dt><dd> \anchor _test000197 Properties and behaviour of a complete Segmentation data structure. - access segments keyed by nominal time - determine the index-Nr of a ModelPort - transactional remoulding of the Segmentation - retrieve effective changes after remoulding - integration with AllocationCluster memory managment <p></dd> <dt> \_setscope steam::control::test::SessionCommandFunction_test Class \_internalref classsteam_1_1control_1_1test_1_1SessionCommandFunction__test "SessionCommandFunction_test" </dt><dd> \anchor _test000115 verify integrated functionality of command dispatch through the SessionCommand facade. - operate lifecycle of the supporting components, similar to activating the »session subsystem« - generate command messages similar to what is received from the UI-Bus - us the handler mechanism from stage::ctrl::CoreService to talk to the facade - have a specially rigged command function to observe invocation - wait for the session loop thread to dispatch this command - verify that commands are really executed single-threaded</dd> <dt> \_setscope steam::control::test::SessionCommandFunction_test Member \_internalref classsteam_1_1control_1_1test_1_1SessionCommandFunction__test#a835f0db286d3d31b25cd7b53dd4d38a1 "SessionCommandFunction_test::perform_massivelyParallel" (Arg args_for_stresstest)</dt><dd> \anchor _test000125 massively multithreaded <em>torture test</em> to verify that commands are properly enqueued and executed one by one - create several threads to send random command messages - verify that, after executing all commands, the internal state variable reflects the result of a proper sequential calculation and summation </dd> <dt> \_setscope steam::control::test::SessionCommandFunction_test Member \_internalref classsteam_1_1control_1_1test_1_1SessionCommandFunction__test#ad30bd813c1f78d7b1a1b137cc300e9f3 "SessionCommandFunction_test::perform_messageInvocation" ()</dt><dd> \anchor _test000124 invoke a command in the same way as CoreService does when handling command messages from the UI-Bus - build a command message, similar to what the \ref stage::model::Tangible "generic UI element" does - use the contents of this message at the SessionCommand facade, similar to what CoreService does </dd> <dt> \_setscope steam::control::test::SessionCommandFunction_test Member \_internalref classsteam_1_1control_1_1test_1_1SessionCommandFunction__test#a0a714ac08295a97f36d2cd59ac227d26 "SessionCommandFunction_test::perform_simpleInvocation" ()</dt><dd> \anchor _test000123 demonstrate a simple direct invocation </dd> <dt> \_setscope steam::control::test::SessionCommandFunction_test Member \_internalref classsteam_1_1control_1_1test_1_1SessionCommandFunction__test#a0ab21e7e75d0c1e3875f90e8c3d67dc1 "SessionCommandFunction_test::startDispatcher" ()</dt><dd> \anchor _test000121 start the session loop thread, similar to what the »session subsystem« does </dd> <dt> \_setscope steam::control::test::SessionCommandFunction_test Member \_internalref classsteam_1_1control_1_1test_1_1SessionCommandFunction__test#a6ff5b0233a620e38042c14ae8e1efe5d "SessionCommandFunction_test::stopDispatcher" ()</dt><dd> \anchor _test000122 verify the »session loop thread« has finished properly </dd> <dt> \_setscope steam::mobject::session::test::SessionElementQuery_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionElementQuery__test "SessionElementQuery_test" </dt><dd> \anchor _test000232 cover the part of the session API allowing to retrieve specific elements by query. - This test first picks an object from the test session, where the filter predicate utilises the specific MObject subclass (here DummyMO). - Then re-fetches the same object using a different filter (based on the specific random int-ID). - Next the element is removed from the test session to verify the "not found" result - finally we re-attach another placement of the same underlying MObject instance at a different location in the test session and verify we can again pick this element with the specific query.</dd> <dt> \_setscope steam::mobject::session::test::SessionElementTracker_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionElementTracker__test "SessionElementTracker_test" </dt><dd> \anchor _test000242 verify the tracking of special session/model elements, to be exposed through an self-contained interface module on the session API. The basic element-tracking mechanism uses a simple (vector based) registry, which stores a smart-ptr. Thus the elements need to be created by a factory. In case of Timeline / Sequence, the asset::StructFactory will take on this role. The integration test creates a Timeline (facade asset) and verifies proper registration and deregistration.</dd> <dt> \_setscope steam::mobject::session::test::SessionElementTracker_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionElementTracker__test#acb9cbac8e1bb2e24f22047e353e3b8f1 "SessionElementTracker_test::verify_cleanup" (PTimeline const &aTimeline_in_session)</dt><dd> \anchor _test000245 ensure the asset cleanup doesn't interfere with session shutdown </dd> <dt> \_setscope steam::mobject::session::test::SessionManager_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionManager__test#a127586b4e8e9c3ce927ec134fd0d03b4 "SessionManager_test::clearSession" ()</dt><dd> \anchor _test000235 clear current session contents without resetting global session config. <p></dd> <dt> \_setscope steam::mobject::session::test::SessionManager_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionManager__test#ad1f8516303f3e94b34a539d3784f70f6 "SessionManager_test::getCurrentSession" ()</dt><dd> \anchor _test000234 accessing the current (global) session </dd> <dt> \_setscope steam::mobject::session::test::SessionManager_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionManager__test#a6b8790f04241c547e2fcdcd5934b526c "SessionManager_test::loadMockSession" ()</dt><dd> \anchor _test000237 use a mock session serialiser to load a preconfigured test session. Verify objects are wired correctly. <p></dd> <dt> \_setscope steam::mobject::session::test::SessionManager_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionManager__test#ad8e7d533b58a18865d2c40b1b940d083 "SessionManager_test::loadSession" (const string &src)</dt><dd> \anchor _test000238 load serialised session using the real session serialiser implementation. </dd> <dt> \_setscope steam::mobject::session::test::SessionManager_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionManager__test#a6ea4c75f4497fc3f468e9669a1194dab "SessionManager_test::resetSession" ()</dt><dd> \anchor _test000236 reset global session config and start with a pristine default session. <p></dd> <dt> \_setscope steam::mobject::session::test::SessionManager_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionManager__test#a9b89ae22c332ed294a890f5f5359a1b0 "SessionManager_test::saveSession" (string &dest)</dt><dd> \anchor _test000240 serialise (save) the current session </dd> <dt> \_setscope steam::mobject::session::test::SessionModifyParts_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionModifyParts__test "SessionModifyParts_test" </dt><dd> \anchor _test000239 perform the most important structural modifications on a session and verify they're carried out properly. - attaching forks ("tracks") - adding clips</dd> <dt> \_setscope steam::mobject::session::test::SessionServiceAccess_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionServiceAccess__test#a9279cce61ff19266fb4fc6d31bb989f5 "SessionServiceAccess_test::access_defaultSession" ()</dt><dd> \anchor _test000248 accessing an non-existing session causes creation of a new TSessionImpl instance. After that, the public API function gets invoked. </dd> <dt> \_setscope steam::mobject::session::test::SessionServiceAccess_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionServiceAccess__test#a62f6aab9ffe5c0e16199ca0f8acaeb2e "SessionServiceAccess_test::invoke_implServices" ()</dt><dd> \anchor _test000250 accessing implementation-level APIs </dd> <dt> \_setscope steam::mobject::session::test::SessionServiceAccess_test Member \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionServiceAccess__test#a75d91b5a0c664634fa4117ce4726619f "SessionServiceAccess_test::make_newSession" ()</dt><dd> \anchor _test000249 invoking the management API to close the session. The next public API invocation will create a new TSessionImpl instance. </dd> <dt> \_setscope steam::mobject::session::test::SessionStructure_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1SessionStructure__test "SessionStructure_test" </dt><dd> \anchor _test000246 access the current session and verify the correct structure of the most important components: The session contains an Sequence, we can get at the Fixture, we have at least one Fork and the corresponding Fork-ID (asset) can be retrieved. <p></dd> <dt> \_setscope lib::test::SeveralBuilder_test Class \_internalref classlib_1_1test_1_1SeveralBuilder__test "SeveralBuilder_test" </dt><dd> \anchor _test000572 use lib::Several to establish small collections of elements, possibly with sub-classing and controlled allocation. - the container is populated through a separate builder - the number of elements is flexible during population - the actual container allows random-access via base interface </dd> <dt> \_setscope lib::test::SeveralBuilder_test Member \_internalref classlib_1_1test_1_1SeveralBuilder__test#af3c16eb73c3b88e165fbb9cfe3cb9e97 "SeveralBuilder_test::check_Builder" ()</dt><dd> \anchor _test000586 various ways to build an populate the container - with a defined interface type \a I, instances of arbitrary subclasses can be added, assuming there is sufficient pre-allocated buffer space; all these subclass instances are accessed through the common interface. - yet the added elements can also be totally unrelated, in which case an <em>unchecked wild cast</em> will happen on access; while certainly dangerous, this behaviour allows for special low-level data layout tricks. - the results from an iterator can be used to populate by copy </dd> <dt> \_setscope lib::test::SeveralBuilder_test Member \_internalref classlib_1_1test_1_1SeveralBuilder__test#ae3df64900a6e073ae272ed08787d3ac7 "SeveralBuilder_test::check_CustomAllocator" ()</dt><dd> \anchor _test000591 demonstrate integration with a custom allocator - use the TrackingAllocator to verify balanced handling of the underlying raw memory allocations - use an AllocationCluster instance to manage the storage </dd> <dt> \_setscope lib::test::SeveralBuilder_test Member \_internalref classlib_1_1test_1_1SeveralBuilder__test#aec3cc31e740a7567d45662e8d703335d "SeveralBuilder_test::check_ElementStorage" ()</dt><dd> \anchor _test000590 verify correct placement of instances within storage - use a low-level pointer calculation for this test to draw conclusions regarding the spacing of objects accepted into the lib::Several-container - demonstrate the simple data elements are packed efficiently - verify that special alignment requirements are observed - emplace several ''non copyable objects'' and then move-assign the lib::Several container instance; this demonstrates that the latter is just a access front-end, while the data elements reside in a fixed storage buffer </dd> <dt> \_setscope lib::test::SeveralBuilder_test Member \_internalref classlib_1_1test_1_1SeveralBuilder__test#a7f6f3ffa4daf39d0582fb2af5f1fdb4a "SeveralBuilder_test::check_ErrorHandling" ()</dt><dd> \anchor _test000587 proper handling of exceptions during population - when the container is filled with arbitrary subclasses of a base interface with virtual destructor, the first element is used to accommodate the storage spread; larger elements or elements of a completely different type can not be accommodated and the container can not grow beyond the initially allocated reserve (defined to be 10 elements by default). - when the container is defined to hold elements of a specific fixed subclass, it can be filled with default-constructed instances, and the initial allocation can be expanded by move-relocation. Yet totally unrelated elements can not be accepted (due to unknown destructor); and when accepting another unspecific subclass instance, the ability to grow by move-relocation is lost. - a container defined for trivial data elements (trivially movable and destructible) can grow dynamically just by moving data around with <tt>memmove</tt>. Only in this case the <em>element spread</em> can easily be adjusted after the fact, since a trivial element can be relocated to accommodate an increased spread. It is possible to add various different data elements into such a container, yet all will be accessed through an unchecked hard cast to the base element (<tt>uint8_t</tt> in this case). However, once we add a <em>non-copyable</em> element, this capability for arbitrarily moving elements around is lost — we can not adapt the spread any more and the container can no longer grow dynamically. - all these failure conditions are handled properly, including exceptions emanating from element constructors; the container remains sane and no memory is leaked. </dd> <dt> \_setscope lib::test::SeveralBuilder_test Member \_internalref classlib_1_1test_1_1SeveralBuilder__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "SeveralBuilder_test::simpleUsage" ()</dt><dd> \anchor _test000583 demonstrate basic behaviour </dd> <dt> \_setscope lib::test::Singleton_test Class \_internalref classlib_1_1test_1_1Singleton__test "Singleton_test" </dt><dd> \anchor _test000009 implement a Singleton class using our Singleton Template. Expected results: single instance created in static memory, single instance properly destroyed, no memory leaks. </dd> <dt> \_setscope lib::test::SingletonSubclass_test Class \_internalref classlib_1_1test_1_1SingletonSubclass__test "SingletonSubclass_test" </dt><dd> \anchor _test000008 specific dependency-injection setup, to create a singleton subclass (implementation class) instance, without coupling the caller to the concrete type. </dd> <dt> \_setscope lib::test::SingletonTestMock_test Class \_internalref classlib_1_1test_1_1SingletonTestMock__test "SingletonTestMock_test" </dt><dd> \anchor _test000019 inject a Mock object into the Singleton Factory, to be returned and used in place of the original object. This test covers the full usage cycle: first access the Client Object, then replace it by two different mocks, and finally restore the original Client Object. </dd> <dt> \_setscope vault::gear::test::SpecialJobFun_test Class \_internalref classvault_1_1gear_1_1test_1_1SpecialJobFun__test "SpecialJobFun_test" </dt><dd> \anchor _test000751 verify a self-managing one-time render job functor. </dd> <dt> \_setscope vault::gear::test::SpecialJobFun_test Member \_internalref classvault_1_1gear_1_1test_1_1SpecialJobFun__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "SpecialJobFun_test::simpleUsage" ()</dt><dd> \anchor _test000756 demonstrate simple usage by λ-binding <p></dd> <dt> \_setscope vault::gear::test::SpecialJobFun_test Member \_internalref classvault_1_1gear_1_1test_1_1SpecialJobFun__test#a5b58042acb8d046dd9142a0b2c7056fa "SpecialJobFun_test::verifyLifecycle" ()</dt><dd> \anchor _test000759 verify storage and lifecycle management - use a instance-tracking marker implanted into the functor - verify no memory is leaked and the tracker instance is deallocated - verify the single tracker instance indeed lives in the JobFunctor - investigate the usage count of the front-end handle - verify the front-end can be copied without impact on the JobFunctor - verify the heap allocated functor keeps itself alive even when the front-end handle is already gone. - verify the functor de-allocates itself after latst invocation <p></dd> <dt> \_setscope lib::test::SplitSplice_test Class \_internalref classlib_1_1test_1_1SplitSplice__test "SplitSplice_test" </dt><dd> \anchor _test000564 verify proper working of a generic procedure to splice an interval into a complete segmentation of an ordered axis into seamless intervals. - demonstrate how to setup the invocation with custom data types - systematic coverage of all possible arrangements of intervals - handling of irregular cases </dd> <dt> \_setscope lib::test::SplitSplice_test Member \_internalref classlib_1_1test_1_1SplitSplice__test#a65d2c4b883b981525b3a1a7e68cc0956 "SplitSplice_test::demonstrate_usage" ()</dt><dd> \anchor _test000570 demonstrate how to use the »Split-Splice« algorithm with custom data </dd> <dt> \_setscope lib::test::SplitSplice_test Member \_internalref classlib_1_1test_1_1SplitSplice__test#a57851c8461ff2a608cd4fed6759bd20b "SplitSplice_test::verify_cornerCases" ()</dt><dd> \anchor _test000574 cover special and boundary cases </dd> <dt> \_setscope lib::test::SplitSplice_test Member \_internalref classlib_1_1test_1_1SplitSplice__test#a564a5e97e0456a7400329f9e4fa9ffe2 "SplitSplice_test::verify_integrity" ()</dt><dd> \anchor _test000575 verify instance data is properly handled on <em>split operation</em> - segments not touched will stay at same memory location - any adapted segments will be new allocated objects - yet segments cloned / split will carry on all data </dd> <dt> \_setscope lib::test::SplitSplice_test Member \_internalref classlib_1_1test_1_1SplitSplice__test#aa7467a89fc37bab63ec63ef0fce2a206 "SplitSplice_test::verify_standardCases" ()</dt><dd> \anchor _test000573 cover all possible cases of splicing an interval </dd> <dt> \_setscope lib::test::SplitSplice_test Member \_internalref classlib_1_1test_1_1SplitSplice__test#af54e75eb9e18ac116d8e4b48027ef503 "SplitSplice_test::verify_testFixture" ()</dt><dd> \anchor _test000571 verify the fixture and self-diagnostics for this test </dd> <dt> \_setscope stage::ctrl::test::StateMapGroupingStorage_test Class \_internalref classstage_1_1ctrl_1_1test_1_1StateMapGroupingStorage__test "StateMapGroupingStorage_test" </dt><dd> \anchor _test000642 verify the storage structure for capturing UI state works as intended.</dd> <dt> \_setscope lib::stat::test::Statistic_test Class \_internalref classlib_1_1stat_1_1test_1_1Statistic__test "Statistic_test" </dt><dd> \anchor _test000539 verifies the proper working of statistic helper functions. - calculate mean and standard derivation - one-dimensional linear regression </dd> <dt> \_setscope lib::stat::test::Statistic_test Member \_internalref classlib_1_1stat_1_1test_1_1Statistic__test#a244b77953f6ccdac1013901daa093d82 "Statistic_test::check_baseStatistics" ()</dt><dd> \anchor _test000544 helpers to calculate mean and standard derivation </dd> <dt> \_setscope lib::stat::test::Statistic_test Member \_internalref classlib_1_1stat_1_1test_1_1Statistic__test#a2da7faa4061be95128d06e98fb80a7b0 "Statistic_test::check_TimeSeriesLinearRegression" ()</dt><dd> \anchor _test000547 regression over a series of measurement data - use greater mount of data generated with randomness - actually a power function is <em>hidden in the data</em> </dd> <dt> \_setscope lib::stat::test::Statistic_test Member \_internalref classlib_1_1stat_1_1test_1_1Statistic__test#a88214f95162a4865718dab4487149374 "Statistic_test::check_wightedLinearRegression" ()</dt><dd> \anchor _test000546 attribute a weight to each data point going into linear regression - using a simple scenario with three points - a line with gradients would run through the end points (1,1) ⟶ (5,5) - but we have a middle point, offset by -2 and with double weight - thus the regression line is overall shifted by -1 - standard derivation is √3 and correlation 81% (both plausible and manually checked </dd> <dt> \_setscope lib::stat::test::Statistic_test Member \_internalref classlib_1_1stat_1_1test_1_1Statistic__test#a23c0a6f1374a2e823841c4326135e702 "Statistic_test::demonstrate_DataSpan" ()</dt><dd> \anchor _test000542 a simplified preview on C++20 ranges </dd> <dt> \_setscope steam::test_format::StreamTypeBasics_test Class \_internalref classsteam_1_1test__format_1_1StreamTypeBasics__test "StreamTypeBasics_test" </dt><dd> \anchor _test000018 check the basic workings of the stream type handling. create some stream implementation data, build a StreamType::ImplFacade from this, and derive a prototype and a full StreamType based on this information. </dd> <dt> \_setscope steam::test_format::StreamTypeLifecycle_test Class \_internalref classsteam_1_1test__format_1_1StreamTypeLifecycle__test "StreamTypeLifecycle_test" </dt><dd> \anchor _test000016 check the stream type registration lifecycle. Any internal or external component (plugin) can extend the Steam Layer's registry of media stream types. There is a basic pristine set of type information, which is restored automatically every time the STypeManager is reset, which in turn happens before loading a (new) Session. </dd> <dt> \_setscope steam::test_format::StreamTypeLifecycle_test Member \_internalref classsteam_1_1test__format_1_1StreamTypeLifecycle__test#a9d4ae28c74d70de242a15cb167be4f9b "StreamTypeLifecycle_test::check_pristineState" ()</dt><dd> \anchor _test000020 this test defines a new (dummy) type info and schedules it for setup in the pristine state; check this info is actually present after resetting the stream type manager, while other additional info \em not scheduled in this manner is not present in this state </dd> <dt> \_setscope steam::test_format::StreamTypeLifecycle_test Member \_internalref classsteam_1_1test__format_1_1StreamTypeLifecycle__test#acdd5858ef5ff3a42e8d49a42ae6af10d "StreamTypeLifecycle_test::register_additional_TypeInfo" ()</dt><dd> \anchor _test000021 use the stream type manager to register additional type info and verify it is used in type resolution. </dd> <dt> \_setscope lumiera::test::SubsystemRunner_test Class \_internalref classlumiera_1_1test_1_1SubsystemRunner__test "SubsystemRunner_test" </dt><dd> \anchor _test000053 managing start and stop of several dependent "subsystems" under various conditions. Using mock-subsystems, which actually spawn a thread and finish by themselves and generally behave sane. For each such MockSys, we can define a behaviour pattern, e.g. weather the start succeeds and if the run terminates with error.</dd> <dt> \_setscope lib::test::Symbol_test Class \_internalref classlib_1_1test_1_1Symbol__test "Symbol_test" </dt><dd> \anchor _test000550 properties of Literal and Symbol data types. - a lib::Literal is just a thin wrapper for a <tt>const char *</tt> - lib::Symbol uses the same implementation, but relies on character string constants <em>interned</em> into a symbol table. <p></dd> <dt> \_setscope lib::test::Symbol_test Member \_internalref classlib_1_1test_1_1Symbol__test#a8599279d9b5ce35e61d5846a5164d799 "Symbol_test::use_as_map_key" ()</dt><dd> \anchor _test000555 use Literal and Symbol as keys in a tree map. </dd> <dt> \_setscope lib::test::SymbolHashtable_test Class \_internalref classlib_1_1test_1_1SymbolHashtable__test "SymbolHashtable_test" </dt><dd> \anchor _test000536 build a hashtable using Symbol objects as Keys. Especially this verifies picking up a customised hash implementation via ADL </dd> <dt> \_setscope lib::test::SyncBarrier_test Class \_internalref classlib_1_1test_1_1SyncBarrier__test "SyncBarrier_test" </dt><dd> \anchor _test000558 verify N-fold synchronisation points by multi-thread loat-test. - start a <em>huge number</em> of TestThread - all those pick up the partial sum from stage1 </dd> <dt> \_setscope lib::test::SyncBarrierPerformance_test Class \_internalref classlib_1_1test_1_1SyncBarrierPerformance__test "SyncBarrierPerformance_test" </dt><dd> \anchor _test000551 investigate performance of N-fold thread synchronisation. - use the \ref lib::test::threadBenchmark() "multithreaded Microbenchmark" - use an array of consecutively used barriers, one for each per-thread repetition - test function is parametrised for comparison of different barrier implementations </dd> <dt> \_setscope lib::test::SyncBarrierPerformance_test Member \_internalref classlib_1_1test_1_1SyncBarrierPerformance__test#a0d8361fd84124dc61ee11cbf208e2059 "SyncBarrierPerformance_test::run" (Arg)</dt><dd> \anchor _test000562 performance investigation of N-fold synchronisation barrier </dd> <dt> \_setscope lib::test::SyncClasslock_test Class \_internalref classlib_1_1test_1_1SyncClasslock__test "SyncClasslock_test" </dt><dd> \anchor _test000557 check proper handling of class (not instance)-based Monitor locks. Because no instance is available in this case, a hidden storage for the Monitor object needs to be provided in a way safe for use even in the static startup/shutdown phase. This can not directly validate this allocation of a shared monitor object behind the scenes, but it can verify the monitor is indeed shared by all ClassLock instances templated to a specific type.</dd> <dt> \_setscope lib::test::SyncLocking_test Class \_internalref classlib_1_1test_1_1SyncLocking__test "SyncLocking_test" </dt><dd> \anchor _test000566 verify the object monitor provides locking and to prevent data corruption on concurrent modification of shared storage. - use a chained calculation with deliberate sleep state while holding onto an intermediary result - run this calculation contended by a huge number of threads - either use locking or no locking </dd> <dt> \_setscope lib::test::SyncTimedwait_test Class \_internalref classlib_1_1test_1_1SyncTimedwait__test "SyncTimedwait_test" </dt><dd> \anchor _test000565 timeout feature on condition wait as provided by the underlying implementation and accessible via the object monitor based locking/waiting mechanism. Without creating multiple threads, we engage into a blocking wait, which aborts due to setting a timeout. </dd> <dt> \_setscope lib::test::SyncWaiting_test Class \_internalref classlib_1_1test_1_1SyncWaiting__test "SyncWaiting_test" </dt><dd> \anchor _test000567 concurrent waiting and notification, implemented via object monitor. This test covers the second part of the monitor pattern, which builds upon the locking part, additionally using an embedded condition. Two interwoven threads are created, both blocked until a start value is given. Once awakened, each thread should add the start value to a common sum field. </dd> <dt> \_setscope lib::test::test::TempDir_test Class \_internalref classlib_1_1test_1_1test_1_1TempDir__test "TempDir_test" </dt><dd> \anchor _test000568 validate proper behaviour of a temporary working directory, including automatic name allocation and clean-up. </dd> <dt> \_setscope lib::test::test::TempDir_test Member \_internalref classlib_1_1test_1_1test_1_1TempDir__test#ad8165126af35afca9845729574baea9f "TempDir_test::verify_Lifecycle" ()</dt><dd> \anchor _test000569 automatic clean-up even in case of errors. </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Class \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test "TestChainLoad_test" </dt><dd> \anchor _test000805 verify a tool to generate synthetic load for Scheduler tests. </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#a84059efd316e201a54cb3065eaf02d5d "TestChainLoad_test::showcase_Expansion" ()</dt><dd> \anchor _test000809 demonstrate shaping of generated topology - the expansion rule injects forking nodes - after some expansion, width limitation is enforced - thus join nodes are introduced to keep all chains connected - by default, the hash controls shape, evolving identical in each branch - with additional shuffling, the decisions are more random - statistics can be computed to characterise the graph - the graph can be visualised as <em>Graphviz diagram</em> </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#a68e5bd82926f6122bb4a156d6582a5cd "TestChainLoad_test::showcase_PruneChains" ()</dt><dd> \anchor _test000812 demonstrate topology with pruning and multiple segments - the prune rule terminates chains randomly - this can lead to fragmentation into several sub-graphs - these can be completely segregated, or appear interwoven - equilibrium of seeding and pruning can be established </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#ab7357c5b833782204ac11d02f0aca6b6 "TestChainLoad_test::showcase_Reduction" ()</dt><dd> \anchor _test000810 demonstrate impact of reduction on graph topology - after one fixed initial expansion, reduction causes all chains to be joined eventually - expansion and reduction can counterbalance each other, leading to localised »packages« of branchings and reductions </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#ae16b18765678bb560352e0da44cca896 "TestChainLoad_test::showcase_SeedChains" ()</dt><dd> \anchor _test000811 demonstrate shaping of generated topology by seeding new chains - the seed rule allows to start new chains in the middle of the graph - combined with with reduction, the emerging structure resembles the processing pattern encountered with real media calculations </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#a598487ecff926b1860062a3b4992f188 "TestChainLoad_test::showcase_StablePattern" ()</dt><dd> \anchor _test000813 examples of realistic stable processing patterns - some cases achieve a real equilibrium - other examples' structure is slowly expanding and become stable under constriction of width - some examples go into a stable repetitive loop - injecting additional randomness generates a chaotic yet stationary flow of similar patterns </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#a1bd289c272d471085e66aad7a9af0e68 "TestChainLoad_test::usageExample" ()</dt><dd> \anchor _test000806 demonstrate simple usage of the test-load - build a graph with 64 nodes, grouped into small segments - use a scheduler instance to »perform« this graph </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#ab9518dc2bb30b36d4d2e07bab0ea60f6 "TestChainLoad_test::verify_adjusted_schedule" ()</dt><dd> \anchor _test000817 verify use of computation weights and topology to establish a predicted load pattern, which can be used to construct a schedule adapted to the expected load. </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#af294dc841d2c55f94b0aa11167d02bac "TestChainLoad_test::verify_computation_load" ()</dt><dd> \anchor _test000814 verify calibration of a configurable computational load. </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#ac18892884a1d055fa7ac5b5b10de0a05 "TestChainLoad_test::verify_Node" ()</dt><dd> \anchor _test000807 data structure to represent a computation Node </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#a018928b085e28242d79cfaaae113193b "TestChainLoad_test::verify_reseed_recalculate" ()</dt><dd> \anchor _test000815 set and propagate seed values and recalculate all node hashes. </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#adf6dc80b9015b09af0b266ee240d10bc "TestChainLoad_test::verify_runtime_reference" ()</dt><dd> \anchor _test000816 compute synchronous execution time for reference </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#aeaea921025e6cc3a2dac27f05976a247 "TestChainLoad_test::verify_scheduling_setup" ()</dt><dd> \anchor _test000818 setup for running a chain-load as scheduled task - running an isolated Node recalculation - dispatch of this recalculation packaged as render job - verify the planning job, which processes nodes in batches; for the test, the callback-λ will not invoke the Scheduler, but rather use the instructions to create clone nodes; if all nodes are processed and all dependency connections properly reported through the callback-λ, then calculating this clone network should reproduce the original hash. </dd> <dt> \_setscope vault::gear::test::TestChainLoad_test Member \_internalref classvault_1_1gear_1_1test_1_1TestChainLoad__test#ad842924ef7b520571aee718141b05a75 "TestChainLoad_test::verify_Topology" ()</dt><dd> \anchor _test000808 build topology by connecting the nodes - pre-allocate a block with 32 nodes and then build a topology to connect these, using default rules - in the default case, nodes are linearly chained - hash is also computed by chaining with predecessor hash - hash computations can be reproduced </dd> <dt> \_setscope steam::engine::test::TestFrame_test Class \_internalref classsteam_1_1engine_1_1test_1_1TestFrame__test "TestFrame_test" </dt><dd> \anchor _test000178 verify test helper for engine tests: a dummy data frame. TestFrame instances can be created right away, without any external library dependencies. A test frame is automatically filled with random data; multiple frames are arranged in sequences and channels, causing the random data to be reproducible yet different in each frame.</dd> <dt> \_setscope steam::engine::test::TestFrame_test Member \_internalref classsteam_1_1engine_1_1test_1_1TestFrame__test#a5a1ca98aa4b85bfbc298db78f2540f96 "TestFrame_test::useFrameTable" ()</dt><dd> \anchor _test000182 the table of test frames computed on demand </dd> <dt> \_setscope steam::engine::test::TestFrame_test Member \_internalref classsteam_1_1engine_1_1test_1_1TestFrame__test#af59e7902f3b78c60f84ce546ec60ada9 "TestFrame_test::verifyFrameSeries" ()</dt><dd> \anchor _test000181 build sequences of test frames, organised into multiple families (channels). Verify that adjacent frames hold differing data </dd> <dt> \_setscope lib::test::test::TestHelper_test Member \_internalref classlib_1_1test_1_1test_1_1TestHelper__test#a4c61cbe664dfe2441227b77cdaeb4764 "TestHelper_test::checkLocalManipulation" ()</dt><dd> \anchor _test000579 check a local manipulations, which are undone when leaving the scope. </dd> <dt> \_setscope lib::test::test::TestHelper_test Member \_internalref classlib_1_1test_1_1test_1_1TestHelper__test#a96f55fac9f22c9fd8093b8608a220cbb "TestHelper_test::checkThrowChecker" ()</dt><dd> \anchor _test000577 check the VERIFY_ERROR macro, which ensures a given error is raised. </dd> <dt> \_setscope lib::test::test::TestHelper_test Member \_internalref classlib_1_1test_1_1test_1_1TestHelper__test#a265dfac4f3fdd0a865c2d3b1070bd2f6 "TestHelper_test::checkTypeDisplay" ()</dt><dd> \anchor _test000576 prints "sizeof()" including some type name. </dd> <dt> \_setscope lib::test::test::TestHelperVariadic_test Class \_internalref classlib_1_1test_1_1test_1_1TestHelperVariadic__test "TestHelperVariadic_test" </dt><dd> \anchor _test000581 document usage of the diagnostics helper for variadic templates. Errors in variadic template instantiations are sometimes hard to spot, due to the intricacies of template argument matching and the reference collapsing rules. Our diagnostics facility is itself a variadic function template, which, when supplied with an argument pack, will build a diagnostic string describing the arguments. </dd> <dt> \_setscope test::TestOption_test Class \_internalref classtest_1_1TestOption__test "TestOption_test" </dt><dd> \anchor _test000578 for test::TestOption, parsing of commandline options </dd> <dt> \_setscope test::TestOption_test Member \_internalref classtest_1_1TestOption__test#abe5df6817ce881ff15cb95df4f0f9c35 "TestOption_test::doIt" (const string cmdline)</dt><dd> \anchor _test000580 performs the actual test for the option parser test::TestOption </dd> <dt> \_setscope lib::test::test::TestTracking_test Class \_internalref classlib_1_1test_1_1test_1_1TestTracking__test "TestTracking_test" </dt><dd> \anchor _test000605 verify proper working of test helpers to track automated clean-up and memory deallocation. </dd> <dt> \_setscope lib::test::test::TestTracking_test Member \_internalref classlib_1_1test_1_1test_1_1TestTracking__test#ab6c4e699f0e5183a575c2056d281fc3d "TestTracking_test::demonstrate_checkAllocator" ()</dt><dd> \anchor _test000613 custom allocator to track memory handling - use the base allocator to perform raw memory allocation - demonstrate checksum and diagnostic functions - use a standard adapter to create objects with <tt>unique_ptr</tt> - use as <em>custom allocator</em> within STL containers - can use several distinct pools - swapping containers will move allocators alongside </dd> <dt> \_setscope lib::test::test::TestTracking_test Member \_internalref classlib_1_1test_1_1test_1_1TestTracking__test#a32b06c9b2ebb776f55d518655401d4db "TestTracking_test::demonstrate_checkObject" ()</dt><dd> \anchor _test000610 dummy object with a tracking checksum. </dd> <dt> \_setscope lib::test::test::TestTracking_test Member \_internalref classlib_1_1test_1_1test_1_1TestTracking__test#a69ca745af9a1edcafc3e596efbb6953e "TestTracking_test::demonstrate_logObject" ()</dt><dd> \anchor _test000608 capture object lifecycle events in the EventLog. </dd> <dt> \_setscope lib::test::TextTemplate_test Class \_internalref classlib_1_1test_1_1TextTemplate__test "TextTemplate_test" </dt><dd> \anchor _test000618 verify a minimalistic text substitution engine with flexible data binding, used for tool integration and script generation - cover the core parsing and templating functionality, using a direct binding - demonstrate the default-binding for a data map - cover the binding to Lumiera's »External Tree Description« </dd> <dt> \_setscope lib::test::TextTemplate_test Member \_internalref classlib_1_1test_1_1TextTemplate__test#abff38d063e657977406b388029ba00f9 "TextTemplate_test::simpeUsage" ()</dt><dd> \anchor _test000622 simple point-and-shot usage... </dd> <dt> \_setscope lib::test::TextTemplate_test Member \_internalref classlib_1_1test_1_1TextTemplate__test#a5fced67171e13df583d27f1a7a4ef31b "TextTemplate_test::verify_conditional" ()</dt><dd> \anchor _test000631 Segments of the text-template can be included conditionally, based on interpretation of a controlling key. </dd> <dt> \_setscope lib::test::TextTemplate_test Member \_internalref classlib_1_1test_1_1TextTemplate__test#a8819b3688ec91cc2f31997f067dad727 "TextTemplate_test::verify_ETD_binding" ()</dt><dd> \anchor _test000638 represent the same logical structure as in the \ref #verify_Map_binding "preceding test", yet this time as a tree of GenNodes - value bindings are translated into attribute access - the iteration now requires an actually nested scope, holding a sequence of child nodes - each of these nodes constitutes a »data entity« - when accessing keys from <em>within</em> such a nested scope, attributes of enclosing scopes are visible, unless shadowed by local definition. </dd> <dt> \_setscope lib::test::TextTemplate_test Member \_internalref classlib_1_1test_1_1TextTemplate__test#a58a41819ecc3e24fd7db240068603566 "TextTemplate_test::verify_instantiation" ()</dt><dd> \anchor _test000629 Compile a template and instantiate with various data bindings. </dd> <dt> \_setscope lib::test::TextTemplate_test Member \_internalref classlib_1_1test_1_1TextTemplate__test#a44afb040adb719d5a357916385ed340f "TextTemplate_test::verify_iteration" ()</dt><dd> \anchor _test000634 Segments of the text-template can be iterated... - there is a control-key to guide the iteration - how this key translates into nested data scopes is defined by the implementation of the data binding - for this test we use the Map-binding, which synthesises key prefixes and expects bindings for those decorated keys - typically, keys in inner scopes will shadow outer keys, as is demonstrated here with the "x" key at top level - loops and conditionals can be nested </dd> <dt> \_setscope lib::test::TextTemplate_test Member \_internalref classlib_1_1test_1_1TextTemplate__test#acabde70e6826510a5e1619b119749c80 "TextTemplate_test::verify_Map_binding" ()</dt><dd> \anchor _test000636 build a data binding to a map-of-strings, and verify all the operations used internally by the text-template engine to navigate the data. </dd> <dt> \_setscope lib::test::TextTemplate_test Member \_internalref classlib_1_1test_1_1TextTemplate__test#a4620d882476c757ad9aaac93a80953ed "TextTemplate_test::verify_parsing" ()</dt><dd> \anchor _test000623 parsing of tag markup and compilation into a sequence of Action-codes </dd> <dt> \_setscope lib::test::ThreadWrapper_test Class \_internalref classlib_1_1test_1_1ThreadWrapper__test "ThreadWrapper_test" </dt><dd> \anchor _test000595 use the lib::Thread wrapper for simplified definition of the thread-function, argument binding and starting of threads. </dd> <dt> \_setscope lib::test::ThreadWrapper_test Member \_internalref classlib_1_1test_1_1ThreadWrapper__test#a2c36f803c25e76304a385a5e7da34915 "ThreadWrapper_test::demonstrateSimpleUsage" ()</dt><dd> \anchor _test000598 demonstrate simple usage of the thread-wrapper a λ-binding </dd> <dt> \_setscope lib::test::ThreadWrapper_test Member \_internalref classlib_1_1test_1_1ThreadWrapper__test#a913be982c20f2eedeba8ccd011db358f "ThreadWrapper_test::verifyConcurrentExecution" ()</dt><dd> \anchor _test000601 verify the thread function is actually performed concurrently - use a derived Thread object, also holding a local data field - the thread function sleeps, and then stores the sum of two numbers - demonstrate that each instance can have a different argument binding - verify each thread function has actually been invoked once per thread, by comparing a local sum with values collected from the Thread objects, - moreover measure the overall time required for launching the threads and then waiting for all threads to have terminated and detached; this time must be <em>shorter</em> than all the <em>average</em> sleep times compounded (as if the function was invoked sequentially). </dd> <dt> \_setscope lib::test::ThreadWrapperAutonomous_test Class \_internalref classlib_1_1test_1_1ThreadWrapperAutonomous__test "ThreadWrapperAutonomous_test" </dt><dd> \anchor _test000582 a variation of the Thread wrapper to launch a detached thread, with automatic memory management for the <em>thread-object.</em>. </dd> <dt> \_setscope lib::test::ThreadWrapperAutonomous_test Member \_internalref classlib_1_1test_1_1ThreadWrapperAutonomous__test#a2c36f803c25e76304a385a5e7da34915 "ThreadWrapperAutonomous_test::demonstrateSimpleUsage" ()</dt><dd> \anchor _test000584 demonstrate simply launching a λ-function into background </dd> <dt> \_setscope lib::test::ThreadWrapperAutonomous_test Member \_internalref classlib_1_1test_1_1ThreadWrapperAutonomous__test#a3455bb093af4523f1693557a39d3dd7e "ThreadWrapperAutonomous_test::verifyMemoryManagement" ()</dt><dd> \anchor _test000585 verify the detached thread autonomously manages its memory. </dd> <dt> \_setscope lib::test::ThreadWrapperJoin_test Class \_internalref classlib_1_1test_1_1ThreadWrapperJoin__test "ThreadWrapperJoin_test" </dt><dd> \anchor _test000588 verify the special flavour of the thread-wrapper, allowing to block waiting on thread end and then pass result or error state. </dd> <dt> \_setscope lib::test::ThreadWrapperLifecycle_test Class \_internalref classlib_1_1test_1_1ThreadWrapperLifecycle__test "ThreadWrapperLifecycle_test" </dt><dd> \anchor _test000593 verify lifecycle behaviour of threads managed by thread-wrapper. </dd> <dt> \_setscope lib::test::ThreadWrapperLifecycle_test Member \_internalref classlib_1_1test_1_1ThreadWrapperLifecycle__test#a00809e92fc9286b9292c863a02fdf847 "ThreadWrapperLifecycle_test::defaultWrapperLifecycle" ()</dt><dd> \anchor _test000594 demonstrate terms of lifecycle for the default case </dd> <dt> \_setscope lib::test::ThreadWrapperLifecycle_test Member \_internalref classlib_1_1test_1_1ThreadWrapperLifecycle__test#aeb9edd31137fae3b37043e8acdb914f8 "ThreadWrapperLifecycle_test::demonstrateExplicitThreadLifecycle" ()</dt><dd> \anchor _test000597 verify a special setup to start a thread explicitly and to track the thread's lifecycle state. - use a component to encapsulate the thread - this TestThread component is managed in a <tt>unique_ptr</tt> - thus it is explicitly possible to be <em>not</em> in <em>running state</em> - when starting the TestThread, a lifecycle callback is bound - at termination this callback will clear the unique_ptr - thus allocation and <em>running state</em> is tied to the lifecycle </dd> <dt> \_setscope lib::test::ThreadWrapperLifecycle_test Member \_internalref classlib_1_1test_1_1ThreadWrapperLifecycle__test#a62a500f6cbd0c660362b472b8d98b21d "ThreadWrapperLifecycle_test::verifyThreadLifecycleHooks" ()</dt><dd> \anchor _test000596 attach user provided callback hooks to the thread lifecycle. </dd> <dt> \_setscope lib::test::ThreadWrapperSelfRecognitionTest_test Class \_internalref classlib_1_1test_1_1ThreadWrapperSelfRecognitionTest__test "ThreadWrapperSelfRecognitionTest_test" </dt><dd> \anchor _test000589 verify the ability of a thread to detect code executing within the thread itself. </dd> <dt> \_setscope lib::test::TimeBasics_test Class \_internalref classlib_1_1test_1_1TimeBasics__test "TimeBasics_test" </dt><dd> \anchor _test000023 sanity check of basic Time handling. </dd> <dt> \_setscope lib::time::test::TimeControl_test Class \_internalref classlib_1_1time_1_1test_1_1TimeControl__test "TimeControl_test" </dt><dd> \anchor _test000034 use the time::Control to push a sequence of modifications to various time entities; in all cases, a suitable change should be imposed to the target and then a notification signal should be invoked.</dd> <dt> \_setscope lib::time::test::TimeControl_test Member \_internalref classlib_1_1time_1_1test_1_1TimeControl__test#a967fb86f9b4525daf49f3921dac6c345 "TimeControl_test::verifyMatrix_of_MutationCases" (TimeValue const &o, TimeValue const &c)</dt><dd> \anchor _test000039 cover all possible combinations of input change values and target time value entities to be handled by time::Control. Each of these cases executes a standard test sequence, which is defined in TestCase#performTestSequence </dd> <dt> \_setscope lib::time::test::TimeDropframe_test Class \_internalref classlib_1_1time_1_1test_1_1TimeDropframe__test "TimeDropframe_test" </dt><dd> \anchor _test000024 document the computation of NTSC drop frame timecode mapping. </dd> <dt> \_setscope lib::time::test::TimeDropframe_test Member \_internalref classlib_1_1time_1_1test_1_1TimeDropframe__test#a4a872429ff928d65d248e6ba2f89353c "TimeDropframe_test::verify_completeMapping" ()</dt><dd> \anchor _test000027 Cover the whole value range of a day in drop-frame: - manually construct a drop-frame timecode - make sure our library function returns the same times. </dd> <dt> \_setscope lib::time::test::TimeDropframe_test Member \_internalref classlib_1_1time_1_1test_1_1TimeDropframe__test#a1e003d926b43071c166969d041fb748d "TimeDropframe_test::verify_DropFrame_conv" ()</dt><dd> \anchor _test000026 perform a drop-frame timecode conversion and verify the complete round-trip is correct. </dd> <dt> \_setscope lib::time::test::TimeFormats_test Class \_internalref classlib_1_1time_1_1test_1_1TimeFormats__test "TimeFormats_test" </dt><dd> \anchor _test000030 verify handling of grid aligned timecode values. - full cycle from parsing to formatting - mutating the components of timecode - some formatting corner cases - formatting in various formats </dd> <dt> \_setscope lib::time::test::TimeFormats_test Member \_internalref classlib_1_1time_1_1test_1_1TimeFormats__test#a1baa6c7dc53fc8dea3ab84e78a0fde6c "TimeFormats_test::checkSmpte" ()</dt><dd> \anchor _test000037 detailed coverage of SMPTE timecode representation. Using a scale grid with PAL framerate; this test doesn't cover the handling of drop-frame timecode. - creating a timecode representation causes frame quantisation - the components of SMPTE timecode can be accessed and manipulated - timecode can be incremented/decremented as a whole - we allow extension of the scale towards negative values - for these, the representation is flipped and the negative orientation only indicated through the sign field. </dd> <dt> \_setscope lib::time::test::TimeFormats_test Member \_internalref classlib_1_1time_1_1test_1_1TimeFormats__test#a707d0cbc267fc2f98f0ff204595c6cd0 "TimeFormats_test::checkTimecodeUsageCycle" ()</dt><dd> \anchor _test000035 demonstrate a full usage cycle of timecode and time values. Starting with a textual representation according to a specific timecode format, and based on the knowledge of the implicit underlying time grid (coordinate system, here with origin=0 and framerate=25fps), this timecode string may be parsed. This brings us (back) to the very origin, which is a raw TimeValue (internal time). Now, this time value might be manipulated, compared to other values etc. Anyway, at some point these time values need to be related to some time scale again, leading to quantised time values, which — finally — can be cast into a timecode format for external representation again, thus closing the circle. </dd> <dt> \_setscope steam::asset::meta::test::TimeGridBasics_test Class \_internalref classsteam_1_1asset_1_1meta_1_1test_1_1TimeGridBasics__test "TimeGridBasics_test" </dt><dd> \anchor _test000068 build some simple time grids and verify their behaviour for quantising (grid aligning) time values.</dd> <dt> \_setscope steam::mobject::session::test::TimelineSequenceHandling_test Class \_internalref classsteam_1_1mobject_1_1session_1_1test_1_1TimelineSequenceHandling__test "TimelineSequenceHandling_test" </dt><dd> \anchor _test000252 verify retrieval and instance management of the top level facade objects as integrated with the session and high-level model. Both sequences and timelines are at the same time structural assets and act as facades on the session API. Thus we can query specific instances from the struct factory or alternatively access them through the session. Moreover we can create new top level elements in the session just by querying the respective asset.</dd> <dt> \_setscope lib::time::test::TimeMutation_test Class \_internalref classlib_1_1time_1_1test_1_1TimeMutation__test "TimeMutation_test" </dt><dd> \anchor _test000029 cover all basic cases for mutating a time specification. - change to a given value - change by an offset - change using a grid value - apply an (grid) increment </dd> <dt> \_setscope lib::time::test::TimeParsing_test Class \_internalref classlib_1_1time_1_1test_1_1TimeParsing__test "TimeParsing_test" </dt><dd> \anchor _test000036 parse textual time specifications given in the supported timecode formats </dd> <dt> \_setscope lib::time::test::TimeQuantisation_test Class \_internalref classlib_1_1time_1_1test_1_1TimeQuantisation__test "TimeQuantisation_test" </dt><dd> \anchor _test000038 verify handling of quantised time values. - the simple usage, just referring to an predefined grid by name - explicitly defining an quantiser - converting these quantised values into various timecode formats - error detection </dd> <dt> \_setscope lib::time::test::TimeValue_test Class \_internalref classlib_1_1time_1_1test_1_1TimeValue__test "TimeValue_test" </dt><dd> \anchor _test000046 verify handling of time values, time intervals. - creating times and time intervals - comparisons - time arithmetics </dd> <dt> \_setscope lib::time::test::TimeValue_test Member \_internalref classlib_1_1time_1_1test_1_1TimeValue__test#a9c9297589cab22f945312e5afb87df9f "TimeValue_test::checkBasicTimeValues" (TimeValue org)</dt><dd> \anchor _test000047 creating some time values and performing trivial comparisons. </dd> <dt> \_setscope lib::time::test::TimeValue_test Member \_internalref classlib_1_1time_1_1test_1_1TimeValue__test#a42613d3a1630389afe20422afb313097 "TimeValue_test::checkMutableTime" (TimeValue org)</dt><dd> \anchor _test000048 time variables can be used for the typical calculations, like summing and subtracting values, as well as multiplication with a scale factor. Additionally, the raw time value is accessible by conversion. </dd> <dt> \_setscope lib::time::test::TimeValue_test Member \_internalref classlib_1_1time_1_1test_1_1TimeValue__test#a74ac85dbf23a01a3f12a08547c598105 "TimeValue_test::checkTimeConvenience" (TimeValue org)</dt><dd> \anchor _test000049 additional convenience shortcuts supported especially by the canonical Time values. </dd> <dt> \_setscope lib::time::test::TimeValue_test Member \_internalref classlib_1_1time_1_1test_1_1TimeValue__test#a484577e0e737f869618fc2cd101f6f3a "TimeValue_test::checkTimeHash" (TimeValue org)</dt><dd> \anchor _test000050 calculate a generic hash value from a time spec </dd> <dt> \_setscope steam::play::test::TimingConstraints_test Class \_internalref classsteam_1_1play_1_1test_1_1TimingConstraints__test "TimingConstraints_test" </dt><dd> \anchor _test000251 document and verify the definition and combining of timing constraints for playback and rendering. </dd> <dt> \_setscope steam::engine::test::Timings_test Class \_internalref classsteam_1_1engine_1_1test_1_1Timings__test "Timings_test" </dt><dd> \anchor _test000185 document and verify frame timing calculations, which are used in the Player / engine::Dispatcher, to translate a CalcStream into individual node jobs. </dd> <dt> \_setscope steam::engine::test::Timings_test Member \_internalref classsteam_1_1engine_1_1test_1_1Timings__test#a3178d4d478d1bd43802d5100b4a4024e "Timings_test::verify_next_startPoint" ()</dt><dd> \anchor _test000189 detect boundaries of frame planning chunks for arbitrary chunk duration. </dd> <dt> \_setscope steam::engine::test::Timings_test Member \_internalref classsteam_1_1engine_1_1test_1_1Timings__test#a48c1d56ef2d98cd33505ed16dd35c698 "Timings_test::verify_simpleFrameStep" ()</dt><dd> \anchor _test000188 perform the basic dispatch step and verify the generated frame coordinates </dd> <dt> \_setscope steam::engine::test::TrackingHeapBlockProvider_test Class \_internalref classsteam_1_1engine_1_1test_1_1TrackingHeapBlockProvider__test "TrackingHeapBlockProvider_test" </dt><dd> \anchor _test000191 verify a test support facility, used to write mock components to test the lumiera engine. The TrackingHeapBlockProvider is a braindead implementation of the BufferProvider interface: it just claims new heap blocks and never de-allocates them, allowing other test and mock objects to verify allocated buffers after the fact. </dd> <dt> \_setscope lib::diff::test::TreeMutator_test Class \_internalref classlib_1_1diff_1_1test_1_1TreeMutator__test "TreeMutator_test" </dt><dd> \anchor _test000307 Demonstrate a customisable component for flexible bindings to enable generic tree changing and mutating operations to arbitrary hierarchical data structures. - we use lambdas to link into our private implementation - this test demonstrates the behaviour of an attribute setter - plus some of the <em>primitive operations</em> available on collections</dd> <dt> \_setscope lib::diff::test::TreeMutatorBinding_test Class \_internalref classlib_1_1diff_1_1test_1_1TreeMutatorBinding__test "TreeMutatorBinding_test" </dt><dd> \anchor _test000374 Building blocks to map generic changes to arbitrary private data structures. - use a dummy diagnostic implementation to verify the interface - verify an adapter to apply structure modification to a generic collection - use closures to translate mutation into manipulation of private attributes - integrate the standard case of tree diff application to <tt>Rec\<GenNode\></tt></dd> <dt> \_setscope lib::diff::test::TreeMutatorBinding_test Member \_internalref classlib_1_1diff_1_1test_1_1TreeMutatorBinding__test#a3711088a1239ad6579f501232dd99a2a "TreeMutatorBinding_test::mutateAttribute" ()</dt><dd> \anchor _test000394 translate generic mutation into attribute manipulation - here we bind directly to data fields local to this scope - we execute the same diff primitives used in the preceding tests - yet binding to data fields has certain intrinsic limits; due to the fixed non-dynamic nature of data fields, it is impossible to define an "ordering" and consequently there is no <em>sequence of diff application.</em> - so the only form of actually <em>applying</em> a change is to invoke the given setter or use the given mechanism to construct a nested mutator. <br> </dd> <dt> \_setscope lib::diff::test::TreeMutatorBinding_test Member \_internalref classlib_1_1diff_1_1test_1_1TreeMutatorBinding__test#ac923cef617e8f4c02e3d951beec4c7b5 "TreeMutatorBinding_test::mutateCollection" ()</dt><dd> \anchor _test000392 map mutation primitives onto a STL collection managed locally. - we perform <em>literally</em> the same diff steps as in mutateDummy() - but now we have a completely opaque implementation data structure, where even the data type is unknown beyond this functions's scope. - thus we build a custom mutator, installing lambdas to tie into this local data structure, without disclosing any details. In fact we even install different lambdas on each usage cycle, according to the specific mutation operations to perform. Of course, it would be pointless to do so in real world usage, yet nicely demonstrates the point that the implementation really remains in control about anything regarding its private data structure. - and still, by exposing such a custom configured mutator, this private structure can be populated, reordered and even altered recursively, by generic instructions. </dd> <dt> \_setscope lib::diff::test::TreeMutatorBinding_test Member \_internalref classlib_1_1diff_1_1test_1_1TreeMutatorBinding__test#a297f2796333e95bdd2333624613fff3a "TreeMutatorBinding_test::mutateDummy" ()</dt><dd> \anchor _test000390 diagnostic binding: how to monitor and verify the mutations applied </dd> <dt> \_setscope lib::diff::test::TreeMutatorBinding_test Member \_internalref classlib_1_1diff_1_1test_1_1TreeMutatorBinding__test#a511f0e21918ffbb0b7505e91d5bb6bf1 "TreeMutatorBinding_test::mutateGenNode" ()</dt><dd> \anchor _test000396 apply mutation primitives to a GenNode tree. - again we perform <em>literally</em> the same diff steps as before - but we use the pre-configured binding for Record<GenNode> - internally this is comprised of two collection binding layers - we start with an empty root node, to be populated and transformed </dd> <dt> \_setscope lib::meta::test::TupleClosure_test Class \_internalref classlib_1_1meta_1_1test_1_1TupleClosure__test "TupleClosure_test" </dt><dd> \anchor _test000441 wrap the constructors for »tuple-like« records as functor and pre-bind some arguments immediately. - verify binding flavours for a tuple with mixed types - verify binding also works seamlessly with std::array </dd> <dt> \_setscope lib::meta::test::TupleClosure_test Member \_internalref classlib_1_1meta_1_1test_1_1TupleClosure__test#aa17107d766fb0bbdf5bfaeff9aa33dcc "TupleClosure_test::array_bindArg" ()</dt><dd> \anchor _test000449 can also use the binding for arbitrary elements in a std::array </dd> <dt> \_setscope lib::meta::test::TupleClosure_test Member \_internalref classlib_1_1meta_1_1test_1_1TupleClosure__test#a39ee855fd58d947dafd1a51f51f14686 "TupleClosure_test::array_bindFront" ()</dt><dd> \anchor _test000448 use a std::array and handle it like a tuple to pre-fix some elements </dd> <dt> \_setscope lib::meta::test::TupleClosure_test Member \_internalref classlib_1_1meta_1_1test_1_1TupleClosure__test#a7e329deb66791080f529abb135445b84 "TupleClosure_test::tuple_bindArg" ()</dt><dd> \anchor _test000446 fix specific argument within tuple </dd> <dt> \_setscope lib::meta::test::TupleClosure_test Member \_internalref classlib_1_1meta_1_1test_1_1TupleClosure__test#a19cc73bc6c2e7425af19d6e54e8b20a7 "TupleClosure_test::tuple_bindBack" ()</dt><dd> \anchor _test000445 fix elements starting from the end of the tuple </dd> <dt> \_setscope lib::meta::test::TupleClosure_test Member \_internalref classlib_1_1meta_1_1test_1_1TupleClosure__test#a1a61c779ea90fa35857eaa66ad1bbe32 "TupleClosure_test::tuple_bindFront" ()</dt><dd> \anchor _test000444 use a regular tuple and pre-fix the first elements </dd> <dt> \_setscope lib::meta::test::TupleClosure_test Member \_internalref classlib_1_1meta_1_1test_1_1TupleClosure__test#a55a08c244cfda7546f1f3068b47c4d29 "TupleClosure_test::verify_AdaptArray" ()</dt><dd> \anchor _test000450 verify properties of the metaprogramming-adapter, used as seamless overlay to handle std::array in the TUpleClosureBuilder. </dd> <dt> \_setscope lib::meta::test::TupleHelper_test Class \_internalref classlib_1_1meta_1_1test_1_1TupleHelper__test "TupleHelper_test" </dt><dd> \anchor _test000456 Cover various aspects of the integration of our type sequences with the tuple type from the standard library - verify our generic tuple access decorator - verify generating tuple types from type list processing - TODO more helpers to come </dd> <dt> \_setscope lib::meta::test::TupleHelper_test Member \_internalref classlib_1_1meta_1_1test_1_1TupleHelper__test#a0909581e2aced3db38c44b8eb7c6fec1 "TupleHelper_test::check_tuple_from_Typelist" ()</dt><dd> \anchor _test000457 verify the ability to generate tuple types from typelist metaprogramming - the resulting types are plain flat <tt>std::tuple</tt> instantiations - memory layout is identical to a POD, as expected - our generic string conversion is extended to work with tuples </dd> <dt> \_setscope lib::meta::test::TupleHelper_test Member \_internalref classlib_1_1meta_1_1test_1_1TupleHelper__test#aaa92faaa4f9e69e205ffef7b6baf98b5 "TupleHelper_test::demonstrate_generic_iteration" ()</dt><dd> \anchor _test000458 demonstrate generic tuple iteration mechanisms - apply a generic lambda to each element of a tuple - iterate over all index numbers of a tuple (or tuple-like) </dd> <dt> \_setscope lib::meta::test::TupleHelper_test Member \_internalref classlib_1_1meta_1_1test_1_1TupleHelper__test#a4845b5acd6bd5dde921f3dbc36488312 "TupleHelper_test::verify_tuple_like_concept" ()</dt><dd> \anchor _test000459 verify construction of a concept to detect <em>tuple-like</em> classes, which conform to the »tuple protocol« and can thus be used in structural bindings - the size of such an entity can be detected at compile time - essentially, these can be considered as <em>product types</em> — which implies that there are N element types - access to the corresponding member data is possible either through a <tt>get</tt> member function or free function detected by ADL </dd> <dt> \_setscope lib::meta::test::TupleRecordInit_test Class \_internalref classlib_1_1meta_1_1test_1_1TupleRecordInit__test "TupleRecordInit_test" </dt><dd> \anchor _test000451 Metaprogramming: how to unload the contents of a runtime typed variant sequence into ctor arguments of a (compile time typed) tuple.</dd> <dt> \_setscope lib::test::TypedAllocationManager_test Class \_internalref classlib_1_1test_1_1TypedAllocationManager__test "TypedAllocationManager_test" </dt><dd> \anchor _test000599 cover the basic implementation of a custom allocator, delegating to mpool. TypedAllocationManager is a base class, used e.g. to build the CommandRegistry.</dd> <dt> \_setscope lib::test::TypedCounter_test Class \_internalref classlib_1_1test_1_1TypedCounter__test "TypedCounter_test" </dt><dd> \anchor _test000041 verify the TypedCounter, which allows to maintain a counter-per-type. - demonstrate behaviour - concurrent test </dd> <dt> \_setscope lib::test::TypedCounter_test Member \_internalref classlib_1_1test_1_1TypedCounter__test#ad599bd7b762382429532b794557b0020 "TypedCounter_test::tortureTest" ()</dt><dd> \anchor _test000042 verify TypedCounter concurrency safety - use a set of types <tt>Dummy\<i\></tt> to access a corresponding counter - run a large number of threads in parallel, each incrementing a randomly picked counter; this is achieved by using a table of »increment operators«, where each one is tied to a specific <tt>Dummy\<i\></tt>. </dd> <dt> \_setscope lib::meta::test::TypeDemangling_test Class \_internalref classlib_1_1meta_1_1test_1_1TypeDemangling__test "TypeDemangling_test" </dt><dd> \anchor _test000438 verify the demangling of C++ names, as available through the GCC platform ABI. The Lumiera support library exposes this non-portable feature through a convenience helper to ease the writing of unit tests.</dd> <dt> \_setscope lib::test::TypedFamilyMemberID_test Class \_internalref classlib_1_1test_1_1TypedFamilyMemberID__test "TypedFamilyMemberID_test" </dt><dd> \anchor _test000040 simplistic unit test to demonstrate generating _member IDs within a family of objects delineated by type. </dd> <dt> \_setscope lib::idi::test::TypedID_test Class \_internalref classlib_1_1idi_1_1test_1_1TypedID__test "TypedID_test" </dt><dd> \anchor _test000080 outline of an instance registration and accounting service. The service is self-contained and supports automatic registration and deregistration. The instance access is configurable on a per-type base. - create instances of an auto-registered type - verify the registration entries - re-access the instances just by symbolic ID - verify the registration is cleaned up automatically.</dd> <dt> \_setscope lib::meta::test::TypeDisplay_test Class \_internalref classlib_1_1meta_1_1test_1_1TypeDisplay__test "TypeDisplay_test" </dt><dd> \anchor _test000455 verify post processing of demangled C++ type names. The purpose of those pretty printing functions is to support diagnostics and unit testing by making type names easier to digest. But of course we do not want to pick the wrong primary type for shortened display and we do not want mess up the semantic structure. - the first example should be passed through unaltered - the second example demonstrates various simplifications * strip some frequent namespace prefixes ** <tt>std::</tt> ** <tt>lib::meta::</tt> ** <tt>steam::mobject::</tt> * omit the standard allocator from STL containers - the third example demonstrates an embedded function signature * the primary type component is "`function`" * anything leading up to anonymous namespaces will be stripped * our special smart-ptr lib::P will be simplified</dd> <dt> \_setscope lib::meta::test::TypeList_test Class \_internalref classlib_1_1meta_1_1test_1_1TypeList__test "TypeList_test" </dt><dd> \anchor _test000453 try out Loki-style typelist metaprogramming. Assembles a Class definition from parts specified as collection of types. The elementary building block has an talking ctor, so by automatic ctor chaining we get a message of each part. </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Class \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test "TypeListManip_test" </dt><dd> \anchor _test000474 check utilities for manipulating lists-of-types. - build an list of constant-wrapper-types and print them for debugging purpose. - append lists, single elements and Nil-Type in various combinations - manipulations like splice, get end, dissect - filtering out some types from a typelist by using a "predicate template" (metafunction) - building combinations and permutations </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#aad1e91809c7c0e3c2e6461aa0242ea67 "TypeListManip_test::demonstrate_diagnostics" ()</dt><dd> \anchor _test000477 can print the type list structure for diagnostic </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#aa1cf2481a8af379233b9082133004a4b "TypeListManip_test::verify_append" ()</dt><dd> \anchor _test000479 append and concatenate type lists </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#a56b42a3284902facb0cd7c3e890aab3b "TypeListManip_test::verify_apply" ()</dt><dd> \anchor _test000488 apply a <em>meta-function</em> to each type in list </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#af8cdc46cd1e53c0efe87cf9901eebb87 "TypeListManip_test::verify_combine" ()</dt><dd> \anchor _test000498 demonstrate special setup to enumerate case combinations </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#a9b81f346534a0b3f1579598b57e10a21 "TypeListManip_test::verify_dissect" ()</dt><dd> \anchor _test000486 dissect and access front and back parts of a list </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#af8cbf2aa96573fe263ea1dc3ee872533 "TypeListManip_test::verify_distribute" ()</dt><dd> \anchor _test000496 use the Prefix mechanism to generate a <em>cartesian product</em> </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#aadba8f707f83a2f67371a9c259c5abd7 "TypeListManip_test::verify_filter" ()</dt><dd> \anchor _test000490 filter a type list based on a meta-predicate </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#a8f472dabb990fb574cff2cb00d077777 "TypeListManip_test::verify_pick" ()</dt><dd> \anchor _test000478 pick a type by index from a type list </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#a53296e905cd37449175873ae2fc91bf1 "TypeListManip_test::verify_prefix" ()</dt><dd> \anchor _test000494 verify generation of nested lists-of-lists by distributing the elements from the first list as prefix-concatenation to the elements of the second list </dd> <dt> \_setscope lib::meta::test::TypeListManip_test Member \_internalref classlib_1_1meta_1_1test_1_1TypeListManip__test#a29f809d9849cdb9db2a705c9c5dbe134 "TypeListManip_test::verify_splice" ()</dt><dd> \anchor _test000482 splice (or rather paste) a list on top of a base list. </dd> <dt> \_setscope lib::meta::test::TypeListUtil_test Class \_internalref classlib_1_1meta_1_1test_1_1TypeListUtil__test "TypeListUtil_test" </dt><dd> \anchor _test000454 verify the simple helpers for working with lists-of-types. These are simple metafunctions to count the number of elements, calculate the maximum size or check for inclusion.</dd> <dt> \_setscope lib::meta::test::TypeSeqManip_test Class \_internalref classlib_1_1meta_1_1test_1_1TypeSeqManip__test "TypeSeqManip_test" </dt><dd> \anchor _test000460 check the basic utilities for manipulating (fixed) type sequences. - re-build an sequence from a type list - prepend a type to a given type sequence - create shifted sequences - dissect a sequence to extract head, tail, prefix, last element </dd> <dt> \_setscope stage::interact::test::UICoord_test Class \_internalref classstage_1_1interact_1_1test_1_1UICoord__test "UICoord_test" </dt><dd> \anchor _test000647 verify the basic properties of topological UI coordinate specifications. - created as path-like sequence of \ref Literal components - provides a builder API for definition and mutation - Normalisation and handling of missing parts - access to UI coordinate components - string representation - comparisons - predicates</dd> <dt> \_setscope stage::interact::test::UICoordResolver_test Class \_internalref classstage_1_1interact_1_1test_1_1UICoordResolver__test "UICoordResolver_test" </dt><dd> \anchor _test000674 verify query and mutation of UICoord in relation to actual UI topology. A UI-Coordinate resolver is a special builder, which is initialised by the given coordinate spec, and also attached to a "location query API", which allows to investigate the current actual UI structure. The builder then exposes query and mutation operations, to determine to what extent the coordinate spec is "covered" by the real UI, and to match and expand any wildcards in the coordinate spec (pattern).</dd> <dt> \_setscope stage::interact::test::UICoordResolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UICoordResolver__test#a25671a9af24e008c7abcfc1d72056853 "UICoordResolver_test::verify_backingQuery" ()</dt><dd> \anchor _test000679 verify the command-and-query interface backing the resolver. This test actually uses a dummy implementation of the interface, which, instead of navigating an actual UI topology, just uses a <tt>Record\<GenNode\></tt> (a "GenNode tree") to emulate the hierarchical structure of UI components. </dd> <dt> \_setscope stage::interact::test::UICoordResolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UICoordResolver__test#a935710c0b67d04585716005dfcd86df6 "UICoordResolver_test::verify_mutateAnchor" ()</dt><dd> \anchor _test000683 mutate given UI coordinates by anchoring them. This operation changes only the window part of the coordinate spec; it might use the result of a preceding coverage solution search or even trigger such a search, but only to find out about the root window. </dd> <dt> \_setscope stage::interact::test::UICoordResolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UICoordResolver__test#ab1cb72904fbe56192bfcff39f9742e6a "UICoordResolver_test::verify_mutateCoverage" ()</dt><dd> \anchor _test000681 path matching algorithm to resolve UI coordinates with wildcards against the current UI structure tree. Since an UI coordinate path with gaps and wildcards could match anywhere, even several times, we need to perform an exhaustive search with backtracking over the whole tree. By convention, we use the first maximal solution, which can be just a partial solution, leaving an additional uncovered trailing part of the UI coordinate spec. Whenever a coordinate spec is <em>not explicit,</em> has wildcards or a leading gap, we need to perform the full matching algorithm, even to just answer the question if coverage <em>is possible</em>. The result, i.e. the computed coverage, is cached internally, and can be used to <em>mutate</em> the UI coordinate spec to match that coverage.</dd> <dt> \_setscope stage::interact::test::UICoordResolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UICoordResolver__test#a4979453a67f5a0620ed3c042efdbfa29 "UICoordResolver_test::verify_mutateCoverPartially" ()</dt><dd> \anchor _test000682 resolve by matching, but retain an extraneous, uncovered extension. This is a variation of the UICoordResolver::cover() operation, which likewise resolves any wildcards; but here we tolerate <em>additional elements below</em> the covered part, as long as those are explicit. The typical use case is when we're about to create a new UI element at a specific existing anchor location within the UI. The extraneous uncovered part then describes those extra element yet to be created. </dd> <dt> \_setscope stage::interact::test::UICoordResolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UICoordResolver__test#abbdf641079a88ec7d25e8f09caf3490d "UICoordResolver_test::verify_mutateExtend" ()</dt><dd> \anchor _test000684 mutate given UI coordinates by uncovered extension. Contrary to just appending something to the path (which is a basic path operation available on the generic path builder), a <em>path extension</em> is always rooted at the end of the actually covered part of the UI coordinates. So extending a path implies search for a coverage solution, followed by truncating the path to the covered part. There are two flavours of extending a path: - extending with a literal specification, which is just appended behind the coverage - extending with an incomplete UI coordinate spec, which allows to place the extension at a specific depth (e.g. as a view). This is typically what we want in practice. </dd> <dt> \_setscope stage::interact::test::UICoordResolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UICoordResolver__test#a0f8a3ce7208a0311d9b3cc1bb6c99dc9 "UICoordResolver_test::verify_queryAnchor" ()</dt><dd> \anchor _test000680 query anchorage of given UI coordinates. - an anchored UI coordinate spec explicitly rooted within a top level window. - an explicit UI coordinate spec impossible to anchor within current UI tree - a UI coordinate spec with dynamic reference to first/current window - an incomplete spec, which needs to be solved (pattern matched) to determine anchor. </dd> <dt> \_setscope stage::interact::test::UICoordResolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UICoordResolver__test#a0f67b19bc1b6b0b6d891b5beffa0c631 "UICoordResolver_test::verify_simpleUsage" ()</dt><dd> \anchor _test000678 introduction to UI coordinate resolution - use a backing "real" (dummy) data structure to resolve against - establish a suitable implementation of the LocationQuery interface - attach a resolver - have fun </dd> <dt> \_setscope stage::interact::test::UILocationSolver_test Class \_internalref classstage_1_1interact_1_1test_1_1UILocationSolver__test "UILocationSolver_test" </dt><dd> \anchor _test000656 verify a mechanism to resolve the desired location of an UI-element. The UILocationSolver is operated by the ViewLocator service, which itself is part of the InteractionDirector. In typical usage, the location rules are drawn from the \ref view-spec-dsl.hpp "ViewSpec-DSL", evaluated with the help of a \ref UICoordResolver "Coordinate Resolver", based on the real UI topology existing at that moment, accessible in abstracted form through the LocationQuery interface. This test setup here mimics that invocation scheme, but replaces the real UI by an abstract tree notation embedded directly into the individual test cases.</dd> <dt> \_setscope stage::interact::test::UILocationSolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UILocationSolver__test#ace4017bb8e0ea442d24bfb46a94008de "UILocationSolver_test::simple_usage_example" ()</dt><dd> \anchor _test000662 demonstrate the typical invocation and usage </dd> <dt> \_setscope stage::interact::test::UILocationSolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UILocationSolver__test#a57851c8461ff2a608cd4fed6759bd20b "UILocationSolver_test::verify_cornerCases" ()</dt><dd> \anchor _test000664 cover theoretical corner cases regarding the process of location solving. Point in question are the requirements and limits when querying against one or several location specification clauses. The actual matching of a location pattern against a UI topology is beyond scope and covered \ref UICoordResolver_test::verify_mutateCoverage "elsewhere" - empty clauses act as neutral element - prerequisites regarding the depth of a location clause relevant for solution - the impact of the query and especially its expected depth - completely explicit clauses vs clauses with wildcards - relevance of partial or total coverage for the solution - regular clauses vs. <em>create clauses</em> (which mandate creating parents as needed) - usage of the first applicable solution when several clauses are given </dd> <dt> \_setscope stage::interact::test::UILocationSolver_test Member \_internalref classstage_1_1interact_1_1test_1_1UILocationSolver__test#a8e636ce91e5cf4dcf66278a284d0ff17 "UILocationSolver_test::verify_standardSituations" ()</dt><dd> \anchor _test000665 emulate the relevant standard situations of view location resolution. The typical location specifications to be expected in practice can be subsumed under a small selection of standard situations; this test demonstrates how these are triggered by specific tree configurations in a (hopefully) obvious way.</dd> <dt> \_setscope lib::test::UniqueMallocOwner_test Class \_internalref classlib_1_1test_1_1UniqueMallocOwner__test "UniqueMallocOwner_test" </dt><dd> \anchor _test000600 Verify automatic management of memory originally allocated by C malloc. This situation typically arises when some plain-C function returns results in a heap allocated buffer, requiring the client to care for proper clean-up. To avoid creating a liability, we wrap the buffer into a smart pointer, which acts as ownership token and abstracts the specifics of clean-up.</dd> <dt> \_setscope util::test::UtilCollection_test Class \_internalref classutil_1_1test_1_1UtilCollection__test "UtilCollection_test" </dt><dd> \anchor _test000603 verify some convenience shortcuts and helpers dealing with Collections and sequences (Iterators). - metafunctions to distinguish STL containers and Lumiera Iterators - get the first element - get the last element </dd> <dt> \_setscope util::test::UtilFloordiv_test Class \_internalref classutil_1_1test_1_1UtilFloordiv__test "UtilFloordiv_test" </dt><dd> \anchor _test000606 Evaluate a custom built integer floor function. Also known as Knuth's floor division. This function is crucial for Lumiera's rule of quantisation of time values into frame intervals. This rule requires time points to be rounded towards the next lower frame border always, irrespective of the relation to the actual time origin. Contrast this to the built-in integer division operator, which truncates towards zero.</dd> <dt> \_setscope util::test::UtilFloordiv_test Member \_internalref classutil_1_1test_1_1UtilFloordiv__test#a0689fec49c5b6d2eb643297c913281a3 "UtilFloordiv_test::runPerformanceTest" ()</dt><dd> \anchor _test000617 timing measurements to compare implementation details. This test uses a sequence of random integers, where the values used as denominator are ensured not to be zero.</dd> <dt> \_setscope util::test::UtilFloorwrap_test Class \_internalref classutil_1_1test_1_1UtilFloorwrap__test "UtilFloorwrap_test" </dt><dd> \anchor _test000604 Verify a custom built integer scale division and wrapping function. This function is relevant for decimating values into a given scale, like splitting time measurements in hours, minutes, seconds etc. Basically, in Lumiera the quantisation into a scale is always done with the same orientation, irrespective of the zero point on the given scale. Contrast this to the built-in integer division and modulo operators working symmetrical to zero. </dd> <dt> \_setscope util::test::UtilForeach_test Class \_internalref classutil_1_1test_1_1UtilForeach__test "UtilForeach_test" </dt><dd> \anchor _test000621 Invoking an operation for each element of a collection. Covers the various flavours of these convenience helpers: They might operate either on a STL container (providing \c begin() and \c end() functions), or at a "Lumiera Forward Iterator", which is incremented and dereferenced for each value it yields, until exhaustion.</dd> <dt> \_setscope util::test::UtilForeach_test Member \_internalref classutil_1_1test_1_1UtilForeach__test#a86c58808162836166b451dbc2d5f0e56 "UtilForeach_test::check_existence_quant" (CO coll)</dt><dd> \anchor _test000633 verify the logic of universal and existential quantisation. Using lambda expressions as predicates </dd> <dt> \_setscope util::test::UtilForeach_test Member \_internalref classutil_1_1test_1_1UtilForeach__test#a887164506eaaf94f00cec2da286ff48b "UtilForeach_test::check_foreach_bind" (CO coll)</dt><dd> \anchor _test000625 bind additional parameters on-the-fly, including the possibility to use a placeholder to denote the position of the variable parameter </dd> <dt> \_setscope util::test::UtilForeach_test Member \_internalref classutil_1_1test_1_1UtilForeach__test#a16e0d0ef9ec933332834cfb2ffb1b87a "UtilForeach_test::check_foreach_bind_const" (CO const &coll)</dt><dd> \anchor _test000628 the input sequence can be also taken from a const container (for iterators this obviously doesn't make sense <br> </dd> <dt> \_setscope util::test::UtilForeach_test Member \_internalref classutil_1_1test_1_1UtilForeach__test#a28a1fe26a3e62a36a9f21dd0972cceb7 "UtilForeach_test::check_foreach_lambda" (CO coll)</dt><dd> \anchor _test000632 use lambda-expressions, to be invoked for each element </dd> <dt> \_setscope util::test::UtilForeach_test Member \_internalref classutil_1_1test_1_1UtilForeach__test#a100e9fd54e72a1f467151fe8ba734206 "UtilForeach_test::check_foreach_memFun" (CO coll)</dt><dd> \anchor _test000630 bind a member function to be invoked for each element </dd> <dt> \_setscope util::test::UtilForeach_test Member \_internalref classutil_1_1test_1_1UtilForeach__test#aa9018117ce7877701a2438514ac41019 "UtilForeach_test::check_foreach_plain" (CO coll)</dt><dd> \anchor _test000624 invoke a simple free function, given as reference, function pointer or functor. The invoked test function will print its argument </dd> <dt> \_setscope util::test::UtilForeach_test Member \_internalref classutil_1_1test_1_1UtilForeach__test#ab1e76205c1a39bc408272be33cbeec3a "UtilForeach_test::check_invoke_on_each" ()</dt><dd> \anchor _test000635 the binding can also be used to \em dispatch an operation on each element within a object collection: here the parameter is used as \c this pointer to specify the object instance </dd> <dt> \_setscope util::test::UtilForeach_test Member \_internalref classutil_1_1test_1_1UtilForeach__test#a2c8886f798519dff32777b141b70f0f2 "UtilForeach_test::check_ref_argument_bind" (CO coll)</dt><dd> \anchor _test000626 under some circumstances, it is even possible to take a ref to the data in the input sequence, or to a summation variable. In the example performed here, the function to be applied takes the 3rd argument by reference and assigns the sum of first and second argument to this parameter. If we us a bind variable at that position, we end up assigning by reference to the values contained in the collection. </dd> <dt> \_setscope util::test::UtilForeach_test Member \_internalref classutil_1_1test_1_1UtilForeach__test#ac8a4fde8200fa2142d2991bcdd0fd3c5 "UtilForeach_test::check_wrapped_container_passing" (VecI coll)</dt><dd> \anchor _test000637 pass the collection to be iterated in various ways - anonymous temporary - smart pointer - pointer - const& </dd> <dt> \_setscope util::test::UtilIdentity_test Class \_internalref classutil_1_1test_1_1UtilIdentity__test "UtilIdentity_test" </dt><dd> \anchor _test000607 verify identity based on memory address location, which can be relevant for custom allocation schemes and to prevent self-assignment. - access to a given entitie's address is used as foundation, with the <em>special twist</em> that a pointer is »unpacked« - based on this address, an ID-number can be generated - moreover, two flavours of identity check are provided + util::isSameObject compares at the level of the <em>language object</em> — it takes its arguments <em>solely</em> by reference and does not »unpack« a pointer. The term <a href="https://en.cppreference.com/w/cpp/language/type.html" >object</a> is used here as in the C++ standard + util::isSameAdr accepts any mix of references and pointers, disregarding any type information, thereby <em>»unpacking«</em> the address information contained in a pointer is (i.e. the address of the pointee is used) </dd> <dt> \_setscope util::test::UtilIdentity_test Member \_internalref classutil_1_1test_1_1UtilIdentity__test#a6bba8503e137fdbc4ebdce7dc39b2fc4 "UtilIdentity_test::verify_addrID" ()</dt><dd> \anchor _test000612 generate a numeric ID based on the memory address. </dd> <dt> \_setscope util::test::UtilIdentity_test Member \_internalref classutil_1_1test_1_1UtilIdentity__test#a828d7cdbdbf77822cd04bdad29cd66ce "UtilIdentity_test::verify_getAdr" ()</dt><dd> \anchor _test000611 determine the address of an referred entity, possibly <em>unpacking</em> a pointer (using its content) </dd> <dt> \_setscope util::test::UtilIdentity_test Member \_internalref classutil_1_1test_1_1UtilIdentity__test#a55bc9c2f2c4f99d9db61cf27b74d2a29 "UtilIdentity_test::verify_isSameAdr" ()</dt><dd> \anchor _test000615 determine identity of referred arguments based on their memory location; pointers are unpacked, referring to the pointee. </dd> <dt> \_setscope util::test::UtilIdentity_test Member \_internalref classutil_1_1test_1_1UtilIdentity__test#ac74742018c42a40931b89d9059dd59e3 "UtilIdentity_test::verify_isSameObject" ()</dt><dd> \anchor _test000616 determine strictly the identity of referred entities as given. </dd> <dt> \_setscope util::test::UtilTuple_test Class \_internalref classutil_1_1test_1_1UtilTuple__test "UtilTuple_test" </dt><dd> \anchor _test000609 verify some convenience shortcuts and helpers for interplay of tuples and iterable sequences:. - unpack a sequence into a tuple of references </dd> <dt> \_setscope util::test::UtilTuple_test Member \_internalref classutil_1_1test_1_1UtilTuple__test#a9aa344bdc182415913fcdb8d6ae0c640 "UtilTuple_test::verify_unpackIterator" ()</dt><dd> \anchor _test000614 unpack a sequence into a tuple of references, usable for structural binding. </dd> <dt> \_setscope lib::meta::test::ValueTypeBinding_test Class \_internalref classlib_1_1meta_1_1test_1_1ValueTypeBinding__test "ValueTypeBinding_test" </dt><dd> \anchor _test000461 verify result type rebinding for containers, iterators values and references. When augmenting, combining or decorating generic entities, there is often the need to find out about the <tt>value_type</tt>, a <tt>reference</tt> or <tt>pointer</tt> to such a value. Many STL compliant containers and iterators provide suitably nested type definitions to indicate those types. The meta::TypeBinding helper allows to pick up such definitions, and additionally it levels and unifies access for various combinations of primitive types, references and pointers. The purpose of this test is to verify and document this behaviour.</dd> <dt> \_setscope lib::meta::test::VariadicArgumentPicker_test Class \_internalref classlib_1_1meta_1_1test_1_1VariadicArgumentPicker__test "VariadicArgumentPicker_test" </dt><dd> \anchor _test000464 check the basic utilities for manipulating variadic template arguments. - single out and pick an argument designated by index - pick an argument with fallback on default construction - demonstrate usage by reordering the position of arguments </dd> <dt> \_setscope lib::meta::test::VariadicArgumentPicker_test Member \_internalref classlib_1_1meta_1_1test_1_1VariadicArgumentPicker__test#a56e6ac4fa704a89698cf36c46ce8a511 "VariadicArgumentPicker_test::check_reorderedArguments" ()</dt><dd> \anchor _test000468 demonstrate reordering of arguments </dd> <dt> \_setscope lib::meta::test::VariadicHelper_test Class \_internalref classlib_1_1meta_1_1test_1_1VariadicHelper__test "VariadicHelper_test" </dt><dd> \anchor _test000463 Cover some advanced metaprogramming helpers to support working with <em>tuple like</em> types together with simple types. </dd> <dt> \_setscope lib::meta::test::VariadicHelper_test Member \_internalref classlib_1_1meta_1_1test_1_1VariadicHelper__test#abdb56e91eded224a907fc8b5d88f1886 "VariadicHelper_test::rebuild_variadic" ()</dt><dd> \anchor _test000465 demonstrate uniform handling of... - simple types, - <em>tuple-like</em> types (usable for structured binding) - <em>generic type sequences</em> </dd> <dt> \_setscope lib::test::Variant_test Class \_internalref classlib_1_1test_1_1Variant__test "Variant_test" </dt><dd> \anchor _test000620 cover the essential properties of Lumiera's lightweight variant record. - this typesafe union can never be constructed empty - it defaults to the default constructed first type in list - it is copyable and assignable, but only with compatible type - value access requires knowledge of the contained type - generic visitor style access</dd> <dt> \_setscope lib::test::VerbFunctionDispatch_test Class \_internalref classlib_1_1test_1_1VerbFunctionDispatch__test "VerbFunctionDispatch_test" </dt><dd> \anchor _test000646 Demonstration/Concept: dispatch a specific function based on the given verbs of an embedded custom language. Actually what we want to achieve here is a specific form of double dispatch; thus the implementation relies on a variation of the visitor pattern.</dd> <dt> \_setscope lib::test::VerbFunctionDispatch_test Member \_internalref classlib_1_1test_1_1VerbFunctionDispatch__test#a8f5b7b23e387c853d7646bbb9ddfbf11 "VerbFunctionDispatch_test::render_verbose" (VerbSeq tokens)</dt><dd> \anchor _test000648 demonstrate the dispatching based on the concrete verb token. Here the implementation just prints the name of the invoked verb </dd> <dt> \_setscope lib::test::VerbFunctionDispatch_test Member \_internalref classlib_1_1test_1_1VerbFunctionDispatch__test#aee5ee04dfe74a796c96b340eb67c375c "VerbFunctionDispatch_test::verify_dispatch" (VerbSeq tokens)</dt><dd> \anchor _test000649 verify the correct individual dispatch through a computation specific for the given verb </dd> <dt> \_setscope lib::test::VerbVisitorDispatch_test Class \_internalref classlib_1_1test_1_1VerbVisitorDispatch__test "VerbVisitorDispatch_test" </dt><dd> \anchor _test000627 Demonstration/Concept: build pre-bound VerbPack objects to embody a specific operation on the "receiver" interface, then invoke them on a given concrete implementation.</dd> <dt> \_setscope lib::test::VerbVisitorDispatch_test Member \_internalref classlib_1_1test_1_1VerbVisitorDispatch__test#a7cb2436f2b03b0a33e9d736d4a60a7ab "VerbVisitorDispatch_test::apply_different_receivers" (TokenSeq &tokens)</dt><dd> \anchor _test000641 demonstrate that another receiver indeed invokes different implementations of the Interface functions embedded within the Verb. Here the implementation just prints the name of the invoked verb and the arguments. </dd> <dt> \_setscope lib::test::VerbVisitorDispatch_test Member \_internalref classlib_1_1test_1_1VerbVisitorDispatch__test#a1103887856ac3515b12b403c2ce2a438 "VerbVisitorDispatch_test::apply_VerboseRenderer" (TokenSeq &tokens)</dt><dd> \anchor _test000640 demonstrate the dispatching based on the concrete verb token. Here the implementation just prints the name of the invoked verb </dd> <dt> \_setscope lib::test::VerbVisitorDispatch_test Member \_internalref classlib_1_1test_1_1VerbVisitorDispatch__test#a4eac47fb8dd724d3369aabe1f202d310 "VerbVisitorDispatch_test::build_and_copy_tokens" ()</dt><dd> \anchor _test000639 verify the correct individual dispatch through a computation specific for the given verb </dd> <dt> \_setscope stage::model::test::ViewHook_test Class \_internalref classstage_1_1model_1_1test_1_1ViewHook__test "ViewHook_test" </dt><dd> \anchor _test000663 verify the mechanism to attach widgets to a canvas, while keeping the canvas implementation itself opaque. - manage the attachment and detach automatically - ability to adjust the location parameter of an existing attachment - ability to re-attach existing attachments in a new sequence order </dd> <dt> \_setscope stage::model::test::ViewHook_test Member \_internalref classstage_1_1model_1_1test_1_1ViewHook__test#af0222477886b8b16aba6fb3380e08054 "ViewHook_test::reOrderHooked" ()</dt><dd> \anchor _test000668 a mechanism to re-attach elements in changed order. </dd> <dt> \_setscope stage::model::test::ViewHook_test Member \_internalref classstage_1_1model_1_1test_1_1ViewHook__test#ae1f1d4c814cd56c56177397ce5f73d81 "ViewHook_test::verify_multiplicity" ()</dt><dd> \anchor _test000667 each hooking has a distinct identity and is managed on its own. </dd> <dt> \_setscope stage::model::test::ViewHook_test Member \_internalref classstage_1_1model_1_1test_1_1ViewHook__test#a5177c031967d8c95052dec2e8ef4b1f1 "ViewHook_test::verify_standardUsage" ()</dt><dd> \anchor _test000666 the standard use case is to hook up a widget to a canvas for display. </dd> <dt> \_setscope stage::interact::test::ViewSpecDSL_test Class \_internalref classstage_1_1interact_1_1test_1_1ViewSpecDSL__test "ViewSpecDSL_test" </dt><dd> \anchor _test000644 verify the mechanics of a functor based internal DSL to configure access and allocation patters for component views.</dd> <dt> \_setscope stage::interact::test::ViewSpecDSL_test Member \_internalref classstage_1_1interact_1_1test_1_1ViewSpecDSL__test#aeb3751660b46ce91849f87e9bb8c5a18 "ViewSpecDSL_test::verify_genericInvocation" ()</dt><dd> \anchor _test000645 generic integrated access through ViewLocator This test demonstrates and verifies the way ViewLocator combines type based selection of the applicable DSL clauses, the invocation of those DSL definitions, the allocation of a suitable element and finally specifically typed access to this located or allocated element. </dd> <dt> \_setscope lib::meta::test::VirtualCopySupport_test Class \_internalref classlib_1_1meta_1_1test_1_1VirtualCopySupport__test "VirtualCopySupport_test" </dt><dd> \anchor _test000469 verify a mechanism to allow for cloning and placement new of opaque, type-erased entities. Basically we allow only assignments and copy between objects of the same concrete type, but we want to initiate those operations from the base interface, without any further knowledge about the actual types involved. </dd> <dt> \_setscope lib::meta::test::VirtualCopySupport_test Member \_internalref classlib_1_1meta_1_1test_1_1VirtualCopySupport__test#ab5fd7dfb465fc3e7552f064e254256d0 "VirtualCopySupport_test::verify_TestFixture" ()</dt><dd> \anchor _test000475 our test fixture is comprised of - a common interface (#Interface) - a implementation template #Sub to hold a buffer and manage a distinct random value at some position in that buffer, which depends on the concrete implementation type - layered on top are adapters to make this implementation class either fully copyable, non-assignable, only movable or noncopyable. - a global checksum, based on the random value of all instances, which are incremented on construction and decremented on destruction. After destroying everything this checksum should go to zero. This test case just verifies this implementation mechanic. </dd> <dt> \_setscope lumiera::visitor_concept_draft::test::VisitingTool_concept Class \_internalref classlumiera_1_1visitor__concept__draft_1_1test_1_1VisitingTool__concept "VisitingTool_concept" </dt><dd> \anchor _test000052 build and run some common cases for developing and verifying ichthyo's implementation concept for the Visitor Pattern. Defines a hierarchy of test classes to check the following cases </dd> <dt> \_setscope lib::visitor::test1::VisitingTool_test Class \_internalref classlib_1_1visitor_1_1test1_1_1VisitingTool__test "VisitingTool_test" </dt><dd> \anchor _test000043 our lib implementation of the visitor pattern. Defines a hierarchy of test classes to check the following cases - calling the correct visiting tool specialised function for given concrete hierarchy classes - visiting tool not declaring to visit some class is silently ignored by default - newly added classes will be handled by existing functions according to inheritance relations </dd> <dt> \_setscope lib::visitor::test2::VisitingToolExtended_test Class \_internalref classlib_1_1visitor_1_1test2_1_1VisitingToolExtended__test "VisitingToolExtended_test" </dt><dd> \anchor _test000045 more esoteric corner cases of our visitor lib implementation. Defines a hierarchy of test classes, which mix two different kinds of "visitable" by two disjoint tool base classes. One of these base classes uses an explicit error handling catch-all-function. </dd> <dt> \_setscope stage::model::test::WLink_test Class \_internalref classstage_1_1model_1_1test_1_1WLink__test "WLink_test" </dt><dd> \anchor _test000657 verify proper behaviour of a smart-link to a <tt>sigc::trackable</tt> GTK widget. </dd> <dt> \_setscope stage::model::test::WLink_test Member \_internalref classstage_1_1model_1_1test_1_1WLink__test#a37cbeebcc5d5c1f1d1e727a17f3cd5ae "WLink_test::verify_copy" ()</dt><dd> \anchor _test000661 registration state is properly handled on copy, move and swap </dd> <dt> \_setscope stage::model::test::WLink_test Member \_internalref classstage_1_1model_1_1test_1_1WLink__test#aaed4521bf3f033f409c19dc5c86ed133 "WLink_test::verify_reconnect" ()</dt><dd> \anchor _test000660 registration is automatically maintained when re-assigning targets </dd> <dt> \_setscope stage::model::test::WLink_test Member \_internalref classstage_1_1model_1_1test_1_1WLink__test#a5177c031967d8c95052dec2e8ef4b1f1 "WLink_test::verify_standardUsage" ()</dt><dd> \anchor _test000659 the standard use case is to hold onto a widget owned by <em>someone else</em>, with automatic disconnection </dd> <dt> \_setscope vault::gear::test::WorkForce_test Class \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test "WorkForce_test" </dt><dd> \anchor _test000768 WorkForce-Service: maintain a pool of active worker threads. </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#a749d41d8b96d53f2e6bc58c1a1a2e71a "WorkForce_test::simpleUsage" ()</dt><dd> \anchor _test000774 demonstrate simple worker pool usage </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#af507390f2be7526680e66df0ddcf5c4f "WorkForce_test::verify_countActive" ()</dt><dd> \anchor _test000784 dynamically determine count of currently active workers. </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#a298b7fcb0d253079946b21735c6db04f "WorkForce_test::verify_defaultPool" ()</dt><dd> \anchor _test000782 by default, the WorkForce is initially inactive; once activated, it scales up to the number of cores reported by the runtime system. </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#afc7709af8ac955fd2ae16b4cda0385fa "WorkForce_test::verify_detectError" ()</dt><dd> \anchor _test000781 exceptions emanating from within the worker are catched and reported by setting the isFailure argument flag of the <tt>finalHook</tt> functor invoked at worker termination. </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#ae9ac0dee9c53c8b0c196249c124cec8d "WorkForce_test::verify_dtor_blocks" ()</dt><dd> \anchor _test000785 verify that the WorkForce dtor waits for all active threads to disappear - use a work-functor which keeps all workers blocked - start the WorkForce within a separate thread - in this separate thread, cause the WorkForce destructor to be called - in the test main thread release the work-functor blocking - at this point, all workers return, detect shutdown and terminate </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#a1fb05e6a03b9820d87bdf5ea328ee93a "WorkForce_test::verify_finalHook" ()</dt><dd> \anchor _test000780 verify invocation of a thread-termination callback </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#afd1e8edb3f807866fb72dc999eb6310f "WorkForce_test::verify_pullWork" ()</dt><dd> \anchor _test000775 the given work-functor is invoked repeatedly, once activated. </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#ad80fbd9e412557947d1a575b0b5dba9e "WorkForce_test::verify_scalePool" ()</dt><dd> \anchor _test000783 the number of (separate) workers can be scaled up, both stepwise and as fraction of full hardware concurrency </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#aa2e36a0397a476d600764aa6b3f8fb41 "WorkForce_test::verify_workerDismiss" ()</dt><dd> \anchor _test000779 when a worker is sent into sleep-cycles for an extended time, the worker terminates itself. </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#a5fdec3975bef7b98d1c1261d55009ffb "WorkForce_test::verify_workerHalt" ()</dt><dd> \anchor _test000776 can cause a worker to terminate by return-value from the work-functor </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#a6ed94f99cdc2855b311d7a0d941cd20a "WorkForce_test::verify_workerRetard" ()</dt><dd> \anchor _test000778 a worker can be retarded and throttled in case of contention. </dd> <dt> \_setscope vault::gear::test::WorkForce_test Member \_internalref classvault_1_1gear_1_1test_1_1WorkForce__test#a507a20903ac6eb809ac47fe44d9aceae "WorkForce_test::verify_workerSleep" ()</dt><dd> \anchor _test000777 a worker can be sent to sleep, throttling the poll frequency. </dd> <dt> \_setscope lib::test::ZombieCheck_test Class \_internalref classlib_1_1test_1_1ZombieCheck__test "ZombieCheck_test" </dt><dd> \anchor _test000044 verify the ability to trap access to deceased objects. </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Class \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test "ZoomWindow_test" </dt><dd> \anchor _test000688 verify consistent handling of scrolling and zoom settings for the timeline. - setting the overall range - setting the visible range - adjusting the scale factor - setting a visible position - nudging the position - nudging the scale factor </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a467b4b2a9d240c8750653717810295dc "ZoomWindow_test::safeguard_extremeOffset" ()</dt><dd> \anchor _test000736 verify ZoomWindow code is protected against excess scrolling. </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#aa2170e788f811deded76abe67d1b089a "ZoomWindow_test::safeguard_extremeTimePos" ()</dt><dd> \anchor _test000735 verify ZoomWindow code can navigate extremal time positions, thereby observing domain bounds without numeric wrap. </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#af02b719a29a26404d3ada79f74a2be8c "ZoomWindow_test::safeguard_extremeZoomOut" ()</dt><dd> \anchor _test000734 verify ZoomWindow code can handle extreme zoom-out to reveal a timeline of epic dimensions.... </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a65f00ba3f702896906c2069d8a1066ab "ZoomWindow_test::safeguard_poisonousMetric" ()</dt><dd> \anchor _test000730 verify ZoomWindow code can handle "poisonous" fractional number parameters - toxic zoom factor passed through ZoomWindow::setMetric(Rat) - toxic proportion factor passed to ZoomWindow::setVisiblePos(Rat) - indirectly cause toxic posFactor in ZoomWindow::anchorWindowAtPosition(FSecs) by providing a target position very far off current window location </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a68f84c35096d34e673632bab11fe5130 "ZoomWindow_test::safeguard_reversed_intervals" ()</dt><dd> \anchor _test000725 verify safeguards against reversed time intervals </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a4893bef6a0eb1c1db5d680847bba1ea6 "ZoomWindow_test::safeguard_toxic_zoomFactor" ()</dt><dd> \anchor _test000727 demonstrate sanitising of "poisonous" fractional zoom factor - construct an example factor of roughly 2/3, but using extremely large numerator and denominator close to total time axis dimensions. - even simple calculations with this poison value will fail - construct a new quantiser, based on the number to be sanitised - re-quantise the toxic number into this new quantiser - the sanitised number is almost identical to the toxic original - yet all the simple calculations can be carried out flawlessly - both toxic and sanitised number lead to the same zoom timespan </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a5298e5bb89a844d730fa4cf1398480f7 "ZoomWindow_test::safeguard_veryDeep" ()</dt><dd> \anchor _test000739 verify ZoomWindow and handle extreme zoom-in. - scrolling has always an effect - visible window is never void </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a9c74019600e7e9389f786a1518d6273c "ZoomWindow_test::safeguard_verySmall" ()</dt><dd> \anchor _test000737 verify ZoomWindow can handle excessively small windows. </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a42ba67ad88d6bbaa2006251a65f20dc2 "ZoomWindow_test::safeguard_zero_init" ()</dt><dd> \anchor _test000724 verify safeguards against empty initialisation interval </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a839a2793ec11ab41455eef39fe48f12f "ZoomWindow_test::verify_calibration" ()</dt><dd> \anchor _test000714 verify defining and retaining the effective extension in pixels - changes to the extension are applied by adjusting the visible window - visible window's start position is maintained - unless the resulting window would exceed the overall canvas, in which case the window is shifted, retaining metrics - however, if resulting window can not be made to fit, it is truncated to current canvas and metric is adjusted to keep overall pixel extension </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a367775b99e7efd71c5e7c1bce7d669f8 "ZoomWindow_test::verify_changeNotification" ()</dt><dd> \anchor _test000722 a notification-λ can be attached and will be triggered on each change </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a8eb81386546f6ec51e8a0d203886530a "ZoomWindow_test::verify_metric" ()</dt><dd> \anchor _test000716 zoom in and out, thereby adjusting the metric - window extension in pixels is always retained - window is shifted when surpassing canvas bounds - metric is adjusted to keep excess window within pixel extension - otherwise zooming is centred around an anchor position, favouring centre </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a0f011cd232c84aa9a8d5dff6075f747a "ZoomWindow_test::verify_scroll" ()</dt><dd> \anchor _test000720 sliding the visible window, possibly expanding canvas </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a7fa9455d94d012a781eb44a48f6c1cf6 "ZoomWindow_test::verify_setup" ()</dt><dd> \anchor _test000712 verify the possible variations for initial setup of the zoom window - can be defined either with the canvas duration, or an explicit extension given in pixels, or both - after construction, visible window always covers whole canvas - window extension, when given, defines the initial metric - otherwise pixel extension is derived from default metric </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a0f67b19bc1b6b0b6d891b5beffa0c631 "ZoomWindow_test::verify_simpleUsage" ()</dt><dd> \anchor _test000708 simple usage example: double the zoom level, then scroll to the left </dd> <dt> \_setscope stage::model::test::ZoomWindow_test Member \_internalref classstage_1_1model_1_1test_1_1ZoomWindow__test#a24e7687971e4e694fa8406d44a828a8c "ZoomWindow_test::verify_window" () position and extension of the visible window can be set explicitly