Upgrade: improve Doxygen parameters and treat some warnings
- remove obsolete configuration settings - walk through all settings according to the documentation https://www.doxygen.nl/manual/config.html - now try to use the new feature to rely on Clang for C++ parsing - walk through the doxygen-warnings.txt and fix some obvious misspellings and structural problems in the documentation comments. With Debian-Trixie, we are now using Doxygen 1.9.8 — which produces massively better results in various fine points. However, there are still problems with automatic cross links, especially from implementation to the corresponding test classes.
This commit is contained in:
parent
a68f145640
commit
555af315b3
62 changed files with 338 additions and 192 deletions
|
|
@ -10,7 +10,7 @@ Import('env')
|
|||
doxydoc = env.Doxygen('devel/Doxyfile')
|
||||
|
||||
# env.Install(dir = '$DESTDIR/share/doc/lumiera$VERSION/devel', source=documentation)
|
||||
env.Clean (doxydoc, doxydoc + ['devel/,doxylog','devel/warnings.txt'])
|
||||
env.Clean (doxydoc, doxydoc + ['devel/,doxylog','devel/doxygen-warnings.txt'])
|
||||
|
||||
|
||||
Export('doxydoc')
|
||||
|
|
|
|||
|
|
@ -35,6 +35,7 @@ SHORT_NAMES = NO
|
|||
JAVADOC_AUTOBRIEF = YES
|
||||
QT_AUTOBRIEF = NO
|
||||
MULTILINE_CPP_IS_BRIEF = NO
|
||||
PYTHON_DOCSTRING = NO
|
||||
INHERIT_DOCS = YES
|
||||
SEPARATE_MEMBER_PAGES = NO
|
||||
TAB_SIZE = 4
|
||||
|
|
@ -43,6 +44,7 @@ OPTIMIZE_OUTPUT_FOR_C = NO
|
|||
OPTIMIZE_OUTPUT_JAVA = NO
|
||||
EXTENSION_MAPPING =
|
||||
MARKDOWN_SUPPORT = YES
|
||||
MARKDOWN_ID_STYLE = GITHUB
|
||||
TOC_INCLUDE_HEADINGS = 2
|
||||
AUTOLINK_SUPPORT = YES
|
||||
BUILTIN_STL_SUPPORT = YES
|
||||
|
|
@ -55,17 +57,20 @@ INLINE_GROUPED_CLASSES = NO
|
|||
INLINE_SIMPLE_STRUCTS = YES
|
||||
TYPEDEF_HIDES_STRUCT = YES
|
||||
LOOKUP_CACHE_SIZE = 2
|
||||
NUM_PROC_THREADS = 0
|
||||
TIMESTAMP = DATE
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Build related configuration options
|
||||
#---------------------------------------------------------------------------
|
||||
EXTRACT_ALL = NO
|
||||
EXTRACT_ALL = YES
|
||||
EXTRACT_PRIVATE = YES
|
||||
EXTRACT_PACKAGE = YES
|
||||
EXTRACT_STATIC = YES
|
||||
EXTRACT_LOCAL_CLASSES = YES
|
||||
EXTRACT_LOCAL_METHODS = YES
|
||||
EXTRACT_ANON_NSPACES = YES
|
||||
RESOLVE_UNNAMED_PARAMS = YES
|
||||
HIDE_UNDOC_MEMBERS = NO
|
||||
HIDE_UNDOC_CLASSES = NO
|
||||
HIDE_FRIEND_COMPOUNDS = NO
|
||||
|
|
@ -73,12 +78,13 @@ HIDE_IN_BODY_DOCS = NO
|
|||
INTERNAL_DOCS = YES
|
||||
CASE_SENSE_NAMES = YES
|
||||
HIDE_SCOPE_NAMES = YES
|
||||
SHOW_HEADERFILE = YES
|
||||
SHOW_INCLUDE_FILES = YES
|
||||
SHOW_GROUPED_MEMB_INC = NO
|
||||
FORCE_LOCAL_INCLUDES = YES
|
||||
INLINE_INFO = YES
|
||||
SORT_MEMBER_DOCS = NO
|
||||
SORT_BRIEF_DOCS = YES
|
||||
SORT_BRIEF_DOCS = NO
|
||||
SORT_MEMBERS_CTORS_1ST = YES
|
||||
SORT_GROUP_NAMES = NO
|
||||
SORT_BY_SCOPE_NAME = NO
|
||||
|
|
@ -150,15 +156,14 @@ REFERENCES_RELATION = YES
|
|||
REFERENCES_LINK_SOURCE = NO
|
||||
SOURCE_TOOLTIPS = YES
|
||||
USE_HTAGS = NO
|
||||
VERBATIM_HEADERS = YES
|
||||
CLANG_ASSISTED_PARSING = NO
|
||||
CLANG_OPTIONS =
|
||||
VERBATIM_HEADERS = NO
|
||||
CLANG_ASSISTED_PARSING = YES
|
||||
CLANG_OPTIONS = -DDEBUG -DEBUG_ALPHA
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the alphabetical class index
|
||||
#---------------------------------------------------------------------------
|
||||
ALPHABETICAL_INDEX = YES
|
||||
COLS_IN_ALPHA_INDEX = 1
|
||||
IGNORE_PREFIX = lumiera:: \
|
||||
lumiera_ \
|
||||
lumi_ \
|
||||
|
|
@ -175,11 +180,14 @@ HTML_FOOTER =
|
|||
HTML_STYLESHEET =
|
||||
HTML_EXTRA_STYLESHEET =
|
||||
HTML_EXTRA_FILES =
|
||||
HTML_COLORSTYLE = LIGHT
|
||||
HTML_COLORSTYLE_HUE = 344
|
||||
HTML_COLORSTYLE_SAT = 68
|
||||
HTML_COLORSTYLE_GAMMA = 80
|
||||
HTML_TIMESTAMP = YES
|
||||
HTML_DYNAMIC_MENUS = YES
|
||||
HTML_DYNAMIC_SECTIONS = YES
|
||||
HTML_CODE_FOLDING = YES
|
||||
HTML_PROJECT_COOKIE = DoxyLumi
|
||||
HTML_INDEX_NUM_ENTRIES = 100
|
||||
GENERATE_DOCSET = NO
|
||||
GENERATE_HTMLHELP = NO
|
||||
|
|
@ -190,8 +198,8 @@ GENERATE_TREEVIEW = YES
|
|||
TREEVIEW_WIDTH = 200
|
||||
ENUM_VALUES_PER_LINE = 1
|
||||
EXT_LINKS_IN_WINDOW = NO
|
||||
HTML_FORMULA_FORMAT = svg
|
||||
FORMULA_FONTSIZE = 9
|
||||
FORMULA_TRANSPARENT = YES
|
||||
USE_MATHJAX = NO
|
||||
SEARCHENGINE = YES
|
||||
SERVER_BASED_SEARCH = NO
|
||||
|
|
@ -216,9 +224,7 @@ PDF_HYPERLINKS = YES
|
|||
USE_PDFLATEX = YES
|
||||
LATEX_BATCHMODE = YES
|
||||
LATEX_HIDE_INDICES = NO
|
||||
LATEX_SOURCE_CODE = NO
|
||||
LATEX_BIB_STYLE = plain
|
||||
LATEX_TIMESTAMP = NO
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the RTF output
|
||||
|
|
@ -239,7 +245,7 @@ EXPAND_ONLY_PREDEF = NO
|
|||
SEARCH_INCLUDES = YES
|
||||
INCLUDE_PATH =
|
||||
INCLUDE_FILE_PATTERNS =
|
||||
PREDEFINED = __cplusplus
|
||||
PREDEFINED = __cplusplus DEBUG EBUG_ALPHA
|
||||
EXPAND_AS_DEFINED =
|
||||
SKIP_FUNCTION_MACROS = YES
|
||||
|
||||
|
|
@ -251,41 +257,29 @@ GENERATE_TAGFILE = lumiera.tag
|
|||
ALLEXTERNALS = NO
|
||||
EXTERNAL_GROUPS = YES
|
||||
EXTERNAL_PAGES = YES
|
||||
PERL_PATH = /usr/bin/perl
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the dot tool
|
||||
#---------------------------------------------------------------------------
|
||||
CLASS_DIAGRAMS = YES
|
||||
MSCGEN_PATH =
|
||||
DIA_PATH =
|
||||
HIDE_UNDOC_RELATIONS = YES
|
||||
HAVE_DOT = YES
|
||||
DOT_NUM_THREADS = 0
|
||||
DOT_FONTNAME = FreeSans
|
||||
DOT_FONTSIZE = 8
|
||||
DOT_FONTPATH =
|
||||
DOT_NUM_THREADS = 0 # use all cores
|
||||
CLASS_GRAPH = YES
|
||||
COLLABORATION_GRAPH = YES
|
||||
GROUP_GRAPHS = YES
|
||||
HIDE_UNDOC_RELATIONS = YES
|
||||
UML_LOOK = YES
|
||||
UML_LIMIT_NUM_FIELDS = 8
|
||||
UML_LIMIT_NUM_FIELDS = 12
|
||||
TEMPLATE_RELATIONS = YES
|
||||
INCLUDE_GRAPH = NO
|
||||
INCLUDED_BY_GRAPH = NO
|
||||
CALL_GRAPH = YES
|
||||
CALLER_GRAPH = YES
|
||||
GRAPHICAL_HIERARCHY = NO
|
||||
DIRECTORY_GRAPH = YES
|
||||
GRAPHICAL_HIERARCHY = NO
|
||||
DOT_IMAGE_FORMAT = svg
|
||||
INTERACTIVE_SVG = YES
|
||||
DOT_PATH =
|
||||
DOTFILE_DIRS =
|
||||
MSCFILE_DIRS =
|
||||
DIAFILE_DIRS =
|
||||
DOT_GRAPH_MAX_NODES = 80
|
||||
MAX_DOT_GRAPH_DEPTH = 20
|
||||
DOT_TRANSPARENT = YES
|
||||
DOT_MULTI_TARGETS = YES
|
||||
GENERATE_LEGEND = YES
|
||||
DOT_CLEANUP = YES
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ namespace lumiera {
|
|||
* fulfilling the given query.
|
||||
* @param solution object fulfilling the query. Will be bound or
|
||||
* unified (in case it's already bound) with the first solution.
|
||||
* @query any goals to be fulfilled by the solution.
|
||||
* @param q any goals to be fulfilled by the solution.
|
||||
* @return false if resolution failed. In this case, solution ptr is empty.
|
||||
*/
|
||||
virtual bool resolve (P<TY>& solution, Query<TY> const& q) = 0;
|
||||
|
|
|
|||
|
|
@ -19,10 +19,10 @@
|
|||
** to decouple the parts of the application and allows for a rules based configuration and
|
||||
** orchestration of the internal workings.
|
||||
**
|
||||
** A Query is a request for just \em someone to come up with a solution, a preconfigured
|
||||
** A Query is a request for _just someone_ to come up with a solution, a preconfigured
|
||||
** setup, some existing data object or contextual information. In order to be usable,
|
||||
** actually a QueryResolver needs to be available to compute the solution and retrieve
|
||||
** the results. As a common denominator, queries can be <i>generic queries</i> given
|
||||
** the results. As a common denominator, queries can be _generic queries_ given
|
||||
** in predicate logic syntax; in this case a generic query resolver (Planned feature
|
||||
** as of 1/2013) will be able at least to determine a suitable facility for delegating
|
||||
** the resolution. Besides, specific subsystems are using more specific kinds of
|
||||
|
|
@ -45,7 +45,7 @@
|
|||
** The QueryResolver returns a result set, actually a Query::Cursor, which can be used to
|
||||
** enumerate multiple solutions, if any.
|
||||
**
|
||||
** Queries are \em immutable, but it is possible to re-build and remould a query using
|
||||
** Queries are _immutable_, but it is possible to re-build and remould a query using
|
||||
** a Query<TY>::Builder, accessible via Query#build() and Query#rebuild().
|
||||
**
|
||||
** @note as of 1/2013 this is rather a concept draft, but some parts of the code base
|
||||
|
|
|
|||
|
|
@ -107,3 +107,46 @@ implementation namespaces within \c lumiera::
|
|||
Implementation namespace for support and library code.
|
||||
*/
|
||||
|
||||
|
||||
|
||||
/* ==== Test Namespaces ==== */
|
||||
|
||||
/** @namespace test
|
||||
Test runner and basic definitions for tests.
|
||||
*/
|
||||
|
||||
/** @namespace lib::test
|
||||
Unit tests for the Lumiera support library.
|
||||
*/
|
||||
|
||||
/** @namespace lib::test::test */
|
||||
/** @namespace lib::time::test */
|
||||
/** @namespace lib::diff::test */
|
||||
/** @namespace lib::hash::test */
|
||||
/** @namespace lib::idi::test */
|
||||
/** @namespace lib::iter::test */
|
||||
/** @namespace lib::meta::test */
|
||||
|
||||
/** @namespace util::test */
|
||||
|
||||
/** @namespace vault::test */
|
||||
/** @namespace vault::mem::test */
|
||||
/** @namespace vault::gear::test */
|
||||
|
||||
/** @namespace steam::test */
|
||||
/** @namespace steam::play:test */
|
||||
/** @namespace steam::engine::test */
|
||||
/** @namespace steam::fixture::test */
|
||||
/** @namespace steam::asset::test */
|
||||
/** @namespace steam::asset::meta::test */
|
||||
/** @namespace steam::control::test */
|
||||
/** @namespace steam::session::test */
|
||||
/** @namespace steam::builder::test */
|
||||
|
||||
/** @namespace stage::test */
|
||||
/** @namespace stage::ctrl::test */
|
||||
/** @namespace stage::model::test */
|
||||
/** @namespace stage::interact::test */
|
||||
|
||||
// Remark: for some unclear reason, cross-links to test-class names do not work in Doxygen;
|
||||
// even after declaring these namespaces, or after setting EXTRACT_ALL = YES
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ using util::noneg;
|
|||
namespace lib {
|
||||
|
||||
|
||||
/** create as a tokenised <i>copy</i> of the current commandline.
|
||||
/** create as a tokenised _copy_ of the current commandline.
|
||||
* Note that argv[0] is always ignored. */
|
||||
Cmdline::Cmdline (int argc, const char** argv)
|
||||
: vector<string> (noneg(argc-1))
|
||||
|
|
|
|||
|
|
@ -430,7 +430,7 @@ namespace diff{
|
|||
auto ignoreAllChanges();
|
||||
|
||||
|
||||
/** attach a listener function, to be invoked on _structural changes._
|
||||
/** attach a listener function, to be invoked on _structural changes_.
|
||||
* Here, we define any change as "structural", which alters the _sequence_ of
|
||||
* child elements, as opposed to their content. In practice, this listener will
|
||||
* be invoked _after_ applying a diff with any `INS`, `DEL`, `FIND`, `SKIP` verb.
|
||||
|
|
@ -442,7 +442,7 @@ namespace diff{
|
|||
template<typename LIS>
|
||||
auto onSeqChange (LIS changeListener);
|
||||
|
||||
/** attach a listener function, to be invoked on any _local change._
|
||||
/** attach a listener function, to be invoked on any _local change_.
|
||||
* This includes the [structural changes](\ref onSeqChange()), but also
|
||||
* value assignments to any attribute or element.
|
||||
* @note mutation of a nested child scope will _not_ trigger this listener.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@
|
|||
*/
|
||||
|
||||
|
||||
/** @file hash-combine.h
|
||||
/** @file hash-combine.hpp
|
||||
** Hash combine function extracted from LibBoost 1.67
|
||||
** Combine two hash values to form a composite depending on both.
|
||||
** @todo 2024 the Lumiera project has yet to decide how to approach
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@
|
|||
**
|
||||
** # Usage
|
||||
** @warning it is essential to understand where actual storage resides!
|
||||
**
|
||||
** A HeteroData chain is built-up gradually, starting with a front-block
|
||||
** - the front-block is usually placed at an _anchor location_ and populated with data
|
||||
** - retrieve a _chain constructor type_ from the _type_ of the front-block,
|
||||
|
|
@ -39,7 +40,8 @@
|
|||
** - need to link this data block explicitly into the front
|
||||
** - get _accessor types_ from the _chain constructor_
|
||||
** - use these to work with individual data elements _through the front-block._
|
||||
** @example
|
||||
**
|
||||
**\par example of typical usage
|
||||
** \code
|
||||
** using Front = lib::HeteroData<uint,double>;
|
||||
** auto h1 = Front::build (1,2.3);
|
||||
|
|
@ -205,7 +207,7 @@ namespace lib {
|
|||
|
||||
|
||||
/**
|
||||
* Accessor-functor to get at the data residing within some tuple element
|
||||
* Accessor-functor to get at the data residing within some tuple element.
|
||||
* Using the enclosing typed scope to ensure safe storage access
|
||||
* @tparam slot number of the data element, counting from zero over the full chain
|
||||
* @note this functor holds no data, but shall be applied to some existing HeteroData.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
*/
|
||||
|
||||
|
||||
/** @file integral.h
|
||||
/** @file integral.hpp
|
||||
** Inclusion for common place integral types and constants.
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -103,8 +103,8 @@ namespace lib {
|
|||
* from (TY *)* -- just we know that our intention is to dereference both levels
|
||||
* of pointers, and then the resulting conversion is correct.
|
||||
* @note in case IT == WrappedIterType, this is just a redefinition of the
|
||||
* default copy ctor. In all other cases, this is an <i>additional
|
||||
* ctor besides the default copy ctor</i> */
|
||||
* default copy ctor. In all other cases, this is an _additional
|
||||
* ctor besides the default copy ctor_. */
|
||||
PtrDerefIter (PtrDerefIter<WrappedIterType> const& oIter)
|
||||
: i_(reinterpret_cast<IT const&> (oIter.getBase()))
|
||||
{ }
|
||||
|
|
|
|||
|
|
@ -1877,7 +1877,7 @@ namespace lib {
|
|||
|
||||
|
||||
|
||||
/** builder function to attach a _custom extension layer._
|
||||
/** builder function to attach a _custom extension layer_.
|
||||
* Any template in compliance with the general construction scheme can be injected through the template parameter.
|
||||
* - it must take a first template parameter SRC and inherit from this source iterator
|
||||
* - towards layers on top, it must behave like a _state core,_ either by redefining the state core API functions,
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@
|
|||
|
||||
/** @file iter-source.hpp
|
||||
** Extension module to build an opaque data source, accessible as
|
||||
** <i>Lumiera Forward Iterator</i>. It is based on combining an IterAdapter
|
||||
** **Lumiera Forward Iterator**. It is based on combining an IterAdapter
|
||||
** with classical polymorphism; here, the data source, which is addressed
|
||||
** by IderAdapter through the "iteration control API", is abstracted behind
|
||||
** an interface (with virtual functions). Together this allows to build
|
||||
|
|
|
|||
|
|
@ -20,14 +20,14 @@
|
|||
** Due to the extremely huge number space, LUID values can be used as unique identifiers
|
||||
** without the need to check for duplicates or collisions. At various places, LUIDs are
|
||||
** thus used right away on creation of new object instances or elements, in case a
|
||||
** distinguishable <i>object identity</i> is required, e.g.
|
||||
** distinguishable _object identity_ is required, e.g.
|
||||
** - any new attachment of an object into the session ("placement")
|
||||
** - unique output designation discovered during the translation into a low-level
|
||||
** node graph ("builder")
|
||||
** - interface slots for external binding and plug-ins
|
||||
**
|
||||
** Moreover, there is a \link luidgen.c Luidgen \endlink tool to generate fixed LUIDs
|
||||
** to be included into source code. It works by replacing the token \c LUIDGEN in the
|
||||
** Moreover, there is a [Luidgen](\ref luidgen.c) tool to generate fixed LUIDs
|
||||
** to be included into source code. It works by replacing the token `LUIDGEN` in the
|
||||
** source code text by a newly generated (random) LUID in octal representation.
|
||||
**
|
||||
** LUIDs can also be used to generate hash values for hash table storage.
|
||||
|
|
|
|||
|
|
@ -232,7 +232,7 @@ namespace util {
|
|||
|
||||
|
||||
/**
|
||||
* Foundation: build a \ref Connex to accept a _terminal symbol._
|
||||
* Foundation: build a \ref Connex to accept a _terminal symbol_.
|
||||
* the actual parsing is delegated to a Regular Expression,
|
||||
* which must match against the _beginning_ of the input sequence,
|
||||
* possibly after skipping some whitespace. The defined parser
|
||||
|
|
@ -966,8 +966,8 @@ namespace util {
|
|||
}
|
||||
|
||||
/**
|
||||
* Start Syntax with a sub-clause enclosed into a _bracketing construct._
|
||||
* The »bracket« is defined as syntax for the _open marker_ and _close marker._
|
||||
* Start Syntax with a sub-clause enclosed into a _bracketing construct_.
|
||||
* The »bracket« is defined as syntax for the _open marker_ and _close marker_.
|
||||
* These are consumed without generating model elements. The parse fails unless
|
||||
* the full sequence `open body close` can be matched.
|
||||
*/
|
||||
|
|
@ -1061,7 +1061,7 @@ namespace util {
|
|||
/**
|
||||
* Combinator: extend this Syntax clause by expecting a further sub-clause
|
||||
* behind the part of the input matched by the already defined part of this Syntax.
|
||||
* The result model will be a \SeqModel, which essentially is a tuple of the
|
||||
* The result model will be a \ref SeqModel, which essentially is a tuple of the
|
||||
* result models of all sequenced parts.
|
||||
* @return Syntax clause instance accepting the extended structure.
|
||||
* @warning the old syntax is invalidated by moving the parse-function out.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@
|
|||
** just for passing an abstraction barrier (while the optimiser can be expected to
|
||||
** remove this barrier and the accompanying nominal copy operations altogether in
|
||||
** the generated code). Consequently the ability to return a polymorphic object
|
||||
** from a factory or configuration function <i>by value</i> would open a lot of
|
||||
** from a factory or configuration function _by value_ would open a lot of
|
||||
** straight forward design possibilities and concise formulations.
|
||||
**
|
||||
** # how to build a copyable value without knowing it's layout in detail
|
||||
|
|
|
|||
|
|
@ -54,13 +54,13 @@ namespace lib {
|
|||
* two instances, it will invoke a free function named
|
||||
* <tt> transfer_control(TY& from, TY& to)</tt> intended
|
||||
* to be found by ADL. Note: in case this function throws,
|
||||
* it <i>must not have any side effects</i>.
|
||||
* - besides, the \em noncopyable type needs to provide an
|
||||
* it **must not have any side effects**.
|
||||
* - besides, the _noncopyable_ type needs to provide an
|
||||
* <tt>operator bool()</tt> yielding true iff currently
|
||||
* containing an managed object. This is similar to
|
||||
* std::unique_ptr or even the behaviour of a plain
|
||||
* old raw pointer, which is equivalent to \c true
|
||||
* when the pointer isn'T \c NULL
|
||||
* old raw pointer, which is equivalent to `true`
|
||||
* when the pointer isn'T `NULL`
|
||||
* @deprecated obsoleted by C++11 rvalue references
|
||||
*
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -20,10 +20,10 @@
|
|||
**
|
||||
** # Implementation data layout
|
||||
**
|
||||
** The front-end container lib::Several<I> is actually just a smart-ptr referring
|
||||
** The front-end container `lib::Several<I>` is actually just a smart-ptr referring
|
||||
** to the actual data storage, which resides within an _array bucket._ Typically
|
||||
** the latter is placed into memory managed by a custom allocator, most notably
|
||||
** lib::AllocationCluster. However, by default, the ArrayBucket<I> will be placed
|
||||
** lib::AllocationCluster. However, by default, the `ArrayBucket<I>` will be placed
|
||||
** into heap memory. All further meta information is also maintained alongside
|
||||
** this data allocation, including a _deleter function_ to invoke all element
|
||||
** destructors and de-allocate the bucket itself. Neither the type of the
|
||||
|
|
@ -31,7 +31,7 @@
|
|||
**
|
||||
** Since the actual data elements can (optionally) be of a different type than
|
||||
** the exposed interface type \a I, additional storage and spacing is required
|
||||
** in the element array. The field ArrayBucket<I>::spread defines this spacing
|
||||
** in the element array. The field `ArrayBucket<I>::spread` defines this spacing
|
||||
** and thus the offset used for subscript access. The actual data storage starts
|
||||
** immediately behind the ArrayBucket, which thus acts as a metadata header.
|
||||
** This arrangement requires a sufficiently sized raw memory allocation to place
|
||||
|
|
@ -144,7 +144,7 @@ namespace lib {
|
|||
|
||||
/**
|
||||
* Helper to determine the »spread« required to hold
|
||||
* elements of type \a TY in memory _with proper alignment._
|
||||
* elements of type \a TY in memory _with proper alignment_.
|
||||
*/
|
||||
template<typename TY>
|
||||
size_t inline constexpr
|
||||
|
|
@ -170,7 +170,7 @@ namespace lib {
|
|||
namespace allo {// Allocation management policies
|
||||
|
||||
/**
|
||||
* Generic factory to manage objects within an ArrayBucket<I> storage,
|
||||
* Generic factory to manage objects within an `ArrayBucket<I>` storage,
|
||||
* delegating to a custom allocator \a ALO for memory handling.
|
||||
* - #create a storage block for a number of objects
|
||||
* - #createAt construct a single payload object at index position
|
||||
|
|
@ -291,7 +291,7 @@ namespace lib {
|
|||
|
||||
/**
|
||||
* Policy Mix-In used to adapt to the ElementFactory and Allocator.
|
||||
* @tparam I Interface type (also used in the lib::Several<I> front-end
|
||||
* @tparam I Interface type (also used in the `lib::Several<I>` front-end
|
||||
* @tparam E a common _element type_ to use by default
|
||||
* @tparam ALO custom allocator template
|
||||
*/
|
||||
|
|
@ -369,7 +369,7 @@ namespace lib {
|
|||
|
||||
|
||||
/*************************************************//**
|
||||
* Builder to create and populate a lib::Several<I>.
|
||||
* Builder to create and populate a `lib::Several<I>`.
|
||||
* Content elements can be of the _interface type_ \a I,
|
||||
* or the _default element type_ \a E. When possible, even
|
||||
* elements of an ad-hoc given, unrelated type can be used.
|
||||
|
|
@ -388,7 +388,7 @@ namespace lib {
|
|||
* patterns, consistency checks may throw at runtime,
|
||||
* when attempting to add an unsuitable element.
|
||||
*/
|
||||
template<class I ///< Interface or base type visible on resulting Several<I>
|
||||
template<class I ///< Interface or base type visible on resulting `Several<I>`
|
||||
,class E =I ///< a subclass element element type (relevant when not trivially movable and destructible)
|
||||
,template<class,class> class POL =allo::HeapOwn ///< Allocator policy template (parametrised `POL<I,E>`)
|
||||
>
|
||||
|
|
|
|||
|
|
@ -61,8 +61,8 @@ namespace lib {
|
|||
|
||||
/**
|
||||
* Policy: use just plain heap allocations
|
||||
* @waring whenever you define a specialisation,
|
||||
* _you_ are responsible for proper alignment
|
||||
* @warning whenever you define a specialisation,
|
||||
* _you_ are responsible for proper alignment
|
||||
* @see TICKET #1204
|
||||
*/
|
||||
template<typename TY>
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
*/
|
||||
|
||||
|
||||
/** @file splite-splice.hpp
|
||||
/** @file split-splice.hpp
|
||||
** Generic algorithm to splice a new segment into a seamless segmentation of intervals.
|
||||
** Here _"segmentation"_ denotes a partitioning of an ordered axis into a seamless sequence
|
||||
** of intervals (here called "segment"). The axis is based on some _ordering type,_ like e.g.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
*/
|
||||
|
||||
|
||||
/** @file statistic.cpp
|
||||
/** @file statistic.hpp
|
||||
** Support for generic statistics calculations.
|
||||
** - average over the N last elements in a data sequence
|
||||
** - simple linear regression with weights (single predictor variable)
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
|
||||
* *****************************************************************/
|
||||
|
||||
/** @file sync.cpp
|
||||
/** @file thread.cpp
|
||||
** This compilation unit holds some implementation details
|
||||
** of the [thread wrapper](\ref lib::Thread), relegated here
|
||||
** to reduce header inclusions.
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ int64_t
|
|||
lumiera_quantise_frames_fps (gavl_time_t time, gavl_time_t origin, uint framerate);
|
||||
|
||||
/**
|
||||
* Similar to #lumiera_quantise_frames, but returns a grid aligned _relative time._
|
||||
* Similar to #lumiera_quantise_frames, but returns a grid aligned _relative time_.
|
||||
* @return time of start of the grid interval containing the given time,
|
||||
* but measured relative to the origin
|
||||
* @warning because the resulting value needs to be limited to fit into a 64bit long,
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
*/
|
||||
|
||||
|
||||
/** @file util-tuples.hpp
|
||||
/** @file util-tuple.hpp
|
||||
** Some small helpers and convenience shortcuts to simplify working with
|
||||
** tuples and sequences (given by iterator). While tuples and sequences
|
||||
** are fundamentally different insofar a tuple has a fixed structure (and
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@
|
|||
** The UI layer retrieves the necessary configuration values from lumiera::Config,
|
||||
** the config facade in the application core. Currently as of 2/2011 these values are
|
||||
** loaded from setup.ini, because the full-blown config system is not yet implemented.
|
||||
** Amongst others, this configuration defines a <i>search path</i> for icons and a
|
||||
** separate search path for resources. These path specs may use the token \c $ORIGIN
|
||||
** Amongst others, this configuration defines a _search path_ for icons and a
|
||||
** separate search path for resources. These path specs may use the token `$ORIGIN`
|
||||
** to refer to the installation directory of the currently executing program.
|
||||
** This allows for a relocatable Lumiera installation bundle.
|
||||
**
|
||||
|
|
|
|||
|
|
@ -54,20 +54,20 @@
|
|||
** and the presence of some component, several contextual predications may be queried:
|
||||
**
|
||||
** - *anchorage*
|
||||
** ** the way the given coordinate spec is or can be anchored
|
||||
** *** it is already _explicitly anchored_ by referring either to a specific window or by generic specification
|
||||
** *** it _can be a anchored_ by interpolation of some wildcards
|
||||
** *** it is _incomplete_ and need to be extended to allow anchoring
|
||||
** *** it is _impossible to anchor_ in the current UI configuration
|
||||
** + the way the given coordinate spec is or can be anchored
|
||||
** * it is already _explicitly anchored_ by referring either to a specific window or by generic specification
|
||||
** * it _can be a anchored_ by interpolation of some wildcards
|
||||
** * it is _incomplete_ and need to be extended to allow anchoring
|
||||
** * it is _impossible to anchor_ in the current UI configuration
|
||||
**
|
||||
** - *coverage*
|
||||
** ** the extent to which a given coordinate spec is backed by the actual UI configuration
|
||||
** ** _please note_: to determine the coverage, the spec needs to be anchored, either explicitly,
|
||||
** or by interpolation, or by extension of an incomplete spec
|
||||
** *** it is _completely covered_
|
||||
** *** it is _partially covered_ with an remaining, uncovered extension part
|
||||
** *** it is _possible to cover completely_
|
||||
** *** it is _impossible to cover_ related to the current UI topology
|
||||
** + the extent to which a given coordinate spec is backed by the actual UI configuration
|
||||
** + _please note_: to determine the coverage, the spec needs to be anchored, either explicitly,
|
||||
** or by interpolation, or by extension of an incomplete spec
|
||||
** * it is _completely covered_
|
||||
** * it is _partially covered_ with an remaining, uncovered extension part
|
||||
** * it is _possible to cover completely_
|
||||
** * it is _impossible to cover_ related to the current UI topology
|
||||
**
|
||||
** \par Some fine points to note
|
||||
** Anchorage and coverage are not the same thing, but coverage implies anchorage. Only when a path is complete
|
||||
|
|
@ -84,17 +84,17 @@
|
|||
** it is also possible to rewrite or extend the spec based on this environment
|
||||
**
|
||||
** - *anchoring*
|
||||
** ** in correspondence to the possible states of anchorage, we may derive an explicitly anchored spec
|
||||
** *** by interpolating the given spec
|
||||
** *** by interpretation and extension of the given spec
|
||||
** + in correspondence to the possible states of anchorage, we may derive an explicitly anchored spec
|
||||
** * by interpolating the given spec
|
||||
** * by interpretation and extension of the given spec
|
||||
**
|
||||
** - *covering*
|
||||
** ** we may construct the covered part of a given spec, which includes automatic anchoring
|
||||
** + we may construct the covered part of a given spec, which includes automatic anchoring
|
||||
**
|
||||
** - *extending*
|
||||
** ** a given UI coordinate pattern is covered...
|
||||
** ** and _truncated_ to the covered part
|
||||
** ** the given _extension suffix_ is then attached behind
|
||||
** + a given UI coordinate pattern is covered...
|
||||
** + and _truncated_ to the covered part
|
||||
** + the given _extension suffix_ is then attached behind
|
||||
**
|
||||
** @see UICoordResolver_test
|
||||
** @see UICoord_test
|
||||
|
|
@ -536,7 +536,7 @@ namespace interact {
|
|||
}
|
||||
|
||||
|
||||
/** mutate to turn a wildcard into _existentially quantified._
|
||||
/** mutate to turn a wildcard into _existentially quantified_.
|
||||
* This means to assume (or require) that an element actually exists at the given position,
|
||||
* without knowing or caring about its actual name. This becomes relevant when matching for
|
||||
* _partially covered_ path; normal wildcards are only accepted to build a solution, when
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
/** @file view-locator.hpp
|
||||
** Access and allocation of UI component views.
|
||||
** Within the Lumiera UI, a _component view_ is a building block to deal with some component
|
||||
** of relevance to _»the model«. As such, all component views exhibit some distinctive traits:
|
||||
** of relevance to _»the model«_. As such, all component views exhibit some distinctive traits:
|
||||
** - they conform to a built-in fixed list of view types, each of which is unique and dedicated
|
||||
** to a very specific purpose: *Timeline*, *Viewer*, (Asset)*Bin*, *Infobox*, *Playcontrol*,...
|
||||
** - each component view has a distinguishable identity and is connected to and addressable
|
||||
|
|
|
|||
|
|
@ -169,8 +169,8 @@ namespace interact {
|
|||
|
||||
|
||||
/**
|
||||
* Allocator is a functor to resolve a given, desired location of a view within the UI, resulting
|
||||
* in creation or allocation of the view -- which happens _as side-effect._ The result of this invocation
|
||||
* Allocator is a functor to resolve a given, desired location of a view within the UI. Invocation results
|
||||
* in creation or allocation of the view -- which happens _as side-effect_. The result of this invocation
|
||||
* are the UI coordinates of an existing or newly created view.
|
||||
*/
|
||||
using Allocator = std::function<UICoord(UICoord)>;
|
||||
|
|
|
|||
|
|
@ -490,7 +490,7 @@ namespace timeline {
|
|||
|
||||
/**
|
||||
* The Lumiera Timeline model does not rely on a list of tracks, as most conventional video editing software does --
|
||||
* rather, each sequence holds a _fork of nested scopes._ This recursively nested structure is parallelled in the way
|
||||
* rather, each sequence holds a _fork of nested scopes_. This recursively nested structure is parallelled in the way
|
||||
* we organise and draw the timeline representation onto the TimelineCanvas: we use an intermediary entity, the TrackBody
|
||||
* as an organisational grouping device, even while we draw _all of the timeline representation_ onto a single global
|
||||
* #mainCanvas_ within the (scrollable) #contentArea_. Thus, adding the first TrackBody to represent the root track
|
||||
|
|
|
|||
|
|
@ -152,9 +152,9 @@ namespace asset {
|
|||
other->unlink (this->id);
|
||||
}
|
||||
|
||||
/** release all links to other <i>dependent</i>
|
||||
* asset objects held internally and advise all parent
|
||||
* assets to do so with the link to this asset.
|
||||
/** release all links to other _dependent asset objects_
|
||||
* held internally and advise all parent assets to do so
|
||||
* with the link to this asset.
|
||||
* @note we don't release upward links to parent assets,
|
||||
* thus effectively keeping the parents alive, because
|
||||
* frequently the accessibility of parent assets is part
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
** These classes are placed into namespace asset and proc_interface.
|
||||
**
|
||||
** Assets are handled by a hierarchy of interfaces. Below the top level Asset interface
|
||||
** there are interfaces for various different <i>Kinds</i> of Assets, like asset::Media,
|
||||
** there are interfaces for various different _Kinds of Assets_, like asset::Media,
|
||||
** asset::Proc, etc. Code utilising the specific properties of e.g. Media assets, will
|
||||
** be implemented directly against the asset::Media interface. To make this feasible
|
||||
** while at the same time being able to handle all asset Kinds in a uniform manner,
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
|
||||
/** @file media.hpp
|
||||
** Media data represented a specific kind of Asset.
|
||||
** For the different <i>kinds</i> of Assets, we use sub-interfaces inheriting
|
||||
** For the different _kinds of Assets_, we use sub-interfaces inheriting
|
||||
** from the general Asset interface. To be able to get asset::Media instances
|
||||
** directly from the AssetManager, we define a specialisation of the Asset ID.
|
||||
**
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
|
||||
/** @file proc.hpp
|
||||
** Data processing Plugins and Codecs can be treated as a specific Kind of Asset.
|
||||
** For the different <i>Kinds</i> of Assets, we use sub-interfaces inheriting
|
||||
** For the different _Kinds of Assets_, we use sub-interfaces inheriting
|
||||
** from the general Asset interface. To be able to get asset::Proc instances
|
||||
** directly from the AssetManager, we define a specialisation of the Asset ID.
|
||||
**
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ namespace asset {
|
|||
bool known (IDA id, const Category& cat) ;
|
||||
|
||||
/** remove the given asset from the internal DB.
|
||||
* <i>together with all its dependents</i> */
|
||||
* _together with all its dependents_. */
|
||||
void remove (IDA id) ;
|
||||
|
||||
/** deregister and evict all known Assets.
|
||||
|
|
|
|||
|
|
@ -541,8 +541,8 @@ namespace control {
|
|||
/** Helper Template for building a Functor or function-like class:
|
||||
* Mix in a function call operator, which mimics the specified signature SIG .
|
||||
* This template is to be used as a base class to inherit the target type TAR from;
|
||||
* this target type is assumed to provide a function \bindArg(Tuple<TYPES..>) --
|
||||
* where \c TYPES... is the sequence of types found in the provided Signature SIG.
|
||||
* this target type is assumed to provide a function `bindArg(Tuple<TYPES..>)` —
|
||||
* where `TYPES...` is the sequence of types found in the provided Signature \a SIG.
|
||||
*/
|
||||
template<typename SIG, class TAR, class BASE =bind_arg::Dummy>
|
||||
class AcceptArgumentTuple
|
||||
|
|
@ -551,7 +551,7 @@ namespace control {
|
|||
{ };
|
||||
|
||||
|
||||
/** Helper Template for Steam-Layer control::Command : mix in a \c bind(...) function
|
||||
/** Helper Template for Steam-Layer control::Command : mix in a `bind(...)` function
|
||||
* @param SIG function signature to mimic (regarding the arguments and return type)
|
||||
* @param TAR the target class providing a function \c bindArg(Tuple<Types<T1...> >)
|
||||
* @param BASE the base class for inheritance chaining
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ namespace control {
|
|||
|
||||
|
||||
/********************************************************************//**
|
||||
* PImpl within SteamDispatcher to implement the _Session Loop Thread._
|
||||
* PImpl within SteamDispatcher to implement the _Session Loop Thread_.
|
||||
* During the lifetime of this object...
|
||||
* - the SessionCommandService is offered to enqueue commands
|
||||
* - the Session Loop thread dispatches commands and triggers the Builder
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ namespace control {
|
|||
friend class lib::DependencyFactory<STypeManager>;
|
||||
|
||||
/** Lifecycle: reset all type registration information
|
||||
* to the <i>generic pristine default</i> state. This includes
|
||||
* to the _generic pristine default_ state. This includes
|
||||
* hard wired defaults and defaults provided by type plugins, but
|
||||
* excludes everything added by the session
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
** The EngineService singleton has no state beyond the jobs currently managed by the
|
||||
** scheduler; when the latter isn't available, any invocation will throw.
|
||||
**
|
||||
** The central concept provided through this facade interface is the <i>calculation stream</i>.
|
||||
** The central concept provided through this facade interface is the **calculation stream**.
|
||||
** This represents a series of calculations, expected to happen in a timely fashion and in order
|
||||
** to deliver a frame data stream into an opened output connection. On the implementation side,
|
||||
** a calculation stream will be translated into a series of jobs to invoke render nodes;
|
||||
|
|
|
|||
|
|
@ -236,7 +236,7 @@ namespace engine {
|
|||
|
||||
|
||||
/**
|
||||
* Trait template to handle an _associated parameter functor._
|
||||
* Trait template to handle an _associated parameter functor_.
|
||||
* In those cases, where the basic processing function is classified such
|
||||
* as to accept parameter(s), it may be desirable to _generate_ those parameters
|
||||
* at invocation — be it as a fixed parametrisation chosen for this usage, or even
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@
|
|||
**
|
||||
** ## Flavours of the processing function
|
||||
** The binding to the actual data processing operations (usually supplied by an external library)
|
||||
** is established by a **processing-functor** passed to configure the [Port builder](\PortBuilderRoot::invoke()).
|
||||
** is established by a **processing-functor** passed to configure the [Port builder](\ref PortBuilderRoot::invoke()).
|
||||
** The supported signatures of this functor are quite flexible to allow for various flavours of invocation.
|
||||
** Data types of parameters and buffers are picked up automatically (at compile time), based on the
|
||||
** signature of the actual function supplied. The accepted variations are described in detail
|
||||
|
|
@ -603,7 +603,7 @@ namespace engine {
|
|||
|
||||
|
||||
/**
|
||||
* Nested sub-Builder analogous to \ref PortBuilder, but for building a _»Param Agent Node«._
|
||||
* Nested sub-Builder analogous to \ref PortBuilder, but for building a _»Param Agent Node«_.
|
||||
* This will compute additional parameters and make them temporarily accessible through the
|
||||
* TurnoutSystem of the invocation, but only while delegating recursively to another
|
||||
* computation node, which can then draw upon these additional parameter values.
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ namespace fixture {
|
|||
|
||||
|
||||
|
||||
/** does the <i>transaction currently being built</i>
|
||||
/** does the transaction _currently being built_
|
||||
* already contain a model port registration for the given ID?
|
||||
* @note this does \em not query registration state of the
|
||||
* global registry; use #isRegistered for that...*/
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@
|
|||
** While client code accesses model ports only as immutable descriptors handled
|
||||
** through an (opaque) reference, the builder is in charge of detecting and organising
|
||||
** any (new) model ports arising as the result of the build process. Changes to the set
|
||||
** of current model ports are to be activated with an atomic <i>transactional switch.</i>
|
||||
** of current model ports are to be activated with an atomic _transactional switch_.
|
||||
**
|
||||
** builder::ModelPortRegistry thus acts as management interface and factory for model ports.
|
||||
** A given instance of this registry can be promoted to be "the" model port registry reflecting
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ namespace fixture {
|
|||
|
||||
/**
|
||||
* For the purpose of building and rendering, the fixture (for each timeline)
|
||||
* is partitioned such that each segment is _structurally constant._
|
||||
* is partitioned such that each segment is _structurally constant_.
|
||||
* For each segment there is a RenderGraph (unit of the render engine)
|
||||
* which is able to render all ExitNode(s) for this segment.
|
||||
*
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ namespace fixture {
|
|||
|
||||
/**
|
||||
* For the purpose of building and rendering, the fixture (for each timeline)
|
||||
* is partitioned such that each segment is _structurally constant._
|
||||
* is partitioned such that each segment is _structurally constant_.
|
||||
* The Segmentation defines and maintains this partitioning. Furthermore,
|
||||
* it is the general entry point for accessing the correct part of the engine
|
||||
* responsible for a given timeline time point.
|
||||
|
|
|
|||
|
|
@ -13,9 +13,9 @@
|
|||
|
||||
|
||||
/** @file interpolator.hpp
|
||||
** Core abstraction: automation parameter interpolator
|
||||
** Core abstraction: automation parameter interpolator.
|
||||
** Each interpolator implementation has the ability to resolve intermediary
|
||||
** values and to provide a parameter value for _every arbitrary point in time._
|
||||
** values and to provide a parameter value for _every arbitrary point in time_.
|
||||
*/
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@
|
|||
** has an associated StreamType.
|
||||
**
|
||||
** Because model ports are discovered this way, dynamically during the build process,
|
||||
** at some point there is a <i>transactional switch</i> to promote the new configuration
|
||||
** at some point there is a _transactional switch_ to promote the new configuration
|
||||
** to become the valid current model port configuration. After that switch, model ports
|
||||
** are immutable.
|
||||
**
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ namespace mobject {
|
|||
* This is an generic map-like container, acting as Interface to be used
|
||||
* in the signature of API functions either providing or requiring a Mapping.
|
||||
* For each distinct usage situation, an instantiation of this template should
|
||||
* be created, providing a <i>definition context</i> as template parameter.
|
||||
* be created, providing a _definition context_ as template parameter.
|
||||
* Instances of this concrete mapping type may then be default constructed
|
||||
* and copied freely. The definition context is supposed to provide
|
||||
* - a functor `DEF::output` usable as function pipe-ID --> Target
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ namespace mobject {
|
|||
namespace session {
|
||||
|
||||
/**
|
||||
* @TODO: clarify asset->mobject relation and asset dependencies; Ticket #255
|
||||
* @todo: clarify asset->mobject relation and asset dependencies; /////////////////////////////////////////TICKET #255
|
||||
*/
|
||||
asset::Proc const&
|
||||
Effect::getProcAsset() const
|
||||
|
|
|
|||
|
|
@ -46,18 +46,18 @@ namespace session {
|
|||
* Within the Session/Model, Placements are used to attach
|
||||
* MObjects; but beyond that, each Placement can \em contain
|
||||
* other Placements, effectively forming a scope. Thus Scope
|
||||
* is basically another view on Placements <i>which are attached
|
||||
* to the session.</i> This (hidden) link to the session is utilised
|
||||
* is basically another view on Placements _which are attached
|
||||
* to the session_. This (hidden) link to the session is utilised
|
||||
* to establish the nesting of scopes and allow querying and navigating.
|
||||
*
|
||||
* Actually, Scope is implemented through a PlacementRef pointing to
|
||||
* the Placement which \em constitutes this Scope. We call this Placement
|
||||
* the "scope top". A fork e.g. can \em contain several clips, but also
|
||||
* the Placement which _constitutes this Scope_. We call this Placement
|
||||
* the "scope top". A fork e.g. can _contain_ several clips, but also
|
||||
* nested sub forks, all of which would be within the scope of this fork.
|
||||
* This scoping relation plays an important role when it comes to \em resolving
|
||||
* This scoping relation plays an important role when it comes to _resolving_
|
||||
* properties of placement, like e.g. the output designation, overlay mode,
|
||||
* sound pan position etc -- properties from enclosing scopes will be
|
||||
* inherited unless \em shaded by local definitions, similar to the
|
||||
* inherited unless _shaded_ by local definitions, similar to the
|
||||
* behaviour known from most programming languages when referring
|
||||
* to local variables.
|
||||
* @note Scope is a passive entity,
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ namespace session {
|
|||
}
|
||||
|
||||
|
||||
/** detach the denoted element from the model _including all children._
|
||||
/** detach the denoted element from the model _including all children_.
|
||||
* @return true if actually erased something
|
||||
* @note when specifying model root, all sub-elements will be cleared,
|
||||
* but model root itself will be retained.
|
||||
|
|
|
|||
|
|
@ -57,8 +57,8 @@ namespace mobject {
|
|||
* implementation object, where the smart pointer is actually
|
||||
* the SessionManager (which is singleton as well...).
|
||||
*
|
||||
* Consequently, if you want to talk to the <i>session manager,</i>
|
||||
* you use dot-notation, while you access the <i>session object</i>
|
||||
* Consequently, if you want to talk to the _session manager_,
|
||||
* you use dot-notation, while you access the _session object_
|
||||
* via arrow notation (e.g. `Session::current->getFixture()` )
|
||||
*/
|
||||
SessManager& Session::current = theSessionManager();
|
||||
|
|
|
|||
|
|
@ -175,7 +175,7 @@ namespace gear {
|
|||
/**
|
||||
* Builder operation: append a Notification link to the end of this Term's chain.
|
||||
* @param targetTerm another Term, which thereby becomes dependent on this Term.
|
||||
* @remark the \q targetTerm will be inhibited, until this Term's chain has
|
||||
* @remark the \a targetTerm will be inhibited, until this Term's chain has
|
||||
* been activated and processed up to emitting the inserted `NOTIFY`.
|
||||
*/
|
||||
Term&
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ namespace gear {
|
|||
|
||||
/**
|
||||
* Allocation Extent holding _scheduler Activities_ to be performed altogether
|
||||
* before a common _deadline._ Other than the underlying raw Extent, the Epoch
|
||||
* before a common _deadline_. Other than the underlying raw Extent, the Epoch
|
||||
* maintains a deadline time and keeps track of storage slots already claimed.
|
||||
* This is achieved by using the Activity record in the first slot as a GATE term
|
||||
* to maintain those administrative information.
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ namespace test{
|
|||
/**
|
||||
* Helper for #tortureTest():
|
||||
* Build a table of functors, where the i-th entry invokes the function
|
||||
* increment<i>(), which leads to incrementing the counter for Dummy<i>.
|
||||
* `increment<i>()`, which leads to incrementing the counter for `Dummy<i>`.
|
||||
*/
|
||||
template<size_t...I>
|
||||
static auto
|
||||
|
|
@ -163,7 +163,7 @@ namespace test{
|
|||
* - run a large number of threads in parallel, each incrementing
|
||||
* a randomly picked counter; this is achieved by using a table
|
||||
* of »increment operators«, where each one is tied to a specific
|
||||
* Dummy<i>.
|
||||
* `Dummy<i>`.
|
||||
*/
|
||||
void
|
||||
tortureTest()
|
||||
|
|
|
|||
|
|
@ -19,23 +19,22 @@
|
|||
** for the drafting process and is self-contained. The final solution was
|
||||
** then extracted later as library implementation into visitor.hpp
|
||||
**
|
||||
** Basic considerations
|
||||
** <ul><li>cyclic dependencies should be avoided or at least restricted
|
||||
** to some library related place. The responsibilities for
|
||||
** user code should be as small as possible.</li>
|
||||
** <li>Visitor is about <i>double dispatch</i>, thus we can't avoid
|
||||
** using some table lookup implementation, and we can't avoid using
|
||||
** some of the cooperating classes' vtables. Besides that, the
|
||||
** implementation should not be too wasteful...</li>
|
||||
** <li>individual Visiting Tool implementation classes should be able
|
||||
** to opt in or opt out on implementing functions treating some of
|
||||
** the visitable subclasses.</li>
|
||||
** <li>there should be a safe fallback mechanism backed by the
|
||||
** visitable object's hierarchy relations. If some new class declares
|
||||
** to be visitable, existing Visiting Tools not yet treating this new
|
||||
** visitable type should fall back rather to the next best match up the
|
||||
** hierarchy, instead of invoking some almost abstract base class</li>
|
||||
** </ul>
|
||||
** \par Basic considerations
|
||||
** - cyclic dependencies should be avoided or at least restricted
|
||||
** to some library related place. The responsibilities for
|
||||
** user code should be as small as possible.
|
||||
** - the purpose of Visitor is to achieve **double dispatch**, thus we
|
||||
** can not avoid using some table lookup implementation, and we can not
|
||||
** avoid using some of the cooperating classes' vtables. Besides that,
|
||||
** the implementation should not be too wasteful...
|
||||
** - individual Visiting Tool implementation classes should be able
|
||||
** to opt in or opt out on implementing functions treating some of
|
||||
** the visitable subclasses.
|
||||
** - there should be a safe fallback mechanism backed by the
|
||||
** visitable object's hierarchy relations. If some new class declares
|
||||
** to be visitable, existing Visiting Tools not yet treating this new
|
||||
** visitable type should fall back rather to the next best match up the
|
||||
** hierarchy, instead of invoking some almost abstract base class.
|
||||
**
|
||||
** @see visitor.hpp the final lib implementation
|
||||
** @see visitingtooltest.cpp test cases using our lib implementation
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@
|
|||
|
||||
/** @file subsystem-runner-test.cpp
|
||||
** The \ref SubsystemRunner_test performs various scenarios
|
||||
** regarding start, stop and failure of _Subsystems._ Its primary
|
||||
** regarding start, stop and failure of _Subsystems_. Its primary
|
||||
** purpose is to cover the \ref SubsystemRunner.
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ namespace test {
|
|||
* and DummyMO objects (wrapped into any acceptable shared-ptr).
|
||||
* Intentionally, we omit to declare it applicable to TestSubMO2 instances.
|
||||
* In reality this would be a case of misconfiguration, because TestSubMO2
|
||||
* is defined to be processable and consequently has an \apply() function,
|
||||
* is defined to be processable and consequently has an `apply()` function,
|
||||
* which, due to this omission can't find a dispatcher entry when invoked,
|
||||
* so it will call the \c onUnknown(Buildable&) instead
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
|
||||
* *****************************************************************/
|
||||
|
||||
/** @file del-stash-test.cpp
|
||||
/** @file hetero-data-test.cpp
|
||||
** unit test \ref HeteroData_test
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
|
||||
* *****************************************************************/
|
||||
|
||||
/** @file iter-index-test.cpp
|
||||
/** @file index-iter-test.cpp
|
||||
** unit test \ref IndexIter_test
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ namespace test {
|
|||
/**
|
||||
* Configurable template framework for running Scheduler Stress tests
|
||||
* Use to build a custom setup class, which is then [injected](\ref StressTestRig::with)
|
||||
* to [perform](\ref StressTestRig::Launcher::perform) a _specific measurement tool._
|
||||
* to [perform](\ref StressTestRig::Launcher::perform) a _specific measurement tool_.
|
||||
* Several tools and detailed customisations are available in `namespace bench`
|
||||
* - bench::BreakingPoint conducts a binary search to _break a schedule_
|
||||
* - bench::ParameterRange performs a randomised series of parametrised test runs
|
||||
|
|
|
|||
|
|
@ -160496,8 +160496,8 @@ actively maintained upstream. Please remove gdl from Debian.</pre>
|
|||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1439176875682" ID="ID_1482098521" MODIFIED="1742175232490" TEXT="Debian/Trixie">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1742175232490" ID="ID_1849121366" MODIFIED="1742175241823" TEXT="Aufgaben">
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1742175284498" ID="ID_381697845" MODIFIED="1742175309536" TEXT="Scons-Build migrieren">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#338800" CREATED="1742175284498" ID="ID_381697845" MODIFIED="1745722043514" TEXT="Scons-Build migrieren">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1742175408138" ID="ID_22551307" MODIFIED="1742176275192" TEXT="den großen Schritt hat bereits Benny gemacht">
|
||||
<linktarget COLOR="#2a999f" DESTINATION="ID_22551307" ENDARROW="Default" ENDINCLINATION="682;41;" ID="Arrow_ID_344918215" SOURCE="ID_1353266444" STARTARROW="None" STARTINCLINATION="885;-71;"/>
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
|
|
@ -160785,10 +160785,98 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
<node COLOR="#435e98" CREATED="1744081211266" ID="ID_1900866796" MODIFIED="1744081269039" STYLE="fork" TEXT="Doxygen 1.9.8 : wesentlich verbessert">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1744081272203" ID="ID_603439219" MODIFIED="1744081300094" STYLE="fork" TEXT="Warnungen im Doxyfile">
|
||||
<node COLOR="#435e98" CREATED="1744081272203" FOLDED="true" ID="ID_603439219" MODIFIED="1745722037099" STYLE="fork" TEXT="Warnungen im Doxyfile">
|
||||
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1745707663740" ID="ID_944767991" MODIFIED="1745707676207" TEXT="Definitionen im Doxyfile durchgesehen"/>
|
||||
<node CREATED="1745707676865" ID="ID_1588763069" MODIFIED="1745707684615" TEXT="obsolete Einstellungen entfernt"/>
|
||||
<node CREATED="1745707687223" ID="ID_1637635649" MODIFIED="1745707709082" TEXT="neue Einstellungen sinnvoll gewählt"/>
|
||||
<node CREATED="1745707713980" ID="ID_1978721037" MODIFIED="1745707716671" TEXT="Anpassungen">
|
||||
<node CREATED="1745707717811" ID="ID_1379881762" MODIFIED="1745707730461" TEXT="habe nun doch EXTRACT_ALL = YES gesetzt">
|
||||
<node CREATED="1745707737991" ID="ID_1873527585" MODIFIED="1745707756663" TEXT="vermutlich der Hauptgrund warum Links fehlen"/>
|
||||
<node CREATED="1745707757260" ID="ID_146201452" MODIFIED="1745707770831" TEXT="sonst müßte ich diverse Namespaces und innere Klasen dokumentieren"/>
|
||||
<node BACKGROUND_COLOR="#f8ebcc" CREATED="1745719246745" ID="ID_238218365" MODIFIED="1745719317394" TEXT="versuche zudem, explizit die nested "test"-Namespaces in doxygen.dox aufzuführen">
|
||||
<icon BUILTIN="back"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1745719329498" ID="ID_1669179666" MODIFIED="1745719807391" TEXT="die Querverweise auf Testklassen-Namen wollen trotzdem einfach nicht funktionieren">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
<node CREATED="1745719974100" ID="ID_725413583" LINK="file:///Werk/devel/lumi/doc/devel/html/classlib_1_1diff_1_1test_1_1DiffTreeApplication__test.html" MODIFIED="1745720034755" TEXT="seltsamerweise funktionieren die automatischen Links innerhalb des namespace lib::diff::test">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1745719345036" ID="ID_610525952" MODIFIED="1745719821867" TEXT="dabei sind nun die Test-Klassen wenigstens schon mal dokumentiert">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1745721980457" ID="ID_1943182149" MODIFIED="1745722020735" TEXT="funktionieren automatische Links überhaupt irgendwo außerhalb des aktuellen Namespace?">
|
||||
<icon BUILTIN="help"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1745707772348" ID="ID_1241109351" MODIFIED="1745707839072" TEXT="VERBATIME_HEADERS = No"/>
|
||||
<node CREATED="1745707839739" ID="ID_1824175795" MODIFIED="1745707845186" TEXT="versuche nun CLANG_ASSISTED_PARSING = YES">
|
||||
<node CREATED="1745707941608" ID="ID_301450630" MODIFIED="1745707961124" TEXT="soll zu deutlich verbesserter Auswertung von C++ - Code führen">
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
<node CREATED="1745707863114" ID="ID_1416573466" MODIFIED="1745707891985" TEXT="setzt libclang vorraus (von Debian als Dependency )"/>
|
||||
<node CREATED="1745707850065" ID="ID_165935386" MODIFIED="1745707857628" TEXT="Build dauert WESENTLICH länger">
|
||||
<node CREATED="1745718764741" ID="ID_1947466431" MODIFIED="1745718784199" TEXT="zusätzliches Problem: Code-Generation läuft dann single-threaded"/>
|
||||
<node CREATED="1745718813319" ID="ID_1766773373" MODIFIED="1745718873200" TEXT="und zwar trotzdem ich NUM_PROC_THREADS = 0 gesetzt habe">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
das wirkt zwar offensichtlich im ersten Teil, wenn die source-Files erstmals geparst werden, denn dann werden (nur mit diesem Setting) alle Cores zu 100% ausgelastet
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1745712100573" ID="ID_1063103301" MODIFIED="1745712121288" TEXT="naja ... nicht sicher ob ich überhaupt eine Verbesserung sehe">
|
||||
<icon BUILTIN="smiley-neutral"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1745718567027" ID="ID_544667736" MODIFIED="1745718578227" TEXT="einige spezielle Warnungen repariert">
|
||||
<node CREATED="1745718579430" ID="ID_1803171119" MODIFIED="1745718680754" TEXT="Wenn ich emphasis am Ende der \brief-Section verwendet habe">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...und zwar in der der _speziellen Form mit Unterstrich._  (meint: der Unterstrich steht hinter dem Punkt, und damit nicht mehr im \brief -Teil
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1745718682705" ID="ID_510006002" MODIFIED="1745718728784" TEXT="Wenn Typnamen die Template-Argument-Liste `somename<i>` enthalten">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
(wird als HTML-Trag geparst)
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1745718737730" ID="ID_718435242" MODIFIED="1745718753587" TEXT="diverse "unknown commands" die auf Schreibfehler zurückgehen"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d4a582" COLOR="#690f14" CREATED="1745718923727" ID="ID_1446478913" MODIFIED="1745719292645">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
das Ergebnis ist letztlich <b>immer wieder enttäuschend</b>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Doxygen (wie auch diverse andere Sourcecode-Scanner und Validatoren) passen konzeptionell nicht sonderlich gut auf die spezielle Struktur von C++ Code, welcher sehr stark auf Scopes und Querbezüge setzt. Und mein eigener Code-Stil trägt dazu auch noch einiges bei. Meistens sind nur die Texte in den Header-Kommentaren brauchbar. Es folgt dann eine mehr-oder-weniger willkürlich wirkende Liste von Klassen und namespace-Membern. Eine solche Liste erzählt keine Geschichte (der Code tut es schon). Und der Umstand, daß in Doxygen die Struktur flach geklopft wird, tut ein Übriges
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -161265,7 +161353,7 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
</node>
|
||||
<node CREATED="1744749837898" ID="ID_426505316" MODIFIED="1744749846538" TEXT="Deprecations">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1744749991694" ID="ID_593970637" MODIFIED="1744751399369" TEXT="rsvg-convert">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1744749991694" FOLDED="true" ID="ID_593970637" MODIFIED="1744751399369" TEXT="rsvg-convert">
|
||||
<icon BUILTIN="bell"/>
|
||||
<node CREATED="1744750427328" ID="ID_976491551" MODIFIED="1744750440220" TEXT="Warnungen">
|
||||
<icon BUILTIN="edit"/>
|
||||
|
|
@ -161302,7 +161390,7 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1742175245473" ID="ID_1357727858" MODIFIED="1745535177961" TEXT="Warnungen">
|
||||
<node COLOR="#338800" CREATED="1742175245473" FOLDED="true" ID="ID_1357727858" MODIFIED="1745535177961" TEXT="Warnungen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#435e98" CREATED="1744717880469" ID="ID_1900004997" MODIFIED="1744765441677" TEXT="std::unary_function is deprecated">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -161611,11 +161699,13 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1742175249127" ID="ID_1185124760" MODIFIED="1742175325795" TEXT="Testsuite GRÜN">
|
||||
<node BACKGROUND_COLOR="#d0e6a4" COLOR="#338800" CREATED="1742175249127" ID="ID_1185124760" MODIFIED="1745628094269" STYLE="fork" TEXT="Testsuite GRÜN">
|
||||
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
|
||||
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1743970651055" ID="ID_527599811" MODIFIED="1743970655841" TEXT="7 failed Tests">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#338800" CREATED="1745537726553" ID="ID_520603271" MODIFIED="1745537840749" TEXT="00test.tests">
|
||||
<node COLOR="#338800" CREATED="1743970651055" FOLDED="true" ID="ID_527599811" MODIFIED="1745628140544" TEXT="7 failed Tests">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1745537726553" FOLDED="true" ID="ID_520603271" MODIFIED="1745628135439" TEXT="00test.tests">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -161643,17 +161733,17 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1745537758304" ID="ID_1842827052" MODIFIED="1745537772123" TEXT="sieht irgendwie nach geänderten Sytemmeldungen aus">
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1745537758304" ID="ID_1842827052" MODIFIED="1745628094270" TEXT="sieht irgendwie nach geänderten Sytemmeldungen aus">
|
||||
<icon BUILTIN="help"/>
|
||||
</node>
|
||||
<node CREATED="1745537807785" ID="ID_1689259926" MODIFIED="1745537827981" TEXT="Ha! ich sehe es: Die Meldung enthält nicht mehr den Pfad '/bin/cat'"/>
|
||||
<node COLOR="#435e98" CREATED="1745537773651" ID="ID_1498219479" MODIFIED="1745537836890" TEXT="Debian hat nun endgültig die top-Level /bin und /sbin und /lib aufgegeben">
|
||||
<node CREATED="1745537807785" ID="ID_1689259926" MODIFIED="1745628094270" TEXT="Ha! ich sehe es: Die Meldung enthält nicht mehr den Pfad '/bin/cat'"/>
|
||||
<node COLOR="#435e98" CREATED="1745537773651" ID="ID_1498219479" MODIFIED="1745628094270" TEXT="Debian hat nun endgültig die top-Level /bin und /sbin und /lib aufgegeben">
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1745537873206" ID="ID_1566687837" MODIFIED="1745539271003" TEXT="FileSupport_test">
|
||||
<node COLOR="#338800" CREATED="1745537873206" FOLDED="true" ID="ID_1566687837" MODIFIED="1745539271003" TEXT="FileSupport_test">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1745537891733" ID="ID_1913606646" MODIFIED="1745537916159" TEXT="Exception wird geworfen">
|
||||
<node CREATED="1745537891733" ID="ID_1913606646" MODIFIED="1745628094270" TEXT="Exception wird geworfen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -161688,8 +161778,8 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
</html></richcontent>
|
||||
<icon BUILTIN="list"/>
|
||||
</node>
|
||||
<node CREATED="1745538088801" ID="ID_1790511977" MODIFIED="1745538098312" TEXT="bei direktem Aufruf der Testsuite ist alles OK"/>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1745539133640" ID="ID_1693419317" MODIFIED="1745539241438" TEXT="Verdacht: SCons bereinigt das Environment">
|
||||
<node CREATED="1745538088801" ID="ID_1790511977" MODIFIED="1745628094270" TEXT="bei direktem Aufruf der Testsuite ist alles OK"/>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1745539133640" ID="ID_1693419317" MODIFIED="1745628094270" TEXT="Verdacht: SCons bereinigt das Environment">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1745539158846" ID="ID_977263920" MODIFIED="1745539170080" TEXT="wir haben jetzt eine neue SCons-Version und Python-3"/>
|
||||
<node CREATED="1745539170814" ID="ID_1113974889" MODIFIED="1745539185769" TEXT="vielleicht war früher $HOME implizit propagiert"/>
|
||||
|
|
@ -161919,15 +162009,16 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1745537939853" ID="ID_856500393" MODIFIED="1745593572737" TEXT="GenNode_test">
|
||||
<node COLOR="#435e98" CREATED="1745537939853" ID="ID_856500393" MODIFIED="1745628125617" TEXT="GenNode_test">
|
||||
<linktarget COLOR="#5f688e" DESTINATION="ID_856500393" ENDARROW="Default" ENDINCLINATION="-7;20;" ID="Arrow_ID_1431024191" SOURCE="ID_981250865" STARTARROW="None" STARTINCLINATION="-251;11;"/>
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node COLOR="#5c3279" CREATED="1745593535416" ID="ID_447874063" MODIFIED="1745593568987" TEXT="war vom vorherigen Bug ebenfalls betroffen">
|
||||
<arrowlink COLOR="#5c3279" DESTINATION="ID_721065474" ENDARROW="Default" ENDINCLINATION="-13;95;" ID="Arrow_ID_1372407656" STARTARROW="None" STARTINCLINATION="13;-103;"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1745537946821" ID="ID_1319727141" MODIFIED="1745599992122" TEXT="HeteroData_test">
|
||||
<node COLOR="#435e98" CREATED="1745537946821" FOLDED="true" ID="ID_1319727141" MODIFIED="1745628113877" TEXT="HeteroData_test">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1745595723151" ID="ID_1057941772" MODIFIED="1745596135332" TEXT="OK: hier hab ich im Test mit »undefined behaviour« gespielt">
|
||||
<node CREATED="1745595723151" ID="ID_1057941772" MODIFIED="1745628094272" TEXT="OK: hier hab ich im Test mit »undefined behaviour« gespielt">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -161935,15 +162026,14 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
Überraschung: wer sich in den Fuß schießt, schießt sich in den Fuß
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1745596148617" ID="ID_230477037" MODIFIED="1745596185817" TEXT="der Compiler ist in keinster Weise verpflichtet, Daten im Stackframe irgendwie anzuordnen"/>
|
||||
<node CREATED="1745598449798" ID="ID_1524131528" MODIFIED="1745598461412" TEXT="was will ich denn hier demonstrieren?">
|
||||
<node CREATED="1745598462637" ID="ID_554868027" MODIFIED="1745598475244" TEXT="daß der Overflow-Datenblock »irgendwo« liegen kann"/>
|
||||
<node CREATED="1745598479159" ID="ID_1513870970" MODIFIED="1745598499276" TEXT="daß die Verzeigerung bestehen bleibt"/>
|
||||
</node>
|
||||
<node CREATED="1745599892391" ID="ID_1677707130" MODIFIED="1745599990906" TEXT="Lösung: die Storage explizit vorgeben">
|
||||
<node CREATED="1745599892391" ID="ID_1677707130" MODIFIED="1745628094272" TEXT="Lösung: die Storage explizit vorgeben">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -161951,11 +162041,10 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
...ohne die implizite Annahme eines Layout, einfach indem ich den Overflow-Frame gleich per placement-New erzeuge; dann kann man trotzdem immer noch zeigen, daß die Daten weiterhin in der UninitialisedStorage liegen und dort verwendet werden können
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1745537959959" ID="ID_802122855" MODIFIED="1745623338004" TEXT="TestChainLoad_test">
|
||||
<node COLOR="#435e98" CREATED="1745537959959" FOLDED="true" ID="ID_802122855" MODIFIED="1745628127369" TEXT="TestChainLoad_test">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node BACKGROUND_COLOR="#e1c768" COLOR="#9f034c" CREATED="1745602150864" ID="ID_154841907" MODIFIED="1745623367165" TEXT="puh... warum weicht der Hash-Wert ab?">
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
|
|
@ -161973,9 +162062,9 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
</html></richcontent>
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
</node>
|
||||
<node CREATED="1745602431987" ID="ID_1407740921" MODIFIED="1745602460803" TEXT="bereits im einfachsten verify_Node()"/>
|
||||
<node CREATED="1745602493802" ID="ID_941458386" MODIFIED="1745603818751" TEXT="wir verwenden hier noch boost::hash_combine">
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1745602633783" ID="ID_715784100" MODIFIED="1745604456746" TEXT="und dessen Impl sieht jetzt anders aus">
|
||||
<node CREATED="1745602431987" ID="ID_1407740921" MODIFIED="1745628094272" TEXT="bereits im einfachsten verify_Node()"/>
|
||||
<node CREATED="1745602493802" ID="ID_941458386" MODIFIED="1745628094272" TEXT="wir verwenden hier noch boost::hash_combine">
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1745602633783" ID="ID_715784100" MODIFIED="1745628094273" TEXT="und dessen Impl sieht jetzt anders aus">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -162000,10 +162089,9 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
<font size="6" color="#c501a2">SCHWEIN</font><font size="4"> gehabt</font>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1745603771294" HGAP="37" ID="ID_528170484" MODIFIED="1745603805617" TEXT="" VSHIFT="1">
|
||||
<node CREATED="1745603771294" HGAP="37" ID="ID_528170484" MODIFIED="1745628094274" TEXT="" VSHIFT="1">
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
<node CREATED="1745603779142" ID="ID_444058662" MODIFIED="1745603794975" TEXT="">
|
||||
|
|
@ -162017,13 +162105,33 @@ Since then others have made contributions, see the log for the history.</font></
|
|||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1745537983863" ID="ID_1313307442" MODIFIED="1745538004763" TEXT="UICoordResolver_test">
|
||||
<node COLOR="#5b280f" CREATED="1745537983863" ID="ID_1313307442" MODIFIED="1745628094274" TEXT="UICoordResolver_test">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1745626600392" ID="ID_34784349" MODIFIED="1745628094274" TEXT="hier gab es Crashes"/>
|
||||
<node COLOR="#338800" CREATED="1745627880489" ID="ID_981250865" MODIFIED="1745628125616" TEXT="gehen nachweislich auf GenNode und den Rec::Mutator zurück">
|
||||
<arrowlink COLOR="#5f688e" DESTINATION="ID_856500393" ENDARROW="Default" ENDINCLINATION="-7;20;" ID="Arrow_ID_1431024191" STARTARROW="None" STARTINCLINATION="-251;11;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1745537993750" ID="ID_1907252021" MODIFIED="1745538004763" TEXT="UILocationSolver_test">
|
||||
</node>
|
||||
<node COLOR="#5b280f" CREATED="1745537993750" ID="ID_1907252021" MODIFIED="1745628094274" TEXT="UILocationSolver_test">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1745627990960" ID="ID_11585725" MODIFIED="1745628094274" TEXT="wackelig">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node COLOR="#810953" CREATED="1745627994313" ID="ID_1589304377" MODIFIED="1745628094274" TEXT="SchedulerStress_test"/>
|
||||
<node COLOR="#810953" CREATED="1745627998855" ID="ID_1932909119" MODIFIED="1745628094274" TEXT="WorkForce_test"/>
|
||||
<node COLOR="#435e98" CREATED="1745628002831" ID="ID_486276485" MODIFIED="1745628094274" TEXT="nichts neues">
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d0e6a4" COLOR="#338800" CREATED="1745628042310" ID="ID_578951152" MODIFIED="1745628066900" STYLE="bubble" TEXT="läuft wieder wie vorher">
|
||||
<edge COLOR="#808080" STYLE="bezier" WIDTH="thin"/>
|
||||
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1742175264309" ID="ID_1163480280" MODIFIED="1742175329181" TEXT="Preview-Release">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
|
|
|
|||
Loading…
Reference in a new issue