BufferProvider: confirm valid Buffer Protocol usage cycle
Some weeks ago, at the time where I started to dig into this topic, I extended the BufferProviderProtocol_test to perform a buffer usage pattern that mimics the usage in the real Render Engine, as implemented last year. For this, I used the `TestFrame` and the chained-hash dummy computations. Now, after reordering and clean-up of the `BufferProvider` implementation interfaces, it can be showed with this computation scheme that - all buffers are indeed allocated and handed out as expected - the metadata handling is correct and points to the processed buffers - the complete memory used in this test is uncorruped and holds correct numbers
This commit is contained in:
parent
064651335f
commit
8a8f98ceb0
4 changed files with 135 additions and 60 deletions
|
|
@ -257,11 +257,10 @@ namespace engine {
|
|||
}
|
||||
|
||||
|
||||
void*
|
||||
BufferDiagnostic::accessMemory (uint bufferID)
|
||||
{
|
||||
NOTREACHED ("shall use new API only");
|
||||
// return dbp_.heapStore_.access_emitted(bufferID).accessMemory(); ///////////////////////////////////////TICKET 1410 : switch to newly defined tracking-API
|
||||
Buff*
|
||||
BufferDiagnostic::accessMemory (HashVal id)
|
||||
{ // may throw when found
|
||||
return created.byHandle(id).get().accessMemory();
|
||||
}
|
||||
|
||||
bool
|
||||
|
|
|
|||
|
|
@ -143,12 +143,12 @@ namespace engine {
|
|||
|
||||
bool buffer_was_used (uint bufferID); ///< @deprecated ////////////////////////////////////////TICKET 1410
|
||||
bool buffer_was_closed (uint bufferID); ///< @deprecated ////////////////////////////////////////TICKET 1410
|
||||
void* accessMemory (uint bufferID); ///< @deprecated ////////////////////////////////////////TICKET 1410
|
||||
bool was_created (HashVal);
|
||||
bool was_emitted (HashVal);
|
||||
bool was_released (HashVal);
|
||||
bool is_in_use (HashVal);
|
||||
bool was_used (HashVal);
|
||||
Buff* accessMemory(HashVal);
|
||||
bool all_buffers_released();
|
||||
diagn::StateReg const& created;
|
||||
diagn::StateReg const& emitted;
|
||||
|
|
|
|||
|
|
@ -21,12 +21,16 @@
|
|||
#include "lib/test/test-helper.hpp"
|
||||
#include "lib/test/tracking-dummy.hpp"
|
||||
#include "lib/util-foreach.hpp"
|
||||
#include "lib/iter-zip.hpp"
|
||||
#include "steam/engine/testframe.hpp"
|
||||
#include "steam/engine/test-rand-ontology.hpp"
|
||||
#include "steam/engine/diagnostic-buffer-provider.hpp"
|
||||
#include "lib/test/diagnostic-output.hpp"////////////////////TODO
|
||||
|
||||
using util::isSameObject;
|
||||
using util::for_each;
|
||||
using lib::HashVal;
|
||||
using lib::zip;
|
||||
|
||||
|
||||
namespace steam {
|
||||
|
|
@ -55,10 +59,10 @@ namespace test {
|
|||
*(data+i) = work.data()[i];
|
||||
return work.getChecksum();
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
/**************************************************************************//**
|
||||
* @test document the usage patterns of the »Buffer Provider Protocol«
|
||||
* Notably this protocol is used by the Render Engine during recursive `pull()`
|
||||
|
|
@ -77,7 +81,7 @@ namespace test {
|
|||
run (Arg)
|
||||
{
|
||||
verifySimpleUsage();
|
||||
verifyRenderingUsage();
|
||||
verifyRenderingUse();
|
||||
// verifyObjectAttachment();
|
||||
// verifyObjectAttachmentFailure(); //////////////////////////OOO need a completely new test case to cover behaviour of failed ctor calls
|
||||
}
|
||||
|
|
@ -101,21 +105,21 @@ namespace test {
|
|||
|
||||
buff.emit();
|
||||
buff.release();
|
||||
CHECK (!buff.isValid());
|
||||
CHECK (not buff.isValid());
|
||||
VERIFY_ERROR (LIFECYCLE, buff.accessAs<TestFrame>() );
|
||||
|
||||
auto diagnostic = watch(provider);
|
||||
CHECK (diagnostic.buffer_was_used (0));
|
||||
CHECK (diagnostic.buffer_was_closed (0));
|
||||
auto inspect = watch(provider);
|
||||
CHECK (inspect.was_used (buff));
|
||||
CHECK (inspect.was_released(buff));
|
||||
|
||||
CHECK (testData(0) == diagnostic.accessMemory (0));
|
||||
CHECK (testData(0) == inspect.accessMemory(buff));
|
||||
}
|
||||
|
||||
|
||||
/** @test demonstrate the full sequence of invocations during rendering
|
||||
*/
|
||||
void
|
||||
verifyRenderingUsage()
|
||||
verifyRenderingUse()
|
||||
{
|
||||
// Test fixture: allows to track/verify allocations after the fact
|
||||
DiagnosticBufferProvider provider;
|
||||
|
|
@ -131,8 +135,8 @@ namespace test {
|
|||
CHECK (desc3.isValid());
|
||||
|
||||
uint num1 = desc1.announce(TEST_ELMS);
|
||||
uint num2 = desc1.announce(TEST_ELMS + 1);
|
||||
uint num3 = desc2.announce(TEST_ELMS * 2);
|
||||
uint num2 = desc2.announce(TEST_ELMS + 1);
|
||||
uint num3 = desc3.announce(TEST_ELMS * 2); // announce more than we actually use (which is tolerated)
|
||||
CHECK (num1 == TEST_ELMS);
|
||||
CHECK (num2 == TEST_ELMS + 1);
|
||||
CHECK (num3 == TEST_ELMS * 2);
|
||||
|
|
@ -173,10 +177,49 @@ namespace test {
|
|||
workBuff.release(); // note: not every buffer need be emitted.
|
||||
CHECK (!workBuff);
|
||||
|
||||
auto diagnostic = watch(provider);
|
||||
CHECK (diagnostic.buffer_was_used (0));
|
||||
CHECK (diagnostic.buffer_was_closed (0));
|
||||
// CHECK (diagnostic.all_buffers_released()); ///////////////OOO do we need this API?
|
||||
auto inspect = watch(provider);
|
||||
CHECK (inspect.created.cnt() == 3*TEST_ELMS + 1);
|
||||
CHECK (inspect.was_used (workBuff));
|
||||
CHECK (inspect.was_released (workBuff));
|
||||
CHECK (not inspect.was_emitted (workBuff));
|
||||
CHECK (inspect.all_buffers_released());
|
||||
|
||||
// now peek into buffer memory
|
||||
// to prove that that the complete computation chain
|
||||
// was in fact performed, and was using the memory as intended
|
||||
uint last = inspect.released.cnt() - 1;
|
||||
diagn::Block lastWork = inspect.released[last];
|
||||
diagn::Block lastMark = inspect.released[last-1];
|
||||
diagn::Block lastData = inspect.released[last-2];
|
||||
|
||||
// due to the way this chained-hash dummy computation was defined,
|
||||
// the last data buffer should contain the same random numbers as the last work buffer...
|
||||
auto& workBuffContent = lastWork.accessAs<TestFrame>().data();
|
||||
auto& dataBuffContent = lastData.accessAs<DataBuff>();
|
||||
|
||||
for (auto [c,v] : zip(workBuffContent,dataBuffContent))
|
||||
CHECK (c == v);
|
||||
|
||||
// furthermore, the last recorded checksum mark
|
||||
// should match the checksum of the last work buffer,
|
||||
// because that is where the last computation was carried out.
|
||||
CHECK (endSum == lastMark.accessAs<HashVal>());
|
||||
|
||||
// we can also verify that all data in emitted buffers is correct,
|
||||
// by re-computing the checksum for each step, using data in the buffers
|
||||
for (uint i=0; i<TEST_ELMS; ++i)
|
||||
{
|
||||
diagn::Block srcBuff = inspect.emitted[i*3 + 0];
|
||||
diagn::Block markBuff = inspect.emitted[i*3 + 2];
|
||||
TestFrame const& src = srcBuff.accessAs<TestFrame>(); // note const -- can not corrupt data in memory
|
||||
ont::Param param = src.getChecksum();
|
||||
TestFrame newWorkBuff;
|
||||
ont::manipulateFrame (&newWorkBuff, &src, param);
|
||||
|
||||
// the checksum recoded during the test run matches the re-computed sum,
|
||||
// based on combining data in memory for a second time with the same chained-hash function
|
||||
CHECK (markBuff.accessAs<HashVal>() == newWorkBuff.getChecksum());
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -110365,7 +110365,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1769203135049" ID="ID_1957618964" MODIFIED="1769203375143" TEXT="neuer Ansatz: jetzt die reale Verwendung analysieren und nachbauen">
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1769203135049" ID="ID_1957618964" MODIFIED="1771372789015" TEXT="neuer Ansatz: jetzt die reale Verwendung analysieren und nachbauen">
|
||||
<linktarget COLOR="#ce0632" DESTINATION="ID_1957618964" ENDARROW="Default" ENDINCLINATION="-1185;43;" ID="Arrow_ID_1824415534" SOURCE="ID_1065671274" STARTARROW="None" STARTINCLINATION="1197;118;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#eae5a6" COLOR="#300f69" CREATED="1769203163926" ID="ID_1465055003" MODIFIED="1769203203294" TEXT="das ist der große Vorteil jetzt: das Node-Network ist implementiert">
|
||||
|
|
@ -110639,8 +110639,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1769210686565" ID="ID_1536189770" MODIFIED="1769210695813" TEXT="dieses Muster nun im Testfall nachbauen">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#cde1be" COLOR="#338800" CREATED="1769210686565" ID="ID_1536189770" MODIFIED="1771372810747" TEXT="dieses Muster nun im Testfall nachbauen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1769213063666" ID="ID_1804838536" MODIFIED="1769213930429" TEXT="auch bereits incl. der anounce()-Operation">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1769213076631" ID="ID_977495368" MODIFIED="1769213479644" TEXT="ich halte die längerfristig für sehr wichtig">
|
||||
|
|
@ -110722,7 +110722,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1769217660348" ID="ID_874516866" MODIFIED="1769217718220" TEXT="⟹ damit fällt hier für diesen Testfall auch das Verketten von Berechnungen weg">
|
||||
<node COLOR="#5b280f" CREATED="1769217660348" ID="ID_874516866" MODIFIED="1771372464849" TEXT="⟹ damit fällt hier für diesen Testfall auch das Verketten von Berechnungen weg">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -110731,6 +110731,19 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ccdee2" COLOR="#018033" CREATED="1771372466452" ID="ID_711147734" LINK="#ID_79001152" MODIFIED="1771372773336" TEXT="Doch! es ist durchaus sinnvoll hier eine verkettete Berechnung zu machen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Man kann damit nämlich zeigen, daß tatsächlich Buffer in der gewünschten Reihenfolge belegt und verwendet werden, indem man anschaut, daß am Ende die Checksumme mit aufgezeichneten Werten übereinstimmt, und in den zugehörigen Dummy-Buffern auch tatsächlich (noch) die Daten der letzten Berechnungsschritte liegen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#70f07e" DESTINATION="ID_1870433294" ENDARROW="Default" ENDINCLINATION="460;21;" ID="Arrow_ID_303606689" STARTARROW="None" STARTINCLINATION="-9;45;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1769273843983" ID="ID_750810589" MODIFIED="1769273855167" TEXT="wirklich wichtig ist">
|
||||
|
|
@ -110739,11 +110752,16 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1769273878090" ID="ID_1739884810" MODIFIED="1769273914463" TEXT="das Belegen auf den BufferDescriptors"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1769303330470" ID="ID_1333832891" MODIFIED="1769303334708" TEXT="Verifikationen">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node COLOR="#338800" CREATED="1769303330470" ID="ID_1333832891" MODIFIED="1771372677394" TEXT="Verifikationen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1769303336197" ID="ID_1486480192" MODIFIED="1769303349894" TEXT="(wartet auf neue Backend-Implementierung)">
|
||||
<font NAME="SansSerif" SIZE="10"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1771372329207" ID="ID_1870433294" MODIFIED="1771372898255" TEXT="Nach dem Umbau: nun gibt es ein neues Diagnose-API">
|
||||
<arrowlink COLOR="#1a8abc" DESTINATION="ID_613670885" ENDARROW="Default" ENDINCLINATION="779;-28;" ID="Arrow_ID_1032863918" STARTARROW="None" STARTINCLINATION="712;38;"/>
|
||||
<linktarget COLOR="#70f07e" DESTINATION="ID_1870433294" ENDARROW="Default" ENDINCLINATION="460;21;" ID="Arrow_ID_303606689" SOURCE="ID_711147734" STARTARROW="None" STARTINCLINATION="-9;45;"/>
|
||||
<icon BUILTIN="forward"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -112164,16 +112182,13 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1771354620091" ID="ID_789673449" MODIFIED="1771359068230" TEXT="in verifyStandardCase()">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Zufallszahlen in lokal gehaltenem Vektor; müßten dann auch im Speicherblock zu finden sein...
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#ae099e" CREATED="1771359078135" ID="ID_325360151" MODIFIED="1771359118319" TEXT="sind sie auch ... wenn man nicht immer Index ≡ 0 anschaut">
|
||||
<icon BUILTIN="smiley-oh"/>
|
||||
|
|
@ -112183,16 +112198,13 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#5b280f" CREATED="1771360399235" ID="ID_698277565" MODIFIED="1771360486104" TEXT="sollte nicht mehr von einem »Test Protocol« reden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
das zeigt nämlich gut die Stelle, an der ich in die Falle gefallen bin; stattessen haben wir nun (hoffentlich) <i>deklarative </i>Diagnose-Funktionen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="stop-sign"/>
|
||||
</node>
|
||||
<node CREATED="1771360487997" ID="ID_1884248019" MODIFIED="1771360491577" TEXT="Namens-Suche">
|
||||
|
|
@ -112214,9 +112226,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1771360635541" ID="ID_161220145" MODIFIED="1771360644073" TEXT="»Introspection«"/>
|
||||
<node BACKGROUND_COLOR="#eccda7" CREATED="1771360645205" ID="ID_651488390" MODIFIED="1771360750193" STYLE="bubble">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
benenne die Variable verbal: 
|
||||
|
|
@ -112225,8 +112235,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<font color="#4a1a65" face="Bitstream Vera Sans Mono" size="9pt"><b>auto</b></font><font color="#3a1f18" face="Bitstream Vera Sans Mono" size="9pt"> </font><font color="#814422" face="Bitstream Vera Sans Mono" size="9pt">inspect</font><font color="#3a1f18" face="Bitstream Vera Sans Mono" size="9pt"> </font><font color="#65533c" face="Bitstream Vera Sans Mono" size="9pt">=</font><font color="#3a1f18" face="Bitstream Vera Sans Mono" size="9pt"> </font><font color="#000000" face="Bitstream Vera Sans Mono" size="9pt">watch</font><font color="#11123a" face="Bitstream Vera Sans Mono" size="9pt">(</font><font color="#b45858" face="Bitstream Vera Sans Mono" size="9pt"><b>provider</b></font><font color="#11123a" face="Bitstream Vera Sans Mono" size="9pt">)</font><font color="#65533c" face="Bitstream Vera Sans Mono" size="9pt">;</font>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<edge COLOR="#201ccb"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
|
|
@ -112234,16 +112243,13 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node COLOR="#435e98" CREATED="1771360758940" ID="ID_318818630" MODIFIED="1771368280809">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
außerdem: <b>TestFrame</b> kann inzwischen viel mehr ....
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1771360784807" ID="ID_1657955100" MODIFIED="1771360797070" TEXT="sollte einen deutlich größeren Buffer nehmen"/>
|
||||
<node CREATED="1771360798301" ID="ID_735423157" MODIFIED="1771360810709" TEXT="sollte aber dann einen TestFrame einpflanzen"/>
|
||||
|
|
@ -112253,6 +112259,41 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1771335749973" ID="ID_431521592" MODIFIED="1771335763465" TEXT="BufferProviderProtocol_test ebenfalls versäubern">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#164e8b" CREATED="1771372143101" ID="ID_1013808062" LINK="#ID_1168667446" MODIFIED="1771374369880" TEXT="ich hatte neulich bereits eine sehr viel realistischere Berechnung skizziert">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
vorausgegangen war eine Analyse der Nutzmuster in dem letztes Jahr entwickelten Node-Invocation-Code
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node COLOR="#164e8b" CREATED="1771372370739" ID="ID_613670885" MODIFIED="1771374369881" TEXT="hier fehlt aber noch die Verifikation der berechneten Daten im Speicher">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Für diesen Testfall hatte ich bereits in einer einfachen Schleife dieses Nutzungsmuster nachtestellt, und dafür meine neue TestRandOntology verwendet; das heißt, wir rechnen jetzt wirklich einen vollen Bufferhinhalt durch, und jedes einzelne Datenwort ist am Ende verifizierbar, vermöge der verketteten Hash-Berechnung
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#1a8abc" DESTINATION="ID_613670885" ENDARROW="Default" ENDINCLINATION="779;-28;" ID="Arrow_ID_1032863918" SOURCE="ID_1870433294" STARTARROW="None" STARTINCLINATION="712;38;"/>
|
||||
</node>
|
||||
<node COLOR="#164e8b" CREATED="1771372691026" ID="ID_79001152" MODIFIED="1771374369881" TEXT="es genügt, die Endergebnisse abzugleichen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Da es sich um eine verkettete Hash-Berechnung handelt, müßte man streng genommen die Berechnung nochmal wiederholen, und die festgestellte Prüfsumme vergleichen. Mit dem Argument, daß dieses an anderer Stelle bereits getan wurde (NodeLink_test), kann ich argumentieren, daß es hier nur darauf ankommt, daß die korrekten Daten dort im Speicher liegen, wo man sie aufgrund der Logik auch erwarten würde
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#174956" COLOR="#8dfd49" CREATED="1771374306703" ID="ID_779094274" MODIFIED="1771374348933" STYLE="bubble" TEXT="Ergebnis: alle Daten matchen">
|
||||
<edge COLOR="#61fe5b" STYLE="bezier" WIDTH="thin"/>
|
||||
<font NAME="SansSerif" SIZE="15"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -113083,9 +113124,9 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1771335613418" ID="ID_389403594" MODIFIED="1771354255277" TEXT="an dieser Stelle: Status-quo bestätigen">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1771335628925" ID="ID_832109359" MODIFIED="1771354236488" TEXT="die beiden Test-Fälle aufräumen">
|
||||
<node COLOR="#338800" CREATED="1771335628925" ID="ID_832109359" MODIFIED="1771372132494" TEXT="die beiden Test-Fälle aufräumen">
|
||||
<arrowlink COLOR="#445360" DESTINATION="ID_1793741597" ENDARROW="Default" ENDINCLINATION="-253;1171;" ID="Arrow_ID_389390476" STARTARROW="Default" STARTINCLINATION="512;-1514;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1771335644345" ID="ID_4824008" MODIFIED="1771335676635" TEXT="beide Tests wieder komplett grün">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
|
|
@ -113114,9 +113155,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node CREATED="1771335383471" ID="ID_1401593839" MODIFIED="1771348112895" TEXT="aber so vollständig, daß ich nix mehr ändern kann">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Seit 2024 bin ich nun mehrfach durch den Kern der Implementierung durchgegangen, und konnte keine offensichtliche Lücke finden (nur ein paar lokale Inkonsistenzen, wie z.B. daß wir uns den aktuellen Buffer-Pointer im Entry speichern, obwohl es genügen würde, ihn nur in den Hash einzurechnen). Auch der Zugangs-Funktionen, BufferMetadata::key(...) sind konsistent und korrekt strukturiert: es gibe eine einzige Funktion, mit der man »aus dem Nichts« einsteigen kann (und in dieser Funktion hatte ich 2024 die Reihenfolge der Qualifizierungen in ein verbindliches Schema geordnet). Außerdem gibt es ein paar weitere Funktionen, mit denen man einen bereits bestehenden Key verfeinern kann, und eine Funktion, die verwendet wird, um daraus einen Entry zu machen.
|
||||
|
|
@ -113314,9 +113353,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node CREATED="1771349685935" ID="ID_1922129061" MODIFIED="1771349810502" TEXT="die Assertion hat dort didaktischen- und Dokumentations-Wert">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Inhaltlich ist sie redundant, denn Zustandsübergänge werden auch in den Metadaten geprüft. Jedoch ist die ganze Struktur relativ offen, und es gibt sogar die »Unschärfe«, daß u.U der Pointer im Handle nicht auf NULL gesetzt wird (hab das gestern durchdacht und bin zu dem Schluß gekommen, daß sich das nur um den Preis eines kompletten Umbaues beheben ließe, wozu ich keinen Anlaß sehe)
|
||||
|
|
@ -113328,9 +113365,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node COLOR="#338800" CREATED="1771349832972" ID="ID_1073377063" MODIFIED="1771350841958" TEXT="also: auch dafür einen API-call-Pfad schaffen: isAllotted">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
ich halte dieses Prädikat für sinnvoller, als ein isEmitted(); es bedeutet, daß noch eine Allokation »dran hängt«
|
||||
|
|
@ -113861,9 +113896,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1771348130096" HGAP="26" ID="ID_407529567" MODIFIED="1771348251787" VSHIFT="11">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
derzeit <b><font size="4" color="#4a0cce">kann</font></b> ich gar nix mehr ändern
|
||||
|
|
|
|||
Loading…
Reference in a new issue