Re: [GT] SVN Commit r623 - trunk/GT

["Robert A. Schmied" <ras AT acm.org>]

GeniusTrader SVN wrote:
> Author: thomas
> Date: 2008-05-03 03:36:52 +0200 (Sat, 03 May 2008)
> New Revision: 623
>
> Modified:
>    trunk/GT/Conf.pm
>    trunk/GT/Tools.pm
> Log:
> Correct alias resolution per RAS suggestion. Avoid repeated loading of object aliases. Remove hard-wired paths for object alias files.
>
> Modified: trunk/GT/Conf.pm
> ===================================================================
> --- trunk/GT/Conf.pm	2008-04-26 22:04:45 UTC (rev 622)
> +++ trunk/GT/Conf.pm	2008-05-03 01:36:52 UTC (rev 623)
> @@ -98,6 +98,28 @@
>  	$conf{lc($key)} = $val;
>      }
>      close FILE;
> +
> +    # Load the various definition of aliases
> +    
> +    foreach my $kind ("Signals", "Indicators", "Systems", "CloseStrategy", 
> +                      "MoneyManagement", "TradeFilters", "OrderFactory",
> +                      "Analyzers")
> +    {
> +        foreach my $file (GT::Conf::_get_home_path()."/.gt/aliases/".lc($kind),
> +         GT::Conf::get("Path::Aliases::$kind"))
> +	{
> +	    next unless defined $file;
> +	    next if not -e $file;
> +            open(ALIAS, "<", "$file") || die "Can't open $file : $!\n";
> +	    while (defined($_=<ALIAS>)) {
> +		if (/^\s*(\S+)\s+(.*)$/) {
> +		    GT::Conf::default("Aliases::$kind\::$1", $2);
> +		}
> +	    }
> +	    close ALIAS;
> +	}
> +    }
> +
>  }
>  
>  =item C<< GT::Conf::clear() >>
>
> Modified: trunk/GT/Tools.pm
> ===================================================================
> --- trunk/GT/Tools.pm	2008-04-26 22:04:45 UTC (rev 622)
> +++ trunk/GT/Tools.pm	2008-05-03 01:36:52 UTC (rev 623)
> @@ -182,7 +182,7 @@
>           .  "\nkey looked for was \"Aliases::Global::$name\"\n";
>      }
>      # The alias content may list another alias ...
> -    while ($sysname !~ /^(I|Indicators|SY|Systems|S|Signals|CS|CloseStrategy|MM|MoneyManagement|TF|TradeFilters|OF|OrderFactory|A|Analyzers|PortfolioEvaluation)/i) {
> +    while ($sysname !~ /:/) {
>  	$sysname = resolve_alias($sysname);
>      }
>      my $n = 1;
> @@ -212,11 +212,21 @@
>  Return the complete description of the object designed by "alias". @param
>  is the array of parameters as returned by GT::ArgsTree::parse_args().
>  
> -Object aliases can be defined in global files
> -(/usr/share/geniustrader/aliases/indicators for example) or in custom
> -files (~/.gt/aliases/indicators) or in the standard configuration file
> -with entries like this one :
> +Object aliases can be defined in global files (as defined in the option
> +Path::Aliases::<object_kind>), for each kind of object (e.g., Signals, 
> +Indicators, etc.), or in user-specific files (~/.gt/aliases/<object_kind>).
>  
> +Such aliases are defined via the syntax
> +  <alias_name>   <definition>
> +
> +For example
> +  MyMean  { I:Generic:Eval ( #1 + #2 ) / 2 }
> +
> +An object alias can also be defined in the option file with the syntax
> +  Aliases::<object_kind>::<alias_name>    <definition>
> +
> +For example:
> +
>   Aliases::Indicators::MyMean  { I:Generic:Eval ( #1 + #2 ) / 2 }
>  
>  Then you can use this alias in any other place where you could have used
> @@ -231,34 +241,6 @@
>  sub resolve_object_alias {
>      my ($alias, @param) = (@_);
>  
> -    # Load the various definition of aliases
> -    GT::Conf::default('Path::Aliases::Signals', '/usr/share/geniustrader/aliases/signals');
> -    GT::Conf::default('Path::Aliases::Indicators', '/usr/share/geniustrader/aliases/indicators');
> -    GT::Conf::default('Path::Aliases::Systems', '/usr/share/geniustrader/aliases/systems');
> -    GT::Conf::default('Path::Aliases::CloseStrategy', '/usr/share/geniustrader/aliases/closestrategy');
> -    GT::Conf::default('Path::Aliases::MoneyManagement', '/usr/share/geniustrader/aliases/moneymanagement');
> -    GT::Conf::default('Path::Aliases::TradeFilters', '/usr/share/geniustrader/aliases/tradefilters');
> -    GT::Conf::default('Path::Aliases::OrderFactory', '/usr/share/geniustrader/aliases/orderfactory');
> -    GT::Conf::default('Path::Aliases::Analyzers', '/usr/share/geniustrader/aliases/analyzers');
> -    
> -    foreach my $kind ("Signals", "Indicators", "Systems", "CloseStrategy", 
> -                      "MoneyManagement", "TradeFilters", "OrderFactory",
> -                      "Analyzers")
> -    {
> -        foreach my $file (GT::Conf::_get_home_path()."/.gt/aliases/".lc($kind),
> -         GT::Conf::get("Path::Aliases::$kind"))
> -	{
> -	    next if not -e $file;
> -            open(ALIAS, "<", "$file") || die "Can't open $file : $!\n";
> -	    while (defined($_=<ALIAS>)) {
> -		if (/^\s*(\S+)\s+(.*)$/) {
> -		    GT::Conf::default("Aliases::$kind\::$1", $2);
> -		}
> -	    }
> -	    close ALIAS;
> -	}
> -    }
> -    
>      # Lookup the alias
>      my $def = GT::Conf::get("Aliases\::$alias");
>      

ahha! i thought i saw a commit that made changes to the way
both system and object aliases were handled -- man i thought i
was losing faster than ever!

i'm still concerned that removing the albeit feeble attempt
to ensure a system alias defines and returns 'a minimal system'
from sub resolve_alias is appropriate. i agree the change was
needed in order to correctly expand an alias but it also removed
the mechanism /\|/ that attempted to ensure the expansion yielded
a system.

to do this correctly the 'minimal system' component set must
be determined -- that appears to be a SY: along with a CS:.
anybody have an alternate list?

then, and one has to decide if sub resolve_alias is the proper
place for it (i think not, but if done in different method all
users (e.g. script applications and possibly even other gt modules)
relying on resolve_alias to do this would need to change as well),
the check for the system components has be crafted. this would
have to include end-user notification as well, something a bit
more than die "system was not a minimal system\n"; i would hope.

me not being a big user of backtest*.pl have assigned a low priority
to this, but it is a concern in the context of gt as a system. how
valid and significant it is is open for discussion and debate.



as for object_aliases, i've already commented the global pathname
change being fine except for users that are already using it (likely
very few). -- if you happen to be one of them please holler. this is
your one second chance!

as long as $kind remains in the pathname, one can create identical
alias names for each component type (systematized use), or even for
a sector class or an individual security. however, anyone with an
investment in object_aliases and sig-sys-descs that use them will
be rightly annoyed if the '@' marker is no longer supported.

and if processing time is reduced that's even better, but just on
the surface (i haven't looked at how object_aliases resolution occurs)
if every object needs to be checked against the alias list because
the "@" marker is removed i'd think that there would be an awful lot
of extra cycles being wasted looking for something that's not there.

aloha

ras