basically we had two lines of doubly nested capsules, due to
using the IterAdaptor template. Actually, the evaluation stack
within JobTicket can be considered an implementation detail and
thus doesn't require an iterator interface; the intention is to
use this through JobPlanning solely.
Thus this reworking removes the special iterator within JobTicket,
but retains the idea of exposing the "current" JobTicket through
a smart pointer or operator->()
work done during the FrOSCon travel
especially the exploration stack is pushed down
first successful definition of all the JobPlanning classes
just the framework of classes necessary to pass the compiler;
all implementation is still stubbed
brainstorming how to implement the job planning stage
the idea is to built on top of the IterExplorer,
but have the "stack" of re-evaluation integrated
into a custom type, which exploits the static
node network structure to avoid heap allocations
solution idea: again use a builder function?
the template _Fun started as an internal helper
for function-closure, but seems to be of
general use. Thus move it into meta/function.hpp
(function-closure.hpp is heavyweight)
this enables expansion of a (functional) data structure
until exhaustion -- which is what we need to
build job functors by traversing and expanding
an arbitrarily nested job definition structure
the intention is to use this to simplify
generating render jobs based on the elaborated
dependency network of the render nodes. The key
challenge is to overcome the necessity to
store partially done evaluations as
continuation
the tricky part seems to be how to combine the
source iterators into a new monad instance, while
keeping this "Combinator" Strategy configurable
...just passes the compiler, while still lacking
even the generic implementation of joining
together the source iterators
The idea is to avoid building a data structure
for intermediary results, while still being able
to process a variably sized and arbitrary shaped
set of source data
without any trickery, we'll always get two indirections.
Thus, the decision is to turn the 2nd indirection
into a VTable call; this way, basically the JobClosure
also acts as job functor itself.
implemented as extension to the linear combinations.
I decided to use the same "always floor" rule
as employed for time quantisation. Moreover,
we don't support floating point, only rationals
funny enough this possible memory corruption
didn't happen in the unit test, because my
compiler optimised the additional int field
of class SubDummy, making it the same size
of the baseclass. Now matters should be safe.
