Observations:
- the initial observation was that we get two instances of the config rules service
- obviously this it is *not* the initialisation of a static variable accessed from
multiple compilation units. But the access from two compilation units is crucial
- we can exclude the effect of all other initialisation. It *is* in SingletonSubclass
- we can exclude the effect of dynamic linking. Even two translation units
linked statically exhibit the same problem
rebuild this test case in the research area, to be able to verify with various compilers
by providing a custom copy function one can adjust otherwise non-copyable
elements. This should be used cautionary because dereferencing elements may
poison the cache and thus have some considerable performance impact
(profile this)
using our util::_Fmt front-end helps to reduce the code size,
since all usages rely on a single inclusion of boost::format
including boost::format via header can cause quite some code bloat
NOTE: partial solution, still some further includes to reorganise
initial draft of an RfC to discuss and define the
requirements for other parts of the application to relie on
note: this commit fixes a merge error; the RfC was lost
while combining documentation and code branches
Notably TiddlyWiki provides now a fallback mechanism
in case the saving to a local file fails due to security
restrictions. When this happens, TiddlyWiki generates a
download link pointing to the current content; this way
one is at least able to "save as" through the browser
context menu.
Due to some controversial policy changes in recent Firefox versions
the support for saving to local files was removed. The rationale
given by the Firefox developers was that this is a rarely used
and generally outdated concept; preferrably people shall use
extensions and save to cloud services (!)
Anyway, Jeremy Ruston, the original author of TiddlyWiki, wrote
a Firefox plugin called "TiddlyFox" to work around these
arcane limitations.
this draft fills in the structure how to get from an invocation
of the engine service to the starting of actual CalcStream instances.
Basically the EngineService implementation is repsonsile to
instruct the Segmentation to provide a suitable Dispatcher.
This is necessary since the implementation of the job functions
calls through the VTable of the interface JobClosure. Thus this
interface (and the VTable definition) needs to reside within
some compilation unit linked together with the basic job class.
TODO: move class Job entirely into the Backend
we were using an very ancient TiddlyWiki version, basically
unaltered since the start of the Lumiera project.
Recent Firefox versions (starting with FF-17) effectively
removed the ability for JavaScript code to get additional
privileges for writing local files; this change seriuosly
undermines the usability of TiddlyWiki and a lot of similar
portable local JavaScript applications.
The original author of TiddlyWiki, Jeremy Ruston, has written
a Firefox plug-in to work around this restriction; this prompts
us to upgrade to a recent TiddlyWiki version as well.
The good news is: recent TiddlyWiki versions are able to import
Tiddlers from older Wikis without much hassle.
now builds for me on Debian-7 Wheezy 64bit
unqualified member functions in dependent base classes not found anymore.
Need to qualify either the class or the instance.
