diff --git a/admin/scons/Platform.py b/admin/scons/Platform.py index adb2ac758..bdf562409 100644 --- a/admin/scons/Platform.py +++ b/admin/scons/Platform.py @@ -56,7 +56,7 @@ def configure(env): conf.env.Append(CPPFLAGS = ' -DHAVE_PTHREAD') conf.env.Append(CCFLAGS = ' -pthread') - if not conf.CheckLib(symbol='clock_gettime', library='rt'): + if not conf.CheckLib(symbol='clock_gettime', library='rt'): # note librt is usually installed with libc6 problems.append('We expect the POSIX realtime extensions to be available through librt. ' + 'Unable to use clock_gettime()') @@ -100,7 +100,7 @@ def configure(env): problems.append('We need the boost regular expression lib (incl. binary lib for linking).') - if not conf.CheckPkgConfig('gavl', 1.0): + if not conf.CheckPkgConfig('gavl', '1.4'): problems.append('Did not find Gmerlin Audio Video Lib [http://gmerlin.sourceforge.net/gavl.html].') else: conf.env.mergeConf('gavl') @@ -108,19 +108,22 @@ def configure(env): if not conf.CheckPkgConfig('alsa', '1.0.23'): problems.append('Support for ALSA sound output is required') - if not conf.CheckPkgConfig('gtkmm-3.0', 3.0): - problems.append('Unable to configure GTK--') + if not conf.CheckPkgConfig('gtkmm-3.0', '3.10'): + problems.append('Unable to configure the mm-bindings for GTK-3') - if not conf.CheckPkgConfig('glibmm-2.4', '2.16'): - problems.append('Unable to configure Lib glib--') + if not conf.CheckPkgConfig('glibmm-2.4', '2.39'): + problems.append('Unable to configure the mm-bindings for Glib') - if not conf.CheckPkgConfig('gthread-2.0', '2.12.4'): - problems.append('Need gthread support lib for glib-- based thread handling.') + if not conf.CheckPkgConfig('glib-2.0', '2.40'): + problems.append('Need a suitable Glib version.') - if not conf.CheckPkgConfig('cairomm-1.0', 0.6): + if not conf.CheckPkgConfig('gthread-2.0', '2.40'): + problems.append('Need gthread support lib for Glib based thread handling.') + + if not conf.CheckPkgConfig('cairomm-1.0', '1.10'): problems.append('Unable to configure Cairo--') - verGDL = '3.8' # NOTE: lowered requriements here (was originally '3.12') + verGDL = '3.8' # lowered requirements to allow building on Ubuntu/Trusty & Mint (was originally '3.12') verGDLmm = '3.7.3' urlGDLmm = 'http://ftp.gnome.org/pub/GNOME/sources/gdlmm/' urlGDLmmDEB = 'http://lumiera.org/debian/' @@ -132,12 +135,14 @@ def configure(env): '(either from GNOME %s or use the debian package from %s)' % (verGDLmm, urlGDLmm, urlGDLmmDEB)) - if not conf.CheckPkgConfig('librsvg-2.0', '2.18.1'): + if not conf.CheckPkgConfig('librsvg-2.0', '2.30'): problems.append('Need rsvg Library for rendering icons.') if not conf.CheckCHeader(['X11/Xutil.h', 'X11/Xlib.h'],'<>'): problems.append('Xlib.h and Xutil.h required. Please install libx11-dev.') + # NOTE the following dependencies where for the video displayer widget. + # As of 11/2015 this is broken and disabled. Might be obsolete.... if not conf.CheckPkgConfig('xv') : problems.append('Need libXv...') if not conf.CheckPkgConfig('x11') : problems.append('Need X-lib...') # for the xvdisplayer widget if not conf.CheckPkgConfig('xext'): problems.append('Need libXext.') diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py index 7a6f73976..0acda186b 100644 --- a/admin/scons/Setup.py +++ b/admin/scons/Setup.py @@ -73,7 +73,7 @@ def defineBuildEnvironment(): env.Replace( CPPPATH =["#src"] # used to find includes, "#" means always absolute to build-root , CPPDEFINES=['LUMIERA_VERSION='+VERSION ] # note: it's a list to append further defines - , CCFLAGS='-Wall -Wextra' + , CCFLAGS='-Wall -Wextra -Wformat-security' , CXXFLAGS='-std=gnu++14 -Wno-enum-compare' , CFLAGS='-std=gnu99' ) diff --git a/doc/technical/build/Dependencies.txt b/doc/technical/build/Dependencies.txt index f9d48494a..0dc06f3e2 100644 --- a/doc/technical/build/Dependencies.txt +++ b/doc/technical/build/Dependencies.txt @@ -21,7 +21,7 @@ Having said that -- for the time being, the core team won't spend much effort on Platform -------- We develop and test on standard PC hardware, 32 and 64 bit. -It is intended to target other platforms running run GNU/Linux eventually. +It is intended to target other platforms running GNU/Linux eventually. Lumiera expects a `standard' desktop installation running a XServer. Graphics:: @@ -42,6 +42,12 @@ Special Hardware:: * Specs and APIs must be open. * someone to do the actual interfacing and support needs to join the team +Compatibility +~~~~~~~~~~~~~ +We try to keep our depdendencies close to Debian/stable and the most recent Ubuntu LTS. +Whenever we need more recent libraries or other dependencies not available for our reference platform, +we care to provide custom Debian / Ubuntu packages as reference. This does not mean Lumiera is +limited to Devian flavours, it should work on any current Linux distribution. Languages and Tools ------------------- @@ -86,7 +92,7 @@ Libraries * for the GUI: (*GTK-3*) gtkmm-3.0 gdlmm-3.0 glibmm-2.4 cairomm-1.0 xv - libgtkmm-3.0-dev - libcairomm-1.0-dev - - libglibmm-2.4-dev, requiring at least glib2.0 and gthread-2.0 + - libglibmm-2.4-dev, requiring at least glib2.0 (2.40 or better) and gthread-2.0 - libxv-dev footnote:[for the XV viewer widget `gui/output/xvdisplayer.cpp` -- currently obsolete as of [yellow-background]#5/2015#][yellow-background]#TODO 5/2015# and X-lib - librsvg-2.0 and librsvg2-dev for rendering Icons diff --git a/doc/technical/howto/backporting.txt b/doc/technical/howto/backporting.txt index 6c14eeb65..65a19549a 100644 --- a/doc/technical/howto/backporting.txt +++ b/doc/technical/howto/backporting.txt @@ -1,6 +1,7 @@ Backporting to older platforms ============================== -:Date: 8/2015 +:Date: 11/2015 +:toc: GCC-4.9 ------- @@ -59,4 +60,69 @@ sudo update-alternatives --config gcc ---- +Building on Mint 17.2 (Rafaela) -- gcc and Libstdc++ 4.9 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Since Mint is based on Ubuntu LTS, we're facing pretty much the same situation here. +But what makes matters yet more confusing is the fact, that Mint offers even a Clang-3.6 +package, which is _unfortunately_ built to rely on the gcc-4.8 libraries; there is a known +header inclusion bug in these libraries, which kicks in as soon as we switch to C++14. + +Thus it is _mandatory_ to install the gcc-4.9 from above mentioned Ubuntu-Toolchain PPA, +which is indeed linked against the 4.9 libraries. Stay away from Clang on Mint for now! + +Transcript from a build session on a ``pristine'' Mint 17.2 installation: + + * add the following to your `/etc/apt/sources.list` ++ +---- +deb http://lumiera.org/debian/ rafaela experimental +deb-src http://lumiera.org/debian/ rafaela experimental +---- + + * install _Ichthyo's_ DEB signing key ++ +---- +gpg --keyserver keyserver.ubuntu.com --recv A1DE94B2 +gpg --export -a A1DE94B2 | sudo apt-key add - +---- + + * prepare build environment ++ +---- +sudo add-apt-repository ppa:ubuntu-toolchain-r/test +sudo apt-get update +sudo apt-get install build-essential gcc-4.9 g++-4.9 git-core +sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 \ + --slave /usr/bin/g++ g++ /usr/bin/g++-4.9 + +sudo apt-get build-dep lumiera +---- ++ +after that, your system is prepared for building Lumiera + + * now build + + * either by (re)compiling the debian package ++ +---- +apt-get source lumiera +cd lumiera +dpkg-buildpackage +---- + + * or check out the source and hack away... ++ +---- +git clone git://git.lumiera.org/LUMIERA +cd LUMIERA + +scons CC=gcc-4.9 CXX=g++-4.9 +---- ++ +...as usual, from this point on, the compiler setting will be remembered in the file +`optcache`, so no need to repeat it for subsequent `scons` invocations. + +TIP: Just run `scons` for standard build or run the testsuite with `scons check`. + Use the switch `-j#` with # corresponding to the number of your cores. + Probably you'll need at least 2GB of memory on AMD64, to build with `-j6` diff --git a/doc/technical/infra/Release.txt b/doc/technical/infra/Release.txt new file mode 100644 index 000000000..2b884fe8c --- /dev/null +++ b/doc/technical/infra/Release.txt @@ -0,0 +1,75 @@ +Release preparation +=================== +:Author: Ichthyo +:Date: Nov 2015 + +we have nothing to show and don't provide public releases yet -- +but we ought to rehearse and practice the release process. +This document contains some hints and a checklist of steps +to perform for a proper release. + +Steps to perform for a release +------------------------------ + + . release prep: clean-up obsolete information + + - Debian package descriptions + - Build-Tutorial + + * building from source + * building the debian way + * contributing + + - technical/build/Dependencies + + . release prep: bump version number + + - `admin/scons/Setup.py` + - `data/config/setup.ini` + - `doc/devel/Doxyfile` + - `doc/devel/Doxyfile.browse` + + . perform a back-merge from the release branch. + + It is relevant not to loose any bugfixes. Especially verify + + - that all ongoing fixes from DEBs and other build activities + are properly represented as patches and committed to the release branch + - that adjustments to platform dependencies are picked up adequately + + . perform the *Release-commit*: + it should mention the kind of the release and the version number. + Typically, with this commit, you'll update some top level stuff in the + source tree, like + + - `README` + - `AUTHORS` + + * also in the ``about'' box in the GTK-UI + * see `setup.ini` + + - check the `LICENSE` file and add new license + declarations and notes, clean obsolete info here. + + . update the *release branch*: ``upgrade current release to ##.##'' + + Make sure the release branch now really reflects current master, maybe + with the omission of some stuff to be kept out of the packages. + Set the *release tag* + + . packaging... + + - merge release -> deb + - verify the package description + - have a look at manpages and similar packaging documents + - update `debian/control` to reflect current version dependencies + - have a look into `debian/rules` (e.g. build flags and similar) + + . delivery + + - use whatever infrastructure is available to build packages. + - verify packages can be installed on a pristine VM + - upload packages to debian depot or commit them to PPAs + - clean-up and discard obsoleted old distributions and packages + + . close the **release ticket** + + diff --git a/doc/user/tutorials/building.txt b/doc/user/tutorials/building.txt index c6544b3de..15e418d7b 100644 --- a/doc/user/tutorials/building.txt +++ b/doc/user/tutorials/building.txt @@ -62,7 +62,12 @@ The GUI depends on the following: * link:http://cgit.freedesktop.org/xorg/lib/libXv[libXv] * link:https://wiki.gnome.org/LibRsvg[lib rSVG] * link:https://git.gnome.org/browse/gdl[lib GDL] - + +CAUTION: there are known problems with *GCC-5.x* as of 11/2015 + + on recent distributions (Ubuntu/wily, Debian/stretch) you might + encounter failing tests.footnote:[these problems aren't really serious; + basically we're sometimes checking mangled class/type names, and seemingly + the mangling behaviour of GCC has changed slightly. We're working on that...] TIP: Generally speaking, when you want to build software, you'll need the _development_ version of the packages that contain the headers and pre-built @@ -79,6 +84,14 @@ libgavl-dev libgtkmm-3.0-dev libgdl-3-dev librsvg2-dev libxv-dev Ubuntu note:: some people reported you need to install the `intltool` package from the standard Ubuntu repository (for this reason it is included in the above collection) +Mint-17.2 (Rafaela) and Ubuntu 12.LTS:: + we really need the gcc-4.9, so building on these platforms is a bit tricky. See our + link:{ldoc}/technical/howto/backporting.html#_building_on_mint_17_2_rafaela_8201_8212_8201_gcc_and_libstdc_4_9[»Backporting«] + page for detailed info... +GCC-5.0:: + we're aware of some changes in mangled names (or type-IDs), which cause some tests to fail. + Other than that, compilation worked for us. + Build Directory diff --git a/doc/user/tutorials/contributing.txt b/doc/user/tutorials/contributing.txt index 8eafb1910..a5f684180 100644 --- a/doc/user/tutorials/contributing.txt +++ b/doc/user/tutorials/contributing.txt @@ -236,6 +236,7 @@ fact, many user interfaces should be possible. - The initial GUI on which considerable work has already been done has been implemented using the GTK toolkit. However, considerable more work needs to be done on this present GUI. +- the stylesheet has been roughly ported to GTK-3, but needs a lot more polishing - we urgently need conceptual (non-coding) contributions * work out a coherent UI handling concept, in accordance with model and core diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm new file mode 100644 index 000000000..226343cd2 --- /dev/null +++ b/wiki/thinkPad.ichthyo.mm @@ -0,0 +1,3218 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ d.h. der usage context entscheidet, ob wir einen Wert, +

+

+ eine Referenz oder einen konstanten Wert verwenden +

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

+ Record selber ist immuable +

+

+ aber hat eine Builder-Mechanik +

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

+ eigentlich fehlte nur die get()-Operation +

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

+ erledigt... ähm vertagt +

+

+ aber nicht wirklich; der workaround könnte schon die Lösung sein #963 +

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

+ ich hatte damals beim Variant und zugehörigen Buffer die Sorge, +

+

+ daß ich die Implikationen einer generischen Lösung nicht durchdringen kann. +

+

+ Und ich wollte keine Zeit auf einen exzessiven Unit-Test verwenden +

+ + + + + + + + + +

+ generische Lösung verschoben #963 +

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

+ C++11 erlaubt =default +

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

+ nicht klar, ob wir das überhaupt brauchen +

+
    +
  • + entweder nur die unmittelbaren Kinder -> komplexe Logik fällt auf den Client +
    • +
  • + oder nur die Blätter -> man kann die Baum-Struktur nicht wirklich nutzen +
    • +
+ + + + + + + + + + +

+ Entscheidung +

+

+ was wir brauchen +

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

+ geht nicht: +

+

+ rekursiver Abstieg in der Mitte eines Iterators +

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

+ das war die Quintessenz der ganzen Entwicklung zum IterExplorer +

+

+ Nachdem ich die depth-first / breadth-first -Strategien systematisch aufgebaut hatte, +

+

+ habe ich das dann reduziert und kompakt nochmal geschrieben. +

+

+ Sehr schön! +

+

+ +

+

+ +

+

+ übrigens: genau den verwenden wir auch zur Job-Planung +

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

+ ...denn wir müssen den Weg zurück finden. +

+

+ Wenn also eine Datenstruktur nur einfach verzeigert ist, oder direkt rekursiv (wie bei uns), +

+

+ dann ist es absolut unmöglich, eine Traversierung mit konstantem Speicher zu machen. +

+

+ Das geht nur bei einer Struktur mit Rückreferenzen -- diese enthalten dann nämlich genau den Speicher, +

+

+ der während dem Einstieg in die einfach verzeigerte Struktur auf dem Stack liegt. Aber letztere +

+

+ braucht nur eine logarithmische Menge an Speicher, und das auch nur während der Traversierung. +

+

+ Dies ist die Abwägung, und darunter läßt sich nichts weghandeln. +

+

+ +

+

+ Der einzige verbleibende Freiheitsgrad ist, bei einer unmittelbaren rekursiven Programmierung +

+

+ direkt den Prozessor-Stack für die Speicherung des Rückweges mitzuverwenden; +

+

+ in dem Moment, wo ich mich für einen Iterator entscheide, ist diese Möglichkeit weg. +

+ + + + + + + + + + +

+ kann genauso effizient werden +

+

+ aber nur, wenn man die Initialisierung hinbekommt +

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

+ oder diese Logik +

+

+ fest verdrahten +

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

+ da es sich um einen disjunktiven Typ (entweder-oder-Typ) handelt, +

+

+ könnte man die Storage mit beiden Bedeutungen überlagern. +

+

+ +

+

+ Voraussetzung wäre, daß man anhand der konkreten Daten gefahrlos  jeweils herausfinden kann, +

+

+ welcher Zweig grade gilt. Da wir aber keine Introspektion haben (und auch nicht wollen!), +

+

+ würde das auf Taschenspielertricks mit der Implementierung hinauslaufen +

+
    +
  • + GenNode und Record beginnen beide fraktisch mit einem String. Man müßte diesen interpretieren können +
    • +
  • + oder man nutzt die letzten Bits des Pointers, um sich dort eine Flag zu speichern... +
    • +
+

+ Damit ist schon klar: sowas macht man nicht ohne Grund +

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

+ Entscheidung: falls eingebetteter Record +

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

+ Begründung: das Durchlaufen und Rekonstruieren eines Baumes +

+

+ ist letztlich doch ein sehr spezieller Fall, und rechtfertigt nicht, +

+

+ den HierarchyOrientationIndicator in jeden Iterator einzubetten. +

+

+ Zumal -- wenn der level zugänglich ist -- kann man diese Mechanik genauso gut +

+

+ dort direkt ansiedeln, wo sie gebraucht wird. +

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

+ also keine Monade +

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

+ Gleichheit +

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

+ kombiniert den Wert-Match mit der Iteration +

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

+ Zweck: kompaktes Anschreiben +

+

+ von literalen Daten +

+ + + + + + + + + +

+ Object builder +

+ + + + + + + + +

+ Problem ist, wir definieren den Typ Record generisch, +

+

+ verwenden dann aber nur die Spezialisierung Record<GenNode> +

+

+ Und die Builder-Funktionen brauchen eigentlich spezielles Wissen über den zu konstruierenden Zieltyp +

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

+ Mutator selber is noncopyable +

+ + + + + + + + + + +

+ Ergebnis move +

+

+ pro / contra +

+ + + + + + + +

+ Move ist gefährlich +

+

+ aber auch deutlich effizienter, +

+

+ denn wir müssen sonst das ganze erzeugte Ergebnis einmal kopieren. +

+

+ Nicht sicher, ob der Optimiser das hinbekommt +

+ + + + + + + + +

+ nur auf dem Mutator +

+ + + + + + + + + +

+ dieser ist nicht kopierbar +

+

+ und muß dediziert erstellt werden +

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

+ möglicherweise schon gelöst, +

+

+ denn Record ist insgesamt immutable. +

+

+ Also können wir einen Find mit einem const_iterator machen +

+ + + + + + + + + +

+ was sinnvoll ist, +

+

+ hängt vom Payload-Typ ab +

+ + + + + + + + + +

+ bei einer 'key = value' -Syntax mit strings +

+

+ ist nur ein Value-Rückgabewert sinnvoll +

+ + + + + + + + + + +

+ ...auch kann man auf diesem Weg die Storage konfigurierbar machten +

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

+ da wir einen IterAdapter verwenden, können wir nur eine 'pos' (einen Quell-Iterator) +

+

+ als Zustands-Markierung verwenden; die gleiche 'pos' wird aber auch inkrementiert und dereferenziert. +

+

+ Daher ist die einzige praktikable Lösung, daß die Typ-ID in einem weiteren Vektor gespeichert wird. +

+

+ Das könnte dann ein Metadaten-Vektor sein. +

+

+ +

+

+ Natürlich ist dieser Ansatz nur sinnvoll, wenn wir wirklich Metadaten brauchen. +

+

+ Denn jeder Record zahlt den Preis für die komplexere (zusätzliche) Datenstruktur! +

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

+ scheidet aus, wegen Wertsemantik +

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

+ mit speziellem Ref-Typ +

+

+ -- im DataCap +

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

+ heißt: in der Diff-Verarbeitung wird dieser spezielle check verwendet +

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

+ m.E. die einzig saubere Desgin-Variante! +

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

+ gemeint ist: +

+
    +
  • + man kann alternativ auch eine RecordRef direkt in eine elementare GenNode packen +
    • +
  • + diese verhält sich dann nicht transparent, denn sie hat eine andere Identität als ihr Ziel +
    • +
  • + das kann aber als spezielles Ausdrucksmittel genutzt werden +
    • +
+ + + + + + + + + + + + + + + +

+ heißt: wird direkt von standard-equality so behandelt +

+ + + + + + + + +

+ brauche speziellen Builder, +

+

+ der das so fabriziert +

+ + + + + + + + + +

+ bekomme einen +

+

+ "ungenutzten" DataCap +

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

+ Idee: Ref-GenNode +

+ + + + + + + + + + +

+ als Ref erkennbar +

+

+ (Prädikat) +

+ + + + + + + + + +

+ hash-identische +

+

+ Ziel-ID ableitbar +

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

+ Verarbeiten +

+

+ von Teilbäumen +

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

+ Interpreter definiert Sprache +

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

+ ROOT +

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

+ INIT +

+ + + + + + + + + +

+ leeres +

+

+ Objekt +

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

+ pick(Ref::CHILD) +

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

+ würde sagen: ja, aber auch nur für das after-Verb! +

+

+ allgemein halte ich einen wrap-around für keine gute Idee, +

+

+ weil er zu Zweideutigekeigen führt und daher Struktur oder Konsistenzfehler überspielt +

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

+ läßt sich stets duch eine inverse Folge von find und pick  emulieren +

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

+ vorerst verworfen, da zusätzlicher Prüf-Aufwand +

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

+ ...Grund: sie werden durch einen jeweils komplett anderen Ansatz implementiert +

+
    +
  • + "Liste" beruht auf dem Attribut-Iterator und dem Aufbauen einer neuen Attribut-Sammlung +
    • +
  • + "Map" beruht darauf, alle Operationen an die Storage zu delegieren +
    • +
+ + + + + + + + + + + + + +

+ das heißt, man kann Attribute in einer "sinnvoll lesbaren" Ordnung anschreiben +

+

+ und später angefügte Attribute bleiben so erkennbar. +

+

+ Vorteilhaft für Version-Management +

+ + + + + + + + + +

+ profitiert also von allen Verbesserungen des allgemeinen Algorithmus +

+ + + + + + + + + +

+ "hoch effizient", unter der Annahme, daß fast immer nur konforme Änderungen kommen. +

+

+ Weil dann nämlich die in unserer Implementierung ggfs. kostspieligen Umordnungen entfallen, +

+

+ kommen wir auf lineare Komplexität für die Verarbeitung +

+

+ + NlogN f ür den Index zur Diff-Erzeugung +

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

+ unsere Impl der Diff-Erzeugung (!) +

+

+ baut einen Index auf (N*logN), um Einfügungen/Entfernungen zu erkennen und Umordnungs-Suche zu unterstützen. +

+

+ Wenn wir aber von ausschließlich konformen Operationen ausgehen, +

+

+ wird dieser Index nicht benötigt. Leider können wir das aber nicht garantieren, denn +

+

+ es könnte ja zwischenzeitlich ein Attribut gelöscht und dann später (am Ende) wieder +

+

+ angehängt worden sein, was dann eben doch einen Index erfordert, um einen +

+

+ korrekten Listen-Diff zu erzeugen +

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

+ d.h. wenn die Storage hoch-optimiert ist, +

+

+ dann überträgt sich das auf die Diff-Behandlung +

+ + + + + + + + + +

+ da wir Attribute in einer Liste speichern, +

+

+ müssen wir für jede Einfügung eine vollständige Suche machen +

+ + + + + + + + + +

+ ...gemeint ist: extra, anders als die normale Listenverarbeitung. +

+

+ Auch wenn diese andere Implementierung nur delegiert +

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

+ danach noch auftretende Attribute +

+

+ erfordern Sonder-Behandlung, +

+

+ indem sie an die Attributs-Liste angehängt werden +

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

+ wegen Entscheidung für das "Listen"-Modell zur Attribut-Handhabung +

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

+ ...da das Kind in der Liste der Attribute nämlich garnicht gefunden wird +

+ + + + + + + + + +

+ ...wenn wir am Ende der Attribut-Zone stehen, +

+

+ und die nächste Operation ein fetch eines Kindes ist, müssen wir implizit den +

+

+ Wechsel in den Scope vollziehen und die Operation dort ausführen. +

+

+ Aber an allen anderen Stellen in der Attribut-Zone ist ein solcher Fetch ein Fehler! +

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

+ standardmäßig strikt +

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

+ List-Diff +

+

+ als Spezialfall +

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

+ kann auch nicht +

+

+ wegen dem Interpreter +

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

+ leicht auf generischen Container +

+

+ zu verallgemeinern +

+ + + + + + + + + + +

+ Erkennung hat die Sprache als Parameter, +

+

+ und verwendet sie zur Token-Generierung +

+ + + + + + + + + +

+ man kann auch dem List-Detector +

+

+ eine Tree-Diff-Language geben +

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

+ Frage: in-Place? +

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

+ entscheidende Frage: wie addressieren? +

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

+ und wird durch die Diff-Anwendung konsumiert +

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

+ Immutablility erzwingt +

+
    +
  • + persistente Datenstrukturen +
    • +
  • + garbage-collector +
    • +
+ + + + + + + + + + +

+ Lösung: wir arbeiten auf einem Mutator +

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

+ auf dem Umweg über einen ContentMutator +

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

+ Innereien des alten Record verbrauchen +

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

+ Problem: Rekursion +

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

+ wenn ein MUT kommt +

+

+ erzeugt man lokal einen DiffApplikator für den geschachtelten Kontext +

+

+ und gibt ihm rekursiv den Diff hinein. Wenn dieser Aufruf zurückkehrt +

+

+ ist der gesammte Diff für den eingeschachtelten Kontext konsumiert +

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

+ wenn ein MUT kommt, +

+

+ pusht der Applikator seinen privaten Zustand +

+

+ auf einen explizit im Heap verwalteten std::stack +

+

+ und legt einen neuen Mutator an für den nested scope +

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

+ Entscheidung: +

+

+ interner Stack +

+ + + + + + + +

+ ....begründet duch die generische Architektur. +

+

+ Die Trennung von Diff-Iteration und dem Interpreter ermöglicht verschiedene Sprach-Ebenen. +

+

+ Allerdings werde ich für die Anwendung auf konkrete Datenstrukturen, +

+

+ also den TreeMutator, vermutlich das andere Modell (rekursiv konsumieren) verwenden. +

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

+ Problem sind mal wieder die automatisch generierten IDs. +

+

+ Die sind natürlich anders, wenn wir die ganze Testsuite ausführen... +

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

+ saugeil +

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

+ ...im Besonderen die guten Diagramme für Pulse, ALSA und Jack +

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

+ bekannter Bug binutils #16936 +

+ + + + + + + + + +

+ Lumiera-Ticket #965 +

+ + + + + + + + + +

+ gelöst in 4e8e63ebe +

+ + + + + + + +

+ ...man "hilft" dem Linker mit +

+

+ "-Wl,-rpath-link=target/modules" +

+ + + + + + + + + + +

+ laufen wieder alle +

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

+ test.sh Zeile 138 +

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

+ Debian-Bug #724461 +

+ + + + + + + + + + +

+ nebenbei ohweh: +

+

+ ulimit -t 1 ist wirkungslos +

+ + + + + + + + +

+ Christian:  bash -c "ulimit -t 1; while :; do :; done" +

+ + + + + + + + + +

+ und wir verbringen unsere Zeit mit contention +

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

+ ist klar, hab ich gebrochen +

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

+ siehe Ticket #587 +

+ + + + + + + + + +

+ Kollisionen jetzt bereits nach 4000 lfd. Nummern +

+

+ Vorher hatte ich erste Kollisionen nach 25000 Nummern +

+ + + + + + + + + +

+ erinnere mich an den +

+

+ guten alten "Knuth-Trick" +

+ + + + + + + + + +

+ wow: es genügt, +

+

+ die letzten beiden Zeichen mit der Knuth-Konstante zu spreizen, +

+

+ und ich komme locker auf 100000 Nummern ohne Kollision +

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

+ Aug 10 04:51:39 flaucher kernel: gdb[8234]: segfault at 7ffe3fa79f50 ip 0000000000718b95 sp 00007ffe3fa79f40 error 6 in gdb[400000+574000] +

+

+ Aug 10 04:51:39 flaucher kernel: traps: test-suite[8249] trap int3 ip:7ffff7deb241 sp:7fffffffe5c8 error:0 +

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

+ function gebunden an ein lambda +

+

+ wobei ein Argument-Typ als vom Template-Argument +

+

+ der umschließenden Funktion aufgegriffen wird +

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

+ Bugreport für Debian/Jessie #795445 +

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

+ Git: debBild/Gdb_DEB.git +

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

+ bison dejagnu flex gobjc libncurses5-dev libreadline-dev liblzma-dev libbabeltrace-dev libbabeltrace-ctf-dev python3-dev +

+ + + + + + + + + + +

+ dutzende Tests scheitern +

+ + + + + + + + + + +

+ verräterrischer Code im debian/rules +

+

+ check-stamp: +

+

+ ifeq ($(run_tests),yes) +

+

+         $(MAKE) $(NJOBS) -C $(DEB_BUILDDIR)/gdb check \ +

+

+           || echo "**Tests failed, of course.**" +

+

+ endif +

+

+         touch $@ +

+

+ +

+

+ au weia LEUTE! +

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

+ speziell: unused-function bei dem Trick mit dem std::hash macht mir Sorgen. +

+

+ +

+

+ und tatsächlich: das ist daneben, GCC hat Recht! +

+ + + + + + + + + + +

+ aktualisieren und neu bauen +

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

+ standard hardening-flags setzen #971 +

+ + + + + + + + + +

+ wähle Kompatibiltät genau so, daß Ubuntu-Trusty noch unterstützt wird. +

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

+ ...damit man auch im Paketbau-Build-Output wenigstens einmal alle  generischen Platform-Schalter sieht +

+

+ Ich meine also: zu Beginn vom Build sollte das Buildsystem einmal eine Infozeile ausgeben +

+ + + + + + + + + +

+ ...denn die stören jeweils beim erzeugen eines Hotfix/Patch im Paketbau per dpkg --commit +

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

+ deprecated: auto_ptr +

+ + + + + + + + + + +

+ Tests mit TypeIDs scheitern +

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

+ Doku durchkämmen nach Müll +

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

+ hier nach offensichtlich obsoleter Info checken +

+

+ WICHTIG: keine vorgreifende Infor publizieren!!!!! +

+ + + + + + + + + + +

+ die explizit angegebenen Paketnamen schon mal vorchecken +

+

+ die Abschnitte zu den LIbraries prüfen / umschreiben +

+

+ insgesamt sorgfältig durchlesen +

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

+ knappe Kennzeichnung des Releases in den Kommentar +

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

+ hier geht es darum, Konsistenz im Git herzustellen. +

+

+ Wenn alles korrekt gemacht wurde, dürfte es hier keinen Rückfluß von Änderungen geben. +

+

+ Bitte auch daran denken, zuerst den DEB-Zweig zu prüfen. Diesen aber nicht zurückmergen, +

+

+ denn wir wollen keine DEB-Info im Master haben! +

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

+ einzeilige Kennzeichnung wiederholen +

+

+ die unmittelbaren Release-Dokumente durchgehen +

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

+ Merge-commit auf den Release-Zweig. +

+

+ Sollte konfliktfrei sein +

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

+ ...das heißt bauen und hochladen +

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

+ Referenz: Debian/Jessie (stable) : i386 and x86_64 +

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

+ Probleme mit der Compile-Reihenfolge  #973 +

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

+ ...führt sowohl eine README, alsauch ein Verzeichnis /usr/share/doc/lumiera/html auf, das (noch) nicht existiert +

+

+ unter Debian/Jessie wird das ignoriert +

+ + + + + + + + + +

+ stelle fest: Fehler auf Trusty, +

+

+ nur Warnung auf Mint +

+ + + + + + + +

+ das heißt, daß ich versuchen kann, das Problem erst mal "unter den Teppich zu kehren" +

+

+ Die Wahrscheinlichkeit, daß irgend jemand Lumiera unter Ubuntu/Trusty installieren möchte, erscheint mir akademisch +

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

+ bauen mit gcc-5 scheitert +

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

+ in lib/hash-standard.hpp +

+ + + + + + + + + +

+ mit gcc-5 gebaute Tests scheitern +

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

+ bauen mit gcc-4.9 nicht möglich +

+ + + + + + + + +

+ es gibt Probleme beim Linken mit den Boost-Libraries, die auf Ubuntu/wily mit gcc-5 gebaut sind. +

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

+ Wichtig: hier nur was wirklich gebaut ist und funktioniert! +

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

+ eigentlich war die nur notwendig für das Video-Viewer Widget, +

+

+ was nun leider tot ist. Wir haben noch keinen Ersatz. Deshalb lasse ich die Abhängigkeit +

+

+ bestehen, aber irgendwann müssen wir das schon glattziehen +

+ + + + + + + + + + +

+ hardening-flags! #971 +

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

+ Ticket #722 +

+ + + + + + + + + +

+ seit gcc-4.8 ist kein static_assert mehr in der STDlib +

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

+ Probleme mit der Compile-Reihenfolge  #973 +

+ + + + + + + + + +