benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Invocation: work out solution for builder initialisation

Browse source 
...turns out to be surprisingly tricky, since the nested
lib::SeveralBuilder instances require parametrisation by a
''policy template,'' which in turn relies on the actual allocator.
And we want to provide the allocator as a constructor parameter,
including the ability to pick up a custom specialisation for
some specific allocator (notably AllocationCluster requires
to hook into this kind of extension point, to be able to
employ its dedicated API for dynamic allocation adjustment)
This commit is contained in:
Fischlurch 2024-07-07 23:56:10 +02:00
parent b01fc6e350
commit cedb1830dc
3 changed files with 291 additions and 162 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
src/lib/several-builder.hpp
View file

@ -776,9 +776,21 @@ namespace lib {
namespace allo { // Setup for custom allocator policies
/**
* Extension point: how to configure the SeveralBuilder
* to use an allocator \a ALO, initialised by \a ARGS
* @note must define a nested type `Policy`,
* usable as policy mix-in for SeveralBuilder
* @remark the meaning of the template parameter is defined
* by the partial specialisations; notably it is possible
* to give `ALO ≔ std::void_t` and to infer the intended
* allocator type from the initialisation \a ARGS altogether.
* @see allocation-cluster.hpp
*/
template<template<typename> class ALO, typename...ARGS>
struct SetupSeveral;
/** Specialisation: use a _monostate_ allocator type \a ALO */
template<template<typename> class ALO>
struct SetupSeveral<ALO>
{
@ -786,6 +798,8 @@ namespace lib {
using Policy = AllocationPolicy<I,E,ALO>;
};
/** Specialisation: store a C++ standard allocator instance,
* which can be used to allocate objects of type \a X */
template<template<typename> class ALO, typename X>
struct SetupSeveral<ALO, ALO<X>>
{

56
src/steam/engine/node-builder.hpp
View file

@ -88,18 +88,60 @@ namespace steam {
namespace engine {
using std::move;
using std::forward;
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
namespace {
template<template<typename> class ALO =std::void_t, typename...INIT>
struct AlloPolicySelector
{
template<class I, class E=I>
static auto
setupBuilder (INIT&& ...alloInit)
{
return lib::makeSeveral<I,E>()
.template withAllocator<ALO> (forward<INIT> (alloInit)...);
}
template<class I, class E=I>
using BuilderType = decltype(setupBuilder<I,E> (std::declval<INIT>()...));
};
struct UseHeapAlloc
{
template<class I, class E=I>
static auto
setupBuilder()
{
return lib::makeSeveral<I,E>();
}
template<class I, class E=I>
using BuilderType = lib::SeveralBuilder<I,E>;
};
template<class POL, class I, class E=I>
using DataBuilder = typename POL::template BuilderType<I,E>;
}
template<class POL>
class PortBuilder;
template<class POL>
class NodeBuilder
: util::MoveOnly
{
lib::SeveralBuilder<Port> ports_;
std::vector<ProcNodeRef> leads_;
using PortData = DataBuilder<POL, Port>;
PortData ports_;
std::vector<ProcNodeRef> leads_{};
public:
template<typename...INIT>
NodeBuilder (INIT&& ...alloInit)
: ports_{POL::template setupBuilder<Port> (forward<INIT> (alloInit)...)}
{ }
NodeBuilder
addLead (ProcNode const& lead)
@ -129,8 +171,9 @@ namespace engine {
}
};
template<class POL>
class PortBuilder
: protected NodeBuilder
: protected NodeBuilder<POL>
, util::MoveOnly
{
public:
@ -174,8 +217,7 @@ namespace engine {
inline auto
prepareNode()
{
UNIMPLEMENTED("start building a new Render Node at Level-2");
return NodeBuilder{};
return NodeBuilder<UseHeapAlloc>{};
}
@ -231,7 +273,7 @@ namespace engine {
retrieve(void* streamType)
{
UNIMPLEMENTED("start a connectivity definition at Level-3");
return NodeBuilder{};
return LinkBuilder{}; ///////////////////////////////////////////////////////////////////OOO this is placeholder code; should at least open a ticket
}

383
wiki/thinkPad.ichthyo.mm
View file

@ -227,9 +227,7 @@
</node>
<node CREATED="1484871442777" ID="ID_492545805" MODIFIED="1576282358164">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
CoreService hat <i>keine volle</i>&#160;Bus-Connection
@ -237,9 +235,7 @@
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...das hab ich mir jetzt explizit so &#252;berlegt und es ist sinnvoll.
@ -270,9 +266,7 @@
<icon BUILTIN="button_ok"/>
<node CREATED="1481320765135" FOLDED="true" ID="ID_379585622" MODIFIED="1576282358163">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
UI: <b>GuiNotification</b>
@ -283,9 +277,7 @@
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1484792679322" HGAP="13" ID="ID_426218722" MODIFIED="1576282358163" TEXT="#1047 preliminary definition of GuiNotification facade" VSHIFT="-3">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
4/18 inzwischen hier alles gekl&#228;rt.
@ -1342,9 +1334,7 @@
</node>
<node CREATED="1484877731337" ID="ID_1859059266" MODIFIED="1538263469664">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
faktisch erfolgt somit ein <b>Callback</b>&#160;aus einem anderen Thread
@ -2301,9 +2291,7 @@
</node>
<node CREATED="1537571223088" ID="ID_1186576760" MODIFIED="1538263469669" TEXT="erst mal gar nicht">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
YAGNI
@ -3488,9 +3476,7 @@
<node CREATED="1538348553006" ID="ID_1259043030" MODIFIED="1538348566936" TEXT="so da&#xdf; dann die n&#xe4;chste Iteration das &#xfc;bern&#xe4;chste Element bearbeitet"/>
<node CREATED="1538348577763" ID="ID_830173416" MODIFIED="1538348597359">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
aber <i>genau der andere Thread,</i>&#160;der das gemacht hat...
@ -5582,9 +5568,7 @@
<arrowlink COLOR="#8487c2" DESTINATION="ID_1034074054" ENDARROW="Default" ENDINCLINATION="-757;-939;" ID="Arrow_ID_186260230" STARTARROW="None" STARTINCLINATION="-258;57;"/>
<node CREATED="1665345747229" ID="ID_354372547" MODIFIED="1665345789624" TEXT="m&#xf6;glichst eigenen Basis-Satz verwenden">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...damit wir nicht der extremen Variabilit&#228;t f&#252;r Desktop-Icons unterliegen
@ -7726,9 +7710,7 @@
<node CREATED="1507939279761" ID="ID_250590373" MODIFIED="1518487921063" TEXT="keine nat&#xfc;rliche Introspektion gegeben"/>
<node CREATED="1507939312860" HGAP="78" ID="ID_444535530" MODIFIED="1576282358127" TEXT="Analyse" VSHIFT="7">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
habe diese Analyse 2017/2018 ein St&#252;ck weit vorangetrieben.
@ -10693,9 +10675,7 @@
</node>
<node CREATED="1512358626607" FOLDED="true" ID="ID_853537387" MODIFIED="1561827469130" TEXT="hab die Idee schon lange">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...da&#223; man ein Ding komplett in einen Iterator packt,
@ -45651,9 +45631,7 @@
</node>
<node CREATED="1669911534853" ID="ID_1958976369" MODIFIED="1669943698789" TEXT="die Summe selber k&#xf6;nnte auch wrappen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...tut sie zwar nicht in dem Beispiel hier, aber mit gen&#252;gend krimineller Energie lie&#223;e sich ein valides Beispiel konstruieren, wobei
@ -45685,9 +45663,7 @@
<node CREATED="1669912456275" ID="ID_661856327" MODIFIED="1669912464070" TEXT="nur bei Addition / gleicher Richtung"/>
<node CREATED="1669912668224" ID="ID_1384499593" MODIFIED="1669914705545" TEXT="nur wenn bei mindestens einem Summanden das h&#xf6;chste Bit gesetzt ist">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
0111 + 0111 = 1110
@ -45712,9 +45688,7 @@
<node CREATED="1669913571311" ID="ID_1313345585" MODIFIED="1669943698789" TEXT="verwende den (absolut) kleineren der beiden Nenner"/>
<node COLOR="#435e98" CREATED="1669914430412" ID="ID_41244947" MODIFIED="1669943698789" TEXT="&#xfc;berpr&#xfc;fe die Gefahrenzone f&#xfc;r die Z&#xe4;hler">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Gefahr besteht...
@ -45748,9 +45722,7 @@
<icon BUILTIN="broken-line"/>
<node CREATED="1669941967260" ID="ID_54342145" MODIFIED="1669943698789" TEXT="Faktor 10 im Beispiel">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p style="margin-top: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; text-indent: 0px">
206435709205.57568 - 206435709205575697/1e6&#160; = abs(-0,000017) &gt; 1e-6
@ -45776,9 +45748,7 @@
<node CREATED="1669943776106" ID="ID_1895721471" MODIFIED="1669943795208" TEXT="bei re-Quantisierung auf &#xb5;-Tick kann ich nicht genauer sein als 1e-6"/>
<node CREATED="1669943801006" ID="ID_1524475083" MODIFIED="1669943916288" TEXT="trotzdem will mir dieser Befund irgendwie logisch nicht in den Kopf">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...ich hab doch ohnehin Zeiten, die sind &#181;-Grid quantisiert; also m&#252;&#223;te der Fehler einer einfachen Addition auf &#181;-Grid genau sein
@ -45793,9 +45763,7 @@
<node CREATED="1669948623670" ID="ID_549263730" MODIFIED="1669948642617" TEXT="sondern bereits beim Berechnen der Bezugs-Position"/>
<node CREATED="1669948657379" ID="ID_765957465" MODIFIED="1669949047942" TEXT="dort re-Quantisieren wir auf 1e-6 weil das der einzige sichere Faktor ist">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...da wir wissen, da&#223; einer der Multiplikatoren eine bereits quantifizierte Zeit ist, k&#246;nnen wir von einem Nenner 1e+6 ausgehen (ggfs noch reduziert um einen gek&#252;rzten Faktor). Das andere Argument, der Anteil-Faktor, stammt von au&#223;en und ist daher beliebig. Der einzige sichere Weg, den K&#252;rzungs-Trick anzuwenden, ist daher, den Kehrwert des Anteil-Faktors zu re-Quantisieren, so da&#223; sich dieses 1e+6 wegk&#252;rzt, und wir dann keine gef&#228;hrliche Multiplikation mehr haben.
@ -45807,9 +45775,7 @@
</node>
<node COLOR="#435e98" CREATED="1669949275009" ID="ID_276477045" MODIFIED="1670015719974" TEXT="letztlich geht es num darum, Funktionsf&#xe4;higkeit in seltenen Randf&#xe4;llen zu erhalten">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...und damit die rationale Arithmetik als M&#246;glichkeit zu erhalten; sie w&#228;re nicht sinnvoll nutzbar, wenn man st&#228;ndig die Sorge haben m&#252;&#223;te, da&#223; einem die Zahlen &#187;explodieren&#171; k&#246;nnen. So ist es nun schon besser, im Regelfall eine hochpr&#228;zise Berechnung zu haben (pr&#228;ziser als floating-point), die in Grenzf&#228;llen ungenau wird, mit letztlich kontrollierbarem Fehler-Level
@ -45822,9 +45788,7 @@
</node>
<node CREATED="1670015367683" ID="ID_1687855073" MODIFIED="1670015724868" TEXT="jetzt bin ich froh, da&#xdf; ich&apos;s gemacht hab">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Es f&#252;hlt sich gut an, das Problem nun doch befriedigend bezwungen zu haben; ich hatte immer das Bauchgef&#252;hl, da&#223; da mehr Genauigkeit m&#246;glich sein sollte. Allerdings &#8212; wie sich zeigte &#8212; nur in g&#252;nstigen F&#228;llen
@ -45840,9 +45804,7 @@
</node>
<node CREATED="1669949048959" ID="ID_595183859" MODIFIED="1669949241962" TEXT="im konkreten Einzelfall k&#xf6;nnte man auch einen gr&#xf6;&#xdf;eren Faktor nehmen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...aber nur nach Ma&#223;gabe der tats&#228;chlichen Dimension der eingehenden Zahlen
@ -45853,9 +45815,7 @@
</node>
<node COLOR="#435e98" CREATED="1669994369691" ID="ID_1448820193" MODIFIED="1669994388355">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Fazit: es ist das <b>gesicherte Minimum</b>
@ -45882,9 +45842,7 @@
</node>
<node COLOR="#338800" CREATED="1670000524698" ID="ID_229993223" MODIFIED="1670000571148" TEXT="...und damit ist das Ergebnis nun hinreichend genau f&#xfc;r diesen Testfall">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
#--&#9670;--# _raw(targetPos) ?&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;= 206435633551724864
@ -45916,9 +45874,7 @@
</node>
<node CREATED="1670024990169" ID="ID_737996846" MODIFIED="1670025107388" TEXT="die Division f&#xfc;r den posFactor funktioniert (&#xfc;berraschenderweise)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
also offensichtlich erkennt boost::rational die M&#246;glichkeit, den gemeinsamen Faktor 1e6 aus Z&#228;hler und Nenner wegzuk&#252;rzen. Da wir aber hier einen FSec-Wert als Offset zugeben, haben wir wenig M&#246;glichkeiten, das zu <i>vergiften</i>
@ -45939,9 +45895,7 @@
</node>
<node CREATED="1670025194925" ID="ID_674387327" MODIFIED="1670025296382" TEXT="Offsets und Durations k&#xf6;nnten 2*Time::MAX (bzw MIN) akzeptieren">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
rein numerisch w&#252;rde das gehen, da ich Time::MAX | MIN sinnigerweise auf INT_MAX / 30 gesetzt habe. Das war vorausschauend....
@ -45955,9 +45909,7 @@
<icon BUILTIN="yes"/>
<node CREATED="1670025330923" ID="ID_664088863" MODIFIED="1670025372823" TEXT="das aktuelle Verhalten ist widersinnig und &#xfc;berraschend">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
es untergr&#228;bt gradezu den Sinn dedizierter Zeit-Entit&#228;ten
@ -45998,9 +45950,7 @@
<node CREATED="1670026054003" ID="ID_873519529" MODIFIED="1670026069149" TEXT="und der nicht durch die Limitierung der Basis-Klasse TimeValue l&#xe4;uft"/>
<node CREATED="1670026074664" ID="ID_1460012408" MODIFIED="1670027376431" TEXT="diese Hintert&#xfc;r darf nicht offensichtlich sein">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<ul>
<li>
@ -46025,9 +45975,7 @@
</node>
<node COLOR="#690f14" CREATED="1670026155933" ID="ID_1357490453" MODIFIED="1670079761362" TEXT="Idee: die Limitierung auf TimeValue per ctor-Parameter steuerbar machen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<ul>
<li>
@ -46049,9 +45997,7 @@
<node CREATED="1670027457629" ID="ID_730521318" MODIFIED="1670027484830" TEXT="der TimeValue-ctor k&#xf6;nnte dann sogar tats&#xe4;chlich die Limitierung enforcen"/>
<node CREATED="1670079580092" ID="ID_1783175998" MODIFIED="1670079740173" TEXT="Idee verworfen! das wird zu explizit und zu offen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Das versaut den bisher sehr sauberen Code von TimeValue, und l&#228;d gradezu dazu ein, hier beliebige Werte zu konstruieren. Im Hinblick darauf, da&#223; ich umgestalten m&#246;chte TimeValue &#10230; MicroTicks, w&#252;rde damit die Daseinsberechtigung untergraben, denn man kann nun nicht mehr sicher sein, da&#223; MicroTicks ein <i>sicherer Wert </i>ist.
@ -46098,9 +46044,7 @@
<node CREATED="1670191507368" ID="ID_1611277271" MODIFIED="1670191525161" TEXT="was hier scheitert ist eine Nebensache"/>
<node CREATED="1670191526749" ID="ID_1074184920" MODIFIED="1670191648400" TEXT="dokumentiert lediglich diese unsinnige Limitierung von Offset | Duration">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...ganz dunkel kommt mir die Erinnerung an eine &#8222;kognitive Dissonanz&#8220; &#8212; die ich dann schell unter den Teppich gekehrt hatte, indem ich sie mit einem Assert dokumentierte....
@ -46141,9 +46085,7 @@
</node>
<node CREATED="1670191945933" ID="ID_838705253" MODIFIED="1670192032827" TEXT="Grid::timeOf() funktioniert andres (und wie erwartet)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
und die unterliegende lumiera_time_of_gridpoint weicht da ebenfalls auff&#228;llig ab...
@ -46155,9 +46097,7 @@
<node CREATED="1670192005076" ID="ID_1578782665" MODIFIED="1670192067197" TEXT="Grid::timeOf() hat reale Verwendung in der Timecode-Handhabung"/>
<node CREATED="1670192068956" ID="ID_1880098778" MODIFIED="1670192159480" TEXT="Fazit: das ist ein &#xbb;hexagonales Rad&#xab;">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
....also ein Feature, das zwar auf theoretischer Basis entwickelt wurde, aber nur im testgetriebenen Kontext; hier wohl entstanden aus der implementierungsm&#228;&#223;igen Symmetrie zu Grid::gridPoint(n)
@ -46173,9 +46113,7 @@
<node CREATED="1670200909516" ID="ID_1643706345" MODIFIED="1670200945558" TEXT="besser doch nicht: die Funtion w&#xe4;re dann n&#xe4;mlich komplett redundant"/>
<node CREATED="1670200914583" ID="ID_316481460" MODIFIED="1670201239789" TEXT="die gew&#xfc;nschte Funktion gibt es bereits auf dem Quantiser-API">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<font face="Monospaced" size="2">TimeValue Quantiser::materialise(TimeValue const&amp; raw) { return timeOf (gridPoint (raw)); }</font>
@ -46185,9 +46123,7 @@
</node>
<node CREATED="1670201304802" ID="ID_1724553119" MODIFIED="1670201393006" TEXT="und letztere hat zudem den Vorteil, da&#xdf; sie nicht clippt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<ul>
<li>
@ -46334,9 +46270,7 @@
</node>
<node CREATED="1672957336020" ID="ID_1233770503" MODIFIED="1672959113510" TEXT="Entscheidung: Signale!">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Ja!!!<br />Hat lange gedauert, bis ich da drauf gekommen bin; aber das ist so eindeutig die richtige und angemessene L&#246;sung, da&#223; ich jetzt ausgesprochen erleichtert bin.
@ -46363,9 +46297,7 @@
<node CREATED="1672952510381" ID="ID_557400282" MODIFIED="1672952543555" TEXT="insofern die Rechnungen als pr&#xe4;zise gelten"/>
<node CREATED="1672952549168" ID="ID_1479986541" MODIFIED="1672952631231" TEXT="aber die Werte-Begrenzungen ber&#xfc;cksichtigen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
in Grenzbereichen greift das ZoomWindow ein und begrenzt Ausschl&#228;ge; selbst wenn der angeschlossene Code direkt die Pixel-Werte verwendet, mu&#223; trotzdem auf solche Eingriffe gepr&#252;ft werden
@ -46453,9 +46385,7 @@
<node CREATED="1673027628894" ID="ID_642294954" MODIFIED="1673027656160" TEXT="sync_and_balance schl&#xe4;gt zus&#xe4;tzliches Padding auf"/>
<node CREATED="1673027656904" ID="ID_748230993" MODIFIED="1673027704972">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
im n&#228;chsten Zyklus wird das aber als Head-<b>content</b>&#160;gewertet &#10233; body-content wird erh&#246;ht
@ -46469,9 +46399,7 @@
<node CREATED="1673029325047" ID="ID_460101701" MODIFIED="1673029337394" TEXT="au weia: diese Berechnungen sind aber noch relativ &quot;vorl&#xe4;ufig&quot;"/>
<node CREATED="1673029338126" ID="ID_1059214961" MODIFIED="1673029685791">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
damals war ich <i>zufrieden, </i>sobald es &#8222;halbwegs&#8220; funktioniert hat
@ -46479,9 +46407,7 @@
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<ul>
<li>
@ -46518,9 +46444,7 @@
<node CREATED="1673745725545" ID="ID_527844757" MODIFIED="1673745739164" TEXT="f&#xfc;r die &quot;content height&quot; wirklich nur die Content-Felder auswerten"/>
<node CREATED="1673745740224" ID="ID_321245152" MODIFIED="1673745785441" TEXT="zus&#xe4;tzliche Expansion in einem anderen Feld machen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
z.B. in (0,1) = Struktur-Graph
@ -46566,9 +46490,7 @@
</node>
<node COLOR="#435e98" CREATED="1678839056977" ID="ID_1367619034" MODIFIED="1678839515363" TEXT="Problem vorl&#xe4;ufig entsch&#xe4;rft durch konsistente Handhabung im Track-Head">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<u>Zwischenfazit</u>: das Problem wurde erst dadurch sichtbar, da&#223; in der Logik im Track-Head innere Widerspr&#252;che bestanden; nach Durchlaufen eines Abstimmungszyklus bestand sofort wieder eine Diskrepanz, und das Layout konnte sich folglich nicht stabilisieren. <i><font color="#2e3084">Dies habe ich inzwischen behoben, </font></i>insofern nun das TrackHeadWidget grunds&#228;tzlich komplett ausformuliert ist, und alle Zust&#228;ndigkeiten dort klar verteilt sind. Nach Durchlaufen einer Display-Evaluation ergibt sich nun in Summe genau der Wert, der der mit dem TrackBody abgestimmten H&#246;he entspricht.
@ -46602,9 +46524,7 @@
<node CREATED="1673746264291" ID="ID_920699526" MODIFIED="1673746274572" TEXT="Argument im Funktor gebunden auf: bodyCanvas_.get_focus_hadjustment()">
<node CREATED="1673746420584" ID="ID_175121956" MODIFIED="1673746454675" TEXT="was ist ein &quot;focus_hadjustment&quot;???">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<font face="Monospaced" size="2">&#160;&#160;/** Hooks up an adjustment to focus handling in a container, so when a child </font>
@ -46665,9 +46585,7 @@
</node>
<node COLOR="#435e98" CREATED="1673807997325" FOLDED="true" ID="ID_1009074242" MODIFIED="1673824061664" TEXT="Assertion-fail">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
0000001086: POSTCONDITION: body-canvas-widget.cpp:512: worker_3: maybeRebuildLayout: (not isnil (profile_)) DisplayEvaluation logic broken
@ -46740,9 +46658,7 @@
</node>
<node CREATED="1673821574701" ID="ID_1681667823" MODIFIED="1673821855384">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
adjust (rulerCanvas_, canvasWidth <b><font color="#fc2020">&#8788;0</font></b>, rulerHeight &#8788;11<font color="#41d448">&#10004;</font>)
@ -46774,9 +46690,7 @@
<icon BUILTIN="forward"/>
<node CREATED="1673822512176" ID="ID_838311135" MODIFIED="1673822561177">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
scrollPos &#10239; zoomWindow ge&#228;ndert, <i>nachdem</i>&#160;das Profil aufgebaut wurde
@ -46785,9 +46699,7 @@
</html></richcontent>
<node CREATED="1673822842715" ID="ID_469521080" MODIFIED="1673822930226" TEXT="ohne den anderen Bug w&#xfc;rde das hier aber nicht auftreten">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn den pixSpan sollte sich ja grade eben nicht &#228;ndern, sondern nur der sichtbare Fenster-Ausschnitt; die Implementierung mit dem ZoomWindow zielt ja genau darauf, die Metrik konstant zu halten, selbst wenn sich das sichtbare Fenster (wie hier) &#228;ndert
@ -46801,9 +46713,7 @@
<node CREATED="1673822961603" ID="ID_1448263496" MODIFIED="1673822979878" TEXT="und deshalb m&#xfc;&#xdf;te die Berechnung dann lediglich invalidiert und wiederholt werden"/>
<node CREATED="1673822981906" ID="ID_1546720017" MODIFIED="1673823013893" TEXT="...bis sie sich stabilisiert">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
und <i>nur das </i>kann man vom Design her einfordern (da&#223; sie sich stabilisiert und nicht in Oszillationen ger&#228;t)
@ -82404,16 +82314,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1720316124312" ID="ID_962601831" MODIFIED="1720316133266" TEXT="das w&#xe4;re vorzuziehen, da lesbarer"/>
<node CREATED="1720316134343" ID="ID_1579996543" MODIFIED="1720316195167" TEXT="ist aber nicht ganz trivial zu implementieren">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...da der Typ des Builders vom Allocator abh&#228;ngt
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<arrowlink COLOR="#525474" DESTINATION="ID_1147972165" ENDARROW="Default" ENDINCLINATION="5;-93;" ID="Arrow_ID_965912718" STARTARROW="None" STARTINCLINATION="-226;14;"/>
</node>
</node>
@ -87507,9 +87414,59 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1720318501983" ID="ID_1668344828" MODIFIED="1720318529687" TEXT="zwei verschiedene Allocatoren in einem Builder sind verwirrend und gef&#xe4;hrlich"/>
<node CREATED="1720318530879" ID="ID_519349426" MODIFIED="1720318546580" TEXT="gut w&#xe4;re, wenn auf einem Level nur ein Allocator relevant ist"/>
<node CREATED="1720318547540" ID="ID_792899561" MODIFIED="1720318561458" TEXT="dann m&#xfc;&#xdf;te aber Level-2 komplett auf dem Ziel-Allocator laufen">
<node CREATED="1720318564566" ID="ID_506557297" MODIFIED="1720318595006" TEXT="er kann dann keine zus&#xe4;tzlichen Arbeitsdaten halten"/>
<node CREATED="1720318564566" ID="ID_506557297" MODIFIED="1720362735820" TEXT="er kann dann keine zus&#xe4;tzlichen Arbeitsdaten halten">
<arrowlink COLOR="#fdfdbe" DESTINATION="ID_1440673661" ENDARROW="Default" ENDINCLINATION="49;-86;" ID="Arrow_ID_1075017295" STARTARROW="None" STARTINCLINATION="13;181;"/>
</node>
<node CREATED="1720318693773" ID="ID_1481571004" MODIFIED="1720318706074" TEXT="bedeutet: alle angelegten Daten wandern in die Render-Node"/>
</node>
<node CREATED="1720363186250" ID="ID_1220186538" MODIFIED="1720363229561" TEXT="warum ein so komplexes Builder-Setup">
<node CREATED="1720363230982" ID="ID_952804911" MODIFIED="1720363247159" TEXT="das ist ein Zielkonflikt: Notation vs Builder-Implementierung"/>
<node CREATED="1720363248178" ID="ID_1851734581" MODIFIED="1720363331000" TEXT="Lesbarkeit ist hier das wichtigere Ziel">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...den Code eines Builders liest man normalerweise gar nicht im Detail, sobald man verstanden hat, da&#223; es sich um einen Builder / eine DSL handelt; wenn der Builder gut geschrieben ist, kann man direkt die gebaute Datenstruktur erkennen
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1720363332301" ID="ID_367242974" MODIFIED="1720363384108" TEXT="Builder brauchen wir nur....">
<node CREATED="1720363385712" ID="ID_1788249804" MODIFIED="1720363397178" TEXT="weil es keine benannten Konstruktor-Argumente gibt"/>
<node CREATED="1720363397934" ID="ID_192466438" MODIFIED="1720363707754" TEXT="weil sich eine Datenstruktur nicht &#xbb;aufbauen und einfrieren&#xab; l&#xe4;&#xdf;t">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
wenn das ginge, dann k&#246;nnte man einfach der Struktur Schritt f&#252;r Schritt die Felder zuweisen, und dann w&#252;rde sie irgendwann <i>auf magische Weise</i>&#160;&#187;fixiert&#171; im Speicher
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1720363710002" ID="ID_635643048" MODIFIED="1720363761462" TEXT="last but not least: weil &#xbb;Builder&#xab; ein bekanntes Pattern ist">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...wir bauen hier eine sehr komplexe Struktur, und deshalb sollte vermieden werden, auch noch ein komplexes Protokoll neu zu erfinden
</p>
</body>
</html></richcontent>
</node>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1720363510143" ID="ID_820187687" MODIFIED="1720363625060" TEXT="Abw&#xe4;gung">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
....es geht hier auch um die Allokation, die Daten sollen nachher kompakt liegen und minimal sein; au&#223;erdem geht es um das Beherrschen von Komplexit&#228;t und die Wartbarkeit des Codes; komplex aufeinander abgestimmte Datenstrukturen sollten abgekapselt sein, um ein Verfallen der Architektur durch opportunistische Anpassungen zu verhindern
</p>
</body>
</html></richcontent>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720316245567" ID="ID_1819027234" MODIFIED="1720316332817" TEXT="cross-Builder-Trick f&#xfc;r Allokator einbauen">
<linktarget COLOR="#721c55" DESTINATION="ID_1819027234" ENDARROW="Default" ENDINCLINATION="-426;-32;" ID="Arrow_ID_1938401610" SOURCE="ID_1147972165" STARTARROW="None" STARTINCLINATION="-70;384;"/>
@ -87518,23 +87475,142 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1720316421216" ID="ID_18485878" MODIFIED="1720316434730" TEXT="Vorteil: man bekommt einen dedizierten Scope f&#xfc;r das Type-Rebinding"/>
<node CREATED="1720316436796" ID="ID_554170067" MODIFIED="1720316451392" TEXT="Nachteil: geht nur per move und bei noch leerem Builder"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720318733128" ID="ID_594929215" MODIFIED="1720318752670" TEXT="zus&#xe4;tzliche Schwierigkeit: Typ f&#xfc;r den Allocator">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720318733128" ID="ID_594929215" MODIFIED="1720366228647" TEXT="zus&#xe4;tzliche Schwierigkeit: Typ f&#xfc;r den Allocator">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1720318754853" ID="ID_1165422564" MODIFIED="1720318770806" TEXT="geht jeweils auch in den Zieldatentyp mit ein"/>
<node CREATED="1720318787977" ID="ID_145712004" MODIFIED="1720318800043" TEXT="macht Klassendefinition kniffelig">
<node CREATED="1720318802329" ID="ID_430923777" MODIFIED="1720318826079" TEXT="mu&#xdf; per decltype() abgreifen"/>
<node CREATED="1720318754853" ID="ID_1165422564" MODIFIED="1720366097449" TEXT="geht jeweils auch in den Zieldatentyp mit ein"/>
<node CREATED="1720318787977" ID="ID_145712004" MODIFIED="1720366097449" TEXT="macht Klassendefinition kniffelig">
<node CREATED="1720318802329" ID="ID_430923777" MODIFIED="1720366097449" TEXT="mu&#xdf; per decltype() abgreifen"/>
</node>
<node CREATED="1720318771515" ID="ID_1440673661" MODIFIED="1720318783185" TEXT="Ausnahme: lib::Several">
<node CREATED="1720318771515" ID="ID_1440673661" MODIFIED="1720366097449" TEXT="Ausnahme: lib::Several">
<linktarget COLOR="#fdfdbe" DESTINATION="ID_1440673661" ENDARROW="Default" ENDINCLINATION="49;-86;" ID="Arrow_ID_1075017295" SOURCE="ID_506557297" STARTARROW="None" STARTINCLINATION="13;181;"/>
<icon BUILTIN="idea"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1720318828899" ID="ID_697070122" MODIFIED="1720360539626" TEXT="aber: erlaubt keinen Zugriff auf die abgelegten Daten">
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1720318828899" ID="ID_697070122" MODIFIED="1720366097449" TEXT="aber: erlaubt keinen Zugriff auf die abgelegten Daten">
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1720318848113" ID="ID_1309186144" MODIFIED="1720318864488" TEXT="Begr&#xfc;ndung war: diese werden ggfs noch per re-alloc verschoben"/>
<node CREATED="1720318865502" ID="ID_1725813889" MODIFIED="1720318886874" TEXT="das ist richtig, gilt aber f&#xfc;r std::vector genauso"/>
<node COLOR="#435e98" CREATED="1720358717835" ID="ID_158212025" MODIFIED="1720360536672" TEXT="&#x27f9; diese Einschr&#xe4;nkung fallenlassen">
<node CREATED="1720318848113" ID="ID_1309186144" MODIFIED="1720366097449" TEXT="Begr&#xfc;ndung war: diese werden ggfs noch per re-alloc verschoben"/>
<node CREATED="1720318865502" ID="ID_1725813889" MODIFIED="1720366097449" TEXT="das ist richtig, gilt aber f&#xfc;r std::vector genauso"/>
<node COLOR="#435e98" CREATED="1720358717835" ID="ID_158212025" MODIFIED="1720366097449" TEXT="&#x27f9; diese Einschr&#xe4;nkung fallenlassen">
<icon BUILTIN="yes"/>
</node>
</node>
<node CREATED="1720366100406" ID="ID_1206749989" MODIFIED="1720366217961" TEXT="das verschiebt das Problem auf den SeveralBuilder">
<arrowlink COLOR="#fd4b66" DESTINATION="ID_1936253657" ENDARROW="Default" ENDINCLINATION="12;-46;" ID="Arrow_ID_520894148" STARTARROW="None" STARTINCLINATION="-71;4;"/>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1720366234101" ID="ID_236959958" MODIFIED="1720366241679" TEXT="was aber ein enormer Fortschrit ist"/>
<node CREATED="1720366246235" ID="ID_345121826" MODIFIED="1720366269244" TEXT="...denn der Alocator verschwindet damit vom Zieltyp"/>
<node CREATED="1720366289949" ID="ID_931662353" MODIFIED="1720366310582" TEXT="......und f&#xfc;r den Builder ist er in einer Policy-Selection eingepackt"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720366069900" ID="ID_1936253657" MODIFIED="1720366213409" TEXT="mu&#xdf; SeveralBuilder-Typ konstruieren">
<linktarget COLOR="#fd4b66" DESTINATION="ID_1936253657" ENDARROW="Default" ENDINCLINATION="12;-46;" ID="Arrow_ID_520894148" SOURCE="ID_1206749989" STARTARROW="None" STARTINCLINATION="-71;4;"/>
<icon BUILTIN="flag-yellow"/>
<node CREATED="1720366322665" ID="ID_661828635" MODIFIED="1720366536903" TEXT="Wunsch">
<icon BUILTIN="yes"/>
<node CREATED="1720366327360" ID="ID_290275852" MODIFIED="1720366379365" TEXT="eigentlicher NodeBuilder tr&#xe4;gt nur noch einen POL-Template-Parameter"/>
<node CREATED="1720366391593" ID="ID_1525764484" MODIFIED="1720366419738" TEXT="es gibt einen inline-Call der sich in der Ctor-Init-List aufrufen l&#xe4;&#xdf;t"/>
<node CREATED="1720366427322" ID="ID_1671979252" MODIFIED="1720366438933" TEXT="dieser macht indirekt die Allocator-Selektion"/>
<node CREATED="1720366509248" ID="ID_1265003258" MODIFIED="1720366525242" TEXT="der POL-Typ l&#xe4;&#xdf;t sich durch eine Metafunktion ermitteln"/>
</node>
<node CREATED="1720366556082" ID="ID_283750108" MODIFIED="1720375332604">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
Ansatzpunkt: <i>genau das</i>&#160;habe ich f&#252;r den SeveralBuilder bereits gel&#246;st
</p>
</body>
</html></richcontent>
<icon BUILTIN="idea"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#d802d8" CREATED="1720374619261" ID="ID_1434632358" MODIFIED="1720374650477" TEXT="puh.... schwere Geburt">
<font NAME="SansSerif" SIZE="13"/>
<icon BUILTIN="smily_bad"/>
<node CREATED="1720374659771" ID="ID_1550262868" MODIFIED="1720374634763" TEXT="ich m&#xf6;chte einen einfachen Policy-Typ als Template-Parameter"/>
<node CREATED="1720374735705" ID="ID_1096969019" MODIFIED="1720374855610" TEXT="ich m&#xf6;chte vermeiden, jetzt hier in Interna von lib::SeveralBuilder zu greifen"/>
<node CREATED="1720374856702" ID="ID_403769106" MODIFIED="1720399078431" TEXT="ich m&#xf6;chte auch nicht ALO und INIT... als Template-Parameter auf dem Builder-Typ haben"/>
<node CREATED="1720375079188" ID="ID_1835496761" MODIFIED="1720375098971">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
warum ist das so schwer <b>verflixt noch einmal</b>!!!!!
</p>
</body>
</html></richcontent>
<node COLOR="#437e98" CREATED="1720375345361" ID="ID_176974101" MODIFIED="1720375355426" TEXT="erst mal eine Runde ins Isartal....">
<font ITALIC="true" NAME="SansSerif" SIZE="12"/>
</node>
</node>
<node CREATED="1720403027249" ID="ID_442277332" MODIFIED="1720403042496" TEXT="es h&#xe4;ngt an ein paar Kleinigkeiten">
<icon BUILTIN="forward"/>
<node CREATED="1720403044320" ID="ID_1061158702" MODIFIED="1720403070344" TEXT="die Policy im Builder selber als einfachen Typ-Parameter definieren"/>
<node CREATED="1720403071195" ID="ID_1277562489" MODIFIED="1720403164722">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
<b>nicht</b>&#160;als template-template-Parameter...
</p>
</body>
</html>
</richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...denn sonst wird man die <font face="Monospaced" color="#872701">ALO, INIT...</font>&#160;- Parameter nicht los, sondern sie werden Teil des Builder-Typs (wir wollen aber, da&#223; sie nur implizit in den Builder-Typ eingehen)
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1720403191478" ID="ID_1499576078" MODIFIED="1720403239136" TEXT="die Policy verpackt / enh&#xe4;lt die Initialisierung des SeveralBuilders"/>
<node CREATED="1720403252562" ID="ID_1281523727" MODIFIED="1720403262877" TEXT="die Policy definiert ein neues / eigenes Interface"/>
<node CREATED="1720403263561" ID="ID_675181635" MODIFIED="1720403289773">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
<i>auf das</i>&#160;mu&#223; sich der Builder abst&#252;tzen, nicht auf den lib::SeveralBuilder oder dessen Policy
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1720403312751" ID="ID_1172888563" MODIFIED="1720403357154" TEXT="und: den default (&#x2259; Heap alloc) einfach als andere Policy daneben stellen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
...nicht versuchen, die beiden zu verbinden oder irgendwie durch default-Parameter ausdr&#252;cken
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1720403358153" ID="ID_437340586" MODIFIED="1720403446512">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
tja... und jedes nested template braucht ein Pr&#228;fix &quot;<font face="Monospaced" color="#3607cb">template &lt;fun&gt;</font>&quot; in der Syntax
</p>
</body>
</html>
</richcontent>
</node>
</node>
</node>
</node>
</node>
</node>
@ -88765,16 +88841,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1720313532365" ID="ID_111352025" MODIFIED="1720313536117" TEXT="gef&#xe4;hrlich...">
<node CREATED="1720313537075" ID="ID_416643606" MODIFIED="1720313566688">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
alle Werte m&#252;ssen zuverl&#228;ssig in die Zieldatenstruktur <b>kopiert</b>&#160; werden
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1720313568317" ID="ID_106309971" MODIFIED="1720313594757" TEXT="das l&#xe4;&#xdf;t sich nicht per Typsystem enforcen">
<node CREATED="1720313596745" ID="ID_680303414" MODIFIED="1720313604212" TEXT="konsistentes Schema im Code verwenden"/>