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

Re: [GT] trunk/GT/Tools.pm 2008-03-30 04:07:51 UTC (rev 594) or later

EMA
especially when they are Weigert, Thomas wrote:

Hmmm... There should be no changes at all to object aliases (unless one
wants to take out the "@", but that is just a proposed patch, and I am
not sure whether it is a good idea or not).


oops -- my mistake it wasn't a commit message but an actual patch.

like i've said i'm not able to keep up with this pace of change



What I did with the object aliases is the following:

1. Removed the hard wired locations for the various paths to a common
location and allow configuration in options file. In the existing
system, the code hardwired in /usr/share/geniustrader/aliases which is a
no-no.


i agree eliminating searching /usr/share/geniustrader/aliases is reasonable
but only if no-one is already keeping stuff there


2. These aliases are loaded everytime an object alias is evaluated.


if this is the case then it ought to be improved if possible.

This

is not necessary. A single load at conf load time is sufficient.

None of these should have a visible effect on the user (other than that
a common location should be defined in the options file, as all other
configuration for GT is).


agreed

but removing the "@" object_alias marker will require searching the %conf
hash for every object being loaded, even though most objects will not be
aliases. is that going to be efficient?



Regarding the foreach (@options)..., I think this is a really useful
feature. Basically, it allows the script to override settings in the
options file. This is no different from editing the options file and
then running the script, and then editing the option file back to how it
was. You often run into situations that you might want to run analysis
over different input directories, for example. This is a simple way to
do so. E.g., say you have data in different input formats, you can now
run gt without having to change the options file all the time.



sounds fine, but i've yet to find the usefulness you have. i simply
switch option files if that is the only way to alter the value(s),
i certainly wouldn't edit the same one twice, every time i wanted to
alter the value(s).


This code was in one of the scripts, and is now available in all... I
have been using this extensively...


my plan has been and remains to sort thru the changes at my pace and
holler if i see something i really really don't like, unless someone
else hollers first.

eventually i'll either catch up or give up trying to keep up. mean
while, other than the database connect/disconnect change, things seem
just fine.

i'm still not clear on why you think moving db discon outside each
application (script) is a good idea. but on the face of it doing more
than a single discon cycle within the same script app isn't appropriate
either.


aloha

ras



Th.

P.S. Your improvements to alias resolution are not in the repository
yet, by the way...


yes -- i don't see any hurry to commit, the users (at least those like
yours truly) need time to consider the change in the fullness of time.
besides the change might be effected/affected by my scan.pl sig-sys-desc
naming proposal which i need to get back to to consider impact on other
scripts and in context as it relates to 'gt as a system'

and you, unless you've already done so, might want to revisit WWMA and
Wilders (and SEMA and EMA) to sort out which one to keep and what name
to give it.

ras






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

AT
acm.org]

Sent: Saturday, May 03, 2008 12:21 PM
To: devel

AT
geniustrader.org

Subject: Re: [GT] trunk/GT/Tools.pm 2008-03-30 04:07:51 UTC (rev 594)
or later

i'm still unsure why you felt it necessary to clobber the object
aliases as hard as you did. but i haven't evaluated it at all yet.

and i don't know what unintended consequence(s)
foreach (@options) {
   my ($key, $value) = split (/=/, $_);
   GT::Conf::set($key, $value);
}
is going to have in the scripts