BufferProvider: experiment for callback configuration
Now I have a working setup for a `BufferProxyAdaptor`. Unfortunately this is still confusingly complex. This is due to my intention to build a generic template, that can be configured with a policy to invoke arbitrary callbacks, whenever one of the passed-through buffers transitions through its lifecycle. * we need to configure the `BufferProviderSetup` to use our specific implementation classes * and the second one of these, our `BufferStore` implementation needs to invoke the callbacks
This commit is contained in:
parent
5a203513c9
commit
02ba977c61
4 changed files with 186 additions and 111 deletions
|
|
@ -225,7 +225,8 @@ namespace engine {
|
|||
Key newKey{parent}; // copy of parent as baseline
|
||||
if (nontrivial(localTag))
|
||||
{
|
||||
if (nontrivial(parent.specifics_))
|
||||
if (nontrivial(parent.specifics_)
|
||||
and localTag != parent.specifics_)
|
||||
throw error::Logic{"Implementation defined local key should not be overridden. "
|
||||
"Underlying buffer type already defines a nontrivial LocalTag"};
|
||||
newKey.parent_ = HashVal(parent);
|
||||
|
|
|
|||
|
|
@ -48,6 +48,7 @@ namespace engine {
|
|||
using lib::Literal;
|
||||
// using std::unique_ptr;
|
||||
// using std::forward;
|
||||
using std::move;
|
||||
|
||||
|
||||
|
||||
|
|
@ -65,6 +66,7 @@ namespace engine {
|
|||
* @todo WIP-WIP 2/2026 used as prototype to forge a path ahead to resolve
|
||||
* the structural problems with OutputSlot vs. BufferProvider ///////////////////////////////////////TICKET #1415 : prototyping to resolve structural mismatch between OutputSlot / DataSink / BufferProvider
|
||||
*/
|
||||
template<class CONF>
|
||||
class BufferProxyAdaptor
|
||||
: util::NonCopyable
|
||||
{
|
||||
|
|
@ -81,6 +83,8 @@ namespace engine {
|
|||
class ProxyBufferStore
|
||||
: public BufferProviderSetup::Store
|
||||
{
|
||||
CONF& callback_;
|
||||
|
||||
Buff*
|
||||
asBuffer (LocalTag targetMarker)
|
||||
{
|
||||
|
|
@ -99,36 +103,38 @@ namespace engine {
|
|||
Slot
|
||||
provideBuffer (size_t,HashVal, LocalTag targetMarker) override
|
||||
{
|
||||
TODO ("invoke LOCK callback");
|
||||
callback_.on_lock();
|
||||
return {asBuffer(targetMarker), targetMarker};
|
||||
}
|
||||
|
||||
void
|
||||
mark_emitted (size_t,HashVal, LocalTag const&) override
|
||||
{
|
||||
TODO ("invoke EMIT callback");
|
||||
callback_.on_emit();
|
||||
}
|
||||
|
||||
void
|
||||
detachBuffer (size_t,HashVal,Slot) override
|
||||
{
|
||||
TODO ("invoke RELEASE callback");
|
||||
callback_.on_release();
|
||||
}
|
||||
|
||||
public:
|
||||
ProxyBufferStore (CONF& policy)
|
||||
: callback_{policy}
|
||||
{ }
|
||||
};
|
||||
|
||||
class PassThroughBufferProvider
|
||||
: public BufferProviderSetup
|
||||
{
|
||||
|
||||
|
||||
public:
|
||||
PassThroughBufferProvider ()
|
||||
: BufferProviderSetup{*this}
|
||||
template<class SETUP>
|
||||
PassThroughBufferProvider (SETUP& setup)
|
||||
: BufferProviderSetup{setup}
|
||||
{ }
|
||||
|
||||
auto buildStage() { return std::make_unique<PreRiggedBufferStage>(); }
|
||||
auto buildStore() { return std::make_unique<ProxyBufferStore>(); }
|
||||
|
||||
BuffDescr
|
||||
registerBuffer (void* buff, size_t siz)
|
||||
{
|
||||
|
|
@ -139,12 +145,21 @@ namespace engine {
|
|||
}
|
||||
};
|
||||
|
||||
struct Setup
|
||||
: CONF
|
||||
{
|
||||
auto buildStage() { return std::make_unique<PreRiggedBufferStage>(); }
|
||||
auto buildStore() { return std::make_unique<ProxyBufferStore>(*this); }
|
||||
};
|
||||
Setup setup_;
|
||||
|
||||
PassThroughBufferProvider proxyProvider_;
|
||||
|
||||
|
||||
public:
|
||||
BufferProxyAdaptor()
|
||||
: proxyProvider_{}
|
||||
BufferProxyAdaptor(CONF policy)
|
||||
: setup_{move(policy)}
|
||||
, proxyProvider_{setup_}
|
||||
{ }
|
||||
|
||||
template<typename TAR>
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
//#include "steam/play/diagnostic-output-slot.hpp"
|
||||
#include "steam/engine/buffer-proxy-adaptor.hpp"
|
||||
#include "steam/engine/test-rand-ontology.hpp"
|
||||
|
||||
#include "lib/test/diagnostic-output.hpp"
|
||||
|
||||
|
||||
namespace steam {
|
||||
|
|
@ -35,11 +35,6 @@ namespace test {
|
|||
* @test verify the design of OutputSlot and BufferProvider by
|
||||
* implementing a delegating BufferProvider to expose
|
||||
* output data buffers provided from _some implementation._
|
||||
* @todo WIP-WIP 12/2024 this turned out to be impossible,
|
||||
* due to inconsistencies in the default implementation. /////////////////////////////////////////////TICKET #1387 : need to consolidate BufferProvider default implementation
|
||||
* @todo 2/2026 broken by refactoring of BufferProvider //////////////////////////////////////////////TICKET #1410 : refactoring to separate external and implementation API
|
||||
* @todo however, something along this lines *must*
|
||||
* be made possible, somehow, for OutputSlot...
|
||||
* @todo 2/2026 now using this setup for prototyping /////////////////////////////////////////////////TICKET #1415 : explore this design idea through prototyping
|
||||
*/
|
||||
class OutputProxyProvider_test : public Test
|
||||
|
|
@ -47,10 +42,15 @@ namespace test {
|
|||
virtual void
|
||||
run (Arg)
|
||||
{
|
||||
size_t seenID{0};
|
||||
BufferState lastState{NIL};
|
||||
struct Callback
|
||||
{
|
||||
void on_lock() { cout << "LOCK" << endl; }
|
||||
void on_emit() { cout << "EMIT" << endl; }
|
||||
void on_release() { cout << "RELEASE" << endl; }
|
||||
};
|
||||
|
||||
// setup with notification callback
|
||||
BufferProxyAdaptor proxPro{};
|
||||
BufferProxyAdaptor proxPro{Callback()};
|
||||
|
||||
// Assuming some data block is »given«
|
||||
seedRand();
|
||||
|
|
@ -58,7 +58,7 @@ namespace test {
|
|||
TestFrame dataBlock (frameNr);
|
||||
CHECK ( dataBlock.isPristine());
|
||||
|
||||
BuffHandle handle = proxPro.lockBuffer (dataBlock); ///////////////////////////////////////////////TICKET #1387 : unable to implement this
|
||||
BuffHandle handle = proxPro.lockBuffer (dataBlock);
|
||||
|
||||
// Now a »client« can do awful things to the buffer...
|
||||
CHECK (handle.isValid());
|
||||
|
|
|
|||
|
|
@ -61678,41 +61678,32 @@
|
|||
<node COLOR="#435e98" CREATED="1771788793398" FOLDED="true" ID="ID_1642148991" MODIFIED="1771803623517" TEXT="2026/02 re-seeding-Hook schaffen">
|
||||
<node CREATED="1771788805420" ID="ID_1256962982" MODIFIED="1771789656478" TEXT="Begründung">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Es wird in Zukunft immer wieder Einrichtungen geben, die neu re-seeded werden müssen, um deterministisch zu sein. Dieses re-Seeding muß zuverlässig und reproduzierbar erfolgen, nachdem der globale PRNG neu initialisiert wurde.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<node CREATED="1771789666980" ID="ID_981389862" MODIFIED="1771789803408" TEXT="relevant für...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...jede Art von Einrichtung, die in komplexer Weise vom Random-Seed abhängt, und bei korrektem Setup deterministisch gemacht werden kann; also immer dann, wenn dieses Setup »schwierig« wird! Als Kontrast: für einen banalen Test zieht man sich einfach eine Zufallszahl und gut is; inwiefern das Test-Ergabnis von dieser Zufallszahl abhängt, ist in einem solchen Fall komplett offensichtlich.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771789805546" ID="ID_400533719" MODIFIED="1771790039049" TEXT="TestFrame">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
TestFrame definiert nicht nur einen Mechanismus, einen Datenblock von Zufallszahlen zu erzeugen, sondern er definiert auch deterministische Sequenzen und Familien solcher Sequenzen. Diese werden aus einem »Diskriminator« gebildet. Per TestFrame::reseed() verwirft man <b>alle bestehenden Testframes<i> </i></b>und zieht einen neuen Diskriminator. Sofern ein Test mit Test-Frames <i>einzeln</i> reproduzierbar sein soll, muß dieres reseed() aufgerufen werden. Das übersieht man natürlich leicht, denn normalerweise will man solche Tests nicht deterministisch wiederholen (was solange gilt, bis es mal ein ernstes Problem gibt)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#422ac0" DESTINATION="ID_400533719" ENDARROW="Default" ENDINCLINATION="560;-60;" ID="Arrow_ID_1144401880" SOURCE="ID_1471348244" STARTARROW="None" STARTINCLINATION="59;634;"/>
|
||||
<node COLOR="#338800" CREATED="1771803415569" HGAP="27" ID="ID_1924672804" MODIFIED="1771803444630" TEXT="registriert sich jetzt automatisch für random-reseed" VSHIFT="13">
|
||||
<icon BUILTIN="idea"/>
|
||||
|
|
@ -61725,29 +61716,23 @@
|
|||
<node CREATED="1771790075663" ID="ID_199419157" MODIFIED="1771790086593" TEXT="soll nicht »global« sein"/>
|
||||
<node CREATED="1771790095335" ID="ID_1384451064" MODIFIED="1771790139494" TEXT="ist keine Vorgabe für die Applikation selber">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Wenn die Lumiera-Applikation mal etwas Vergleichbares braucht, muß es anderweitig an den Application-Lifecycle gebunden werden
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771790141343" ID="ID_82436164" MODIFIED="1771790159436">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
soll aber <i>ohne Weiteres</i> stets für jeden Test verfügbar sein
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771790162692" ID="ID_1146500637" MODIFIED="1771790172217" TEXT="⟹ gehört ins Test-Framework"/>
|
||||
</node>
|
||||
|
|
@ -61759,9 +61744,7 @@
|
|||
<node CREATED="1771790516661" ID="ID_240891815" MODIFIED="1771790530643" TEXT="wie »flexibel« und »aufwendig« können wir uns leisten?">
|
||||
<node CREATED="1771790541501" ID="ID_6099611" MODIFIED="1771790592906" TEXT="klarer Fall von YAGNI !">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Explizit ausformuliert:
|
||||
|
|
@ -61775,70 +61758,55 @@
|
|||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771790594730" ID="ID_57250862" MODIFIED="1771790600805" TEXT="denkbare Spannbreite">
|
||||
<node CREATED="1771790773155" ID="ID_1631916355" MODIFIED="1771790890048" TEXT="eine zentrale Implementierungs-Funktion mit hart gecodeten Aufrufen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Jede Einrichtung, die am re-Seeding teilnehmen muß, hat sich da selbst in den Code zu integrieren. Sobald sich diese Integrierung ändert, ändert sich der Seed für alle Beteiligten. Aufgrund der Layer-Ordnung können nur Library-Einrichtungen an einem solchen Setup teilnehmen; alles oberhalb muß dann auf weitere, verteilte Random-Generatoren aufbauen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771790606212" ID="ID_1443915290" MODIFIED="1771791021498" TEXT="ein Reseeding-System, mit dem eine feste Reihenfolge garantiert wird">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
irgend ein Koordiniertungs-System, entweder compile-time oder run-time. Es muß sicherstellen, daß Partizipatoren leicht hinzukonfiguriert werden können, idealerweise automatisch, indem man einen Header includiert. Weiterhin muß aber sichergestellt werden, daß die Ordnung der Zuteilung stabil bleibt. Konsequenz: das wird aufwendiger als es auf den ersten Blick aussieht; dafür ist die Aufgabe für die Konsumenten des Random-Seed sehr einfach
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771790638283" ID="ID_847997173" MODIFIED="1771791176690" TEXT="lediglich einen Master-Seed bereitstellen — jeder muß seinen eigenen Generator verwalten">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Auch bei dieser Variante gibt es einen Registrierungs-Hook, der sehr bequem automatisiert wird. Allerdings liefert er nur <i>einen einzigen Seed-Wert identisch an alle Konsumenten.</i> Jeder Konsument muß daher zwingend seinen eigenen, lokalen Random-Generator verwalten und darf nirgends lib::defaultGen verwenden. Wenn mehr als ein einziger Client diese Regel mißachtet, bricht das System zusammen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771790731312" ID="ID_1007624727" MODIFIED="1771791752741" TEXT="eine Registrierung auf ein Application-Event">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Dieser Ansatz ist mit den beiden zuvor genannten Varianten kombinierbar. Es erlaubt dann beliebigen Komponenten in verschiedensten Setups, automatisch am re-Seeding teilzunehmen. Effektiv läuft das aber darauf hinaus, auch getrennte Generatoren für jeden Konsumenten zu verlangen, also keine bequeme Library-Funktion mehr!
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1771791759624" ID="ID_459999408" MODIFIED="1771791773321" TEXT="ich sehe folgende Stufen">
|
||||
<node CREATED="1771791777380" ID="ID_928787324" MODIFIED="1771794166900" TEXT="nichts tun! jeder Test ist selbst verantwortlich" VSHIFT="4">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<u>Vorteil</u>: in den meisten Tests ist die Situation so einfach, daß sich all die schwierigeren Fragen überhaupt nicht stellen
|
||||
|
|
@ -61847,17 +61815,14 @@
|
|||
<u>Nachteil</u>: das Thema ist nicht offensichtlich und wird deshalb leicht übersehen, so daß man dann im Ernstfall vor einem nicht-reproduzierbaren Problem steht
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<node COLOR="#435e98" CREATED="1771792328036" HGAP="25" ID="ID_1177735425" MODIFIED="1771792411958" TEXT="so habe ich das bisher gehalten" VSHIFT="-10">
|
||||
<font NAME="SansSerif" SIZE="10"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1771791855035" ID="ID_1248754284" MODIFIED="1771794227272" TEXT="zentrale Reseed-Funktion für alle problematischen Komponenten">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<u>Vorteil</u>: man kümmert sich nur um das, was wirklich ein Problem darstellt, und läßt alles andere laufen
|
||||
|
|
@ -61866,8 +61831,7 @@
|
|||
<u>Nachteil</u>: das Problembewußtsein muß da sein, sonst funktioniert der Ansatz nicht
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#a71043" DESTINATION="ID_1248754284" ENDARROW="Default" ENDINCLINATION="-130;5;" ID="Arrow_ID_1619567275" SOURCE="ID_1809491977" STARTARROW="None" STARTINCLINATION="10;-13;"/>
|
||||
</node>
|
||||
<node CREATED="1771792007414" ID="ID_937121719" MODIFIED="1771792019688" TEXT="was »feineres«">
|
||||
|
|
@ -61888,57 +61852,45 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#bb1490" CREATED="1771794484488" ID="ID_1866843924" MODIFIED="1771794530803">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
tja ... alles schön gesültzt bis jetzt — <b>geht aber am Problem vorbei</b>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="smiley-angry"/>
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#980d32" CREATED="1771794537160" ID="ID_1578449818" MODIFIED="1771794672517" TEXT="�� Problem ist...">
|
||||
<node CREATED="1771794554047" ID="ID_1793181159" MODIFIED="1771794571808" TEXT="ich habe (bisher) exakt einen Use-Case"/>
|
||||
<node CREATED="1771794572796" ID="ID_1762569226" MODIFIED="1771794596493">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
und der paßt nicht ins Schema: der sitzt nämlich <b>NICHT</b> in der lib-Lumiera
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771794643571" ID="ID_870959085" MODIFIED="1771794649046" TEXT="sondern in libtest-core.so"/>
|
||||
</node>
|
||||
<node CREATED="1771794721112" ID="ID_339259825" MODIFIED="1771795424036">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
wir haben auch schon ein App-Event-System — das ist aber <i><font color="#a70202">leider zu knapp definiert</font></i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...es kann nur einfachste void(void)-Funktionen aufrufen, und auch nicht in definierter Reihenfolge. Zudem gibt es keine Scopes, d.h. wir müßten ein globales Lifecycle-Event definieren ON_RESEED. Das ist <b>genau das was ich definitiv nicht will</b> — weil wir damit in ein viel anspruchsvolleres Feature einsteigen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1771795425474" ID="ID_114413932" MODIFIED="1771803342428" TEXT="also hilft nur: basteln">
|
||||
<icon BUILTIN="yes"/>
|
||||
|
|
@ -61979,9 +61931,7 @@
|
|||
</node>
|
||||
<node COLOR="#338800" CREATED="1771803502493" ID="ID_1580946206" MODIFIED="1771803620895" TEXT="manuell getestet">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<i>Explizit nicht sinnvoll</i> hierfür einen Unit-Test zu schreiben!
|
||||
|
|
@ -62007,8 +61957,7 @@
|
|||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -114336,7 +114285,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1771539807853" ID="ID_1455262817" MODIFIED="1771539852207" TEXT="Prototyping : OutputProxyProvider_test als Experimentierfeld">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1771616038792" ID="ID_1389235656" MODIFIED="1771616326306" TEXT="Forschung: Policy konfigurieren">
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1771616038792" ID="ID_1389235656" MODIFIED="1771809186526" TEXT="Forschung: Policy konfigurieren">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1771616054739" ID="ID_297187964" MODIFIED="1771616315207" TEXT="hab die dunkle Erinnerung daß in so was Ähnliches schon zig mal vergeblich versucht habe">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
|
|
@ -114424,6 +114374,65 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1771634200296" ID="ID_1781890966" MODIFIED="1771634221593" TEXT="das ist angemessen; es geht um Implementierungs-Technik"/>
|
||||
<node CREATED="1771634718849" ID="ID_158495787" MODIFIED="1771634743108" TEXT="man könnte zudem die Anforderungen als Concept dokumentieren"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1771807890857" ID="ID_44174155" MODIFIED="1771809182613" TEXT="Experiment zur Policy">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1771807898504" ID="ID_1896427982" MODIFIED="1771807909962" TEXT="einfachste Form: eine Policy als Baseclass"/>
|
||||
<node CREATED="1771807911166" ID="ID_1166005757" MODIFIED="1771807924271" TEXT="die Policy selber soll moveable sein"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1771807934449" ID="ID_292154472" MODIFIED="1771807951937" TEXT="Problem: ich brauch die Policy in der Store-Implementierung">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1771808870215" ID="ID_1799682600" MODIFIED="1771808894898" TEXT="damit verbundenes Problem: Konfiguration des BufferProviderSetup">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1771808897410" ID="ID_1165872773" MODIFIED="1771808913796" TEXT="den müssen wir ebenfalls per Policy konfigurieren">
|
||||
<node CREATED="1771808914975" ID="ID_1601123928" MODIFIED="1771808929187" TEXT="damit wir die Spezialisierung erst im Konstruktor-Rumpf brauchen"/>
|
||||
<node CREATED="1771808930291" ID="ID_180591398" MODIFIED="1771808947529" TEXT="denn sonst würde die Policy auf den Typ des BufferProvider-Interfaces durchschlagen"/>
|
||||
</node>
|
||||
<node CREATED="1771808957102" ID="ID_266948865" MODIFIED="1771808988313">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
das macht die sache nun <font size="4" color="#aa0707">extrem ekelhaft und verworren</font>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="smiley-angry"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1771808997763" ID="ID_251025614" MODIFIED="1771809261721" TEXT="irgendwie durchprügeln">
|
||||
<linktarget COLOR="#4198b7" DESTINATION="ID_251025614" ENDARROW="Default" ENDINCLINATION="280;452;" ID="Arrow_ID_1811648927" SOURCE="ID_357384264" STARTARROW="None" STARTINCLINATION="230;-772;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1771809030317" ID="ID_888890635" MODIFIED="1771809050553" TEXT="mache einen weiteren Setup-Kontext im umschließenden BufferProxyAdaptor"/>
|
||||
<node CREATED="1771809051767" ID="ID_741792921" MODIFIED="1771809068353" TEXT="lasse diesen von der Policy erben, aber auch die Konfiguration der Backends machen"/>
|
||||
<node CREATED="1771809073468" ID="ID_1644352238" MODIFIED="1771809093437" TEXT="dann kann man die Policy dort zur Initialisierung reinschieben"/>
|
||||
<node CREATED="1771809094897" ID="ID_1954503680" MODIFIED="1771809099725" TEXT="Einschränkungen">
|
||||
<node CREATED="1771809101214" ID="ID_398957418" MODIFIED="1771809112001" TEXT="die Store-Implementierung hat jetzt eine Back-Referenz"/>
|
||||
<node CREATED="1771809113111" ID="ID_300180321" MODIFIED="1771809161169">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
in der einfachsten Form muß der Aufrufer herumtricksen,
|
||||
</p>
|
||||
<p>
|
||||
weil die Policy mit <b>drei Lambdas<i> </i></b>konfiguriert wird...
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1771809163667" ID="ID_792139119" MODIFIED="1771809168991" TEXT="immerhin: das tut">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1771634755779" ID="ID_1904273320" MODIFIED="1771634765200" TEXT="Skizze: Grundstruktur">
|
||||
<node CREATED="1771634766556" ID="ID_1120594617" MODIFIED="1771634791497" TEXT="daraus ergibt sich dann vielleicht auch ein klareres Bild bezüglich Policy"/>
|
||||
|
|
@ -114660,8 +114669,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
...und kann aber keinen rechten Grund finden, es zu rechtfertigen....
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<edge COLOR="#f451c4"/>
|
||||
<font NAME="SansSerif" SIZE="11"/>
|
||||
<icon BUILTIN="smiley-oh"/>
|
||||
|
|
@ -114707,9 +114715,60 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1771719337142" ID="ID_1438749510" MODIFIED="1771719352671" TEXT="es fällt jetzt alles direkt an seinen Platz"/>
|
||||
<node CREATED="1771719312958" ID="ID_1439242903" MODIFIED="1771719327096" TEXT="das zeigt doch schon mal, daß ich in der letzten Woche etwas geleistet habe"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1771719388571" ID="ID_518110024" MODIFIED="1771719406796" STYLE="fork" TEXT="error::Logic(Underlying buffer type already defines a nontrivial LocalTag)">
|
||||
<node COLOR="#435e98" CREATED="1771719388571" ID="ID_518110024" MODIFIED="1771786539566" STYLE="fork" TEXT="error::Logic(Underlying buffer type already defines a nontrivial LocalTag)">
|
||||
<font NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1771786421323" ID="ID_1428649903" MODIFIED="1771786443496" TEXT="da scheitert ein sinnvoller Konsistenz-Check"/>
|
||||
<node CREATED="1771786444987" ID="ID_863321778" MODIFIED="1771786502619">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...der hier nicht zugrifft, denn kein <i>anderes</i> LocalTag
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771786504118" ID="ID_1195397068" MODIFIED="1771786527551" TEXT="wir definieren hier lediglich das gleiche LocalTag bereits im »Buffer Type«">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1771787699562" ID="ID_1338445084" MODIFIED="1771803643108" TEXT="Nebenschauplatz: Fehler im Random-reseeding entdeckt">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1771788175302" ID="ID_1889273920" MODIFIED="1771788356892" TEXT="fällt mir nur auf wegen »Prokrastination«">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
weiß nicht recht warum ich so überhaupt keinen Antrieb hab, meine eigentliche Aufgabe voranzutreiben ... vielleicht weil ich zehn andere Verpflichtungen habe, die ich nur wegen Lumiera zurückstelle, obwohl sie einfacher zu erledigen wären?
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1771788359811" ID="ID_1797609498" MODIFIED="1771788445962" TEXT="jedenfalls ist da ganz klar eine Lücke, die schnell behoben werden sollte">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...bevor sich ein Workaround festsetzt, den man dann immer wieder vergißt, oder das ganze Thema wird insgesamt vergessen und führt dann zu Bugs.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1771788450555" ID="ID_262212223" MODIFIED="1771803693549" TEXT="also: fixen">
|
||||
<arrowlink COLOR="#a00e3d" DESTINATION="ID_1995924412" ENDARROW="Default" ENDINCLINATION="-2471;146;" ID="Arrow_ID_1407537427" STARTARROW="None" STARTINCLINATION="-636;133;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node COLOR="#984392" CREATED="1771803653032" HGAP="25" ID="ID_1693381367" MODIFIED="1771803688021" TEXT="( wieder mal erflogreich prokrastiniert )" VSHIFT="11">
|
||||
<font NAME="SansSerif" SIZE="8"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1771809197740" ID="ID_1401631162" MODIFIED="1771809206379" TEXT="läuft im einfachsten Test">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#257162" CREATED="1771809207859" ID="ID_357384264" MODIFIED="1771809261721" TEXT="zusammen mit Hack für die Policy">
|
||||
<arrowlink COLOR="#4198b7" DESTINATION="ID_251025614" ENDARROW="Default" ENDINCLINATION="280;452;" ID="Arrow_ID_1811648927" STARTARROW="None" STARTINCLINATION="230;-772;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue