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

["Weigert, Thomas" <weigert AT mst.edu>]

Comments below... Good job in GT archeology...

> -----Original Message-----
> From: Robert A. Schmied [mailto:ras
AT
acm.org]
> Sent: Friday, May 09, 2008 12:50 AM
> To: devel
AT
geniustrader.org
> Subject: Re: [GT] SVN Commit r623 - trunk/GT


> it isn't clear whether an object alias may
> be used to define multiple components of a system (e.g. contain a
> connecting
> '|' symbol). the code commentary, and pod implies that is not their
> intended purpose, for that it's probably just wiser to use a system
> alias.

You cannot define such aliases as object aliases. Object aliases, as the
name says, are aliases for objects. The following are supported:
"Signals", "Indicators", "Systems", "CloseStrategy", "MoneyManagement",
"TradeFilters", "OrderFactory", "Analyzers".

"Global aliases" are for defining "full system names. (As an aside, note
that you do not have to have a "|" connecting system components for
that, a single system description is sufficient.)

> and also in the directory(ies) defined by %conf keys
> "Path::Aliases::$kind"
> (case insensitive) which by default is the path(s)
> /usr/share/geniustrader/aliases/$kind
> 

As of the latest version, there is no default. In the previous version,
there was only the default. I guess you could have somewhere defined a
different path but it was not defined anywhere...


> the format is:
>    "Aliases::Indicators::"<my_object_alias> <whitespace> <object_alias
> specification>
> 
> 
> the second form of an object alias format is:
>     <my_object_alias> <whitespace> <object_alias specification>
> 

And global aliases have yet another form...

> 
> i haven't evaluated the effect of putting signal object aliases in
> files expected to be indicators.

In loading these would be defined as indicators. If you reference them
as indicators using @I:xxx, they will be correctly loaded and define a
signal, but it would be sort of weird and confusing.

> 
> i have not been able to get an object alias that references another
> object alias to work. either recursion isn't supported or i'm unable
> to properly specify the recursive alias correctly.

Recursion is not supported, and it would be a little tricky due to the
fact that parameter handling is as in standard objects, not as in global
aliases.

> 
> i haven't made the effort to evaluate object alias argument
> substitution,
> that being plugging in the correct arguments for #1, #2, $n
> placeholders.

Works as advertised...

> 
> finally i haven't made the effort to ensure that the arithmetic
> operators
> ( + - * / ) work.

Work just fine but it seems an unnecessary complication.

> 
> 
> findings and other observations:
> 
>    i) GT::Tools::resolve_object_alias reloads all alias files for
every
>       object alias encountered.

Not in the current implementation.

> 
>   ii) object aliases don't appear to allow recursion

Correct.

> 
>  iii) two different object aliases specification formats is confusing

Yes, but understandable why it is done this way. However, requiring that
even the shared files are formatted in style #1 would allow additional
error checking.

> 
>   iv) multiple object aliases file locations is confusing

Not really. User specific files override the shared files.

> 
>    v) case is ignored when resolving object_aliases names

Correct.

> 
>   vi) lower case is normally use for standard and default pathnames to
>       object alias files, but if you alter the default pathnames you
>       will get what ever case you specify

Correct.

> 
>  vii) silently ignoring standard and default pathnames that aren't
>       lower case

Correct.

> 
> viii) lack of useful error messages when object alias resolution fails
> 

Correct.

> 
> 
> ok now what is broken and needs fixing and what is not broke but
> could be improved and what is not broke at all.
> 
> broken
>  i) multiple loading is a defect -- i dislike the solution implemented
>     in this change notice moving object alias loading into the
>     GT::Conf::load method. preferring instead the semaphore fix
>     i proposed. it's simpler, it doesn't change the GT::Conf::load
> method,
>     and doesn't change the GT::Tools::resolve_object_alias that much
> either.
>     refer to "Re: [GT] SVN Commit r623 - trunk/GT" dated 08may08 for
> details.

I'll comment in a different email, but I disagree.

> 
>       the default paths being wrong 'because they are not under every
>       users control' is not a valid argument -- that path was chosen
>       specifically because it might be a controlled area. 

You got to be kidding. Requiring that you have /usr/share/geniustrader
in you file system is a non-starter. Many users might not be able to
install into that directory.

It is not necessary that every user can change the location,  but the
location must be somewhere where we can be assured it can be installed
into.