ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/src/steam/engine/weaving-pattern-builder.hpp

154 lines
4.8 KiB
C++
Raw Normal View History

Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
/*
WEAVING-PATTERN-BUILDER.hpp - build an invocation pattern for media calculations
Copyright (C) Lumiera.org
2024, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/** @file weaving-pattern-builder.hpp
** Construction kit for establishing an invocation scheme for media calculations.
**
** @see turnout.hpp
** @see node-builder.hpp
** @see NodeLinkage_test
**
** @todo WIP-WIP-WIP as of 7/2024 prototyping how to build and invoke render nodes /////////////////////////TICKET #1367
**
*/
#ifndef STEAM_ENGINE_WEAVING_PATTERN_BUILDER_H
#define STEAM_ENGINE_WEAVING_PATTERN_BUILDER_H
//#include "steam/common.hpp"
//#include "steam/engine/channel-descriptor.hpp"
//#include "vault/gear/job.h"
#include "lib/several-builder.hpp"
#include "steam/engine/turnout.hpp"
Invocation: introduce engine-context for dependency injection ...by relying on DI for some effectively global services, notably the cache provider, the API for building and wiring render nodes can be simplified to cover only the actual node connectivity
2024-08-03 03:21:59 +02:00
#include "steam/engine/engine-ctx.hpp"
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
#include "steam/engine/buffer-provider.hpp"
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
//#include "lib/util-foreach.hpp"
//#include "lib/iter-adapter.hpp"
//#include "lib/meta/function.hpp"
//#include "lib/itertools.hpp"
//#include "lib/util.hpp"
//#include <utility>
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
#include <functional>
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
//#include <array>
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
#include <vector>
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
namespace steam {
namespace engine {
using std::forward;
using lib::Several;
template<class POL, class I, class E=I>
using DataBuilder = lib::SeveralBuilder<I,E, POL::template Policy>;
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Prototyping: how to assemble a Turnout
template<uint N, class FUN>
using SimpleDirectInvoke = SimpleWeavingPattern<Conf_DirectFunctionInvocation<N,FUN>>;
template<class POL, uint N, class FUN>
struct SimpleWeavingBuilder
: util::MoveOnly
{
DataBuilder<POL, PortRef> leadPort;
DataBuilder<POL, BuffDescr> outTypes;
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
using TypeMarker = std::function<BuffDescr(BufferProvider&)>;
using ProviderRef = std::reference_wrapper<BufferProvider>;
std::vector<TypeMarker> buffTypes;
std::vector<ProviderRef> providers;
Invocation: investigate ways to configure the output-info ...still not convinced that this is a good design, since it seems to subvert the general design to treat one special case. However, I can't see a good way to address this special case directly
2024-07-30 23:44:55 +02:00
uint resultSlot{0};
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
struct ServiceCtx
{
ProviderRef mem;
ProviderRef cache;
ProviderRef output;
};
ServiceCtx ctx; //////////////////////////////////////////OOO need to wire that top-down through all builders!
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
SimpleWeavingBuilder
attachToLeadPort(ProcNode& lead, uint portNr)
{
PortRef portRef; /////////////////////////////////////OOO TODO need Accessor on ProcNode!!!!!
leadPort.emplace (portRef);
ENSURE (leadPort.size() < N);
return move(*this);
}
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
template<class BU>
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
SimpleWeavingBuilder
Invocation: investigate ways to configure the output-info ...still not convinced that this is a good design, since it seems to subvert the general design to treat one special case. However, I can't see a good way to address this special case directly
2024-07-30 23:44:55 +02:00
appendBufferTypes(uint cnt)
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
{
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
while (cnt--)
buffTypes.emplace_back([](BufferProvider& provider)
{ return provider.getDescriptor<BU>(); });
ENSURE (buffTypes.size() < N);
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
return move(*this);
}
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
SimpleWeavingBuilder
Invocation: investigate ways to configure the output-info ...still not convinced that this is a good design, since it seems to subvert the general design to treat one special case. However, I can't see a good way to address this special case directly
2024-07-30 23:44:55 +02:00
selectResultSlot(uint idx)
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
{
Invocation: investigate ways to configure the output-info ...still not convinced that this is a good design, since it seems to subvert the general design to treat one special case. However, I can't see a good way to address this special case directly
2024-07-30 23:44:55 +02:00
this->resultSlot = idx;
return move(*this);
}
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
auto
build()
{
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
maybeFillDefaultProviders (buffTypes.size());
uint i=0;
Invocation: investigate ways to configure the output-info ...still not convinced that this is a good design, since it seems to subvert the general design to treat one special case. However, I can't see a good way to address this special case directly
2024-07-30 23:44:55 +02:00
for (auto& typeConstructor : buffTypes)
outTypes.emplace (
typeConstructor (providers[i]));
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
ENSURE (leadPort.size() < N);
ENSURE (outTypes.size() < N);
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
using Product = Turnout<SimpleDirectInvoke<N,FUN>>;
///////////////////////////////OOO need a way to prepare SeveralBuilder-instances for leadPort and outDescr --> see NodeBuilder
Invocation: investigate ways to configure the output-info ...still not convinced that this is a good design, since it seems to subvert the general design to treat one special case. However, I can't see a good way to address this special case directly
2024-07-30 23:44:55 +02:00
return Product{leadPort.build(), outTypes.build()};
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
}
Invocation: Prototyping to clarify buffer type marking Requirement analysis shows that the ''actual buffer provider'' to use constitutes yet another independent degree of freedom, which conceivably must be handled by the Builder internals rather than by the Domain Ontology. Thus the simple solution to use a `BuffDescr` to mark the type must be augmented to also allow configuration of the underlying `BufferProvider`, which generates the descriptor and can later be invoked with this descriptor to ''lock an actual Buffer.'' In some cases, setup of the buffer types could even be more complicated and require access to the actual (runtime) invocaton context; such extreme cases however could be rendered as an extension of the scheme established here, by storing the (up to now transient) constructor functors persistently. Which leads to the decision not to care for those extremely complicated corner cases right now, and thus to construct all buffer descriptors in the `build()` call
2024-07-24 20:29:37 +02:00
private:
void
maybeFillDefaultProviders (size_t maxSlots)
{
for (uint i=providers.size(); i < maxSlots; ++i)
providers.emplace_back (ctx.mem);
}
Invocation: Prototyping how to setup invocation wiring ...still fighting to find a suitable API to define how inputs and outputs are connected and mapped to function parameters. The solution drafted here uses the reshaped `DataBuilder` (≙`lib::SeveralBuilder`) to add up connections for each »slot«, disregarding the possibility of permutations. Similar to `NodeBuilder`, a policy template is used to pass down the setup for an actual custom allocator.
2024-07-23 03:52:44 +02:00
};
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : (End)Prototyping: how to assemble a Turnout
}}// namespace steam::engine
#endif /*STEAM_ENGINE_WEAVING_PATTERN_BUILDER_H*/
Reference in a new issue Copy permalink