|
|
|
|
@ -8417,9 +8417,7 @@
|
|
|
|
|
<icon BUILTIN="button_cancel"/>
|
|
|
|
|
<node CREATED="1510365447736" ID="ID_268132850" MODIFIED="1510365460367">
|
|
|
|
|
<richcontent TYPE="NODE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
dann aber als <b>State Monad</b>
|
|
|
|
|
@ -8451,9 +8449,7 @@
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1510366161399" ID="ID_854251162" MODIFIED="1510366222663">
|
|
|
|
|
<richcontent TYPE="NODE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
wende die resultierende State-Monade
|
|
|
|
|
@ -8494,9 +8490,7 @@
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1510446985581" FOLDED="true" HGAP="7" ID="ID_1266495962" MODIFIED="1561827469127" VSHIFT="44">
|
|
|
|
|
<richcontent TYPE="NODE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
alternatives
|
|
|
|
|
@ -8527,9 +8521,7 @@
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1510540265979" FOLDED="true" HGAP="17" ID="ID_1160853986" MODIFIED="1561827469147" VSHIFT="26">
|
|
|
|
|
<richcontent TYPE="NODE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
Fazit:
|
|
|
|
|
@ -8553,9 +8545,7 @@
|
|
|
|
|
<node CREATED="1510540740977" ID="ID_1864011655" MODIFIED="1512797263191" TEXT="ersetzt aktuellen Knoten durch seine Kinder"/>
|
|
|
|
|
<node CREATED="1510939295181" ID="ID_454143909" MODIFIED="1512797263191">
|
|
|
|
|
<richcontent TYPE="NODE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
das impliziert <i>grundsätzlich</i> einen <b>Stack</b>
|
|
|
|
|
@ -9228,9 +9218,7 @@
|
|
|
|
|
<icon BUILTIN="button_cancel"/>
|
|
|
|
|
<node CREATED="1512251214046" ID="ID_1353274464" MODIFIED="1512251270499" TEXT="Konsequenz: alle Layer müssen StateCore sein">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
...denn wenn mal ein Layer "nur" Iterator wäre,
|
|
|
|
|
@ -11357,9 +11345,7 @@
|
|
|
|
|
<node CREATED="1513893653949" ID="ID_201919603" MODIFIED="1513893660896" TEXT="Up erfordert Backlink"/>
|
|
|
|
|
<node CREATED="1513893682521" ID="ID_1477689037" MODIFIED="1513893811288">
|
|
|
|
|
<richcontent TYPE="NODE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
<i>möglicherwese</i> aber notwendig
|
|
|
|
|
@ -12713,9 +12699,7 @@
|
|
|
|
|
<node CREATED="1516910736388" ID="ID_1267411576" MODIFIED="1518487921067" TEXT="Principle of least surprise"/>
|
|
|
|
|
<node CREATED="1516910715343" ID="ID_1721041331" MODIFIED="1576282358116" TEXT="sonst default für den default">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
sonst bekommen wir eine versteckte
|
|
|
|
|
@ -13621,9 +13605,7 @@
|
|
|
|
|
<icon BUILTIN="idea"/>
|
|
|
|
|
<node CREATED="1519359176855" ID="ID_853060191" MODIFIED="1519359192777">
|
|
|
|
|
<richcontent TYPE="NODE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
der <i>Level</i> im UI ist noch offen
|
|
|
|
|
@ -15085,9 +15067,7 @@
|
|
|
|
|
<icon BUILTIN="button_ok"/>
|
|
|
|
|
<node CREATED="1509143055036" ID="ID_810015478" MODIFIED="1576282358114" TEXT="absichtlich unorthogonal repräsentiert">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
...um zu prüfen, ob das allgemeine Design
|
|
|
|
|
@ -81429,7 +81409,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
<node CREATED="1720220989004" ID="ID_1204792955" MODIFIED="1720220996471" TEXT="linkt den neu definierten Port">
|
|
|
|
|
<node CREATED="1720220989004" ID="ID_1204792955" MODIFIED="1728856456964" TEXT="linkt den neu definierten Port">
|
|
|
|
|
<arrowlink COLOR="#4225b0" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="-964;48;" ID="Arrow_ID_287970761" STARTARROW="None" STARTINCLINATION="-440;43;"/>
|
|
|
|
|
<linktarget COLOR="#5f6184" DESTINATION="ID_1204792955" ENDARROW="Default" ENDINCLINATION="486;31;" ID="Arrow_ID_197971585" SOURCE="ID_346803250" STARTARROW="None" STARTINCLINATION="361;16;"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1720220997038" ID="ID_1481586771" MODIFIED="1720221137187" TEXT="kehrt dann zum aufrufenden NodeBuilder zurück">
|
|
|
|
|
@ -89466,6 +89447,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
<icon BUILTIN="broken-line"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node COLOR="#435e98" CREATED="1728569398198" ID="ID_1013813267" MODIFIED="1728606967970" TEXT="⟹ das fällt dann der nächst höheren Ebene zu ≙ dem PortBuilder">
|
|
|
|
|
<arrowlink COLOR="#667ba9" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="73;-4;" ID="Arrow_ID_198065069" STARTARROW="None" STARTINCLINATION="-159;7;"/>
|
|
|
|
|
<icon BUILTIN="idea"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
@ -89473,6 +89455,162 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
<node CREATED="1728575095471" ID="ID_807507393" MODIFIED="1728580412842" TEXT="muß aber auch API-Design bedenken">
|
|
|
|
|
<arrowlink COLOR="#507ec8" DESTINATION="ID_1267841334" ENDARROW="Default" ENDINCLINATION="-66;-100;" ID="Arrow_ID_537610685" STARTARROW="None" STARTINCLINATION="-257;20;"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1728856264065" ID="ID_647212329" MODIFIED="1728856511042" TEXT="erst im completePort() ggfs fall-back auf 1:1-Verdrahtung">
|
|
|
|
|
<linktarget COLOR="#4225b0" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="-964;48;" ID="Arrow_ID_287970761" SOURCE="ID_1204792955" STARTARROW="None" STARTINCLINATION="-440;43;"/>
|
|
|
|
|
<linktarget COLOR="#667ba9" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="73;-4;" ID="Arrow_ID_198065069" SOURCE="ID_1013813267" STARTARROW="None" STARTINCLINATION="-159;7;"/>
|
|
|
|
|
<icon BUILTIN="pencil"/>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728856564010" ID="ID_351253239" MODIFIED="1728856613658" TEXT="Erfüllungs-Kriterium">
|
|
|
|
|
<icon BUILTIN="forward"/>
|
|
|
|
|
<node CREATED="1728856581150" ID="ID_1770028915" MODIFIED="1728856607090" TEXT="alle Slots des InvocationAdapters werden bedient">
|
|
|
|
|
<icon BUILTIN="yes"/>
|
|
|
|
|
<node CREATED="1728857251364" ID="ID_880125093" MODIFIED="1728857272946" TEXT="FeedManifold::inBuff und outBuff"/>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728857277871" ID="ID_1643482991" LINK="#ID_174258961" MODIFIED="1728857399366" TEXT="enthält jeweils ein BuffHandle"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728856616380" ID="ID_1508359460" MODIFIED="1728856643102" TEXT="Ausgabe-Slots ⟹ brauchen empfangenden Buffer"/>
|
|
|
|
|
<node CREATED="1728856644258" ID="ID_61712664" MODIFIED="1728856683944" TEXT="Eingabe-Slots ⟹ brauchen Datenversorgung">
|
|
|
|
|
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728856766094" ID="ID_276112278" MODIFIED="1728856774433" TEXT="hier ggfs Fehler möglich">
|
|
|
|
|
<icon BUILTIN="messagebox_warning"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728857699331" ID="ID_25559479" MODIFIED="1728857849299" TEXT="später zur Invocation dann...">
|
|
|
|
|
<icon BUILTIN="info"/>
|
|
|
|
|
<node CREATED="1728858252686" ID="ID_232790909" MODIFIED="1728858255148" TEXT="pull">
|
|
|
|
|
<node CREATED="1728858262402" ID="ID_807172869" MODIFIED="1728858267263" TEXT="rekursiver call-down"/>
|
|
|
|
|
<node CREATED="1728858268443" ID="ID_1337335793" MODIFIED="1728858280841" TEXT="liefert direkt BuffHandle in die FeedManifold"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728858291271" ID="ID_1032851869" MODIFIED="1728858294323" TEXT="shed">
|
|
|
|
|
<node CREATED="1728858345985" ID="ID_151628152" MODIFIED="1728858540930" TEXT="für alle outTypes">
|
|
|
|
|
<node CREATED="1728858394149" ID="ID_672697263" MODIFIED="1728858485197" TEXT="im jeweilgen Slot liegt ein BufferDescriptor"/>
|
|
|
|
|
<node CREATED="1728858486270" ID="ID_134365508" MODIFIED="1728858498129" TEXT="in diesen ist bereits der erwartete Buffer-Typ encodiert"/>
|
|
|
|
|
<node CREATED="1728858502500" ID="ID_192657626" MODIFIED="1728858539006" TEXT="ruft lockBuffer() ⟼ BuffHandle ⟶ in den slot der FeedManifold"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728857728456" ID="ID_1108346903" MODIFIED="1728858311859" TEXT="SimpleFunctionInvocationAdapter::connect()">
|
|
|
|
|
<node CREATED="1728857749871" ID="ID_571778632" MODIFIED="1728857759068" TEXT="geht blindlings alle seine Slots durch"/>
|
|
|
|
|
<node CREATED="1728857760524" ID="ID_1488115240" MODIFIED="1728857824010" TEXT="ruft jeweils im slot: BuffHandle::accessAs<Buffer*>()"/>
|
|
|
|
|
<node CREATED="1728857826372" ID="ID_1750707944" MODIFIED="1728857844418" TEXT="übernimmt diesen Pointer in das interne Buffer-Ptr-Array"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728856777992" ID="ID_1457051384" MODIFIED="1728856785965" TEXT="Verdrahtung (fertig) ausführen">
|
|
|
|
|
<icon BUILTIN="flag-yellow"/>
|
|
|
|
|
<node CREATED="1728858555925" ID="ID_65764746" MODIFIED="1728858571751" TEXT="was zu leisten ist....">
|
|
|
|
|
<node CREATED="1728858604761" ID="ID_790361441" MODIFIED="1728858624320" TEXT="eingangsseitig muß für jeden Slot eine Lead-Connection bestehen">
|
|
|
|
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728858628016" ID="ID_303987757" MODIFIED="1728858659791" TEXT="Datentyp muß pasen — hier nicht mehr überprüfbar">
|
|
|
|
|
<icon BUILTIN="messagebox_warning"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728858723831" ID="ID_38123688" MODIFIED="1728858886282" TEXT="nur der Build-Vorgang in der Domain-Ontology kann wissen was woher kommt">
|
|
|
|
|
<icon BUILTIN="idea"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728858668070" ID="ID_1431639114" MODIFIED="1728858931894" TEXT="kann nur noch Anzahl prüfen und fehlende Slots per Lead/default-Port befriedigen">
|
|
|
|
|
<node CREATED="1728860974222" ID="ID_1130205156" MODIFIED="1728860983031" TEXT="Ports werden der Reihe nach eingefüllt"/>
|
|
|
|
|
<node CREATED="1728860984062" ID="ID_322570697" MODIFIED="1728861006719" TEXT="⟹ PortBuilder kann seine eigene Port-Nummer erschließen"/>
|
|
|
|
|
<node CREATED="1728861007944" ID="ID_1830241208" MODIFIED="1728861032180" TEXT="muß aber gespeichert werden, da konfigurierbar"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728858747160" ID="ID_1825558530" MODIFIED="1728858939877" TEXT="Konsequenz ⟹ zu wenig Leads bedeutet error::Logic">
|
|
|
|
|
<icon BUILTIN="yes"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728858952853" ID="ID_157065776" MODIFIED="1728858971152" TEXT="ausgangsseitig hat der WeavingBuilder ein Array mit Typinfos">
|
|
|
|
|
<node CREATED="1728859055657" ID="ID_1509836267" MODIFIED="1728859066657" TEXT="das muß mit Typ-Markern gefüllt werden"/>
|
|
|
|
|
<node CREATED="1728859075077" ID="ID_708925676" MODIFIED="1728859099002" TEXT="1:1-Verdrahtung heißt hier: den festen Output-Typ einfüllen"/>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728861156109" ID="ID_717078277" MODIFIED="1728861169116" TEXT="den muß daher der PortBuilder ermitteln">
|
|
|
|
|
<icon BUILTIN="flag-yellow"/>
|
|
|
|
|
<node CREATED="1728861989407" ID="ID_1702195585" MODIFIED="1728862007092" TEXT="konkreter Typ wird erst für den InvocationAdapter + Manifold ermittelt"/>
|
|
|
|
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728862023317" ID="ID_82788432" MODIFIED="1728862039191" TEXT="...und der steckt bisher fest verdrahtet im WeavingBuilder">
|
|
|
|
|
<icon BUILTIN="broken-line"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728861938092" ID="ID_474371188" MODIFIED="1728862042391" TEXT="bisher alles noch zu knapp gehalten">
|
|
|
|
|
<arrowlink COLOR="#dd0239" DESTINATION="ID_865228634" ENDARROW="Default" ENDINCLINATION="1738;0;" ID="Arrow_ID_1284493211" STARTARROW="None" STARTINCLINATION="-299;23;"/>
|
|
|
|
|
<icon BUILTIN="messagebox_warning"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728862045992" ID="ID_1245289000" MODIFIED="1728862204253" TEXT="Prototyp ⟹ erst mal das Type-Binding explizit in den WeavingBuilder aufdoppeln">
|
|
|
|
|
<icon BUILTIN="yes"/>
|
|
|
|
|
<node CREATED="1728862298588" ID="ID_1483120295" MODIFIED="1728862313310" TEXT="und zwar als Spezialisierung für die 1:1-Verdrahtung"/>
|
|
|
|
|
<node CREATED="1728862314322" ID="ID_21254566" MODIFIED="1728862354792" TEXT="denn hiefür müssen stets alle restlichen Output-Buffer ausgefüllt werden"/>
|
|
|
|
|
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1728862763793" ID="ID_842556948" MODIFIED="1728862777881" TEXT="Logische Inkonsistenz im Design">
|
|
|
|
|
<icon BUILTIN="broken-line"/>
|
|
|
|
|
<node CREATED="1728862780842" ID="ID_1335801248" MODIFIED="1728862813235" TEXT="»buffer type« : einerseits ein explizit getypter Pointer"/>
|
|
|
|
|
<node CREATED="1728862814218" ID="ID_73032642" MODIFIED="1728862857856" TEXT="»buffer type« : andererseits ein Inlay-Typ, der vom BufferProider in den Buffer konstruiert wird"/>
|
|
|
|
|
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728862873502" ID="ID_780472721" MODIFIED="1728862893714" TEXT="TOTAL UNKLAR was „die Libraries“ wirklich brauchen">
|
|
|
|
|
<icon BUILTIN="messagebox_warning"/>
|
|
|
|
|
<node CREATED="1728862945789" ID="ID_1315354060" MODIFIED="1728862967044" TEXT="mutmaßlich zwei Pattern">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
...da es sich um C-Libraries handelt....
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
<node CREATED="1728862969220" ID="ID_1526575552" MODIFIED="1728863006246" TEXT="Quelle / Generator alloziert auch Speicher"/>
|
|
|
|
|
<node CREATED="1728863010348" ID="ID_1461256214" MODIFIED="1728863036884" TEXT="Quelle / Vorgänger erwartet einen Speicherblock"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728863084211" ID="ID_1367824352" MODIFIED="1728863094410" TEXT="ersteres wäre ein ganz erhebliches Problem"/>
|
|
|
|
|
<node CREATED="1728863100280" ID="ID_942277652" MODIFIED="1728863115524" TEXT="aber lösbar durch einen smart-Adapter im Buffer">
|
|
|
|
|
<icon BUILTIN="ksmiletris"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728863117520" ID="ID_1664512933" MODIFIED="1728863132032" TEXT="zweiteres könnte man auf einen Inlay-Typ abbilden"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1728863140155" ID="ID_739905259" MODIFIED="1728863470251" TEXT="Fazit: für den Prototyp weiterhin mit einem InlayTyp arbeiten">
|
|
|
|
|
<linktarget COLOR="#653656" DESTINATION="ID_739905259" ENDARROW="Default" ENDINCLINATION="-69;74;" ID="Arrow_ID_577244058" SOURCE="ID_1241817970" STARTARROW="None" STARTINCLINATION="463;18;"/>
|
|
|
|
|
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
|
|
|
|
<icon BUILTIN="yes"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node COLOR="#338800" CREATED="1728863361338" ID="ID_228239335" MODIFIED="1728863430987" TEXT="damit implementierbar">
|
|
|
|
|
<icon BUILTIN="button_ok"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728863381122" ID="ID_1241817970" MODIFIED="1728863470251" TEXT="PortBuilder muß hier vorerst Hilfsfunktion auf WeavingBuilder aufrufen">
|
|
|
|
|
<arrowlink COLOR="#653656" DESTINATION="ID_739905259" ENDARROW="Default" ENDINCLINATION="-69;74;" ID="Arrow_ID_577244058" STARTARROW="None" STARTINCLINATION="463;18;"/>
|
|
|
|
|
<icon BUILTIN="yes"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1728870351532" ID="ID_228375055" MODIFIED="1728871019335" TEXT="Implementierung(Prototyp)">
|
|
|
|
|
<icon BUILTIN="pencil"/>
|
|
|
|
|
<node CREATED="1728870363207" ID="ID_695992250" MODIFIED="1728870530894" TEXT="Probleme beim Weitergeben des Typs der Processing-Function">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
Unsicherheiten beim Durchreichen des Initialisierers.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Das notorische Problem; ich möchte in der eigentlichen ProcNode keine std::function haben, sondern idealerweise ein Lambda. Aber irgendwo im Turnout muß ein Prototyp dieses Funktors liegen, von dem wir für jeden Aufruf kopieren können. Das ist kniffelig, wenn der Initialisierer hierfür durch eine perfect-forwarding-Kette durchgereicht werden soll.
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
<icon BUILTIN="messagebox_warning"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728870377629" ID="ID_616326824" MODIFIED="1728870428683" TEXT="Irgendetwas mit der move/realloc-Funktion in lib::SeveralBuilder ist nicht in Ordnung">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
src/lib/several-builder.hpp:327:39: warning: parameter 'src' set but not used [-Wunused-but-set-parameter]
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
         moveElem (size_t idx, Bucket* src, Bucket* tar)
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
<icon BUILTIN="messagebox_warning"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728870929451" ID="ID_1740846481" MODIFIED="1728870951984" TEXT="der Gebrauch des BuffHandle::accessAs<TY>() ist zweifelhaft">
|
|
|
|
|
<icon BUILTIN="messagebox_warning"/>
|
|
|
|
|
<node CREATED="1728870953831" ID="ID_1005617048" MODIFIED="1728870963978" TEXT="ich bekomme einen LInker-Fehler"/>
|
|
|
|
|
<node CREATED="1728870964942" ID="ID_1694707450" MODIFIED="1728870992248" TEXT="ist nämlich nur im Header buffhandle-attach.hpp definiert"/>
|
|
|
|
|
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1728870993972" ID="ID_1606733362" MODIFIED="1728871010352" TEXT="warum ist das so? ist das als Extension gedacht?">
|
|
|
|
|
<icon BUILTIN="help"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1721782550869" ID="ID_173220882" MODIFIED="1721782642416" TEXT="vereinfachtes Aufruf-API: Slots der Reihe nach belegen">
|
|
|
|
|
@ -89600,6 +89738,31 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
<icon BUILTIN="idea"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728861567310" ID="ID_1015927332" MODIFIED="1728861674145" TEXT="⟹ eigentlich müßte die Flexibilität zwischen PortBuilder und WeavingBuilder liegen">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
...weil es immer mehr darauf hinaus läuft, daß der PortBuilder die high-level-Sicht auf die Verdrahtung hat, während der WeavingBuilder von ersterem explizit gesteuert werden muß
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1728861676015" ID="ID_865228634" MODIFIED="1728861963334" TEXT="da habe ich für den Prototypen zu stark vereinfacht">
|
|
|
|
|
<linktarget COLOR="#dd0239" DESTINATION="ID_865228634" ENDARROW="Default" ENDINCLINATION="1738;0;" ID="Arrow_ID_1284493211" SOURCE="ID_474371188" STARTARROW="None" STARTINCLINATION="-299;23;"/>
|
|
|
|
|
<icon BUILTIN="broken-line"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728861734053" ID="ID_1720499002" MODIFIED="1728861867336" TEXT="müßte das Produkt des WeavingBuilders konfigurierbar machen">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
<head/>
|
|
|
|
|
<body>
|
|
|
|
|
<p>
|
|
|
|
|
...derzeit verwendet der fest eingestellt das SimpleWeavingPattern — und ebenso eine fest verdrahtete Basis-Konfiguration. Richtig wäre es, entweder mehrere WeavingBuilder-Varianten zu haben, oder — wenn schon ein einziger WeavingBuilder genügt — diesen nicht nur mit der Funktion zu parametrisieren
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
@ -89690,8 +89853,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
siehe <b><font face="Monospaced">TestFrame_test</font></b>
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
<icon BUILTIN="idea"/>
|
|
|
|
|
<node CREATED="1728778030637" ID="ID_450784295" MODIFIED="1728778047012" TEXT="hat eine fixierte Größe von 1k (+Metadata)"/>
|
|
|
|
|
<node CREATED="1728777455066" ID="ID_1238676043" MODIFIED="1728777545746" TEXT="Inhalt reproduzierbar, geordnet nach Channel and Seq-No">
|
|
|
|
|
@ -89702,8 +89864,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
es gibt nur einen festen Seed-Mechanismus, der auf der Kanal- und Sequenz-Nummer beruht
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728777897375" ID="ID_560401601" MODIFIED="1728777958502">
|
|
|
|
|
<richcontent TYPE="NODE"><html>
|
|
|
|
|
@ -89713,8 +89874,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
kann Lifecycle markieren als <font color="#563c31">CREATED, EMITTED, DISCARDED</font>
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728778080366" ID="ID_1631642281" MODIFIED="1728778216760" TEXT="kann Konsistenz und damit Korruption erkennen"/>
|
|
|
|
|
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728777587128" ID="ID_939285679" MODIFIED="1728786873689" TEXT="fehlt bisher">
|
|
|
|
|
@ -89733,8 +89893,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
bringt nicht wirklich was, aber zumindest sollte std::random mit kompatiblem Generator verwendet werden
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
<icon BUILTIN="button_cancel"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728781231984" ID="ID_283829609" MODIFIED="1728781974281" TEXT="wünschenswert">
|
|
|
|
|
@ -89750,8 +89909,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
Es fehlt ja generell noch ein Framework für Zufallswerte in Tests, so daß jeder Test seinen definiten Seed bekommt, welcher zwar normalerweise zufällig, ansonsten aber feststellbar und reproduzierbar sein sollte
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
<icon BUILTIN="flag-yellow"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728781144210" ID="ID_51267004" MODIFIED="1728781989516" TEXT="Standard Generator-Sequenzen auf jeder Stufe sind unabhängig hierarchisch">
|
|
|
|
|
@ -89762,8 +89920,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
Das sind sie bereits in der bestehenden Implementierung, und das Prinzip ist auch bereits gut genug; allerdings sollten wir das Schema von std::random verwenden, d.h. jeweils einen Generator und darauf aufbauend eine Distribution
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
<icon BUILTIN="flag-yellow"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
@ -89776,8 +89933,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
Das Daten-Array liegt nicht am Anfang, und ist deshalb plattform/implementierungsabhängig aligned; das erschwert auch die direkte Interpretation eines Datenblocks als TestFrame....
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
<icon BUILTIN="messagebox_warning"/>
|
|
|
|
|
<node CREATED="1728778765874" ID="ID_1342398369" MODIFIED="1728778778502" TEXT="der Metadatenblock sollte am Ende sein"/>
|
|
|
|
|
<node CREATED="1728778790871" ID="ID_92579679" MODIFIED="1728779021706" TEXT="Metadaten sollten optional sein">
|
|
|
|
|
@ -89788,8 +89944,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
....und damit sollte man jede beliebige Speicherlocation als Testframe interpretieren können, ohne diese zu korrumpieren; das impliziert auch, daß der behandelnde Code erkennen kann, ob ein Metadatenblock überhaupt angelegt wurde — und wenn das nicht der Fall ist, sollte auch niemals implizit in den Speicher geschrieben werden
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728779023048" ID="ID_1104714285" MODIFIED="1728779233787" TEXT="man sollte die Prüfsumme explizit markieren können">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
@ -89799,8 +89954,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
Dabei ist die Prüfsumme ein verknüpfter Hash, und man sollte diese jederzeit berechnen können; jedoch ein regulär erstellter TestFrame sollte die Prüfsumme explizit speichern, und auch für beliebigen Dateninhalt sollte sich die Prüfsumme explizit markiern (speichern) lassen, denn damit werden auch weitergehende Berechnungen auf den Daten möglich, die vom initialen Seed abweichen
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728778477601" ID="ID_1156423837" MODIFIED="1728778494727" TEXT="direkter Zugang zu den Daten / Iteration">
|
|
|
|
|
@ -89817,8 +89971,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
<b>neue Bedeutung</b>: es ist ein TestFrame mit erkennbarem Metadatenblock (auch wenn ansonsten keine der Prüfsummen mit den Daten zusammenpaßt); es sollte recht unwahrscheinlich sein, daß ein zufälliger Datenblock diesen Test besteht.
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728779408099" ID="ID_186109727" MODIFIED="1728779644910" TEXT="isValid">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
@ -89828,8 +89981,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
Es ist ein TestFrame mit gültigem Metadaten-Block, und die dort gespeicherte Prüfsumme wird durch die Daten bestätigt
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728779415747" ID="ID_135096780" MODIFIED="1728779750157" TEXT="isPristine">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
@ -89839,8 +89991,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
entspricht dem bisherigen isSane() — d.h. isValid() aber zusätzlich passen die Daten auf die gespeicherte distinction, und das heißt, die Daten wurden vom Standard-Schema erzeugt und nicht weiter bearbeitet
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
@ -89880,8 +90031,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
@ -89913,8 +90063,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
...das bedeutet, sie läuft auf size_t (oder was dann letztlich die Wortbreite sein wird für Lumiera Hash-Vorgänge) und sie ist <b>nicht kommutativ<i> </i></b>in den Argumenten
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728782252204" ID="ID_757336693" MODIFIED="1728782549197" TEXT="es wird ein uniformer Seed-Wert für jeden Datenpunkt mit injiziert">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
@ -89924,8 +90073,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
Jeder Funktionsaufruf ist „gefärbt“, aber ansonsten äquivalent. Das heißt, ein fester Parameterwert fließt mit in die Berechnung jedes einzelnen Datenpunktes, und dieser Wert ist an den jeweiligen Aufruf gebunden wird, wodurch auch eine Kette gleichartiger Aufrufe in der Reihenfolge unterscheidbar gemacht werden kann.
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728782874164" ID="ID_1997651851" MODIFIED="1728783179058" TEXT="dieser Seed, zusammen mit den Kenndaten, bildet eine reproduzierbare Identität">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
@ -89935,8 +90083,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
...zwar handelt es sich stets nur um eine Hash-Verknüpfung, aber die Arität (und ggfs. später auch noch ein Array-Wertiger Input) kommen als Steuerparameter hinzu. Diese Parameter können als lesbarer Spec-String ausgegeben werden, und in einen Hash eingerechnet werden, der dann die Funktion markiert und unterscheidbar macht. Wenn ein Seed explizit angegeben wird, dann fließt er zusätzlich mit ein, und markiert außerdem auch die Berechnung an jedem Datenpunkt
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728783188923" ID="ID_1138350224" MODIFIED="1728783420787" TEXT="der Seed könnte später wie ein Automations-Parameterwert eingebracht werden">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
@ -89946,8 +90093,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
...später, wenn ich abschließend geklärt habe, wie Automation funktionieren soll. Derzeit denke ich, daß solche Funktions-Parameter in einem Tree-walk vor dem eigentlichen pull() der Invocation gesetzt werden, also über das Turnout-System. Speziell für die Test-Ontology könnte man hier auch eine Node-ID oder einen Node-Struktur-Hash einfließen lassen (wobei mit jetzt aber nicht klar ist, ob diese Idee für das Testen überhaupt von Nutzen ist)
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728782162715" ID="ID_647461586" MODIFIED="1728783566268" TEXT="Berechnung unabhängig pro Datenpunkt">
|
|
|
|
|
@ -89958,8 +90104,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
Ich will also eine laterale Vermischung der Daten vermeiden; erst über die Prüfsumme des Ergebnis-Datenblocks werden die einzelnen Datenpunkte zusammengeführt; theoretisch wäre es dadurch sogar möglich, die Korruption einzelner Datenpunkte zu erkennen, indem man die intendierte Berechnungskette explizit gecodet nochmal ausführt und dann die Ergebnisdaten vergleicht.
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
<node CREATED="1728783585707" ID="ID_288581450" MODIFIED="1728783674793" TEXT="für jede Berechnung gibt es eine human-readable spec">
|
|
|
|
|
<richcontent TYPE="NOTE"><html>
|
|
|
|
|
@ -89982,8 +90127,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
d.h. das EventLog liegt in einem Singleton, und wenn es da ist, dann hinterläßt jeder Funktionsaufruf einen Log-Eintrag, so daß sich der gesamte Berechnungsweg mit allen Aufruf-Reihenfolgen nachvollziehen und verifizieren läßt
|
|
|
|
|
</p>
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
</richcontent>
|
|
|
|
|
</html></richcontent>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
@ -90006,10 +90150,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
<icon BUILTIN="ksmiletris"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785768422" ID="ID_1775907930" MODIFIED="1728785783907" TEXT="ProcNode als Ergebnis bekommen">
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785768422" ID="ID_1775907930" MODIFIED="1728836959981" TEXT="Connectivity als Ergebnis bekommen">
|
|
|
|
|
<icon BUILTIN="flag-yellow"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785785350" ID="ID_1997976250" MODIFIED="1728785795791" TEXT="1:1-Verdrahtung durchfürhen">
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785785350" ID="ID_1997976250" MODIFIED="1728785795791" TEXT="1:1-Verdrahtung durchführen">
|
|
|
|
|
<icon BUILTIN="flag-yellow"/>
|
|
|
|
|
</node>
|
|
|
|
|
</node>
|
|
|
|
|
@ -90017,6 +90161,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|
|
|
|
<icon BUILTIN="hourglass"/>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785829235" ID="ID_59153641" MODIFIED="1728785837551" TEXT="Zahl der Leads / Ports">
|
|
|
|
|
<icon BUILTIN="flag-yellow"/>
|
|
|
|
|
<node CREATED="1728837023895" ID="ID_605946582" MODIFIED="1728837031771" TEXT="auf Connectivity direkt zugänglich"/>
|
|
|
|
|
</node>
|
|
|
|
|
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785840998" ID="ID_663732870" MODIFIED="1728785852800" TEXT="Funktions-ID generieren">
|
|
|
|
|
<icon BUILTIN="flag-yellow"/>
|
|
|
|
|
|