decision: the base for any deadline calculations
is the expected real time corresponding to the grid origin.
This value is contained in the Timings record.
this clarifies the relation of TimeAnchor and Timings,
the latter act as a general spec and abstracted grid,
while the latter actually performs the conversion and
deadline checking
isn't actually *being subject to* a wider goal
or an inner demand -- isn't that exactly the core
of the distinction between "professionality"
as opposed to an attitude of someone "just doing his job"?
Rationale: this is the *support* Library.
The real "Lumiera-Library" does not exist yet.
liblumiera.so will be the *interface* every external
module / plug-in uses to get Lumiera functionality.
Especially the work on Library dependency clean-up
made outright clear, that this interface library
needs to be a separate piece of software, which is
carefully crafted, and more-or-less depends on the
whole application.
No problem if changes/questions are done to this section. As this section is
so important, the reviewer may correct, add or even reject the corrections
here.
We'll get there, iteratively.
Some obvious typos were corrected. Other material improved.
The section on Git was considerably improved.
An entirely new section on Git was added, but which contains some previous
material on git.
The reason for adding a new section on Git was I though it better to have one
single place where someone new to Git and Lumiera could read a simple
recipe-type explanation on how to retrieve source code, make changes and then
push the changes. All information necessary including Git, links, etc should be
on this page, no following liknks. In fact there is no real _new_ information
here that isn't to be found somewhere else. The point being that _all_
information necessary to ge someone up and going is located on one page.
For this reason, I added information on the mailing list and IRC; again, all
essential information in how to contribute to Lumiera, the title ang goal of
this page.
There might be stuff missing here, so please add, but do not make this page too
long. That tends to scare people, in fact, someone might just like to shorten my
contributions here, that would be good!
TODO: Backend, needs just a little more, not much, e.g.:
Area where low-level memory, hardware i/o, etc occur => here
is where real gain in efficiency through modern algorithms can occur,
thus, achieving another goal of Lumiera: efficient & runs on all kinds
of hardware!
this is the entry point into the section holding the various
design documents -- we try to separatte conceptual/design
from the actual technical documentation
the buildsystem will now pick up and link
all test cases according to the layer, e.g.
backend tests will automatically be linked
against the backend + library solely.
tests used to be defined ad hoc and test definitions
are scattered confusingly over various directories.
Now built some simple rules into the buildsystem
to allow organising the tests into layers and
linking them accordingly.
Note: this switches to building shared objects
for the test classes too, which effectively speeds up
both re-building and re-running of test cases
No problem if changes/questions are done to this section. As this section is
so important, the reviewer may correct, add or even reject the corrections
here.
We'll get there, iteratively.
Only just language corrections.
Reviewer might like to examine the following sections: Overview and GUI.
TODO: Backend, needs just a little more, not much, e.g.:
Area where low-level memory, hardware i/o, etc occur => here
is where real gain in efficiency through modern algorithms can occur,
thus, achieving another goal of Lumiera: efficient & runs on all kinds
of hardware!
No rewrite of sections, only the language was corrected. Only very
little rewriting, although some sections might be rewritten and improved
later.
A slight note on style: after a colon (i.e., ':') upper case or lower case
can follow. Both are corrected. To be consistent, I changed all to be the same,
i.e., lower case.
Our libraries constitute a clear dependency hierarchy,
we do not want circular dependencies. Declaring these
dependencies while creating the shared libraries would
allow strict checking by the linker; but unfortunately
this also creates transitive depdendencies stored as
DT_NEEDED tags.
While basically this would be just fine, the resolution of $ORIGIN
on gets confused in case of transitively defined library dependencies
over multiple hops, especially in case when actually no symbol of this
transitive dependency is used. Since these newer systems set the
--as-needed switch for linking by default, these unnecessary
DT_NEEDED entries will be purged from the executable, but of course
not from the shared library causing the transitive dependencies.
As a consequence, when loading the executable, the $ORIGIN resolution
mechanism doesn't act on the dependencies recorded in the library,
causing the shared loader to abort with an "unresolved dependency"
So the resolution for these problems is not to use transitive
dependencies on libraries intended to be found via $ORIGIN
This is kind of a workaround to avoid having to maintain two variants.
Explanation: between Boost 1.42 and 1.52 there was the transition to a
reworked version of the filesystem library, itroducing some breaking changes
The new version distinguishes much clearer between the native and the
generic representation of paths -- which becomes relevant when porting
to non-POXIX operating systems.
Actually the intention was to use the generic path representation in all
configuration; currently this distinction is moot, since we're caring
only for POSIX systems.
So the workaround is to use the fsys::path::string() function, which
is available in both versions, but changed meaning to yield the native
string. Later, when able to deprecate older Boost versions, we should
switch to generic_string()
Note: an alternative solution was found by Mike Fisher in 3b39f35
using the compiletime define BOOST_FILESYSTEM_VERSION=2
See also ticket #896
now this library doesn't refer to any symbols from
Proc-Layer anymore. Resolving these problems
highlighted IMHO a serious shortcomming of our
interface system, which hinders the building
of abstractions at interface level
this is the entry point into the section holding the various
design documents -- we try to separatte conceptual/design
from the actual technical documentation
Some obvious typos were corrected. Other material improved.
The section on Git was considerably improved.
An entirely new section on Git was added, but which contains some previous
material on git.
The reason for adding a new section on Git was I though it better to have one
single place where someone new to Git and Lumiera could read a simple
recipe-type explanation on how to retrieve source code, make changes and then
push the changes. All information necessary including Git, links, etc should be
on this page, no following liknks. In fact there is no real _new_ information
here that isn't to be found somewhere else. The point being that _all_
information necessary to ge someone up and going is located on one page.
For this reason, I added information on the mailing list and IRC; again, all
essential information in how to contribute to Lumiera, the title ang goal of
this page.
There might be stuff missing here, so please add, but do not make this page too
long. That tends to scare people, in fact, someone might just like to shorten my
contributions here, that would be good!
