fix a regression regarding struct-asset naming scheme

This commit is contained in:
Fischlurch 2010-04-17 01:56:14 +02:00
parent 0514c24487
commit 5b48b9f864
7 changed files with 72 additions and 75 deletions

View file

@ -202,14 +202,14 @@ namespace asset {
Asset::Ident
getIdent() const
{
Category cat (STRUCT, idi::StructTraits<TY>::catFolder);
Category cat (STRUCT, idi::StructTraits<TY>::catFolder());
return Asset::Ident (this->getSym(), cat);
}
static idi::HashVal
getTypeHash()
{
return hash_value (Category (STRUCT, idi::StructTraits<TY>::catFolder));
return hash_value (Category (STRUCT, idi::StructTraits<TY>::catFolder()));
}
@ -237,7 +237,7 @@ namespace asset {
operator string () const
{
return "ID<"+idi::StructTraits<TY>::idSymbol+">-"+EntryID::getSym();
return "ID<"+idi::StructTraits<TY>::idSymbol()+">-"+EntryID::getSym();
}
friend ostream& operator<< (ostream& os, EntryID const& id) { return os << string(id); }

View file

@ -99,7 +99,7 @@ namespace asset {
// does the query somehow specify the desired name-ID?
string nameID = extractID (genericIdSymbol, query);
if (isnil (nameID))
nameID = extractID (StructTraits<STRU>::idSymbol, query);
nameID = extractID (StructTraits<STRU>::idSymbol(), query);
if (isnil (nameID))
{
// no name-ID contained in the query...
@ -107,15 +107,15 @@ namespace asset {
static int i=0;
static format namePattern ("%s.%d");
static format predPattern ("%s(%s), ");
nameID = str(namePattern % StructTraits<STRU>::namePrefix % (++i) );
nameID = str(namePattern % StructTraits<STRU>::namePrefix() % (++i) );
name.insert(0,
str(predPattern % StructTraits<STRU>::idSymbol % nameID ));
str(predPattern % StructTraits<STRU>::idSymbol() % nameID ));
}
ENSURE (!isnil (name));
ENSURE (!isnil (nameID));
ENSURE (contains (name, nameID));
Category cat (STRUCT, StructTraits<STRU>::catFolder);
Category cat (STRUCT, StructTraits<STRU>::catFolder());
return Asset::Ident (name, cat ); ///////////////////////TICKET #565 the ID field should be just the ID, the query should go into a dedicated "capabilities" field.
}

View file

@ -36,30 +36,14 @@
#define ASSET_STRUCT_SCHEME_H
//#include "proc/mobject/session.hpp"
//#include "proc/mobject/mobject.hpp"
#include "lib/symbol.hpp"
//#include "lib/error.hpp"
//#include "lib/util.hpp"
//#include <boost/format.hpp>
#include <boost/format.hpp>
using boost::format;
/////////////////////////////////////////////////////////TODO needs to be pushed down into a *.cpp
#include <cstdlib>
//using mobject::Session;
//using mobject::MObject;
/////////////////////////////////////////////////////////TICKET #166 : needs to be pushed down into a *.cpp
#include <boost/format.hpp>
using boost::format;
using lib::Symbol;
//using util::isnil;
//using util::contains;
//using asset::Query;
//using lumiera::query::LUMIERA_ERROR_CAPABILITY_QUERY;
//using lumiera::query::extractID;
namespace mobject {
namespace session {
@ -77,28 +61,76 @@ namespace asset{
class Timeline;
class Sequence;
namespace idi {
// structural asset ID scheme ///////////////////////////////////////////////////////////TICKET #565
using lib::Symbol;
/* ==== structural asset ID scheme ==== */ /////////////////////////////////////////////TICKET #565 : better organisation of this naming scheme
template<class STRU>
struct StructTraits
{
static Symbol namePrefix;
static Symbol catFolder;
static Symbol idSymbol;
static Symbol namePrefix();
static Symbol catFolder();
static Symbol idSymbol();
};
// Note: individual defaults are defined in stuct.cpp
///////////////////////////////////////////////////////////////////////////////////////////TICKET #581 intending to abandon asset::Track in favour of a plain EntryID
template<> struct StructTraits<asset::Track>
{
static Symbol namePrefix() { return "track"; }
static Symbol catFolder() { return "tracks";}
static Symbol idSymbol() { return "track"; }
};
template<> struct StructTraits<mobject::session::Track>
{
static Symbol namePrefix() { return "track"; }
static Symbol catFolder() { return "tracks";}
static Symbol idSymbol() { return "track"; }
};
template<> struct StructTraits<mobject::session::Clip>
{
static Symbol namePrefix() { return "clip"; }
static Symbol catFolder() { return "clips";}
static Symbol idSymbol() { return "clip"; }
};
template<> struct StructTraits<Pipe>
{
static Symbol namePrefix() { return "pipe"; }
static Symbol catFolder() { return "pipes";}
static Symbol idSymbol() { return "pipe"; }
};
template<> struct StructTraits<const ProcPatt>
{
static Symbol namePrefix() { return "patt"; }
static Symbol catFolder() { return "build-templates";}
static Symbol idSymbol() { return "procPatt"; }
};
template<> struct StructTraits<Timeline>
{
static Symbol namePrefix() { return "tL"; }
static Symbol catFolder() { return "timelines";}
static Symbol idSymbol() { return "timeline"; }
};
template<> struct StructTraits<Sequence>
{
static Symbol namePrefix() { return "seq"; }
static Symbol catFolder() { return "sequences";}
static Symbol idSymbol() { return "sequence"; }
};
/* catch-all defaults */
template<class X>
Symbol StructTraits<X>::idSymbol = typeid(X).name(); ////////////////////TICKET #583 this default works but is ugly
Symbol StructTraits<X>::idSymbol() { return typeid(X).name(); } ////////////////////TICKET #583 this default works but is ugly
template<class X>
Symbol StructTraits<X>::catFolder = StructTraits<X>::idSymbol;
Symbol StructTraits<X>::catFolder(){ return idSymbol(); }
template<class X>
Symbol StructTraits<X>::namePrefix = StructTraits<X>::idSymbol;
Symbol StructTraits<X>::namePrefix(){return idSymbol(); }
@ -109,9 +141,9 @@ namespace asset{
{
static uint i=0;
static format namePattern ("%s.%03d");
/////////////////////////////////////////////////////////TODO needs to be pushed down into a *.cpp
////////////////////////////////////////////////////////////////////////////////TICKET #166 : needs to be pushed down into a *.cpp
return str(namePattern % StructTraits<STRU>::namePrefix % (++i) );
return str(namePattern % StructTraits<STRU>::namePrefix() % (++i) );
}

View file

@ -155,39 +155,4 @@ namespace asset {
template PSequence StructFactory::operator() (const Query<Sequence>& query);
/* ======= struct asset naming scheme ======== */
///////////////////////////////////////////////////////////////////////////////////////////TICKET #565 better organisation for the asset::Struct naming scheme
///////////////////////////////////////////////////////////////////////////////////////////TICKET #581 intending to abandon asset::Track in favour of a plain EntryID
template<> Symbol StructTraits<asset::Track>::namePrefix = "track";
template<> Symbol StructTraits<asset::Track>::catFolder = "tracks";
template<> Symbol StructTraits<asset::Track>::idSymbol = "track";
template<> Symbol StructTraits<mobject::session::Track>::namePrefix = "track";
template<> Symbol StructTraits<mobject::session::Track>::catFolder = "tracks";
template<> Symbol StructTraits<mobject::session::Track>::idSymbol = "track";
template<> Symbol StructTraits<mobject::session::Clip>::namePrefix = "clip";
template<> Symbol StructTraits<mobject::session::Clip>::catFolder = "clips";
template<> Symbol StructTraits<mobject::session::Clip>::idSymbol = "clip";
template<> Symbol StructTraits<Pipe>::namePrefix = "pipe";
template<> Symbol StructTraits<Pipe>::catFolder = "pipes";
template<> Symbol StructTraits<Pipe>::idSymbol = "pipe";
template<> Symbol StructTraits<const ProcPatt>::namePrefix = "patt";
template<> Symbol StructTraits<const ProcPatt>::catFolder = "build-templates";
template<> Symbol StructTraits<const ProcPatt>::idSymbol = "procPatt";
template<> Symbol StructTraits<Timeline>::namePrefix = "tL";
template<> Symbol StructTraits<Timeline>::catFolder = "timelines";
template<> Symbol StructTraits<Timeline>::idSymbol = "timeline";
template<> Symbol StructTraits<Sequence>::namePrefix = "seq";
template<> Symbol StructTraits<Sequence>::catFolder = "sequences";
template<> Symbol StructTraits<Sequence>::idSymbol = "sequence";
} // namespace asset

View file

@ -12,7 +12,7 @@ END
TEST "normalise ID" QueryUtils_test normaliseID <<END
out-lit: ..original : a A AA dufte 1a _1 A_A BÄH White space §&Ω%€GΩ%€ar ☠☠☠ baäääääge!!!!! :
out-lit: ..original : a A AA dufte 1a _1 A_A BÄH White space §&Ω%€GΩ%€ar ☠☠☠ baäääääge!!!!! :
out-lit: normalised : a a aA dufte o1a o_1 a_A bH o white_space gar_bage :
END

View file

@ -94,7 +94,7 @@ namespace test{
{
Cmdline tokens ("a A AA dufte 1a _1 A_A BÄH");
tokens.push_back ("");
tokens.push_back (" White space ");
tokens.push_back (" White \t space ");
tokens.push_back ("§&Ω%€GΩ%€ar ☠☠☠ baäääääge!!!!! ");
cout << "..original : " << tokens << " :"<<endl;

View file

@ -541,7 +541,7 @@ In a more elaborate scheme, the advised entity could provide a signal to be invo
&amp;rarr; AdviceImplementation
</pre>
</div>
<div title="AdviceImplementation" modifier="Ichthyostega" modified="201004110525" created="201004100056" tags="impl draft img" changecount="17">
<div title="AdviceImplementation" modifier="Ichthyostega" modified="201004160249" created="201004100056" tags="impl draft img" changecount="19">
<pre>[&lt;img[Advice solution|uml/fig141573.png]]
@ -556,7 +556,7 @@ In order to find matches and provide advice solutions, the advice system maintai
This is the tricky part of the whole advice system implementation. A naive implementation will quickly degenerate in performance, as costs are of order ~AdviceProvisions * ~AdviceRequests * (average number of binding terms). But contrary to the standard solutions for rules based systems (either forward or backward chaining), in this case here always complete binding sets are to be matched, which allows to reduce the effort.
!!!solution idea
The binding patterns are organised by //predicate symbol and the lists are normalised.// A simple normalisation could be lexicographic ordering of the predicate symbols. Then the resulting representation can be //hashed.// When all predicates are constant, match can be found by hashtable lookup, otherwise, in case some predicates contain variable arguments ({{red{planned extension}}}), the lookup is followed by an unification. For this to work, we'll have to include the arity into the predicate symbols used in the first matching stage. Moreover, we'll create a //matching closure// (functor object), internally holding the arguments for unification. This approach allows for //actual interpretation of the arguments.// It is conceivable that in special cases we'll get multiple instances of the same predicate, just with different arguments. The unification of these terms needs to consider each possible pairwise combination (cartesian product) &amp;mdash; but working out the details of the implementation can safely be deferred until we'll actually hit such a special situation, thanks to the implementation by a functor.
The binding patterns are organised by //predicate symbol and the lists are normalised.// A simple normalisation could be lexicographic ordering of the predicate symbols. Then the resulting representation can be //hashed.// When all predicates are constant, a match can be detected by hashtable lookup, otherwise, in case some of the predicates contain variable arguments ({{red{planned extension}}}), the lookup is followed by an unification. For this to work, we'll have to include the arity into the predicate symbols used in the first matching stage. Moreover, we'll create a //matching closure// (functor object), internally holding the arguments for unification. This approach allows for //actual interpretation of the arguments.// It is conceivable that in special cases we'll get multiple instances of the same predicate, just with different arguments. The unification of these terms needs to consider each possible pairwise combination (cartesian product) &amp;mdash; but working out the details of the implementation can safely be deferred until we'll actually hit such a special situation, thanks to the implementation by a functor.
Fortunately, the calculation of this normalised patterns can be separated completely from the actual matching. Indeed, we don't even need to store the binding patterns at all within the binding index &amp;mdash; storing the hash value is sufficient (and in case of patterns with arguments we'll attach the matching closure functor). Yet still we need to store a marker for each successful match, together with back-links, in order to handle changing and retracting of advice.
</pre>