RE: [GT] usability enhancement of scan.pl and sig-sys descriptions

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

I guess we have a slightly different view of GT here... please see
comments below...

> -----Original Message-----
> From: Robert A. Schmied [mailto:ras
AT
acm.org]
> Sent: Saturday, May 03, 2008 11:48 AM
> To: devel
AT
geniustrader.org
> Subject: Re: [GT] usability enhancement of scan.pl and sig-sys
> descriptions
> the changes are happening so fast that, i for one, am unable to keep
> up.
> 
> that is a bit concerning too since there isn't a distinction between
> stable and developmental branches.

Yes, there is good and bad to an evolving system. I think it is great
that various people make contributions, but it is also difficult to keep
track and verify everything. That is the nature of open source
development.

Regarding stability, I would prefer if we had two branches, a
development branch and a stable branch, and were we would merge
periodically, say every half year, from the development branch to the
stable branch.

> 
> i'm content to hack away in my little world and toss out 'hey, look at
> this
> neat feature/fix/idea messages' from time to time. it's up to the user
> community to adopt it or not.

I operated in this mode since 2005 with the end result that there were
many changes made to the system (not all for the better I think) which
required me to spend enormous time over the last half year integrating
my stuff back together with the repository version. I do not recommend
that you go down that route.

I would prefer that GT is a system where the community contributes and
it keeps getting better rather than a system where everybody has their
own private version.

> 
> how, when and if it gets into the repository is the responsibility of
> the
> maintainers.

Who are these people?

> 
> as far as 'needing to keep the files used consistent!' posh i say. if
> one particular script reads data from a file then that script alone
can
> define the format it will accept in that file. just because the data
> in the file resembles data in other files doesn't mean the file
formats
> have to be identical.

Here is where I differ. I view GT as a system. The scripts are just
commands within the system. Having inconsistent commands in an
application is not good. We should avoid that, even if there are
considerable costs.

> 
> however, i do agree that such uniqueness is undesireable, but if it
> makes
> the end product better for the user that is the way to go.

I think that the inconsistencies which I just removed had made the
system worse for the user. 

> 
> the amount of work required to integrate, and test every change into
> every script is not trivial, scripts that aren't used, don't work, or
> have little utility are simply un-improved or left to another user who
> does it and posts the patch set.


You are definitely right about there being a different level of utility
for different scripts. It is not even clear at times why some are there.
E.g., what really is the difference between backtest_many and
backtest_multi? Some of the ash files and analysis files are also
unclear. 

I'd be fine with a strategy to deprecate some of them and officially
declare that they will not be kept up-to-date unless somebody steps up
to clean them up or at least helps to do so. But for the scripts that
are under maintenance, we have the responsibility to keep them all in
synch, I think.

Th.