benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

implement creation of "default" Timeline

Browse source
This commit is contained in:
Fischlurch 2010-10-25 06:08:36 +02:00
parent 13e1a3a943
commit 987026f4c8
4 changed files with 26 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
src/common/configrules.hpp
View file

@ -35,6 +35,7 @@
** All details and consequences of this approach still have to be worked out...
**
** @note this is rather a scrapbook and in flux... don't take this code too literal!
** @todo clarify the relation of config query and query-for-defaults ///////////////TICKET #705
**
** @see lumiera::Query
** @see mobject::session::DefsManager

9
src/proc/mobject/session/sess-manager-impl.cpp
View file

@ -122,9 +122,14 @@ namespace session {
}
else
{ // inject some default session content
REQUIRE (0 == session_->timelines.size(), "injecting default timeline, but session isn't pristine");
// issue a default query to retrieve or create a Timeline and a default Sequence
asset::PTimeline initialTimeline = session_->defaults (lumiera::Query<asset::Timeline> ());
/////////////TODO howto "attach a timeline"??
//session_->attach( timeline );
// these got registered automatically
ENSURE (1 == session_->timelines.size());
ENSURE (initialTimeline == session_->timelines[0]);
}
}

12
tests/components/proc/mobject/session/defsmanagertest.cpp
View file

@ -66,10 +66,10 @@ namespace asset
/***********************************************************************
* @test basic behaviour of the defaults manager ("the big picture")
* <ol><li>retrieving a "default" object repeatedly</li>
* <li>retrieving a more constrained "default" object</li>
* <li>failure registers a new "default"</li>
* </ol>
* - retrieving a "default" object repeatedly
* - retrieving a more constrained "default" object
* - failure registers a new "default"
*
* Using pipe assets as an example. The defaults manager shouldn't
* interfere with memory management (it holds weak refs).
*/
@ -164,7 +164,7 @@ namespace asset
PPipe pipe1 = Session::current->defaults (query_for_pID);
//
// this is fine but doesn't work as long as there is another entry in the mock table...
// ...for now we use hack to overwrite the reference in the mock table
// ...for now we use a hack to overwrite the reference in the mock table
//
ASSERT (3 == pipe1.use_count()); // that's the problem; it should be 2
@ -173,7 +173,7 @@ namespace asset
typeHandler.resolve (pipe2, query_for_pID); // in the mock impl this has the side effect
ASSERT (pipe2); // of replacing the mock entry
//////////////////////////////////////////// so from now on the test works as intended....
//////////////////////////////////////////// so from here onward the test works as intended....
ASSERT (2 == pipe1.use_count());
hash = pipe1->getID();

18
wiki/renderengine.html
View file

@ -1476,7 +1476,7 @@ For this to work, we need each of the //participating object types// to provide
@@clear(left):display(block):@@</pre>
</div>
<div title="ConfigRules" modifier="Ichthyostega" modified="200910171607" created="200801171352" tags="overview spec Rules" changecount="14">
<div title="ConfigRules" modifier="Ichthyostega" modified="201010250338" created="200801171352" tags="overview spec Rules" changecount="19">
<pre>Many features can be implemented by specifically configuring and wiring some unspecific components. Rather than tie the client code in need of some given feature to these configuration internals, in Lumiera the client can //query // for some kind of object providing the //needed capabilities. // Right from start (summer 2007), Ichthyo had the intention to implement such a feature using sort of a ''declarative database'', e.g. by embedding a Prolog system. By adding rules to the basic session configuration, users should be able to customize the semi-automatic part of Lumiera's behaviour to great extent.
[[Configuration Queries|ConfigQuery]] are used at various places, when creating and adding new objects, as well when building or optimizing the render engine node network.
@ -1489,6 +1489,12 @@ For this to work, we need each of the //participating object types// to provide
The query is given as a number of logic predicates, which are required to be true. Syntactically, it is a string in prolog syntax, e.g. {{{stream(mpeg)}}}, where &quot;stream&quot; is the //predicate, // meaning here &quot;the stream type is...?&quot; and &quot;mpeg&quot; is a //term // denoting an actual property, object, thing, number etc &amp;mdash; the actual kind of stream in the given example. Multible comma separated predicates are combined with logical &quot;and&quot;. Terms may be //variable // at start, which is denoted syntactically by starting them with a uppercase letter. But any variable term need to be //bound // to some known value while computing the solution to the query, otherwise the query fails. A failed query is treated as a local failure, which may cause some operation being aborted or just some other possibility being chosen.
Queries are represented by instantiations of the {{{Query&lt;TYPE&gt;}}} template, because their actual meaning is &quot;retrieve or create an object of TYPE, configured such that...!&quot;. At the C++ side, this ensures type safety and fosters programming against interfaces, while being implemented rule-wise by silently prepending the query with the predicate &quot;{{{object(TYPE)}}}&quot;
!!!querying for default
A special kind of configuration query includes the predicate {{{default(X)}}}, which is kind-of an existential quantisation of the variable {{{X}}}. Using this predicate states that a suitable //default-configured// object exists somehow. This behaviour could be used as an fallback within a config query, allowing us always to return a solution. The latter can be crucial when it comes to integrating the query subsystem into an existing piece of implementation logic, which requires us to give some guarantees.
&amp;rarr; see DefaultsManagement on details how to access these captured defaults
But note, the exact relation of configuration queries and query-for-default still needs to be worked out, especially when to use which flavour. {{red{WIP 10/2010 &amp;rArr; see Ticket [[#705|http://issues.lumiera.org/ticket/705]]}}}
!executing a Configuration Query
Actually posing such an configuration query, for example to the [[Defaults Manager in the Sessison|DefaultsManagement]], may trigger several actions: First it is checked against internal object registries (depending on the target object type), which may cause the delivery of an already existing object (as reference, clone, or smart pointer). Otherwise, the system tries to figure out an viable configuration for a newly created object instance, possibly by issuing recursive queries. In the most general case this may silently impose additional decisions onto the //execution context // of the query &amp;mdash; by default the session.
@ -1525,7 +1531,7 @@ This is an very important external Interface, because it links together all thre
<pre>[[ProcLayer and Engine]]
</pre>
</div>
<div title="DefaultsImplementation" modifier="Ichthyostega" modified="200806030204" created="200802200043" tags="spec impl draft" changecount="12">
<div title="DefaultsImplementation" modifier="Ichthyostega" modified="201010250143" created="200802200043" tags="spec impl draft" changecount="14">
<pre>As detailed in the [[definition|DefaultsManagement]], {{{default(Obj)}}} is sort of a Joker along the lines &quot;give me a suitable Object and I don't care for further details&quot;. Actually, default objects are implemented by the {{{mobject::session::DefsManager}}}, which remembers and keeps track of anything labeled as &quot;default&quot;. This defaults manager is a singleton and can be accessed via the [[Session]] interface, meaning that the memory track regarding defaults is part of the session state. Accessing an object via the query for an default actually //tagges// this object (storing a weak ref in the ~DefsManager). Alongside with each object successfully queried via &quot;default&quot;, the degree of constriction is remembered, i.e. the number of additional conditions contained in the query. This enables us to search for default objects starting with the most unspecific.
!Skeleton
@ -1541,15 +1547,15 @@ This is an very important external Interface, because it links together all thre
#** otherwise, the newly created object is remembered (tagged) as new default, together with the degree of constriction
!!!Implementation details
Taken precisely, the &quot;degree of constriction&quot; yields only a partial ordering &amp;mdash; but as the &quot;default&quot;-predicate is sort of a existential quantification anyways, its sole purpose is to avoid polluting the session with unnecessary default objects, and we don't need to care for absolute precision. A suitable approximation is to count the number of predicates terms in the query and use a (sorted) set (separate for each Type) to store weak refs to the the objects tagged as &quot;default&quot;
Taken precisely, the &quot;degree of constriction&quot; yields only a partial ordering &amp;mdash; but as the &quot;default&quot;-predicate is sort of a existential quantification anyway, its sole purpose is to avoid polluting the session with unnecessary default objects, and we don't need to care for absolute precision. A suitable approximation is to count the number of predicates terms in the query and use a (sorted) set (separate for each Type) to store weak refs to the the objects tagged as &quot;default&quot;
{{red{WARN}}} there is an interference with the (planned) Undo function. This is a general problem of the config queries; just ignoring this issue seems reasonable.
!!!Problems with the (preliminary) mock implementation
As we don't have a Prolog interpreter on board yet, we utilize a mock store with preconfigured answers. (see MockConfigQuery). As this preliminary solution is lacking the ability to create new objects, we need to resort to some trickery here (please look away). The overall logic is quite broken, because the system isn't capable to do any real resolution &amp;mdash; if we ignore this fact, the rest of the algorithm can be implemented, tested and used right now.
As we don't have a Prolog interpreter on board yet, we utilize a mock store with preconfigured answers. (see MockConfigQuery). As this preliminary solution is lacking the ability to create new objects, we need to resort to some trickery here (please look away). The overall logic is quite broken, not to say outright idiotic, because the system isn't capable to do any real resolution &amp;mdash; if we ignore this fact, the rest of the algorithm can be implemented, tested and used right now.
</pre>
</div>
<div title="DefaultsManagement" modifier="Ichthyostega" modified="200803212244" created="200801121708" tags="def spec" changecount="12">
<pre>For several components and properties there is an implicit default value or configuration; it is stored alongside with the session. The intention is that defaults never create an error, instead, they are to be extended silently on demand. Objects configured according to this defaults can be retrieved at the [[Session]] interface by a set of overloaded functions {{{Session::current-&gt;default(Query&lt;TYPE&gt; (&quot;query string&quot;))}}}, where the //query string // defines a capability query similar to what is employed for pipes, stream types, codecs etc. This query mechanism is implemented by [[configuration rules|ConfigRules]]
<div title="DefaultsManagement" modifier="Ichthyostega" modified="201010250138" created="200801121708" tags="def spec" changecount="13">
<pre>For several components and properties there is an implicit default value or configuration; it is stored alongside with the session. The intention is that defaults never create an error, instead, they are to be extended silently on demand. Objects configured according to these defaults can be retrieved at the [[Session]] interface by a set of overloaded functions {{{Session::current-&gt;default(Query&lt;TYPE&gt; (&quot;query string&quot;))}}}, where the //query string // defines a capability query similar to what is employed for pipes, stream types, codecs etc. This query mechanism is implemented by [[configuration rules|ConfigRules]]
!!!!what is denoted by {{{default}}}?
{{{default(Obj)}}} is a predicate expressing that the object {{{Obj}}} can be considered the default setup under the given conditions. Using the //default// can be considered as a shortcut for actually finding a exact and unique solution. The latter would require to specify all sorts of detailed properties up to the point where only one single object can satisfy all conditions. On the other hand, leaving some properties unspecified would yield a set of solutions (and the user code issuing the query had to provide means for selecting one soltution from this set). Just falling back on the //default// means that the user code actually doesn't care for any additional properties (as long as the properties he //does// care for are satisfied). Nothing is said specifically on //how//&amp;nbsp; this default gets configured; actually there can be rules //somewhere,// and, additionally, anything encountered once while asking for a default can be re-used as default under similar circumstances.