this becomes more relevant now, since the actual MutationMessage iterators
are implemented in terms of a shared_ptr to IterSource. Thus, when building
processing pipelines, we most definitively want to move that smart-ptr into
the destination, since this avoids touching the shared count and thus avoids
generating unnecessary memory barriers.
obsoleted by C++11
* in most cases, it can be replaced by an explicit conversion operator
* especially for the Lumiera Forward Iterators, we need an implicit conversion
This changeset fixes a huge pile of problems, as indicated in the
error log of the Doxygen run after merging all the recent Doxygen improvements
unfortunately, auto-linking does still not work at various places.
There is no clear indication what might be the problem.
Possibly the rather unstable Sqlite support in this Doxygen version
is the cause. Anyway, needs to be investigated further.
After some consideration, it became clear that this service implementation
is closely tied to the DispatcherLoop -- which will consequently be
responsible to run and expose this service implementation
...because of questionable utility
And it turned out to be quite a liability when it comes to implementing
the building blocks for binding tree implementation data structures
this is a tricky problem and a tough decision.
After quite some pondering I choose to enforce mandatory fields
through the ctor, and not to allow myself cheating my way around it
BoUML was close sourced by its author and consequently dropped
from Debian. We use UML as a drawing and documentation tool,
and thus we'll just start over with the /obvious/ choice,
which is the Umbrello tool.
not sure yet if any of this works, because the
technicalities of dealing with variadic types are
quite different to our LISP-style typelist processing.
The good news is that with variadic templates it is
indeed possible, to supply dynamically picked arguments
to another function taking arbitrary arguments.
This all relies on the feature to unpack argument packs,
and, more specifically, about the possiblity to "wrap"
this unpacking around interspersed function call syntax
template<size_t...i>
Xyz
do_something(MyTuple myTuple)
{
return Xyz (std::get<i> (myTuple) ... );
}
Here the '...' will be applied to the i... and then
the whole std::get-construct will be wrapped around
each element. Mind bogging, but very powerful
this is a bit trickty, since we need to install gcc-4.9 from a PPA.
Mint only provides the libstdc++ 4.8, which is known to break when
compiling in C++14 mode
NOTE: we have the policy to always support current Debian/stable
amd at least one Ubuntu LTS release, unless hard dependency problems prevent that.
Currently, Ubuntu/Trusty is already a bit dated, but the only problematic dependency
could be libboost (1.54 in Trusty, 1.55 in Jessie).
GCC-4.8 can be replaced by GCC-4.9 in Trusty without problems
It is always a bit tricky to find out the precise lower boundary,
so we try to upgrade these requirements as our platform progresses.
For now we have used the level available on Ubuntu/Trusty to set
the lower constraints for most libraries
...this will be the third preview release
Lumiera is still in pre-alpha stage, and thus
there are no proper releases, just preview snapshots.
Again this version will be built and packaged
on several supported Linux platforms
This page gives the rationale for the way our diff framework is built.
This reasoning might *reduce* the relevance of any decisions
regarding the implementation data structure and thus lead to
far reaching consequences for the whole architecture.
This means we have rather tight compiler requirements now.
Beyond that, we expect no serious impact; the most notable
C++14 feature we're likely to use soon is type inference
on lambda arguments.
Introduce the new term "Fork" at various relevant places
within the documentation. We do not entirely purge the
term "track" though; rather we
- make clear that "Fork" is the entity to build tracks
- use "fork" also synonymous to the "tree of tracks"
This switches the Lumiera UI from GTK-2 to GTK-3
Unfortunately, this move breaks two crucial features, which have been
disabled for now: the display of video and our custom timeline widget.
Since both of these require some reworking, which in fact has already
started, we prefer to do the library and framework switch right away.
This too was a long-standing issue. While these practices
basically can be considered "common knowledge", experience
showed those topics are frequently unknown even to practised
programmers.
So now we have a single page dealing with all those issues of
code bloat, dependency poliferation, binary dependency resolution
and issues of transitive and circular library dependencies
the corresponding requirements are already reflected in the
SCons build, see Platform.py
NOTE: the current debian package is still based on the preview
Release 0.2.pre from last year. It will be upgraded probably after
the transition to Jessie as reference system
This piece of documentation describes an insideous special case, which
some time ago prevented us from switching to --as-needed linking.
We treat this as a special case (and it is way easier to do so
now, after the reorganisation of our test suite).
deliberately, I've left #948 open to nudge me about writing this doc
This is very arkane, hard to find knowledge about some intricacies
of the dynamic library resolution. Very relevant for Lumiera,
since we use a resolution scheme relative to the location
of the executable. Documenting this stuff was a long-standing issue
a long standing TODO to document the actual start-up sequence, which
is implemented this way since a long time now. There was an unwritten
section in the "Linking and Application Structure", which seems the
apropriate place for this kind of intricate techincal details.
Last week, Benny Lyons was here on visit in munich and he was pondering
the idea of an experimental secondary build system, as a way to learn
more about the source structure of Lumiera. This reminded me to fill
some missing parts of the documentation. Possibly this is also the
right moment to land the GTK-3 transition?
There is a long-standing RfC which basically describes the
same idea on a much wider, conceptual scope. Indeed I consider
this approach used here for solving the problem with GUI uptades
also as a proof of concept, to be expanded to a much wider scope
in case it works out well.
The new insight here is, that, by transferring a diff in pull mode,
we can circumvent the architectural problems with typing, which
showed up quite clearly in earlier design studies towards this
concept. The change from push to pull is by far not so fundamental
as it looks, since the sender still may initiate the exchange
by sending a message offering the diff iterator for the receiver
to pull. This way, we get a handshake and still sustain the
crucial part, which is to decouple the data representation
and give the receiver full control over the interpretation
of the exchanged data.
