Ouch!
Why does C++ lack the most basic everyday stuff?
It needn't be performant. It needn't support some fancy
higher order container. Just join the f***ing strings.
use Bosst?? -- OMG!! pulls in half the metra programming library
and tries to work on any concievable range like object. Just
somehow our Lumiera Forward Iterators aren't "range-like" enough
for boost's taste.
Thus let's code up that fucking for-loop ourselves, once and forever.
This is kind of the logic consequence, since we consider our
functional iterator concept still superior and will continue
to rely on it.
For some time now, I've considered to build a generic bridge
function, to use enable_if and metaprogramming to figure out
if some type is a "Lumiera Forward Iterator" automatically.
But since our concept is to some degree a contract regarding
semantics, which never can be captured by any kind of introspection,
such a bridge implementation would be rather heuristic and
bears the danger to trigger on types actually not intended
as iterator at all. So I consider such a solution as dangerous
and we'll settle with just supplying the necessary bridge
functions as free functions injected for ADL on a case by case base
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"
In Lumiera, "Tracks" are not what you'd expect from
conventional video editing software. They are a mere
grouping devide, and are also used to implement the
"media bins" and tool palettes.
But having "folders" on the timeline would be likewise
confusing, as would be to have a "branch" or "tree".
To get out of that dilemma, we chose an understandable
but deliberately somewhat strange name: "Fork"
It was common understanding on the Mailinglist that we
should handle this renaming in a tuned-down and discrete
way: The UI will continue to show "Tracks" for a familiar
sight and "Bins" in the Asset section. But Lumiera developers
will be nudged to accomodate by renaming the entity in
source code accordingly
Cockoo hashing is a thrilling algorithm.
We investigated it during the time or our first draft
towards a confirugation system in 2008. This usage turned
up some problems -- not sure if based on the implementation
or the algorithm itself; at that time, we just switched
to the probabilistic splay tree. The whole configuration
system effort stalled afterwards; so the cuckoo implementation
remained in tree as a zombie.
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.
over time, a specific Lumiera code writing style has emerged.
The GUI, as it stood, used somewhat different conventions,
which now have been aligned to the common standard.
Basically we use GNU style, with some adjustments for OO-programming,
we prefer CamelCase, and write TypeNames uppercase, variableNames lowercase
it is a widely accepted rule to shape names with the usage site in mind.
Especially this means, that we use the singular form for all kinds
of collections and assortments.
Thus, the namespace should be called "widget" not "widgets",
because at usage site this becomes gui::widget::TimelineWidget
Likewise for "dialogs" and "pannels"
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?
The actual trick to make it work is to use decltype on the function operator
http://stackoverflow.com/questions/7943525/is-it-possible-to-figure-out-the-parameter-type-and-return-type-of-a-lambda/7943765#7943765
In addition, we now pick up the functor by template type and
store it under that very type. For one, this cuts the size
of the generated class by a factor of two. And it gives the
compiler the ability to inline a closure as much as is possible,
especially when the created Binder / Mutator lives in the same
reference frame the closure taps into.
to carry out that rather obvious step, I was bound to consider
all the implications of choosing a given layout and handling pattern
for our external structure representation.
Finally, I settled upon the following decisions
- the value space represented within the DataCap is flat, not further structured
- the distinction between "attribute" and "nested object" is merely conceptual
and will be enforced solely by the diff detection / representation protocol
- basically, a nested subtree may appear as an attribute; the difference
between attributes and children lies solely in the way of access and referral:
by-name vs. positional
- it is pointless to save space for the representation of the discriminator ID
- but we can omit any further explicit type tag, because
- we do *not* support programming by switch-on-type, and thus
- we do *not* support full introspection, only a passive type-safety check
- this is *not* a limitation, since we acknowledge that GenNode is a *Monad*
- and the partial function needed within any flatMap implementation
maps naturally onto our Variant-Visitor; thus
- the DataCap can basically just *be* a Variant
- and GenNode has just to supply the neccessary shaffolding
to turn that into a full fledged Monad implementation, including
direct construction by wrapping a value and flatMap with tree walk
All relevant uses will rely on the more strict access policy
implemented with the new util::AccessCasted. Along the same line
of thinking, I've removed the "second try" convenience conversion
from the typed get-Function of OpaqueHolder. Such an unbounded
"convert it somehow" approach is almost never a good idea. Either,
one knows by design the precise type to expect, or alternatively
should rely on the base interface solely.
...with the sole exception of the usage in WrapperPointer,
which in itself looks obsolete to me; we should better re-think
the way we handle "wrapped" objects for the BuilderTools, once
we actually start implementing the Builder
Ticket #450
This mindmap explains some of the ideas and concepts in more detail.
It can be viewed with the "freeplane" mind mapping software.
("freemind" works as well, but will mess up some of the formatting)
note by the committer: this mindmap was really work in progress.
Christoph shared it with me while in discussion. I'll place it
here in the git history, since it might be interesting to se
how the thoughts evolved. Isn't that what mindmaps are all about?
Note: the new Variant implementation is a re-write from scratch
and does not rely on util::AccessCasted any more. Anyway, both
are now thoroughly covered by unit test
NOTE: this was a one-time verification. Unfortunately there is no way
to verify a failing compilation automatically from a unit-test.
Thus we need to comment out these invalid cases, leaving them
here just for later referral. Need to check those manually
for new compilers to be sure!
this overload will be picked only if none of the more specific
overloads is applicable. Instantiating this overload will then
trigger a static assertion failure. This way we sort out
impossible or dangerous combinations at compile time already.
I found no simple way to include the actual type parameters in
the generated error message (string concatenation at compiletime)
The throw-statement is only there to prevent a warning due
to missing return statement.
...since I consider that a comparatively safe convenience feature.
Of course we *do perform* a NULL check and throw an exception.
So now the actual casting or conversion functions are designed
to work always on the same level of references or pointers,
which means we can just use the standard conversions of the
language. This has the nice effect of ruling out dangerous
combinations (like taking a L-ref from a R-ref) automatically
(extracted from the git history of file try.cpp, May 2008)
basically this is the draft implementation from which
AccessCasted was extracted. I see two problems
- this version prints from within the access functions
- we do not want the automatic static downcast anymore.
meanwhile, I consider this kind of "do everything for me"
programming style as dangerous. If unchecked donwcasts
are desired, then code them up explicitly
TODO: might break some unit-tests...
Explanation: our wrapper around boost::format has special
built-in support for custom operator string(). Any type,
which is neiter standard, or printable through such a
custom string conversion, is represented as a type-string.
For this fallback case, we now use our recently added
demangling call (which actually relies on a rather obscure
but standard compiler API)
still passes compilation, but not actually tested.
The visitor-style accees needs to be implemented, and the
whole virtual copy support mechanism extracted into a separate
header and covered by unit test
now the solution with the copy policy class is in place,
I prefer to return to the more verbose yet clearer notion
of distinct constructors for each case on the outer and
the inner capsule likewise.
The idea with the separate builder class would be significant
only if this class would also provide the copy support. This
turns out to be difficult, due to the access restrictions
and the necessary passing of type parameters.
turns out to be quite a tough challenge....
since obviously we want to support usage of types with
partially disabled copy/assignment operations within Variant.
As long as the corresponding operations on the container aren't
invoked, we expect those types to be usable just fine.
The problem arises at the interaction with type erasure;
to support corret copy / assignement in such a situation, we need
virtual copy / assignment operators. And, since these are to be installed
into a VTable, the templated functions will be instantiated allways,
which might cause invocation of inhibited copy / assignement functions
and thus compilation failure, in spite of never actually invoking such
an illegal operation.
The drafted solution is to mix in a specifically configured copy support policy,
which at least raises a runtime error, instead of invoking the incriminating operation(s)
finally got all those copy / assgnment flavours straight.
Still unsolved: unable to instantiate the Variant template
for a type with private assignment operator (like e.g. Time )
The problem is our virtual assignement operator, which forces
instantiation of the implementation (for the VTable), even if
the actual assignment is never invoked.
