From e98fe1e78b5d4e58e7ba0c8e596dc3d5f7e586fc Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 29 Aug 2023 02:18:07 +0200 Subject: [PATCH] Activity-Lang: scaffolding to create a simple Term --- src/vault/gear/activity-lang.hpp | 14 +- src/vault/gear/activity-term.hpp | 13 +- tests/vault/gear/activity-detector.hpp | 15 +- tests/vault/gear/scheduler-activity-test.cpp | 14 +- wiki/thinkPad.ichthyo.mm | 1102 ++++++------------ 5 files changed, 422 insertions(+), 736 deletions(-) diff --git a/src/vault/gear/activity-lang.hpp b/src/vault/gear/activity-lang.hpp index 700af005c..cd0549e33 100644 --- a/src/vault/gear/activity-lang.hpp +++ b/src/vault/gear/activity-lang.hpp @@ -76,15 +76,27 @@ namespace gear { // using default copy/assignment + + /** + * Builder-API: initiate definition of render activities for a media calculation job. + */ + activity::Term + buildCalculationJob (Job job, Time start, Time deadline) + { + return setupActivityScheme (activity::Term::CALC_JOB, job, start, deadline); + } + + private: /** @internal generate the builder / configurator term */ activity::Term - setupActivityScheme (activity::Term::Template schemeKind, Time start, Time after) + setupActivityScheme (activity::Term::Template schemeKind, Job job, Time start, Time after) { return activity::Term{ mem_.until(after) , schemeKind , start , after + , job }; } }; diff --git a/src/vault/gear/activity-term.hpp b/src/vault/gear/activity-term.hpp index cec89d1b7..f6959686d 100644 --- a/src/vault/gear/activity-term.hpp +++ b/src/vault/gear/activity-term.hpp @@ -48,6 +48,7 @@ #include "vault/gear/activity.hpp" #include "vault/gear/block-flow.hpp" +#include "vault/gear/job.h" //#include "lib/symbol.hpp" #include "lib/time/timevalue.hpp" //#include "lib/util.hpp" @@ -80,6 +81,9 @@ namespace gear { AllocHandle alloc_; + Activity* invoke_{nullptr}; + Activity* post_{nullptr}; + public: enum Template {CALC_JOB ///< scheme for a synchronous media calculation job ,LOAD_JOB ///< scheme for an asynchronous data retrieval job @@ -87,7 +91,7 @@ namespace gear { }; explicit - Term (AllocHandle&& allocHandle, Template kind, Time start, Time after) + Term (AllocHandle&& allocHandle, Template kind, Time start, Time after, Job job) : alloc_{move (allocHandle)} { } @@ -101,6 +105,13 @@ namespace gear { // { // return diagnostic(); // } + + Activity& + post() + { + REQUIRE (post_, "Activity Term not yet fully configured"); + return *post_; + } }; diff --git a/tests/vault/gear/activity-detector.hpp b/tests/vault/gear/activity-detector.hpp index 69d4859a4..d4b79dab5 100644 --- a/tests/vault/gear/activity-detector.hpp +++ b/tests/vault/gear/activity-detector.hpp @@ -62,7 +62,7 @@ #include "vault/common.hpp" -//#include "lib/test/test-helper.hpp" +#include "lib/test/test-helper.hpp" #include "lib/test/event-log.hpp" //#include "steam/play/dummy-play-connection.hpp" @@ -499,6 +499,19 @@ namespace test { buildDiagnosticFun (id)); } + Job + buildMockJob (string id ="" + ,Time nominal = lib::test::randTime() + ,size_t extra = rand()) + { + InvocationInstanceID invoKey; + invoKey.part.a = extra; + invoKey.part.t = _raw(nominal); + return Job{buildMockJobFunctor (isnil(id)? "mockJob-"+util::toString(nominal) : id) + ,invoKey + ,nominal}; + } + /** build a rigged HOOK-Activity to record each invocation */ Activity& buildActivationProbe (string id) diff --git a/tests/vault/gear/scheduler-activity-test.cpp b/tests/vault/gear/scheduler-activity-test.cpp index 6bd4c002b..f8c020d71 100644 --- a/tests/vault/gear/scheduler-activity-test.cpp +++ b/tests/vault/gear/scheduler-activity-test.cpp @@ -350,11 +350,23 @@ namespace test { /** @test TODO verify the Activity term builder - * @todo WIP 7/23 ⟶ define ⟶ implement + * @todo WIP 8/23 🔁 define ⟶ implement */ void termBuilder() { + ActivityDetector detector; + + BlockFlowAlloc bFlow; + ActivityLang activityLang{bFlow}; + + Job job = detector.buildMockJob(); + Time start{0,1}; + Time dead{0,10}; + auto term = activityLang.buildCalculationJob (job,start,dead); + + Activity& post = term.post(); + CHECK (Activity::POST == post.verb_); } diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 0ca73a866..a0dfd723e 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -76507,9 +76507,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...weil es der Sache nach wirklich nur eine Konversion der aufgesammelten Infos ist, und nicht eine komplexe Berechnung; außerdem paßt es so halbwegs auch syntaktisch zum beabsichtigen Nutzen — aber genau dieser Nutz-Kontext ist auch ein Gegen-Argument: der Sinn der Sache erschließt sich nämlich nicht intuitiv, wenn man da sieht: *pipeline @@ -76555,9 +76553,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Definition: der letzte Zeitpunkt an dem der Job starten darf @@ -76587,9 +76583,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Definition: Pufferzeit, um die der Job bereits früher starten kann @@ -76642,9 +76636,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

das ist adäquat, da in diesem Bereich grundsätzlich nichts mehr gecheckt wird (das hat alles schon der Builder getan) @@ -76657,8 +76649,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + @@ -76715,9 +76707,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

sonst wird der Test später instabil @@ -76730,9 +76720,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...aktuell denke ich, die Details der Timings kommen aus der RenderEnvironmentClosure (aber was das heißt sei dahingestellt....) @@ -76758,9 +76746,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

InvocationInstanceID invoKey{timeHash (nominalTime, provision.invocationSeed)}; @@ -76771,9 +76757,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

brauche dann aber einen Weg, @@ -76797,9 +76781,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

im Job wäre die nominelle Zeit gegeben @@ -76811,9 +76793,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

die aktuelle Frame-Nummer ist nun nur noch ein lokales Detail in der Planning-Pipeline; für den re-Trigger-Job genügt eine Zeitangabe, aus der dann eine realTime-Deadline abgeleitet wird @@ -76823,6 +76803,51 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + + +

+ Das könnte potentiell tückisch werden; vermutlich ist es aber harmlos in der Praxis, sofern durch sinnvolle Parametrisierung für ausreichenden Zeitpuffer gesorgt wird. Das Restrisiko besteht darin, daß die Aktivierung bereits geplanter Jobs den Planungsvorgang überholt, welcher dann nachträglich noch Vorraussetzungen aufschaltet auf einen bereits gestarteten Job; schlimmstenfalls gibt sogar der BlockFlow bereits die ganze Epoche frei, während der aktuell laufende Planning-Chunk noch auf den damit verbundenen Activities arbeitet ⟹ data corruption, Segfault +

+ + + + + + + +

+ bekommen wir das Problem durch Checks in den Griff — +

+

+ oder brauchen wir eine transaktionelle Schnittstelle? +

+ + + + + + + + + + + +

+ ...denn auch das Entnehmen und Starten von Jobs muß unter Grooming-Token erfolgen, kann also erst erfolgen, nachdem der Planning-Chunk komplett abgeschlossen wurde +

+ + + + + + @@ -76847,9 +76872,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

unklar: JobTicket::startExploration() — wie wird die eigentliche Planung eingefädelt? @@ -76923,9 +76946,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

es wird das Vorhandensein abstrakt definierter Zustands-Deskriptoren impliziert, deren Sinn der Implementierung vorbehalten bleibt @@ -76960,9 +76981,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

weil Segment inhärent ein mutabler Typ ist (ich denke an das Umbauen und Modifizieren), gibt der reine Access nur ein Segment const& raus @@ -76992,9 +77011,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...uns anders wäre es sogar erst mal viel plausibler; ich selber habe lange Zeit anders gedacht, nämlich das die Channel hier den Medienkanälen entsprechen. Dann müßte man aber jedem CalcStream noch ein Channel-Mapping mitgeben, und auch für Prerequisites müßte eine Transformation für dieses Mapping mit angegeben werden. Daraus wird plausibel, warum ich diesen naiven Ansatz verworfen habe.... @@ -77004,9 +77021,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...denn der Builder-Ansatz bedeutet, daß das semantische / domänen-bezogene high-level-Modell explizit übersetzt wird in ein reines Ausführungs-Modell. Letzteres soll keine Intelligenz mehr zur Interpretation enthalten, sondern nur noch zwangsläufig ausgeführt werden. Dem entsprechend muß in diesem Ausführungs-Modell (low-level-Modell) jedweder dynamische Auswertungszustand soweit möglich vermieden werden. Zur konkreten Ausführung dennoch erforderlicher Zustand wird symbolisch repräsentiert ("representational state") @@ -77061,9 +77076,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...zur Übersetzung der internen Strukturen im JobTicket in eine Folge verschachtelter Prerequisite-JobTicket @@ -77095,8 +77108,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + @@ -77153,9 +77166,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

denn diese wären rekursiv wieder JobTickets; würde man die Aufteilung nach ModelPort in das JobTicket selber hineinnehmen, dann wären auch die Prerequisites wieder nach ModelPort untergliedert; das wiederspricht den Freiheitsgraden der Struktur (Prerequisites sind an die einzelne ExitNode gebunden) @@ -77166,9 +77177,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Grundsätzlich ist es erst mal egal, man braucht eben einen Descriptor-Record pro Segment pro ModelPort. Da aber JobTickets on-demand erzeugt werden, wird der Aufwand hierfür verschoben in die Job-Planung (und findet gar nicht statt, solange eine bestimmte ExitNode konkret noch gar nicht bespielt wurde) @@ -77189,9 +77198,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Und zwar, weil es so am Einfachsten ist für die Implementierung der OutputConnection = slot.allocate() .... @@ -77216,9 +77223,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...es ist keineswegs sicher, daß wir mit einer bloßen Addressierung per Channel-Nummer auskommen; es könnte durchaus passieren, daß Erweiterung auf eine generische Selektions-Sprache notwendig wird @@ -77236,9 +77241,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

man denke nur an higher-order Ambisonics... @@ -77252,9 +77255,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

den Channel-Parameter kann man leichter wegfallen lassen, als ihn nachträglich durchzufädeln; die Entscheidung selber wird erst relevant, wenn wir das low-Level-Model konkretisieren @@ -77265,9 +77266,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...Kernargument ist: das Multiplexing von Medienchannels ist Teil der Berechnungen selber, tritt also nicht auf Interface-Ebene auf. Selbst die Funktionalität des Switch-Board im GUI-Player wird in der Renderpipeline selber implementiert... @@ -77282,9 +77281,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Klärung: „Channel“ ist hier eine Port-Nummer @@ -77292,9 +77289,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Dies folgt aus den Überlegungen zur Identität eines CalcStream, sowie aus dem Builder-Ansatz: es handelt sich demnach nicht um den Medien-Channel, sondern nur um die Auswahl aus N an dieser Stelle theoretisch möglichen CalcStrams / Daten-Strömen. Im klassischen Standard-Beispiel gäbe es also einen Port für Video und einen Port für Sound, und ein Play-Prozeß könnte optional nur einen oder alle beide abspielen, aber jeder von diesen geht an ein anderes Device und läuft deshalb selbständig. Die Zuordnung eines solchen möglichen Datenstroms zu einer ganz bestimmten Processing-Pipeline ist schon im Build-Vorgang vorentschieden worden, und ist im Job-Ticket jeweils für ein Segment komplett voreingestellt; soll dann konkret ein bestimmter Datenstrom erzeugt werden, muß man nur noch diese Port-Nummer anzugeben, um dafür die passenden Jobs zu generieren @@ -77307,9 +77302,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Dies ist erst mal nicht offensichtlich, denn grundsätzlich wird ja immer auf einheitliche Topologie hin segmentiert; es wäre sehr wohl denkbar, daß z.B. der Sound fast durchgehend nur eine einzige Topologie der Processing-Pipeline hat, während für Video mehrfach die Topologie gewechselt wird (Fades, Overlays...). Aber eine praktische Abschätzung ergibt, daß im Regelfall für jeden Clip sowohl die Sound-Quelle, alsauch die Video-Quelle jeweils spezifish ist, auch bezüglich des Offset im Quellmedium; wenn ein Clip wechselt, dann wechseln sowohl Bild und Ton. Daher ist es wahrscheinlich, daß eine feingranularer angesetzte Segmentation in der Regel redundant wäre. Und diese Redundanz wäre kostspielig, denn die Zahl der Segmente ist erwartungsgemäß hoch. @@ -77348,9 +77341,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

und alle müssen an dieser Stelle auf einen Schlag angebunden werden @@ -77395,9 +77386,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Begründung: wir wollen definitiv nicht für jedes Segment wieder einen Map-Lookup machen @@ -77430,9 +77419,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Nach aktuellem Stand verweist das JobTicket per Pointer oder Referenz auf ein ExitNode-Objekt, und diese Referenz wird später an den JobFunktor durchgereicht. Irgendwo dahinter verbirgt sich ein Element mit fester Identität (Referenz-Semantik), aber ich weiß noch nicht wo genau. Meine Vorstellung ist, daß das Segment an einer festen Position im Speicher fixiert bleibt, solange noch CalcStreams bzw. Jobs aktiv sind, die die dahinter hängenden Render-Nodes referenzieren — das ist die Grundidee hinter dem »AllocationCluster« @@ -77443,9 +77430,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...und zwar, um den Umgang mit der Datenstrutur und das Testing nicht unnötig zu verkomplizieren; ich hoffe, der Umstand, daß ExitNode als MoveOnly markiert ist, sorgt für ausreichend Sicherheit (deshalb dürfte sich die Collection der ExitNodes nicht ohne Weiteres kopieren lassen) @@ -77462,9 +77447,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Also konkret die Frage: kann ein-und-diesselbe ProcNode mit allen darunter hängenden Strukturen gleichzeitig von mehreren Segmenten verwendet werden? Das klingt zunächst einmal durchaus nach einer plausiblen Möglichkeit, da ja die Render-Nodes selber nichts über ihre nominelle Zeit wissen sollen; demnach wären die Render-Nodes eine persistente Datenstruktur @@ -77475,9 +77458,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

⟹ Render-Nodes als persistente Datenstruktur behandeln? @@ -77487,9 +77468,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

↯ ABER dann brauchen wir einen Ref-count... @@ -77507,9 +77486,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

im low-level-Model selber gibt es keine Entscheidungslogik mehr; sofern es mehrere Ausprägungen oder Verzweigungen gibt, werden diese als Zweige im Modell explizit gemacht @@ -77519,9 +77496,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

die konkrete Ausprägung jedweder Eigenschaft findet im Node-Graph statt, nicht sonstwo in der Fixture. Beispielsweise ist im Node-Graph festgelegt, wo Caching stattfinden kann, oder welche Sub-Zweige als Prerequisites separat gescheduled werden. Die ExitNode aggregiert diese Informationen nur, und im JobTicket werden sie aufgehängt @@ -77531,9 +77506,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

sofern irgend eine Eigenschaft renderbar ist, gibt es eine Anknüpfung aus einem Segment per ModelPort-Nr in das Modell @@ -77564,9 +77537,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...damit, daß das JobPlanning bereits in der Mitte der Pipeline erzeugt wird... @@ -77576,9 +77547,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

hier spielt auch mit, daß man das expandPrerequisites() stets weglassen kann (das folgt schon aus den Eigenschaften einer solchen Expander-Funktion — sie muß auch ohne Expansion funktionieren) @@ -77592,9 +77561,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Vorläufig: einen Transformer vorsehen, der das JobPlanning noch manipulieren kann @@ -77602,9 +77569,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Wichtig: dieser Transformer muß explizit JobPlanning& als Ergebnistyp deklarieren: damit bekommt man die »Referenz-Variante« vom ItemWrapper — leider aber auch eine zusätzliche Indirektion, die nicht wegoptimiert werden kann (weil sie je nach darunter liegendem Expander woanders hin zeigt) @@ -77619,9 +77584,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

es gibt einen commit @@ -77633,9 +77596,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Einträge sind woanders alloziert @@ -77659,9 +77620,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

nur eine einzige, die Aktive @@ -77692,9 +77651,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

geplant: generisches front-End für Custom Allocator @@ -77724,9 +77681,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

das bedeutet: die alten Interfaces müssen von den neuen Interfaces erben, dann kann schon stückweise Code geschrieben werden, der die neuen Interfaces vorraussetzt... @@ -77827,9 +77782,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

wir können nicht die Daten für jeden Job einzeln nachverfolgen (dann würden wir etwa den Level von Arbeit leisten, wie ein Garbage-Collector) — vielmehr muß es sowas wie »epochs« geben @@ -77840,9 +77793,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

In extremen Situationen kann es vorkommen, daß das Checkpoint-System eine Rest-Menge identifiziert, die aus anderen Gründen  zuverlässig beobachtet werden muß. Als Beispiel denke ich über obsolete Reste einer aufwendigen Berechnungskette, die unterwegs geändert wurde: hier müssen diejenigen (wenigen) Activities gefunden werden, die bereits „unterwegs“ sind; erst wenn diese alle wieder zurückgekommen sind, kann ein Clean-up-Trigger feuern @@ -77865,9 +77816,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

ganz im Gegenteil: hier braucht man eine trivial kopierbare und destruierbare Datenstruktur mit Standard-Layout und keinerlei Magic @@ -77888,9 +77837,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

dispatches a JobFunctor into an appropriate worker thread, based on the job definition's execution spec @@ -77923,9 +77870,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

push a message to another Activity or process record @@ -77935,9 +77880,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

probe a launch window from start to deadline, and additionally check a count-down latch; on success activate the next Activity, else re-schedule @self into the future @@ -77947,9 +77890,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

supply additional payload data for a preceding Activity @@ -77959,9 +77900,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

post a message providing a chain of further time-bound Activities @@ -77971,9 +77910,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

internal engine »heart beat« -- invoke internal maintenance hook(s) @@ -77995,9 +77932,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Activity-Terme sind sowohl semantsich, als auch operational polymorph; das heißt es gibt einen gemeinsamen Kontrakt und eine flexible Ausdifferenzierung im Verhalten. ABER aus Performance-Gründen können wir uns im Scheduler keine unnötigen Indirektionen und variablen Allokationen leisten; stattdessen wird die gesamte Storage per Mehrfachbelegung auf einen einzigen Datenblock abgebildet, und das Verhalten wird in ein Switch-on-Selector-Field übersetzt @@ -78043,9 +77978,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

startTime @@ -78127,9 +78060,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Richtwert: 2 * 64bit + next-Ptr @@ -78172,8 +78103,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + @@ -78279,9 +78210,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Das ergibt sich unmittelbar aus den Prinzipien dieses Designs: Job-Planung läuft auf das Erstellen von Activities hinaus, und dies bedingt Speicherverwaltung — welche der grundlegenden Entscheidung gemäß nur im Management-Modus (single-threaded, unter GroomingToken) stattfinden darf @@ -78322,13 +78251,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + - - + + @@ -78354,9 +78283,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + @@ -78426,9 +78356,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - +

aus dem Term können die @@ -78440,7 +78368,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + @@ -78453,7 +78381,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + + + @@ -78463,9 +78394,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - +

Builder-Operationen können auch nachher @@ -78484,9 +78413,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

das Job-Planning „muß wissen was es tut“ — typischerweise müssen alle Zeitfenster hinreichend weit in der Zukunft liegen @@ -78494,28 +78421,42 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + - + + + + + + +

+ nach vorläufiger Analyse: harmlos +

+ + + + + + + - + - - - +

wenig Raum für Diskussionen — und zwar wegen der Memory-Allokation

+ @@ -78919,9 +78860,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Das wäre dann eine sehr spezielle Design-Entscheidung: nicht eine passiver Threadpool, dem von einem aktiven Manager aus die Aufgaben zugewiesen werden, sondern aktive Worker, die sich selber regulieren und Arbeit holen @@ -79702,6 +79641,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + @@ -80427,9 +80369,55 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + + + + + + +

+ hier ist es nicht sinnvoll, die MockJobs aus dem Dispatcher zu verwenden, und zwar aus zwei Gründen +

+
    +
  • + Linking-Dependencies: wir sind in der Vault +
    • +
  • + Verifikation per EventLog ⟷ Verifikation per internem Invocation-Record +
    • +
+ + + + + + + + + + + + + + + +

+ POST⟶TIMESTART⟶INVOKE⟶FEED⟶FEED⟶TIMESTOP +

+ + + + + + + + + + + @@ -87595,9 +87583,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - +

Achtung: der Begriff »POD« is @deprecated @@ -87618,9 +87604,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

„trivial“ ⟹ der Compiler muß nix Spezielles  machen @@ -87663,9 +87647,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Ticket #886 @@ -87683,9 +87665,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

09.05.19 17:10 @@ -87710,9 +87690,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

OpaqueUncheckedBuffer_test für InPlaceBuffer @@ -87725,9 +87703,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

vielleicht doch @@ -87738,9 +87714,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

das Problem sind implizit definierte Konstruktoren in der Vererbuns-Hierarchie @@ -87770,9 +87744,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Coroutinen sind nicht per se asynchron @@ -87786,9 +87758,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

welche dann jedoch stets aus einer Coroutine heraus per co_await aktiviert werden. Beispiel: ein lock-free mutex @@ -87799,9 +87769,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Kontrollübergänge erfolgen ausschließlich an den suspend points in der Coroutine selber @@ -87809,9 +87777,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

Das untermauert nochmal, daß Coroutinen inhärent synchron und deterministisch sind. Man kann allerdings das low-level-Framework nutzen, um an einem bestimmten suspend-point den "eingefrorenen" Zustand der Coroutine asynchron an einen anderen Thread zu übertragen @@ -87840,9 +87806,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - - +

...also für template templtate parameter; @@ -87880,9 +87844,7 @@ class Something - - - +

verblüffenderweise ist das im Schnitt die effizienteste Lösung, aufgrund der guten Cache-Lokalität des Vektors @@ -87902,9 +87864,7 @@ class Something - - - +

Eine Störstelle in der Heap-Struktur wird durch „lokales bubble“ korrigiert. Ein am Ende hinzugefügtes Element bubbled hoch, bis es größer ist als beide Kinder. Für ein entferntes größtes Element rutscht das größere Kind hoch. Für ein entferntes inneres Element wird zunächst das letzte Element an diese Stelle gesetzt  (weil dadurch dann die letzte Position frei wird); die dadurch entstehende Störstelle wird dann nach oben/unten korrigiert: ist das Element größer als der Vater, tauscht es mit diesem, ist es kleiner als das größere seiner Kinder, tauscht es mit diesem. @@ -87919,9 +87879,7 @@ class Something - - - +

...hatte ich vor einigen Jahren schon durchgeführt. Die Boost-Impl wird weithin empfohlen, sie kommt einer Standard-Lib am nächsten. Für Ringbuffer gibt es diverse Alternativen, aber für Multi-Producer / Multi-Consumer-Queue habe ich ansonsten nur Einzelfall-Implementierungen gefunden @@ -87963,9 +87921,7 @@ class Something - - - +

"load effective address"
Es entspricht also dem &-Operator in C @@ -87977,9 +87933,7 @@ class Something - - - +

Lessons @@ -87995,9 +87949,7 @@ class Something - - - +

auf incomplete type achten @@ -88008,9 +87960,7 @@ class Something - - - +

Vorsicht bei @@ -88022,9 +87972,7 @@ class Something - - - +

kann eines der Templates im Zyklus vorrübergehend als "incomplete" gelten. @@ -88034,9 +87982,7 @@ class Something - - - +

...wenn man dummerweise auf verschlungenen Pfaden @@ -88069,9 +88015,7 @@ class Something - - - +

werden u.U sillschweigend nicht generiert @@ -88079,9 +88023,7 @@ class Something - - - +

Wenn bestimmte Vorraussetzungen nicht erfüllt sind, dann unterbleibt das automatische Injizieren eines generierten Konstruktors. Die Klasse verhält sich dann so, als wäre die btr. Definition nicht gegeben... @@ -88091,9 +88033,7 @@ class Something - - - +

d.h. Member-Init kann unterbleiben (bei elementaren Typen, wenn die Klasse damit ein POD wird). @@ -88110,9 +88050,7 @@ class Something - - - +

error: use of deleted function Derived::Derived(const Derived &) @@ -88178,9 +88116,7 @@ class Something - - - +

die uniform initialisation ist leider unrund geraten @@ -88194,9 +88130,7 @@ class Something - - - +

die Werte in der initializer_list sind Values und werden per copy-Konstruktion erstellt @@ -88226,9 +88160,7 @@ class Something - - - +

wenn ein Template ein statisches member-Feld hat, @@ -88260,9 +88192,7 @@ class Something - - - +

@@ -88475,9 +88405,7 @@ class Something - - - +

das sind verschiedene Blickwinkel auf das gleiche Thema @@ -88494,9 +88422,7 @@ class Something - - - +

Bedeutung dieser Schreibweise: @@ -88536,9 +88462,7 @@ class Something - - - +

eine Solche konstituiert die synchronizes-with-Beziehuung @@ -88550,9 +88474,7 @@ class Something - - - +

Grundbeziehung: synchronizes-with @@ -88572,9 +88494,7 @@ class Something - - - +

das gilt nur im Rahmen der synchronizes-with-Beziehung @@ -88584,9 +88504,7 @@ class Something - - - +

das heißt, nur für einen vom gleichen Mutex geschützen  Bereich! @@ -88596,9 +88514,7 @@ class Something - - - +

In der naiven Implementierung greift der prüfende Thread auf die instance-Variable @@ -88632,9 +88548,7 @@ class Something - - - +

...haben wir es hier mit einem Pattern zu tun @@ -88644,9 +88558,7 @@ class Something - - - +

ich nenne es "synchronised visibility cones" @@ -88656,9 +88568,7 @@ class Something - - - +

Dieses errichtet die Fiktion, @@ -88675,9 +88585,7 @@ class Something - - - +

...und andernfalls überhaupt vermeiden, @@ -88702,9 +88610,7 @@ class Something - - - +

man ruft explizit eine Service-Loop-Funktion auf — io_context::run() @@ -88725,9 +88631,7 @@ class Something - - - +

Teil der Vision / wir wollen das @@ -88736,9 +88640,7 @@ class Something - - - +

/** @file mmap.h @@ -88778,9 +88680,7 @@ class Something - - - +

wenn eine getemplatete Klasse zum Qualifizieren eines Feldes verwendet wird, @@ -88805,9 +88705,7 @@ class Something - - - +

@param hat stets einen Parameternamen als Argument @@ -88815,9 +88713,7 @@ class Something - - - +

...der ist nicht optional @@ -88842,9 +88738,7 @@ class Something - - - +

also keine "Banner" aus Sternen.
Abhilfe: /*********************//** @@ -88860,9 +88754,7 @@ class Something - - - +

....haben in ihrem @file-Kommentar @@ -88920,9 +88812,7 @@ class Something - - - +

...wird zwar vom Skript ausgelesen, @@ -88951,9 +88841,7 @@ class Something - - - +

...im Besonderen die guten Diagramme für Pulse, ALSA und Jack @@ -89014,9 +88902,7 @@ class Something - - - +

auf diese Stellen konzentrierte sich für längere Zeit die Aktivität, und keines dieser Themen konnte ich wirklich abschließen, denn es sind noch zu viele strategische Fragen ungeklärt — mit 2022 ist immerhin jedes dieser Themen auf einen längerfristig tragfähigen Grund gestellt @@ -89119,9 +89005,7 @@ class Something - - - +

kein Vorwärts/Rückwärts spulen, kein Springen, kein Looping, keine variable Geschwindigkeit @@ -89167,9 +89051,7 @@ class Something - - - +

involviert Problem des Output Network @@ -89189,9 +89071,7 @@ class Something - - - +

nur eben dahinter geschaltet, und flexibler @@ -89215,9 +89095,7 @@ class Something - - - +

  • @@ -89233,9 +89111,7 @@ class Something - - - +

    Entscheidung: im Builder @@ -89279,9 +89155,7 @@ class Something - - - +

    Baum-Monaden-Framework für Job-Planung
    fragwürdiges Design @@ -89291,9 +89165,7 @@ class Something - - - +

    habe das wohl schon damals gemerkt... der Quelltext ist voller "entschuldigender Kommentare" @@ -89304,9 +89176,7 @@ class Something - - - +

    das primäre Problem ist hier nicht C++, oder eine ungeschickte Implementierung meinerseits, sondern das brennende Problem ist, daß die Monaden-Struktur nichts zum Verständnis der Verwendung beiträgt, sondern diese durch eine rein-mathematische Symmetrie verstellt und verschleiert @@ -89327,9 +89197,7 @@ class Something - - - +

    und bietet monadische-Expansion als Spezialfall @@ -89364,9 +89232,7 @@ class Something - - - +

    Es ist zwar schon klar, daß ein separates Output-Network gebaut werden muß, um die generierten Frames für den konkreten Viewer in der GUI aufzubereiten. Aber es ist noch nicht wirklich geklärt, wie dieses in das generelle Design mit High-Level-Model, Builder und Low-Level-Model zu integrieren ist. Bisher hatte ich immer nur den Begriff "ViewConnection" verwendet (Siehe TiddlyWiki) und dazu festgehalten, daß es sich um ein »Binding« handeln soll. Unklar ist aber die genaue Verhältnisbestimmung zu dem Binding, das für Timeline und VirtualClip zum Tragen kommen wird. @@ -89424,9 +89290,7 @@ class Something - - - +

    ...dieser Monaden-Code ist undurchdringlich (selbst für micht, und ich kann mich noch gut daran erinnern, was er leisten soll) @@ -89559,9 +89423,7 @@ class Something - - - +

    das ViewHook / CanvasHook-Konzept hat sich hervorragend bewährt, und durch das zoom-metric-Mix-in gibt es auch bereits eine sehr elaborierte und robuste Implementierung für alle Belange der temporalen Ausdehnung (horizontal). Allerdings funktionieren alle diese Basis-Implementierungen bisher nur für den eigentlichen Content in der Timeline — ganz einfach weil ich noch nicht so recht weiß, was es mit den »Rulern« so auf sich hat ....  ⌛ @@ -89572,9 +89434,7 @@ class Something - - - +

    Das Thema »Layout-Steuerung in der Timeline« lief aus dem Ruder (wie erwartet — warum soll's mir besser gehen, als Joel Holdsworth?). Ich habe dahinter aber ein Architektur-Problem identifiziert, nämlich daß hier eine selbs-ähnliche rekursive Struktur notwendig ist, welche aber mehrere separate Kontexte überspannt. Dafür habe ich die Entität DisplayFrame  erfunden, und die Idee war, diesen als Kristallisationskern zu verwenden, um die gesamte Struktur um das Timeline-Layout zu reinigen. Leider konnte ich das aber (Stand 9/2022) nicht weiterführen, weil ich nun das GUI wieder verlassen muß, um an der RenderEngine weiterzuarbeiten... @@ -89585,9 +89445,7 @@ class Something - - - +

    ....dieses Thema sollte generisch gelöst werden, und dann weiter entwickelt in Richtung »Interaction Design« — also mit einem aktuellen Fokus verbunden, und mit jeweils eigener Historie pro Fokus, so daß man in die verschiedenen Fokus-Zonen über gut etablierte "Leitern" wieder einsteigen könnte. Leider muß ich (Stand 9/2022) das GUI nun wieder verlassen, und es ist ganz und gar ungeklärt, unter welchen Umständen dieses zentrale Thema wieder aufgenommen werden kann... @@ -89598,9 +89456,7 @@ class Something - - - +

    Es gibt immer noch Zweifel ob gewisser Race-Conditions.... @@ -89614,9 +89470,7 @@ class Something - - - +

    ...beim Herauslösen aus dem Gnome-Application / GIO-Framework habe ich detailiert die Strukturen um die Main-Loop untersucht und verstanden. Leider stehen diese Infos bisher (Stand 9/2022) nur in meiner Mindmap; ich sollte eine eigene Kategorie in der Webseite/Dokumentation schaffen, in der solche Einsichten aufgezeichnet werden können... @@ -89639,9 +89493,7 @@ class Something - - - +

    Leitlinie: so viel tun, daß uns das Thema nicht über den Kopf wächst @@ -89659,9 +89511,7 @@ class Something - - - +

    hier stammt die Darstellung im Wesentlichen aus den ersten Jahren, ist aber mit dem teilweisen Re-Design verflochten ⟹ verwirrende Mix aus überholten Ansichten und Konzepten für die ferne Zukunft @@ -89679,9 +89529,7 @@ class Something - - - +

    Aber es gibt auch stellenweise Überarbeitungen (von Benny) auf der offizielen Linie @@ -89709,9 +89557,7 @@ class Something - - - +

    ...ging völlig problemlos, und das Resultat/Changeset sieht plausibel aus... @@ -89726,9 +89572,7 @@ class Something - - - +

    • @@ -89778,9 +89622,7 @@ class Something - - - +

      Beispiele zur Verwendung @@ -89797,9 +89639,7 @@ class Something - - - +

      Diese Info hatte ich vor längerer Zeit mal "aufgegabelt" und sie wer der erste Content auf dieser Styling-Doku-Seite. Inzwischen hat sich der Scope verschoben, und sowas gehört ehr in die CodeBase-Sektion @@ -89825,9 +89665,7 @@ class Something - - - +

      TODO: dokumentieren, wie das Lumiera-Interface ausgelegt und angeordnet wird, bis hinab zu den Details der Widget-Anordnung, damit ein Außenstehender im Stande ist, am Styling mitzuarbeiten... @@ -89842,9 +89680,7 @@ class Something - - - +

      Darstellung: about Monads @@ -89852,9 +89688,7 @@ class Something - - - +

      Dezember 2017 ausgearbeitet und im TiddlyWiki vergraben. @@ -90039,9 +89873,7 @@ class Something - - - +

      bekannter Bug binutils #16936 @@ -90051,9 +89883,7 @@ class Something - - - +

      Lumiera-Ticket #965 @@ -90063,9 +89893,7 @@ class Something - - - +

      gelöst in 4e8e63ebe @@ -90073,9 +89901,7 @@ class Something - - - +

      ...man "hilft" dem Linker mit @@ -90089,9 +89915,7 @@ class Something - - - +

      laufen wieder alle @@ -90106,9 +89930,7 @@ class Something - - - +

      test.sh Zeile 138 @@ -90121,9 +89943,7 @@ class Something - - - +

      Debian-Bug #724461 @@ -90134,9 +89954,7 @@ class Something - - - +

      nebenbei ohweh: @@ -90148,9 +89966,7 @@ class Something - - - +

      Christian:  bash -c "ulimit -t 1; while :; do :; done" @@ -90160,9 +89976,7 @@ class Something - - - +

      und wir verbringen unsere Zeit mit contention @@ -90175,9 +89989,7 @@ class Something - - - +

      ist klar, hab ich gebrochen @@ -90189,9 +90001,7 @@ class Something - - - +

      siehe Ticket #587 @@ -90201,9 +90011,7 @@ class Something - - - +

      Kollisionen jetzt bereits nach 4000 lfd. Nummern @@ -90216,9 +90024,7 @@ class Something - - - +

      erinnere mich an den @@ -90231,9 +90037,7 @@ class Something - - - +

      wow: es genügt, @@ -90254,9 +90058,7 @@ class Something - - - +

      Aug 10 04:51:39 flaucher kernel: gdb[8234]: segfault at 7ffe3fa79f50 ip 0000000000718b95 sp 00007ffe3fa79f40 error 6 in gdb[400000+574000] @@ -90273,9 +90075,7 @@ class Something - - - +

      function gebunden an ein lambda @@ -90296,9 +90096,7 @@ class Something - - - +

      Bugreport für Debian/Jessie #795445 @@ -90310,9 +90108,7 @@ class Something - - - +

      Git: debBild/Gdb_DEB.git @@ -90324,9 +90120,7 @@ class Something - - - +

      bison dejagnu flex gobjc libncurses5-dev libreadline-dev liblzma-dev libbabeltrace-dev libbabeltrace-ctf-dev python3-dev @@ -90337,9 +90131,7 @@ class Something - - - +

      dutzende Tests scheitern @@ -90350,9 +90142,7 @@ class Something - - - +

      verräterrischer Code im debian/rules @@ -90412,9 +90202,7 @@ class Something - - - +

      speziell: unused-function bei dem Trick mit dem std::hash macht mir Sorgen. @@ -90431,9 +90219,7 @@ class Something - - - +

      aktualisieren und neu bauen @@ -90473,9 +90259,7 @@ class Something - - - +

      früher war das so eine typische "nörgel"-Warnung, die man unter den Teppich kehren konnte: 'ey, der Compiler bekommt es ja trotzdem richtig hin. @@ -90492,9 +90276,7 @@ class Something - - - +

      • @@ -90525,9 +90307,7 @@ class Something - - - +

        standard hardening-flags setzen #971 @@ -90537,9 +90317,7 @@ class Something - - - +

        wähle Kompatibiltät genau so, daß Ubuntu-Trusty noch unterstützt wird. @@ -90588,9 +90366,7 @@ class Something - - - +

        env.GuiResource(f) for f in env.Glob('stage/*.css') @@ -90605,9 +90381,7 @@ class Something - - - +

        wenn ich doch mal noch komplexere Bäume transportieren muß @@ -90617,9 +90391,7 @@ class Something - - - +

        ich mag code-nahe Resourcen lieber beim Code selber @@ -90636,9 +90408,7 @@ class Something - - - +

        aber bei der Implementierung hab' ich dann Pragmatismus walten lassen @@ -90661,9 +90431,7 @@ class Something - - - +

        @@ -90685,9 +90453,7 @@ class Something - - - +

        nämlich im src/SConscript, wenn es um das GUI geht @@ -90698,9 +90464,7 @@ class Something - - - +

        und sie war ohnehin schon so geschrieben worden, daß das Endresultat irgendwie paßt @@ -90727,9 +90491,7 @@ class Something - - - +

        ...damit man auch im Paketbau-Build-Output wenigstens einmal alle  generischen Platform-Schalter sieht @@ -90742,9 +90504,7 @@ class Something - - - +

        ...denn die stören jeweils beim erzeugen eines Hotfix/Patch im Paketbau per dpkg --commit @@ -90763,9 +90523,7 @@ class Something - - - +

        deprecated: auto_ptr @@ -90776,9 +90534,7 @@ class Something - - - +

        Tests mit TypeIDs scheitern @@ -90793,9 +90549,7 @@ class Something - - - +

        Grund ist die Umstellung auf inline-Storage @@ -90806,9 +90560,7 @@ class Something - - - +

        wäre theoretisch jetzt möglich, @@ -90833,9 +90585,7 @@ class Something - - - +

        waren nur minimale Anpassungen @@ -90867,9 +90617,7 @@ class Something - - - +

        das Problem wurde vom GCC beim Bauen des alten Lumiera-Paketes angemahnt; tatsächlich aber hatte ich das Problem inzwischen längst schon anderweitig bemerkt und an der Wurzel gelöst, anstatt nur Symptome zu behandeln @@ -90883,9 +90631,7 @@ class Something - - - +

        als "workaround" hatte ich boost::rational<long> genommen @@ -90935,9 +90681,7 @@ class Something - - - +

        und wir brauchen die definitiv zum sinnvollen Rechenen mit Zeiten auf micro-Scala @@ -90945,9 +90689,7 @@ class Something - - - +

        Der kritsche Fall ist nämlich, wenn wir mit FSecs anfangen, und dann irgendwo in der Rechnung mal Time::SCALE multiplizieren, um auf die µ-Skala zu wechseln. Am Ende der Rechnung würde dann typischerweise ein rational_cast stehen. Damit das funktioniert, muß vor allem der Zähler des Bruches die volle Zeitskala unterstützen. Daher sind 64bit zwingend @@ -90962,9 +90704,7 @@ class Something - - - +

        weil 64bit -> 32bit eine narrowing conversion ist, die zumindest eine Warnung erzeugt @@ -91069,9 +90809,7 @@ class Something - - - +

        src/lib/itertools.hpp:805 @@ -91135,9 +90873,7 @@ class Something - - - +

        die überladene const-Variante ist der Grund @@ -91184,9 +90920,7 @@ class Something - - - +

        Frage: wollen wir auf noexcept einschränken? @@ -91213,9 +90947,7 @@ class Something - - - +

        • @@ -91236,9 +90968,7 @@ class Something - - - +

          "sinnvoll" heißt @@ -91266,9 +90996,7 @@ class Something - - - +

          warum...? @@ -91290,9 +91018,7 @@ class Something - - - +

          es sollte genau die Eigenschaften abdecken, die wir tatsächlich brauchen @@ -91326,9 +91052,7 @@ class Something - - - +

          mit const und volatile... @@ -91353,9 +91077,7 @@ class Something - - - +

          Doku durchkämmen nach Müll @@ -91366,9 +91088,7 @@ class Something - - - +

          hier nach offensichtlich obsoleter Info checken @@ -91381,9 +91101,7 @@ class Something - - - +

          die explizit angegebenen Paketnamen schon mal vorchecken @@ -91404,9 +91122,7 @@ class Something - - - +

          knappe Kennzeichnung des Releases in den Kommentar @@ -91421,9 +91137,7 @@ class Something - - - +

          hier geht es darum, Konsistenz im Git herzustellen. @@ -91446,9 +91160,7 @@ class Something - - - +

          einzeilige Kennzeichnung wiederholen @@ -91472,9 +91184,7 @@ class Something - - - +

          Merge-commit auf den Release-Zweig. @@ -91498,9 +91208,7 @@ class Something - - - +

          ...das heißt bauen und hochladen @@ -91516,9 +91224,7 @@ class Something - - - +

          Referenz: Debian/Jessie (stable) : i386 and x86_64 @@ -91530,9 +91236,7 @@ class Something - - - +

          Probleme mit der Compile-Reihenfolge  #973 @@ -91561,9 +91265,7 @@ class Something - - - +

          ...führt sowohl eine README, alsauch ein Verzeichnis /usr/share/doc/lumiera/html auf, das (noch) nicht existiert @@ -91576,9 +91278,7 @@ class Something - - - +

          stelle fest: Fehler auf Trusty, @@ -91589,9 +91289,7 @@ class Something - - - +

          das heißt, daß ich versuchen kann, das Problem erst mal "unter den Teppich zu kehren" @@ -91612,9 +91310,7 @@ class Something - - - +

          bauen mit gcc-5 scheitert @@ -91628,9 +91324,7 @@ class Something - - - +

          in lib/hash-standard.hpp @@ -91640,9 +91334,7 @@ class Something - - - +

          mit gcc-5 gebaute Tests scheitern @@ -91653,9 +91345,7 @@ class Something - - - +

          bauen mit gcc-4.9 nicht möglich @@ -91663,9 +91353,7 @@ class Something - - - +

          es gibt Probleme beim Linken mit den Boost-Libraries, die auf Ubuntu/wily mit gcc-5 gebaut sind. @@ -91681,9 +91369,7 @@ class Something - - - +

          Wichtig: hier nur was wirklich gebaut ist und funktioniert! @@ -91708,9 +91394,7 @@ class Something - - - +

          eigentlich war die nur notwendig für das Video-Viewer Widget, @@ -91727,9 +91411,7 @@ class Something - - - +

          hardening-flags! #971 @@ -91784,9 +91466,7 @@ class Something - - - +

          Ticket #722 @@ -91796,9 +91476,7 @@ class Something - - - +

          seit gcc-4.8 ist kein static_assert mehr in der STDlib @@ -91838,9 +91516,7 @@ class Something - - - +

          Aber Vorsicht: es wird noch gar nicht verwendet @@ -91862,9 +91538,7 @@ class Something - - - +

          typed-allocation-manager.hpp 217 @@ -91921,9 +91595,7 @@ class Something - - - +

          Probleme mit der Compile-Reihenfolge  #973 @@ -91952,9 +91624,7 @@ class Something - - - +

          TEST Dispatch functors into other threads: CallQueue_test .. FAILED @@ -92001,9 +91671,7 @@ class Something - - - +

          for I in `seq 1 50`; do target/test-suite CallQueue_test; done @@ -92015,9 +91683,7 @@ class Something - - - +

          habe gleichzeitig erst die Testsuite gebaut mit -j 36 und dann laufen lassen. @@ -92052,9 +91718,7 @@ class Something - - - +

          weil sich die Threads gegenseitig ihre Counter inkrementieren. @@ -92074,9 +91738,7 @@ class Something - - - +

          alle anderen (mit Ausnahme von BusTerm_test) @@ -92117,9 +91779,7 @@ class Something - - - +

          angeregt durch Gabriel; @@ -92151,9 +91811,7 @@ class Something - - - +

          wann sind Funktoren äquivalent ?? @@ -92161,9 +91819,7 @@ class Something - - - +

          mathematisch gilt: @@ -92185,9 +91841,7 @@ class Something - - - +

          in tr1::functional war ein equality-Operator spezifiziert @@ -92233,9 +91887,7 @@ class Something - - - +

          sonst auf Äquivalenz getestet @@ -92246,9 +91898,7 @@ class Something - - - +

          und genau das Letztere ist nicht garantiert korrekt implementierbar @@ -92268,9 +91918,7 @@ class Something - - - +

          Selbst verschiedene Closures haben selbst die noch eine eindeutige Identität @@ -92299,9 +91947,7 @@ class Something - - - +

          d.h. wir brauchen keine Äquivalenz? @@ -92400,9 +92046,7 @@ class Something - - - +

          sporadich, nicht bei jedem Lauf, aber reproduzierbar. @@ -92424,9 +92068,7 @@ class Something - - - +

          ...weil der Objekt-Monitor nicht mehr bedingungslos gewartet hat, @@ -92441,9 +92083,7 @@ class Something - - - +

          aber inChange bleibt true @@ -92477,9 +92117,7 @@ class Something - - - +

          ...es könnte dann nämlich die Session geschlossen und freigegeben werden,