[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GT] SVN Commit r623 - trunk/GT - object alias resolution

Nicholas Kuechler wrote:

Hi,

Regarding the path /usr/share/geniustrader I also agree we need to move away
from the hard wired and put the option in .gt/options file.


that option is already available via your .gt/options file.

set each of these option keys to whatever path you prefer, but i encourage
you to name the file with the lowercase value that follows Path::Aliases::

Path::Aliases::Signals		/what/ever/path/you/like/signals
Path::Aliases::Indicators	/what/ever/path/you/like/indicators
Path::Aliases::Systems		/what/ever/path/you/like/systems
Path::Aliases::CloseStrategy	/what/ever/path/you/like/closestrategy
Path::Aliases::MoneyManagement	/what/ever/path/you/like/moneymanagment
Path::Aliases::TradeFilters	/what/ever/path/you/like/tradefilters
Path::Aliases::OrderFactory	/what/ever/path/you/like/orderfactory
Path::Aliases::Analyzers	/what/ever/path/you/like/analyzers



Perhaps, to make this change easier to implement, if no option exists in the
.gt/options file for the path, then fall back on /usr/share/geniustrader as
the default.


actually that is exactly how it currently works -- set the options shown above
and viola /what/ever/path/you/like/signals will be the last one of three places
searched for signal object aliases. (the other two places searched are the
.gt/options file and .gt/aliases/signals). well the .gt/options file isn't
searched for, as it has already been read and any object aliases defined there
have already been set.

again -- there is no downside to not having the default path /usr/share/geniustrader/aliases,
the code ignores non existing paths. the same applies to .gt/aliases.



i've been looking at object aliases recently more than i ever have before. i'm
finding an implementation that is not well integrated with name resolution and
seems to be applied haphazardly in the various script applications (it seems
backtest.pl doesn't support them at all? or am i doing something wrong?)

anyway -- if anyone really wants to put them to serious use i think they
require a complete re-implementation, plus better integration in the existing
applications.

ras


if anyone really cares here's the current state of my (in development state)
hack of GT::Tools::resolve_object_alias. it starts with the leading pod. this
method will accept lines like
  Aliases::Indicators::MyMean  { I:Generic:Eval ( #1 + #2 ) / 2 }
in object aliases files (files in dirs under .gt/aliases and /usr/share/geniustrader/aliases)
where the prior implementation allowed only
  MyMean  { I:Generic:Eval ( #1 + #2 ) / 2 }
this version will accept either format.

in addition it also allows comment lines in these files as well.


=item C<< resolve_object_alias($alias, @param) >>

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 :

# NB -- object alias key value entry for $HOME/.gt/options file only
Aliases::Indicators::MyMean  { I:Generic:Eval ( #1 + #2 ) / 2 }

object alias entries for files in $HOME/.gt/aliases/$kind and in the
shared files (/usr/share/geniustrader/aliases/$kind) are different
from those found in your $HOME/.gt/options file. there must not be
the Aliases::$kind string prefix on them -- that is implicit from the
file pathname.
# NB -- object alias key value entry for $HOME/.gt/aliases/$kind files
MyMean  { I:Generic:Eval ( #1 + #2 ) / 2 }

the different object alias entry format has been changed to correctly
use either the orginal format (w/o Aliases::$kind:: prefix) or the
format with the prefix for files in aliases/$kind files.'

in addition, object alias files now support simple comments on lines
by themselves. start a comment line using the # symbol. because
object aliases provide positional parameter substitution comments
cannot appear at the end of the line.

also note object alias files do not currently support continuation
lines.

Then you can use this alias in any other place where you could have used
a standard indicator as argument. Here's how you would reference it with
custom parameters :

{ @I:MyMean 50 {I:RSI} }

for example: %  display_indicator.pl @I:MyMean GOOG '50 {I:RSI}'

If you don't need any parameters then you can just say "@I:MyMean".

=head2 object aliases precedence

object aliases defined in $HOME/.gt/options override all others

object aliases defined in $HOME/.gt/aliases/$kind override any from
shared location (/usr/share/geniustrader/aliases/$kind or as set
via Path::Aliases::$kind options)


=cut
my $alias_loaded = 0;    # sempaphore to inhibit multi alias loadings

sub resolve_object_alias {
   my ($alias, @param) = (@_);

   goto LOOKUP unless $alias_loaded == 0;    # skip alias loading if already done
   ++$alias_loaded;
#print STDERR "roa: loading $alias_loaded\n";

   # 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> ) ) {
               next if /^\s*$/;
               next if /^\s*#/;
               # continuation lines should be implemented here too
if ( my ( $objanam, $obja ) = /^\s*(\S+)\s+(.*)$/ ) { $objanam =~ s/^Aliases:+$kind:+//i if ( $objanam =~ m/^Aliases:+$kind:+/i ); 
                   GT::Conf::default( "Aliases::$kind\::$objanam", $obja );
               }
           }
           close ALIAS;
       }
   }
GT::Conf::conf_dump() if ( defined($main::verbose) && $main::verbose > 1 );
LOOKUP:
   # Lookup the alias
#print STDERR "look up \"Aliases :: $alias\"\n";
   my $def = GT::Conf::get("Aliases\::$alias");
if ( defined($main::verbose) && $main::verbose > 1 ) {
   print STDERR "look up \"Aliases::$alias\", def=\"$def\"\n";
   print STDERR "param=\"@param\"\n";
}

   my $n = 1;
   foreach my $arg (GT::ArgsTree::args_to_ascii(@param))
   {
       $def =~ s/#$n/$arg/g;
       $n++;
   }
print STDERR "position param subs done \"$def\", n=$n\n"
if ( defined($main::verbose) && $main::verbose > 1 );

   # Take care about operators + - / * in a string like #1+#2
   eval {
       $def =~ s|(\d+)\*(\d+)| $1 * $2 |eg;
       $def =~ s|(\d+)\/(\d+)| $1 / $2 |eg;
       $def =~ s|(\d+)\+(\d+)| $1 + $2 |eg;
       $def =~ s|(\d+)\-(\d+)| $1 - $2 |eg;
   } if $def;

   if ( $def =~ /\|/ ) {
       my $msg = "warn: object aliases containing multiple system components"
        . " is not supported.\n$def\n";
       warn "$msg";
   }
#print STDERR "final alias form:\"$def\"\n";
   return $def;
}




Regards,
Nick



On Thu, May 15, 2008 at 11:32 AM, Weigert, Thomas <weigert

AT
mst.edu> wrote:




RAS,

While I disagree with each of of your points, for the sake of moving on
I shall
- move the loading of object alias into the resolve_object_alias routine
- implement the "load once" solution based on semaphores

I really think the default path /usr/share/geniustrader is a very bad
idea. Having hard wired paths is already a bad idea, but having
hard-wired paths that are not guaranteed to exist is an even worse idea.
Not every user has control over their system; often such users are
prevented from creating directories in /usr or /usr/share (if that
exists). In particular, the common directory is probably used primarily
where more users share a GT installation and in these scenarios it is
more likely that access to /usr is controlled.

Th.



-----Original Message-----
From: Robert A. Schmied [mailto:ras

AT
acm.org]

Sent: Wednesday, May 14, 2008 2:18 PM
To: devel

AT
geniustrader.org

Subject: Re: [GT] SVN Commit r623 - trunk/GT - object alias resolution


my objections to the changes made via this change notice are


basically:


 i) the change to GT::Conf::load materially alters the methods
    operational effects while not ensuring it solves the problem.

ii) preventing multiple object alias loading can be achieved without
    making changes to any other method.

    in addition, one can argue that moving the object alias loading
    code to GT::Conf::load doesn't guarantee multiple loading
    won't happen. should some script call GT::Conf::load a second
    time to load a file other than the default $HOME/.gt/options file
    the object alias loading code will be executed again.

iii) the change related to 'the disliked' path is just change
    for change sake as far as i can tell. the path need not exist,
    ever, the code does not care and operates without issuing
    complaints or warnings should the path not exist.

    this path is a reasonable, practical default (at least for
    *nix platforms), and users can easily change it if it isn't
    suitable for their environment.

    changing the path will adversely affect anyone using it.

    not providing hardwired default values requires additional code
    that handles (ignores) uninitialized variables.

    forcing all users to update their $HOME/.gt/options file in
    support of a no-change change isn't reasonable.

iv) regardless of how small the impact is, there is nothing to be
    gained by always loading (or attempting to load) data that is
    unneeded.


ras