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

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

Ras,

To come back to the question as to how to obtain the alias definitions
for object alias resolution... 

I understand that you do not agree with the changes to how the
definitions for object aliases are obtained for the shared aliases. I
do, however, not yet understand the reasons for your objection. 

If I were to understand the cause for your concern, it would be easier
to define a good solution.

> -----Original Message-----
> From: Robert A. Schmied [mailto:ras
AT
acm.org]
> Sent: Thursday, May 08, 2008 2:26 AM
> To: devel
AT
geniustrader.org
> Subject: Re: [GT] SVN Commit r623 - trunk/GT
> 
> 
> the improvements to object_aliases all discussed above are
appropriate,
> i just don't think the implemented change is the best approach from a
> systems point of view.
> my objections are
> 
> 1) a significant operational change to GT::Conf::load
>    moving the object alias file loading into GT::Conf::load
>    is the objection. GT::Conf::load never did that in the past,
>    that is a big change especially considering GT::Conf::load
>    is was designed from the start to load only the users options
>    file.

Of course you realize that a phrase "was not designed to do X" is
somewhat misplaced with a system where there are so many things that
seem to have grown almost randomly.

Admittedly the doc says that conf.pm "manages personal configuration",
but it is not clear whether that means that it cannot manage other
configuration.

> 
>    i see the logic in having GT::Conf::load also load the object
>    alias files but i don't like it much; primarily because it forces
>    alias file loading when the files exist, even when not needed.

I believe that there is no problem with loading the shared alias files
at startup, as
i. the performance impact is minimal
ii. there is no visible impact on the user as these loaded aliases are
used only when needed and if needed they behave exactly as before (i.e.,
they override a user defined alias).

> 
>    we agree, before the change the files didn't load unless an
>    object alias was detected ...

This is correct, but from a user point of view I think the change is
only an improvement. The small hit of loading the alias files is
dominated by the loading of the market file at startup. Loading that
information at startup is much preferable to loading it during analysis
time, as could be the case with the old scheme, depending on where the
alias is used.  

> 
> 2) your concern about "Avoid repeated loading of object aliases."
>    again, we agree on this point. but i think there is a far simpler
>    solution more fully shown below that yields the exact same result
>    (e.g. encounter an object alias, load the object alias files (one
> time only)).
> 

If it is really important, we can use the semaphore solution.
Personally, I think that loading the aliases when all the other aliases
are loaded is simpler and easier to understand and motivate. But if that
is a big concern for you, I'll put the semaphore scheme in.

However, I am strongly opposed to a hardwired path
/usr/share/geniustrader for the shared aliases. If you don't want this
to be set in the options file, I am ok with a default path that is in
the installation directory, as we know that this directory will exist. I
am also willing to implement a system wide conf file where this and
other common configuration items could go. 

We could ship GT with such a conf file and avoid the new user problems
arising from not having the options file correctly. The user options
file would override information in the common options file.