Invocation: pick up work on the render node spec
...at the point where I identified the need to parse nested terms. The goals are still the same * write tests to ''verify connectivity'' of nodes generated by the new `NodeBuilder` * allow for ''extended custom attributes'' in the ProcID * provide the ability to mark specific parametrisations * build a Hash-Key to identify a given processing step __Note Library__: this is the first time `lib::Several` was used to hold a ''const object''. Some small adjustments in type detection were necessary to make that work. Access to stored data happens through the `lib::Several` front-end and thus always includes the const modifier; so casting any const-ness out of the way in the low-level memory management is not a concern...
This commit is contained in:
parent
0a0369a4a5
commit
bd70c5faec
6 changed files with 394 additions and 51 deletions
|
|
@ -97,9 +97,9 @@
|
|||
#include "include/limits.hpp"
|
||||
#include "lib/iter-explorer.hpp"
|
||||
#include "lib/format-string.hpp"
|
||||
#include "lib/meta/trait.hpp"
|
||||
#include "lib/util.hpp"
|
||||
|
||||
#include <type_traits>
|
||||
#include <functional>
|
||||
#include <cstring>
|
||||
#include <utility>
|
||||
|
|
@ -125,6 +125,7 @@ namespace lib {
|
|||
using util::max;
|
||||
using util::min;
|
||||
using util::_Fmt;
|
||||
using util::unConst;
|
||||
using util::positiveDiff;
|
||||
using std::is_nothrow_move_constructible_v;
|
||||
using std::is_trivially_move_constructible_v;
|
||||
|
|
@ -183,13 +184,16 @@ namespace lib {
|
|||
using AlloT = std::allocator_traits<Allo>;
|
||||
using Bucket = ArrayBucket<I>;
|
||||
|
||||
template<typename X>
|
||||
using XAlloT = typename AlloT::template rebind_traits<std::remove_cv_t<X>>;
|
||||
|
||||
Allo& baseAllocator() { return *this; }
|
||||
|
||||
template<typename X>
|
||||
auto
|
||||
adaptAllocator()
|
||||
{
|
||||
using XAllo = typename AlloT::template rebind_alloc<X>;
|
||||
using XAllo = typename XAlloT<X>::allocator_type;
|
||||
if constexpr (std::is_constructible_v<XAllo, Allo>)
|
||||
return XAllo{baseAllocator()};
|
||||
else
|
||||
|
|
@ -229,7 +233,7 @@ namespace lib {
|
|||
ASSERT (storageBytes - offset >= cnt*spread);
|
||||
Bucket* bucket = reinterpret_cast<Bucket*> (loc);
|
||||
|
||||
using BucketAlloT = typename AlloT::template rebind_traits<Bucket>;
|
||||
using BucketAlloT = XAlloT<Bucket>;
|
||||
auto bucketAllo = adaptAllocator<Bucket>();
|
||||
// Step-2 : construct the Bucket metadata | ▽ ArrayBucket ctor arg ▽
|
||||
try { BucketAlloT::construct (bucketAllo, bucket, storageBytes, offset, spread); }
|
||||
|
|
@ -247,9 +251,9 @@ namespace lib {
|
|||
createAt (Bucket* bucket, size_t idx, ARGS&& ...args)
|
||||
{
|
||||
REQUIRE (bucket);
|
||||
using ElmAlloT = typename AlloT::template rebind_traits<E>;
|
||||
using ElmAlloT = XAlloT<E>;
|
||||
auto elmAllo = adaptAllocator<E>();
|
||||
E* loc = reinterpret_cast<E*> (& bucket->subscript (idx));
|
||||
E* loc = reinterpret_cast<E*> (& unConst(bucket->subscript (idx)));
|
||||
ElmAlloT::construct (elmAllo, loc, forward<ARGS> (args)...);
|
||||
ENSURE (loc);
|
||||
return *loc;
|
||||
|
|
@ -270,11 +274,11 @@ namespace lib {
|
|||
if (not is_trivially_destructible_v<E>)
|
||||
{
|
||||
size_t cnt = bucket->cnt;
|
||||
using ElmAlloT = typename AlloT::template rebind_traits<E>;
|
||||
using ElmAlloT = XAlloT<E>;
|
||||
auto elmAllo = adaptAllocator<E>();
|
||||
for (size_t idx=0; idx<cnt; ++idx)
|
||||
{
|
||||
E* elm = reinterpret_cast<E*> (& bucket->subscript (idx));
|
||||
E* elm = reinterpret_cast<E*> (& unConst(bucket->subscript (idx)));
|
||||
ElmAlloT::destroy (elmAllo, elm);
|
||||
}
|
||||
}
|
||||
|
|
@ -479,6 +483,15 @@ namespace lib {
|
|||
return move(*this);
|
||||
}
|
||||
|
||||
/** consume all values exposed through an iterator by moving into the builder */
|
||||
template<class SEQ>
|
||||
SeveralBuilder&&
|
||||
moveAll (SEQ& dataSrc)
|
||||
{
|
||||
explore(dataSrc).foreach ([this](auto it){ emplaceMove(it); });
|
||||
return move(*this);
|
||||
}
|
||||
|
||||
/** emplace a number of elements of the defined element type \a E */
|
||||
template<typename...ARGS>
|
||||
SeveralBuilder&&
|
||||
|
|
@ -540,6 +553,14 @@ namespace lib {
|
|||
emplaceNewElm<Val> (*dataSrc);
|
||||
}
|
||||
|
||||
template<class IT>
|
||||
void
|
||||
emplaceMove (IT& dataSrc)
|
||||
{
|
||||
using Val = typename IT::value_type;
|
||||
emplaceNewElm<Val> (move (*dataSrc));
|
||||
}
|
||||
|
||||
template<class TY, typename...ARGS>
|
||||
void
|
||||
emplaceNewElm (ARGS&& ...args)
|
||||
|
|
@ -716,22 +737,26 @@ namespace lib {
|
|||
Deleter
|
||||
selectDestructor()
|
||||
{
|
||||
using IVal = typename lib::meta::Strip<I>::TypeReferred;
|
||||
using EVal = typename lib::meta::Strip<E>::TypeReferred;
|
||||
using TVal = typename lib::meta::Strip<TY>::TypeReferred;
|
||||
|
||||
typename Policy::Fac& factory(*this);
|
||||
|
||||
if (is_Subclass<TY,I>() and has_virtual_destructor_v<I>)
|
||||
if (is_Subclass<TVal,IVal>() and has_virtual_destructor_v<IVal>)
|
||||
{
|
||||
__ensureMark<TY> (VIRTUAL);
|
||||
return [factory](ArrayBucket<I>* bucket){ unConst(factory).template destroy<I> (bucket); };
|
||||
__ensureMark<TVal> (VIRTUAL);
|
||||
return [factory](ArrayBucket<I>* bucket){ unConst(factory).template destroy<IVal> (bucket); };
|
||||
}
|
||||
if (is_trivially_destructible_v<TY>)
|
||||
if (is_trivially_destructible_v<TVal>)
|
||||
{
|
||||
__ensureMark<TY> (TRIVIAL);
|
||||
return [factory](ArrayBucket<I>* bucket){ unConst(factory).template destroy<TY> (bucket); };
|
||||
__ensureMark<TVal> (TRIVIAL);
|
||||
return [factory](ArrayBucket<I>* bucket){ unConst(factory).template destroy<TVal> (bucket); };
|
||||
}
|
||||
if (is_same_v<TY,E> and is_Subclass<E,I>())
|
||||
if (is_same_v<TVal,EVal> and is_Subclass<EVal,IVal>())
|
||||
{
|
||||
__ensureMark<TY> (ELEMENT);
|
||||
return [factory](ArrayBucket<I>* bucket){ unConst(factory).template destroy<E> (bucket); };
|
||||
__ensureMark<TVal> (ELEMENT);
|
||||
return [factory](ArrayBucket<I>* bucket){ unConst(factory).template destroy<EVal> (bucket); };
|
||||
}
|
||||
throw err::Invalid{_Fmt{"Unsupported kind of destructor for element type %s."}
|
||||
% util::typeStr<TY>()};
|
||||
|
|
|
|||
|
|
@ -21,6 +21,10 @@
|
|||
** matches relevant semantic distinctions. In this context, "different" means
|
||||
** that two functions produce _perceptibly different results_ — which also
|
||||
** implies that for equivalent IDs we can use cached calculation results.
|
||||
** \par Code arrangement
|
||||
** - proc-node.hpp is a shallow interface header (included rather widely)
|
||||
** - proc-id.hpp (this header) details node specifications and is used for the NodeBuidler
|
||||
** - proc-node.cpp acts as »module« and anchor for all implementation services
|
||||
**
|
||||
** ## Structure and syntax
|
||||
** A complete processing-specification combines a high-level identification of the enclosing
|
||||
|
|
@ -62,8 +66,8 @@
|
|||
#include "lib/error.hpp"
|
||||
#include "lib/hash-standard.hpp"
|
||||
#include "lib/several.hpp"
|
||||
//#include "steam/streamtype.hpp"
|
||||
|
||||
#include <utility>
|
||||
#include <string>
|
||||
|
||||
|
||||
|
|
@ -71,6 +75,7 @@ namespace steam {
|
|||
namespace engine {
|
||||
namespace err = lumiera::error;
|
||||
|
||||
using std::move;
|
||||
using lib::HashVal;
|
||||
using std::string;
|
||||
using StrView = std::string_view;
|
||||
|
|
@ -134,6 +139,9 @@ namespace engine {
|
|||
string genNodeSpec(Leads&);
|
||||
string genSrcSpec (Leads&); ///< transitively enumerate all unique source nodes
|
||||
|
||||
struct ArgModel;
|
||||
ArgModel genArgModel();
|
||||
|
||||
friend bool
|
||||
operator== (ProcID const& l, ProcID const& r)
|
||||
{
|
||||
|
|
@ -152,6 +160,34 @@ namespace engine {
|
|||
|
||||
|
||||
|
||||
/**
|
||||
* Expanded information regarding node input and output.
|
||||
* Requires [parsing the spec](\ref ProcID::genArgModel) for construction.
|
||||
*/
|
||||
struct ProcID::ArgModel
|
||||
: util::MoveAssign
|
||||
{
|
||||
using Strings = lib::Several<const string>;
|
||||
using iterator = Strings::iterator;
|
||||
|
||||
Strings iArg;
|
||||
Strings oArg;
|
||||
|
||||
bool empty() const { return not hasArgs(); };
|
||||
bool hasArgs() const { return hasInArgs() or hasOutArgs();}
|
||||
bool hasInArgs() const { return not iArg.empty(); }
|
||||
bool hasOutArgs() const { return not oArg.empty(); }
|
||||
uint inArity() const { return iArg.size(); }
|
||||
uint outArity() const { return oArg.size(); }
|
||||
|
||||
private:
|
||||
ArgModel (Strings&& iarg, Strings&& oarg)
|
||||
: iArg{move (iarg)}
|
||||
, oArg{move (oarg)}
|
||||
{ }
|
||||
friend ArgModel ProcID::genArgModel();
|
||||
};
|
||||
|
||||
|
||||
}} // namespace steam::engine
|
||||
#endif /*ENGINE_PROC_ID_H*/
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@
|
|||
|
||||
#include "steam/engine/proc-id.hpp"
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
#include "lib/several-builder.hpp"
|
||||
#include "lib/iter-explorer.hpp"
|
||||
#include "lib/format-string.hpp"
|
||||
#include "lib/format-util.hpp"
|
||||
|
|
@ -204,6 +205,19 @@ namespace engine {
|
|||
}
|
||||
|
||||
|
||||
/** parse and dissect the argument specification */
|
||||
ProcID::ArgModel
|
||||
ProcID::genArgModel()
|
||||
{
|
||||
using VecS = std::vector<string>;
|
||||
VecS v1{"bla","blubb"};
|
||||
VecS v2;
|
||||
auto elms1 = lib::makeSeveral<const string>().appendAll(v1);
|
||||
auto elms2 = lib::makeSeveral<const string>().appendAll(v2);
|
||||
return ProcID::ArgModel{elms1.build(), elms2.build()};
|
||||
}
|
||||
|
||||
|
||||
|
||||
/**
|
||||
* @return symbolic string with format `NodeSymb--<predecessorSpec>`
|
||||
|
|
|
|||
|
|
@ -108,7 +108,6 @@
|
|||
#include "lib/several.hpp"
|
||||
|
||||
#include <string>
|
||||
#include <vector>
|
||||
#include <optional>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@
|
|||
#include "lib/test/run.hpp"
|
||||
#include "steam/engine/proc-node.hpp"
|
||||
#include "steam/engine/node-builder.hpp"
|
||||
#include "lib/format-util.hpp"
|
||||
//#include "steam/engine/test-rand-ontology.hpp" ///////////TODO
|
||||
#include "lib/test/diagnostic-output.hpp"/////////////////TODO
|
||||
//#include "lib/util.hpp"
|
||||
|
|
@ -26,13 +27,14 @@
|
|||
#include <cmath>
|
||||
|
||||
//using std::string;
|
||||
using std::abs;
|
||||
|
||||
|
||||
namespace steam {
|
||||
namespace engine{
|
||||
namespace test {
|
||||
|
||||
using std::abs;
|
||||
using util::join;
|
||||
|
||||
|
||||
|
||||
|
|
@ -76,6 +78,11 @@ namespace test {
|
|||
CHECK (p3.genProcName() == "N3"_expect );
|
||||
CHECK (p2.genProcSpec() == "U:N2.+(a1,a2)"_expect );
|
||||
CHECK (p3.genProcSpec() == "O:N3(in/3)(o1,o2/2)"_expect );
|
||||
|
||||
ProcID::ArgModel arg1 = p1.genArgModel();
|
||||
ProcID::ArgModel arg2 = p2.genArgModel();
|
||||
ProcID::ArgModel arg3 = p3.genArgModel();
|
||||
SHOW_EXPR(join (arg1.iArg))
|
||||
UNIMPLEMENTED ("parse and evaluate");
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -55167,9 +55167,10 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736882670002" ID="ID_1282038470" MODIFIED="1736883801040" TEXT="schlankes Parser-Combinator-Framework">
|
||||
<node COLOR="#338800" CREATED="1736882670002" ID="ID_1282038470" MODIFIED="1738208375987" TEXT="schlankes Parser-Combinator-Framework">
|
||||
<linktarget COLOR="#586e82" DESTINATION="ID_1282038470" ENDARROW="Default" ENDINCLINATION="-1550;3855;" ID="Arrow_ID_950785657" SOURCE="ID_1113355653" STARTARROW="None" STARTINCLINATION="1131;56;"/>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#306476" CREATED="1736718095868" ID="ID_149635951" MODIFIED="1737603564463" TEXT="Skizze">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#306476" CREATED="1736718095868" FOLDED="true" ID="ID_149635951" MODIFIED="1738186737822" TEXT="Skizze">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1736718101981" ID="ID_749637806" MODIFIED="1736718178019" TEXT="Parser">
|
||||
<node CREATED="1736718185911" ID="ID_869386255" MODIFIED="1736718261272" TEXT="StrView ⟼ Eval<RES>"/>
|
||||
|
|
@ -55278,9 +55279,9 @@
|
|||
<node CREATED="1736728565818" ID="ID_787144515" MODIFIED="1736728580729" TEXT="PAR : Parser-Typ konfiguriert die Syntax"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1736811553465" ID="ID_758725308" MODIFIED="1738186737822" TEXT="Ausarbeitung einer Implementierung">
|
||||
<node COLOR="#338800" CREATED="1736811553465" FOLDED="true" ID="ID_758725308" MODIFIED="1738208383671" TEXT="Ausarbeitung einer Implementierung">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1736811562712" ID="ID_501249017" MODIFIED="1738186387349" TEXT="Entscheidungen">
|
||||
<node COLOR="#435e98" CREATED="1736811562712" FOLDED="true" ID="ID_501249017" MODIFIED="1738208365762" TEXT="Entscheidungen">
|
||||
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="list"/>
|
||||
<node CREATED="1736817250352" ID="ID_401051695" MODIFIED="1736817482304" TEXT="vom pragmatischen Nutzen her aufbauen">
|
||||
|
|
@ -55479,7 +55480,7 @@
|
|||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#dbf0b6" COLOR="#006399" CREATED="1736811967713" ID="ID_1645773137" MODIFIED="1738185134450" TEXT="Aufbau">
|
||||
<node BACKGROUND_COLOR="#dbf0b6" COLOR="#006399" CREATED="1736811967713" FOLDED="true" ID="ID_1645773137" MODIFIED="1738185134450" TEXT="Aufbau">
|
||||
<icon BUILTIN="edit"/>
|
||||
<node COLOR="#435e98" CREATED="1736811972979" ID="ID_1413698396" MODIFIED="1738185498885" TEXT="Policy-Base als Struktur-Konfiguration">
|
||||
<icon BUILTIN="yes"/>
|
||||
|
|
@ -55495,7 +55496,7 @@
|
|||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1736875251595" ID="ID_193269102" MODIFIED="1738185491685" TEXT="Regexp-search">
|
||||
<node COLOR="#338800" CREATED="1736875251595" FOLDED="true" ID="ID_193269102" MODIFIED="1738185491685" TEXT="Regexp-search">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1736875265103" ID="ID_205680289" MODIFIED="1736875271589" TEXT="oops ... gar nicht so einfach"/>
|
||||
<node CREATED="1736875272991" ID="ID_460559047" MODIFIED="1736875300935" TEXT="deshalb verwende ich fast überall meinen RegexSearchIterator"/>
|
||||
|
|
@ -55533,7 +55534,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1736896942694" ID="ID_50956958" MODIFIED="1738185461447" TEXT="Kreis schließen: Parser wieder aus Syntax bauen">
|
||||
<node COLOR="#435e98" CREATED="1736896942694" FOLDED="true" ID="ID_50956958" MODIFIED="1738185461447" TEXT="Kreis schließen: Parser wieder aus Syntax bauen">
|
||||
<linktarget COLOR="#587bde" DESTINATION="ID_50956958" ENDARROW="Default" ENDINCLINATION="-792;1631;" ID="Arrow_ID_1971370194" SOURCE="ID_950065344" STARTARROW="None" STARTINCLINATION="-1469;98;"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1736896960412" ID="ID_281482378" MODIFIED="1736896967137" TEXT="will nicht recht funktionieren">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
|
|
@ -55586,7 +55587,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1736897354542" ID="ID_1609713458" MODIFIED="1737649511943" TEXT="Sequenz-Kombinator anlegen">
|
||||
<node COLOR="#338800" CREATED="1736897354542" FOLDED="true" ID="ID_1609713458" MODIFIED="1737649511943" TEXT="Sequenz-Kombinator anlegen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1736897787716" ID="ID_663293705" MODIFIED="1737234458887" TEXT="Basis-Mechanik">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
|
|
@ -56102,7 +56103,7 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1737511832794" ID="ID_209338146" MODIFIED="1737511947153" TEXT="Steuerung der Model-Komposition lösen">
|
||||
<node COLOR="#338800" CREATED="1737511832794" FOLDED="true" ID="ID_209338146" MODIFIED="1737511947153" TEXT="Steuerung der Model-Komposition lösen">
|
||||
<arrowlink COLOR="#579bd2" DESTINATION="ID_226754618" ENDARROW="Default" ENDINCLINATION="6;427;" ID="Arrow_ID_220186183" STARTARROW="None" STARTINCLINATION="1852;-83;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1737511902291" HGAP="22" ID="ID_1061539705" MODIFIED="1737512327118" TEXT="die Fälle werden übersetzt in Template-Spezialisierungen" VSHIFT="36"/>
|
||||
|
|
@ -56114,7 +56115,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1737234396680" ID="ID_679636766" MODIFIED="1737511439516" TEXT="Alternativ-Kombinator bauen">
|
||||
<node COLOR="#338800" CREATED="1737234396680" FOLDED="true" ID="ID_679636766" MODIFIED="1737511439516" TEXT="Alternativ-Kombinator bauen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1737235517170" ID="ID_1134480788" MODIFIED="1737430437282" TEXT="muß hier zuerst die Model-Mechanik entwickeln">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
|
|
@ -56843,7 +56844,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1737513793917" ID="ID_295869669" MODIFIED="1737581158352" TEXT="Iterativ-Kombinator bauen">
|
||||
<node COLOR="#338800" CREATED="1737513793917" FOLDED="true" ID="ID_295869669" MODIFIED="1737581158352" TEXT="Iterativ-Kombinator bauen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1737513809440" ID="ID_933768224" MODIFIED="1737581154369" TEXT="Ansatz">
|
||||
<icon BUILTIN="info"/>
|
||||
|
|
@ -57012,7 +57013,7 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1737515386507" ID="ID_1671829221" MODIFIED="1737683894096" TEXT="optionaler Kombinator">
|
||||
<node COLOR="#338800" CREATED="1737515386507" FOLDED="true" ID="ID_1671829221" MODIFIED="1737683894096" TEXT="optionaler Kombinator">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1737515398692" ID="ID_1478704437" MODIFIED="1737515413091" TEXT="der ist einfach zu realisieren und sehr nützlich"/>
|
||||
<node CREATED="1737515413799" ID="ID_1235063232" MODIFIED="1737515424929" TEXT="das Model wird in einen std::optional gewickelt"/>
|
||||
|
|
@ -57053,7 +57054,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1737515434452" ID="ID_1202348659" MODIFIED="1737693034882" TEXT="geklammerter Kombinator">
|
||||
<node COLOR="#338800" CREATED="1737515434452" FOLDED="true" ID="ID_1202348659" MODIFIED="1737693034882" TEXT="geklammerter Kombinator">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1737515442819" ID="ID_1736743033" MODIFIED="1737686220301" TEXT="Ansatz">
|
||||
<icon BUILTIN="info"/>
|
||||
|
|
@ -57099,7 +57100,7 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1737762868854" ID="ID_311219420" MODIFIED="1737850558883" TEXT="Result-Bindings">
|
||||
<node COLOR="#338800" CREATED="1737762868854" FOLDED="true" ID="ID_311219420" MODIFIED="1737850558883" TEXT="Result-Bindings">
|
||||
<linktarget COLOR="#d2fad9" DESTINATION="ID_311219420" ENDARROW="Default" ENDINCLINATION="-362;51;" ID="Arrow_ID_1251442496" SOURCE="ID_1290815698" STARTARROW="None" STARTINCLINATION="-954;49;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1737762977024" ID="ID_1561603785" MODIFIED="1737762981006" TEXT="Basis-Implementierung">
|
||||
|
|
@ -57365,7 +57366,7 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1737515362910" ID="ID_1587990202" MODIFIED="1738091484405" TEXT="offene Rekursion">
|
||||
<node COLOR="#338800" CREATED="1737515362910" FOLDED="true" ID="ID_1587990202" MODIFIED="1738091484405" TEXT="offene Rekursion">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#d9bf94" COLOR="#690f14" CREATED="1737515599278" ID="ID_1897353084" MODIFIED="1737940885393" STYLE="fork" TEXT="schwierige Frage....">
|
||||
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
|
||||
|
|
@ -58040,8 +58041,8 @@
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1736884111530" ID="ID_1649572298" MODIFIED="1736897372481" TEXT="Parse_test">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#338800" CREATED="1736884111530" FOLDED="true" ID="ID_1649572298" MODIFIED="1738208347772" TEXT="Parse_test">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1736884118136" ID="ID_514916302" MODIFIED="1736884144205" TEXT="Terminal als RegExp akzeptieren">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1736884130551" ID="ID_320996380" MODIFIED="1736884148677" TEXT="Parser-Objekt direkt"/>
|
||||
|
|
@ -102547,7 +102548,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<node CREATED="1736355038203" ID="ID_1099574201" MODIFIED="1736355055168" TEXT="die Processing-Identity dagegen ist komplex">
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1736355056700" ID="ID_383862700" MODIFIED="1736355075048" TEXT="sie läßt sich nicht auf statische Strukturen reduzieren">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1736355094705" ID="ID_751619290" MODIFIED="1736355120432" TEXT="das ist der tiefere Grund hinter dem Buffer-Hash-Problem">
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1736355094705" ID="ID_751619290" MODIFIED="1736355120432" TEXT="das ist der tiefere Grund hinter dem Buffer-Handler Hash-Problem">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -102822,7 +102823,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Und das <i>muß auch so sein,</i> denn sonnst wäre das kein freier Extension-Point. Jede Abweichung davon bedeutet effektiv eine Einschränkung der Implementierung — oder anders ausgedrückt, eine Erweiterung des Port-Interfaces. Das wäre durchaus denkbar; hier geht es allerdings um den sekundären Belang, wie man eine solche Erweiterung mit möglichst geringen Kosten realisiert
|
||||
Und das <i>muß auch so sein, </i>denn sonnst wäre das kein freier Extension-Point. Jede Abweichung davon bedeutet effektiv eine Einschränkung der Implementierung — oder anders ausgedrückt, eine Erweiterung des Port-Interfaces. Das wäre durchaus denkbar; hier geht es allerdings um den sekundären Belang, wie man eine solche Erweiterung mit möglichst geringen Kosten realisiert
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
|
|
@ -102893,7 +102894,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
Die Kosten werden hierdurch in die Laufzeit verschoben, genauer gesagt, aus dem Code-Segment in die Allokation für Nodes. Es ist weiterhin Compile-Time-Logik erforderlich, um für den Standard-Fall ein entsprechendes Tag in den <i>extended attributes</i> zu hinterlassen.
|
||||
</p>
|
||||
<p>
|
||||
Zunächst einmal erzeugt diese Lösung einen <i>erheblichen run-time-Storage-Overhead.</i> Die dynamische Codierung ersetzt einen einzelnen Pointer in der VTable jeweils durch eine String-Spec mit vmtl. mehr als 8 char Länge, sowie dazu noch einen Eintrag in einer sekundären Dispatcher-Table, bestehend aus einer Hash-ID (size_t) plus ... genau einem Function-Pointer. So gesehen, erst mal ziemlich dämlich. ABER es gibt nun einen zusätzlichen Hebel durch <b>de-Duplikation</b>: zum Einen deduplizieren wir die Spec-Strings selber; was aber noch wichtiger ist, da die Detail-Operationen nur auf Teile der Spec-Strings differenzieren, wird es <i>deutlich weniger Einträge</i> in der sekundären Dispatcher-Table geben. Eine String-View kostet <i>zwei «slot»</i> — also wäre bei mehr als <i>zwei</i>  Zusatz-Operationen der Overhead in der ProcID selber bereits reingeholt. Allerdings gibt es noch viel zusätzliche String-Storage, und die Dispatcher-Table-Einträge. Ob sich diese amortisieren, hängt von der Differenzierung in der Praxis ab. Entsprechend gibt es auch noch den Trade-off, ob man in der ProcID weniger oder mehr Teil-Komponenten des Spec-String separat speichert
|
||||
Zunächst einmal erzeugt diese Lösung einen <i>erheblichen run-time-Storage-Overhead.</i> Die dynamische Codierung ersetzt einen einzelnen Pointer in der VTable jeweils durch eine String-Spec mit vmtl. mehr als 8 char Länge, sowie dazu noch einen Eintrag in einer sekundären Dispatcher-Table, bestehend aus einer Hash-ID (size_t) plus ... genau einem Function-Pointer. So gesehen, erst mal ziemlich dämlich. ABER es gibt nun einen zusätzlichen Hebel durch <b>de-Duplikation</b>: zum Einen deduplizieren wir die Spec-Strings selber; was aber noch wichtiger ist, da die Detail-Operationen nur auf Teile der Spec-Strings differenzieren, wird es <i>deutlich weniger Einträge </i>in der sekundären Dispatcher-Table geben. Eine String-View kostet <i>zwei «slot»</i> — also wäre bei mehr als <i>zwei </i>Zusatz-Operationen der Overhead in der ProcID selber bereits reingeholt. Allerdings gibt es noch viel zusätzliche String-Storage, und die Dispatcher-Table-Einträge. Ob sich diese amortisieren, hängt von der Differenzierung in der Praxis ab. Entsprechend gibt es auch noch den Trade-off, ob man in der ProcID weniger oder mehr Teil-Komponenten des Spec-String separat speichert
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
|
|
@ -105112,7 +105113,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1730510962225" ID="ID_786613770" MODIFIED="1730563164682" TEXT="Metadaten-Zugriff / API">
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1730510962225" ID="ID_786613770" MODIFIED="1738288973161" TEXT="Metadaten-Zugriff / API">
|
||||
<arrowlink COLOR="#4416dc" DESTINATION="ID_1600745522" ENDARROW="Default" ENDINCLINATION="-224;60;" ID="Arrow_ID_1199285145" STARTARROW="None" STARTINCLINATION="183;0;"/>
|
||||
<linktarget COLOR="#34417f" DESTINATION="ID_786613770" ENDARROW="Default" ENDINCLINATION="-278;-1402;" ID="Arrow_ID_1689861408" SOURCE="ID_1257287659" STARTARROW="None" STARTINCLINATION="-284;14;"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1730510982342" ID="ID_310976542" MODIFIED="1730510998830" TEXT="Struktur/Modell">
|
||||
|
|
@ -105306,6 +105308,43 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736632825326" ID="ID_445490716" MODIFIED="1736632833373" TEXT="Argumentlisten aufschlüsseln">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1738288578828" ID="ID_1600745522" MODIFIED="1738288973161" TEXT="Wozu?">
|
||||
<linktarget COLOR="#4416dc" DESTINATION="ID_1600745522" ENDARROW="Default" ENDINCLINATION="-224;60;" ID="Arrow_ID_1199285145" SOURCE="ID_786613770" STARTARROW="None" STARTINCLINATION="183;0;"/>
|
||||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1738288603129" ID="ID_1338179026" MODIFIED="1738288730525" TEXT="zunächst geht es um Testing der Connectivity">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
ich war blockiert mit dem testgetriebenen Ansatz, denn ich kann zwar jetzt Nodes bauen, aber nicht einfach verifizieren und dokumentieren, daß sie korrekt verdrahtet sind.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1738288616423" ID="ID_1286145380" MODIFIED="1738288759369" TEXT="in Ergänzung wird damit Diagnose-Funktionalität aufgebaut">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
die gleiche Funktionalität wird später zur Problem-Diagnose benötigt; also nichts performance-kritisches
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1738288630853" ID="ID_929483195" MODIFIED="1738288876134" TEXT="produktiv gebraucht wird das zur Aufbereitung beim Build (⟼ Cache-Key)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
im Moment sieht's so aus, daß der erzeugende Code im Library-Plug-In ohnehin von internen strukturierten Daten ausgeht, um daraus die Node-Spec <i>zu generieren.</i> Diese wird dann einmal beim Builde per Parse zerlegt und ggfs noch zusätzlich dekoriert, und das war's dann.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1736632885429" ID="ID_1285666886" MODIFIED="1736633401873" TEXT="in Input / Output-Teil zerlegen">
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
<node CREATED="1736637886757" ID="ID_1642918073" MODIFIED="1736637912343" TEXT="Mist! muß Klammerung parsen"/>
|
||||
|
|
@ -105347,8 +105386,8 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1738092795598" ID="ID_461276578" MODIFIED="1738185016897" TEXT="uuuuund ... kaum wart' ma zwei Wochen, schon können wir das">
|
||||
<arrowlink COLOR="#996494" DESTINATION="ID_1363201028" ENDARROW="Default" ENDINCLINATION="-20;-32;" ID="Arrow_ID_621419348" STARTARROW="None" STARTINCLINATION="195;9;"/>
|
||||
<node CREATED="1738092795598" ID="ID_461276578" MODIFIED="1738285081902" TEXT="uuuuund ... kaum wart' ma zwei Wochen, schon können „wir“ das">
|
||||
<arrowlink COLOR="#996494" DESTINATION="ID_1363201028" ENDARROW="Default" ENDINCLINATION="-20;-32;" ID="Arrow_ID_621419348" STARTARROW="None" STARTINCLINATION="132;6;"/>
|
||||
<linktarget COLOR="#2469a2" DESTINATION="ID_461276578" ENDARROW="Default" ENDINCLINATION="1338;-36;" ID="Arrow_ID_1078242662" SOURCE="ID_195611513" STARTARROW="Default" STARTINCLINATION="1743;85;"/>
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
</node>
|
||||
|
|
@ -105377,7 +105416,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#996494" DESTINATION="ID_1363201028" ENDARROW="Default" ENDINCLINATION="-20;-32;" ID="Arrow_ID_621419348" SOURCE="ID_461276578" STARTARROW="None" STARTINCLINATION="195;9;"/>
|
||||
<linktarget COLOR="#996494" DESTINATION="ID_1363201028" ENDARROW="Default" ENDINCLINATION="-20;-32;" ID="Arrow_ID_621419348" SOURCE="ID_461276578" STARTARROW="None" STARTINCLINATION="132;6;"/>
|
||||
<font NAME="SansSerif" SIZE="10"/>
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#9c5185" CREATED="1738093029861" HGAP="44" ID="ID_993271724" MODIFIED="1738093169040" STYLE="fork" TEXT="und schon sind wieder zwei Wochen weg" VSHIFT="15">
|
||||
|
|
@ -105391,10 +105430,141 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1738332756317" ID="ID_908054156" MODIFIED="1738365016846" TEXT="Argument-Auswertung implementieren">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1738332766392" ID="ID_1638579640" MODIFIED="1738332770822" TEXT="Code-Anordnung">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1738332780351" ID="ID_1622923755" MODIFIED="1738335786356" TEXT="aus ProcNode.hpp heraushalten">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1738332793111" ID="ID_1858019254" MODIFIED="1738332811810" TEXT="steht direkt im Bezug zu ProcID">
|
||||
<node CREATED="1738332813724" ID="ID_1718339469" MODIFIED="1738332830622" TEXT="diese wird bisher nur in den Node-Builder importiert"/>
|
||||
<node CREATED="1738332847560" ID="ID_724096295" MODIFIED="1738333393945" TEXT="und in ProcNode.cpp ⟶ Auswertungsfunktionen dort">
|
||||
<arrowlink COLOR="#818a9a" DESTINATION="ID_589924971" ENDARROW="Default" ENDINCLINATION="66;9;" ID="Arrow_ID_1785024076" STARTARROW="None" STARTINCLINATION="94;5;"/>
|
||||
</node>
|
||||
<node CREATED="1738333494057" ID="ID_1032752071" MODIFIED="1738333516848">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
⟹ alle <i>Deklarationen</i> zum Spec / Model dorthin
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1738335743700" ID="ID_729101988" MODIFIED="1738335778129" TEXT="auch hier auf Footprint achten">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1738333064027" ID="ID_718627795" MODIFIED="1738333074210" TEXT="brauche eine Translation Unit">
|
||||
<node CREATED="1738333075648" ID="ID_1240771253" MODIFIED="1738333396512" TEXT="ProcNode.cpp">
|
||||
<node CREATED="1738333128706" ID="ID_589924971" MODIFIED="1738333393945" TEXT="ist eine Art »Modul«">
|
||||
<linktarget COLOR="#818a9a" DESTINATION="ID_589924971" ENDARROW="Default" ENDINCLINATION="66;9;" ID="Arrow_ID_1785024076" SOURCE="ID_724096295" STARTARROW="None" STARTINCLINATION="94;5;"/>
|
||||
</node>
|
||||
<node CREATED="1738333148199" ID="ID_1689953878" MODIFIED="1738333163304" TEXT="besteht bisher bereits zu >90% aus ID-Berechnungen"/>
|
||||
<node CREATED="1738333207784" ID="ID_1710182774" MODIFIED="1738333254957" TEXT="dient aber auch als Ankerpunkt für VTables und statische Einrichtungen"/>
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1738333257913" ID="ID_1601381760" MODIFIED="1738333286200" TEXT="man könnte eine ProcID.cpp einführen">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1738333289530" ID="ID_1670243705" MODIFIED="1738333301132" TEXT="das stünde dann aber in Konkurrenz zu ProcNode"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1738333302655" ID="ID_18611619" MODIFIED="1738333320034" TEXT="potentielle Probleme mit der Static-Init-Order">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1738333450336" ID="ID_527818328" MODIFIED="1738333461282" TEXT="also kommt auch der Spec-Parser dort hin">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1738347634026" ID="ID_891035798" MODIFIED="1738347641955" TEXT="ArgumentModel anlegen">
|
||||
<node COLOR="#5b280f" CREATED="1738347643696" ID="ID_522386929" MODIFIED="1738347656236" TEXT="vector-Storage">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1738347663501" ID="ID_1464148521" MODIFIED="1738347671672" TEXT="ist zwar naheliegend...."/>
|
||||
<node CREATED="1738347672930" ID="ID_1031193959" MODIFIED="1738347688238" TEXT="aber zwingt dazu, alle Zugriffsoperationen + Iterator zu wrappen"/>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1738347690249" ID="ID_862217851" MODIFIED="1738364998155" TEXT="lib::Several<const string>">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1738347706783" ID="ID_336712415" MODIFIED="1738347755736" TEXT="würde exakt die benötigten Operationen direkt bieten">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
d.h. ArgumentModel könnte eine Struct sein, und lediglich zusätzliche Informations-Funktionen bieten
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1738347757673" ID="ID_343200211" MODIFIED="1738347794623" TEXT="es gibt noch kein fill-by-move ⟹ nachrüsten">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1738347797563" ID="ID_128830147" MODIFIED="1738364972902" TEXT="const Element-Typ macht Probleme">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1738347812806" ID="ID_248989693" MODIFIED="1738364970007" TEXT="reinterpret-cast macht keinen const-cast">
|
||||
<node CREATED="1738347833854" ID="ID_1340813798" MODIFIED="1738347845378" TEXT="hey... was soll das??">
|
||||
<icon BUILTIN="smiley-angry"/>
|
||||
</node>
|
||||
<node CREATED="1738361418511" ID="ID_543773842" MODIFIED="1738361846225" TEXT="eine Spitzfindigeit: »reinterpret« bezieht sich auf die Interpretation der Storage-Bytes"/>
|
||||
<node CREATED="1738361883471" ID="ID_627488338" MODIFIED="1738361914832" TEXT="const_cast kann nur eine const-Sicht (Referenz / Pointer) übersteuern">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1738361855650" ID="ID_1275535621" MODIFIED="1738361873251" TEXT="ein const-Objekt könnte in ein read-only datensegment gelegt werden">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1738348359719" ID="ID_968746797" MODIFIED="1738364967687" TEXT="seltsame Probleme mit dem Allokator">
|
||||
<node CREATED="1738348393499" ID="ID_536251182" MODIFIED="1738361405248" TEXT="Spezialisierung ist wohl nur für non-CV definiert"/>
|
||||
<node CREATED="1738348411361" ID="ID_404478938" MODIFIED="1738348444571" TEXT="also CV automatisch vom Typ entfernen">
|
||||
<node COLOR="#435e98" CREATED="1738348446044" ID="ID_1406523831" MODIFIED="1738361998554" TEXT="will nicht funktionieren">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1738348458226" ID="ID_59165298" MODIFIED="1738361926851" TEXT="mismatch mit new_allocator, der einen Basis-Allocator per Pointer nimmt">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
<node COLOR="#990033" CREATED="1738348499778" ID="ID_446457610" MODIFIED="1738361939446" TEXT="Woot?? vorher hat es doch auch funktioniert???">
|
||||
<icon BUILTIN="help"/>
|
||||
<node COLOR="#c50b88" CREATED="1738361943320" ID="ID_595058481" MODIFIED="1738361988922" TEXT="werlesenkannistklarimVorteil">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...mußte dazu erst mal eine Runde raus, dann hab ichs rasch gesehen...
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<font NAME="SansSerif" SIZE="11"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1738359177729" ID="ID_1678432646" MODIFIED="1738359205265" TEXT="habe allocator und allocator-traits verwechselt">
|
||||
<icon BUILTIN="smiley-oh"/>
|
||||
<node CREATED="1738360439157" ID="ID_1282286706" LINK="#ID_1432559286" MODIFIED="1738360568628" TEXT="Zur Erinnerung: allocator_traits ist das Interface für die Container"/>
|
||||
<node CREATED="1738360595944" ID="ID_1287964624" MODIFIED="1738360631591" TEXT="dagegen den Allocator spezialisiert man (oder schreibt ihn komplett selbst)"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1738362009001" ID="ID_1270461864" MODIFIED="1738362022913" TEXT="damit geht's kann einen const-String von non-const-String initialisieren"/>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1738364889035" ID="ID_1815714742" MODIFIED="1738364963180" TEXT="Destruktor kann nicht festgestellt werden">
|
||||
<node CREATED="1738364904359" ID="ID_1913087416" MODIFIED="1738364944225" TEXT="liegt ebenfalls an CV">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1738364912664" ID="ID_601860907" MODIFIED="1738364960954" TEXT="not is_same<string, const string>">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1738364946554" ID="ID_987653524" MODIFIED="1738364958732" TEXT="Lösung: lib::meta::Strip">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1738364976050" ID="ID_192401035" MODIFIED="1738364993580" TEXT="damit jetzt nutzbar für const-strings"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1736632908578" ID="ID_1359149203" MODIFIED="1736633401873" TEXT="Token-Sequenz generieren">
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
<node CREATED="1736633418536" ID="ID_1128683976" MODIFIED="1736633455934" TEXT="Regular-Expressions (nach Schema-F)">
|
||||
<node COLOR="#5b280f" CREATED="1736633418536" ID="ID_1128683976" MODIFIED="1738280806304" TEXT="Regular-Expressions (nach Schema-F)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -105403,7 +105573,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="idea"/>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1736633520472" ID="ID_837769302" MODIFIED="1736633745684" TEXT="delimiter? ⟹ Komma mit (optionalen) Quotes">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
|
|
@ -105414,9 +105584,84 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1738280884035" ID="ID_1578797036" MODIFIED="1738281039768" TEXT="leicht zu implementieren aber mühsam zu handhaben">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Das passiert, wenn man mit einer Implementierungtechnik anfängt, und nicht bei der Anforderungs-Analyse....
|
||||
</p>
|
||||
<p>
|
||||
Ja, es würde definitiv gehen, und der User würde fluchen, denn die allgegenwärtigen Quotes haben die Nützlichkeit einer »einfachen Listen-Spec« wieder auf. Hinzu kommt, daß es einige spziell lästige Grenzfälle gibt, wie nested-Quotes , die man dann finden und escapen muß
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1738281900077" ID="ID_285802042" MODIFIED="1738282063851" TEXT="bin besorgt wegen der noch offenen Richtung der Entwicklung">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
weiß noch nicht recht, wohin das mit der Node-Spec noch führen wird; nach der Lösung mit einer textuellen Spech habe ich vor allem gegriffen, da ich eine Festlegung auf ein Meta-Modell vermeiden möchte — da noch auf lange Zeit das Projekt nicht im Stande sein wird, das Feld der Möglichkeiten hier zu überblicken (was für Medien werden überhaupt verarbeitet? Außer Video und Sound, meine ich....)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1738280786811" ID="ID_1355841919" MODIFIED="1738280796189" TEXT="also dann doch richtig parsen">
|
||||
<node CREATED="1738281073002" ID="ID_537165384" MODIFIED="1738281158036" TEXT="schon beim Zerlegen in Input/Output bin ich auf diese Probleme gestoßen —">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
....und jetzt hab ich einen echten LL-Parser, der diese Aufgabe direkt und ohne Implementierungstricks handhaben kann
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1738281326205" ID="ID_1746479195" MODIFIED="1738281816880" TEXT="per Parse kann man aber auch gleich ein Modell erzeugen">
|
||||
<node CREATED="1738281820274" ID="ID_1616091691" MODIFIED="1738281831902" TEXT="ist die Frage ob das hier sinnvoll ist"/>
|
||||
<node CREATED="1738281832897" ID="ID_1679825734" MODIFIED="1738281848598" TEXT="alternativ könnte man auch x-mal immer wieder parsen"/>
|
||||
<node COLOR="#435e98" CREATED="1738282103267" ID="ID_981290324" MODIFIED="1738288404860" TEXT="was für Zugriffe wären denn regelmäßig zu erwarten">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1738282122522" ID="ID_1638205904" MODIFIED="1738282141735" TEXT="(also nicht im Test, sondern beim Rendern)">
|
||||
<font NAME="SansSerif" SIZE="10"/>
|
||||
</node>
|
||||
<node CREATED="1738287496191" ID="ID_603773549" MODIFIED="1738287513728" TEXT="Proc-ID-Hash ⟼ Cache-Key">
|
||||
<node CREATED="1738287635731" ID="ID_1544335110" MODIFIED="1738287651757" TEXT="ließe sich durch Hashing gespeicherter ID-Bestandteile realisieren"/>
|
||||
<node CREATED="1738287652784" ID="ID_437630211" MODIFIED="1738287666843" TEXT="insofern ist nur die Aufbereitung (beim Build) relevant"/>
|
||||
</node>
|
||||
<node CREATED="1738288309624" ID="ID_203838981" MODIFIED="1738288402151" TEXT="Instrumentierung würde sich wohl v.A. auf Node-Connectivity abstützen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...deshalb habe ich ja auch die Node-Connectivity beibehalten (obwohl zum Rendern nur die Port-Connectivity gebraucht wird). Zusätzlich könnten noch Attribute in der ProcID eine Rolle spielen. Also insgesamt ehr kein separates Parsing
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1738288408915" ID="ID_1594772328" MODIFIED="1738288439248">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
⟹ also so implementieren wie's <i>am einfachsten</i> geht
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736633780461" ID="ID_182647940" MODIFIED="1736633788547" TEXT="Repetitions-Spec /#"/>
|
||||
</node>
|
||||
<node CREATED="1736633797874" ID="ID_266262938" MODIFIED="1736633802805" TEXT="Token-Pipeline aufbauen">
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1736633797874" ID="ID_266262938" MODIFIED="1738288459135" TEXT="Token-Pipeline aufbauen">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node COLOR="#5b280f" CREATED="1736633850189" ID="ID_187292513" MODIFIED="1736633861182" TEXT="könnte ein Expander sein">
|
||||
<icon BUILTIN="stop-sign"/>
|
||||
<node COLOR="#5b280f" CREATED="1736633863015" ID="ID_1166752601" MODIFIED="1736633908235" TEXT="unnötig komplex">
|
||||
|
|
@ -105441,6 +105686,19 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1738282167772" ID="ID_323008097" MODIFIED="1738282287346" TEXT="Woot?? wozu hier eine Pipeline">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Aua, dieses Thema ist zu lange liegen geblieben; drei Monate später weiß ich nicht mehr, was ich überhaupt bezwecken wollte....  Kam das mit der Pipeline so zustande, weil ich mir vorgestllt hatte, einen Spec-String mit einer RegExp zu »scannen« — denn so einfach wird es nicht sein
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<node CREATED="1738288462715" ID="ID_721467849" MODIFIED="1738288475560" TEXT="sehe jetzt (1/25) keine direkte Notwendigkeit"/>
|
||||
<node CREATED="1738288476858" ID="ID_1430760953" MODIFIED="1738288501992" TEXT="und aus einem temporär erzeugten Proc-Argument-Model ließe sich sowas leicht erzeugen"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1736632937502" ID="ID_461312539" MODIFIED="1736632988969" TEXT="Reduktion machen wir nicht">
|
||||
|
|
@ -105484,7 +105742,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node CREATED="1736455424795" ID="ID_1408873676" MODIFIED="1736518472498" TEXT="dedizierter Record-Datentyp">
|
||||
<icon BUILTIN="forward"/>
|
||||
<node CREATED="1736455468174" ID="ID_875438649" MODIFIED="1736519180780">
|
||||
<node CREATED="1736455468174" ID="ID_875438649" MODIFIED="1738282498188">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -105497,7 +105755,7 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
eine »offene« Lösung würde einer Erweiterung von Lumiera (plug-in) oder einer speziellen Library-Integration ermöglichen, Attribute durch das low-level-Model hindurch zu »tunneln«, ohne spezielle Unterstützung der Core-Implementierung. Ich halte das jedoch aktuell für einen <i>nicht naheliegenden</i> Ansatz, da es keinen »Rück-Kanal« vom low-level-Model in die Erweiterungen/Plug-ins gibt; generell hat sich das low-level-Model zu einer internen Struktur entwickelt und kann nicht verstanden werden ohne implizite Kenntnis mancher Entwicklungs-Aspekte
|
||||
eine »offene« Lösung würde einer Erweiterung von Lumiera (plug-in) oder einer speziellen Library-Integration ermöglichen, Attribute durch das low-level-Model hindurch zu »tunneln«, ohne spezielle Unterstützung der Core-Implementierung. Ich halte das jedoch aktuell für einen <i>nicht naheliegenden </i>Ansatz, da es keinen »Rück-Kanal« vom low-level-Model in die Erweiterungen/Plug-ins gibt; generell hat sich das low-level-Model von einer Schnittstelle weg und zu einer internen Struktur hin entwickelt und kann nicht verstanden werden ohne implizite Kenntnis mancher Entwicklungs-Aspekte
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
|
|
@ -105632,7 +105890,11 @@ StM_bind(Builder<R1> b1, Extension<R1,R2> extension)
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610781361" ID="ID_1231919908" LINK="#ID_25381362" MODIFIED="1736611024747" TEXT="Argument-Listen parsen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1736629449423" ID="ID_1820450120" MODIFIED="1736629456341" TEXT="werden grundsätzlich abgespalten"/>
|
||||
<node CREATED="1736629449423" ID="ID_1820450120" MODIFIED="1736629456341" TEXT="werden grundsätzlich abgespalten">
|
||||
<node CREATED="1738289004062" ID="ID_126365125" LINK="#ID_1594772328" MODIFIED="1738289050186" TEXT="Hinweis zur Anlage der Implementierung beachten">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1736632585878" ID="ID_919502124" MODIFIED="1736632594880" TEXT="zerlegen in Input und Output"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1736610789680" ID="ID_466994748" LINK="#ID_25381362" MODIFIED="1736611024747" TEXT="extended Attributes auswerten">
|
||||
|
|
@ -152515,7 +152777,7 @@ std::cout << tmpl.render({"what", "World"}) << s
|
|||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715693174737" FOLDED="true" ID="ID_152113212" MODIFIED="1715725332461" TEXT="(custom)Allocator">
|
||||
<node CREATED="1715693174737" ID="ID_152113212" MODIFIED="1715725332461" TEXT="(custom)Allocator">
|
||||
<linktarget COLOR="#4961d5" DESTINATION="ID_152113212" ENDARROW="Default" ENDINCLINATION="-2030;323;" ID="Arrow_ID_717223261" SOURCE="ID_868305899" STARTARROW="None" STARTINCLINATION="-1527;135;"/>
|
||||
<node CREATED="1715693298760" ID="ID_1472333314" MODIFIED="1715693300284" TEXT="Quellen">
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1715696253175" ID="ID_267534641" MODIFIED="1715696324289" TEXT="CPP-Referenz">
|
||||
|
|
|
|||
Loading…
Reference in a new issue