WIP start a unit test to cover simple time grids

src/proc/asset/meta/time-grid.hpp

@@ -74,6 +74,8 @@ namespace meta {
       TimeGrid (EntryID<TimeGrid> const&);
     };
   
+  typedef lumiera::P<TimeGrid> PGrid;
+  
     
   
   

tests/41asset.tests

@@ -68,3 +68,8 @@ END
 TEST "OrderingOfAssets_test" OrderingOfAssets_test <<END
 return: 0
 END
+
+
+PLANNED "Simple TimeGrid" TimeGridBasics_test <<END
+return: 0
+END

tests/components/Makefile.am

@@ -51,6 +51,7 @@ test_components_SOURCES =								\
 	$(testcomponents_srcdir)/proc/asset/orderingofassetstest.cpp			\
 	$(testcomponents_srcdir)/proc/asset/testasset.cpp				\
 	$(testcomponents_srcdir)/proc/asset/typed-id-test.cpp				\
+	$(testcomponents_srcdir)/proc/asset/meta/time-grid-basics-test.cpp		\
 	$(testcomponents_srcdir)/proc/control/argument-tuple-accept-test.cpp		\
 	$(testcomponents_srcdir)/proc/control/command-argument-test.cpp			\
 	$(testcomponents_srcdir)/proc/control/command-basic-test.cpp			\

tests/components/proc/asset/meta/time-grid-basics-test.cpp

@@ -0,0 +1,129 @@
+/*
+  TimeGridBasics(Test)  -  verify a simple reference scale for time quantisation
+
+  Copyright (C)         Lumiera.org
+    2010,               Hermann Vosseler <Ichthyostega@web.de>
+
+  This program is free software; you can redistribute it and/or
+  modify it under the terms of the GNU General Public License as
+  published by the Free Software Foundation; either version 2 of
+  the License, or (at your option) any later version.
+
+  This program is distributed in the hope that it will be useful,
+  but WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  GNU General Public License for more details.
+
+  You should have received a copy of the GNU General Public License
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+* *****************************************************/
+
+
+#include "lib/test/run.hpp"
+#include "lib/test/test-helper.hpp"
+
+#include "proc/asset/meta.hpp"
+#include "proc/asset/meta/time-grid.hpp"
+//#include "proc/asset/entry-id.hpp"
+//#include "lib/p.hpp"
+//#include "proc/assetmanager.hpp"
+//#include "proc/asset/inventory.hpp"
+//#include "proc/mobject/session/clip.hpp"
+//#include "proc/mobject/session/track.hpp"
+//#include "lib/meta/trait-special.hpp"
+//#include "lib/util-foreach.hpp"
+//#include "lib/symbol.hpp"
+
+//#include <tr1/unordered_map>
+//#include <iostream>
+//#include <string>
+
+//using lib::test::showSizeof;
+//using lib::test::randStr;
+//using util::isSameObject;
+//using util::and_all;
+//using util::for_each;
+//using util::isnil;
+using lib::test::randStr;
+//using lib::Literal;
+//using lib::Symbol;
+//using lumiera::P;
+//using std::string;
+//using std::cout;
+//using std::endl;
+
+
+
+namespace asset {
+namespace meta {
+namespace test {
+  
+  typedef Builder<TimeGrid> GridBuilder;
+  typedef EntryID<TimeGrid> GridID;
+  
+  namespace { // Test definitions...
+    
+    Time testOrigin (12,23);
+    TimeFract testFps (5,4);
+    
+  }
+  
+  
+  
+  /***************************************************************************
+   * @test build some simple time grids and verify their behaviour
+   *       for quantising (grid aligning) time values.
+   * 
+   * @todo WIP-WIP-WIP                                       ////////////////////TICKET #736
+   * 
+   * @see asset::meta::TimeGrid
+   * @see time-quantisation-test.cpp usage context
+   */
+  class TimeGridBasics_test : public Test
+    {
+      
+      virtual void
+      run (Arg)
+        {
+          createGrid_fullProcedure();
+          createGrid_simplified();
+        }
+      
+      
+      void
+      createGrid_fullProcedure()
+        {
+          GridID myGrID (randStr(8));
+          GridBuilder spec = asset::Meta::create (myGrID);
+          
+          CHECK (!spec.fps_);
+          CHECK (spec.origin_ == Time(0));
+          CHECK (!spec.predecessor_);
+          
+          spec.fps_ = testFps;
+          spec.origin_ = testOrigin;
+          
+          PGrid myGrid = spec.commit();
+          CHECK (myGrid);
+          
+          UNIMPLEMENTED ("the basic Grid API, so we can actually check anything");
+        }
+      
+      
+      void
+      createGrid_simplified()
+        {
+        }
+      
+      
+    };
+  
+  
+  
+  /** Register this test class... */
+  LAUNCHER (TimeGridBasics_test, "unit asset");
+  
+  
+}}} // namespace asset::meta::test

wiki/renderengine.html

@@ -2744,15 +2744,15 @@ For the case here in question this seems to be the ''resource allocation is cons
 And, last but not least, doing large scale allocations is the job of the backend. Exceptions being long-lived objects, like the session or the sequences, which are created once and don't bear the danger of causing memory pressure. Besides, the ProcLayer code shouldn't issue "new" and "delete" when it comes in hand, rather it should use some centralized [[Factories]] for all allocation and freeing, so we can redirect these calls down to the backend, which may use pooling or special placement allocators or the like. The rationale is, for modern hardware/architectures, care has to be taken with heap allocations, esp. with many small objects and irregular usage patterns.
 </pre>
 </div>
-<div title="MetaAsset" modifier="Ichthyostega" modified="201012300230" created="201012290320" tags="def" changecount="5">
+<div title="MetaAsset" modifier="Ichthyostega" modified="201012302032" created="201012290320" tags="def" changecount="7">
 <pre>This category is comprised of the various aspects of the way the application controls and manages its own behaviour. They are more related to the way the application behaves, as opposed to the way the edited data is structured and organised.
 * StreamType
 * ScaleGrid
 
 !accessing meta assets
-It turns out that all meta assets follow a distinct usage pattern: //they aren't built as individual entities.// Either, they are introduced into the system as part of a larger scale configuration activity, or they are //derived from category.// The latter is a prototype-like approach; mostly, the individual entry just serves to keep track of a categorisation, while at some point, such a link into a describing category may evolve into a local differentiation of some settings.
+It turns out that all meta assets follow a distinct usage pattern: //they aren't built as individual entities.// Either, they are introduced into the system as part of a larger scale configuration activity, or they are //derived from category.// The latter fits in with a prototype-like approach; initially, the individual entry just serves to keep track of a categorisation, while at some point, such a link into a describing category may evolve into a local differentiation of some settings.
 
-Another distinct property of meta assets is to be just a generic front-end to some very specific data entry, which needs to be allocated and maintained and provided on demand. Consider for example configuration rules, which have a textual and AST representation and will be assembled and composed into an effective rule set. Another example would be the enormous amount of parameter data created by parameter automation in the session. While certainly the raw data needs to be stored and retrieved somehow, the purpose of the corresponding meta asset is to access and manipulate this data in a structured and specific fashion.
+Another distinct property of meta assets is to be just a generic front-end to some very specific data entry, which needs to be allocated and maintained and provided on demand. Consider for example configuration rules, which have both a textual and an AST representation and will be assembled and composed into an effective rule set, depending on usage scope. Another example would be the enormous amount of parameter data created by parameter automation in the session. While certainly the raw data needs to be stored and retrieved somehow, the purpose of the corresponding meta asset is to access and manipulate this data in a structured and specific fashion.
 
 !!!self referential structure
 These observation leads to a design relying on a self referential structure: each meta asset is a {{{meta::Descriptor}}}. In the most basic version -- as provided by the generic implementation by {{{asset::Meta}}}, this descriptor is just the link to another descriptor, which represents a category. Thus, meta assets are created or accessed by