geniustrader-devel — participate in geniustrader development, ask for help, suggest improvements, etc

[GT] SVN Commit r675 - in branches/CPAN: . lib lib/Finance t

[GeniusTrader S. <ra...@ge...>]

Author: thomas
Date: 2009-07-26 01:51:05 +0200 (Sun, 26 Jul 2009)
New Revision: 675

Added:
   branches/CPAN/.svnignore
   branches/CPAN/Changes
   branches/CPAN/MANIFEST
   branches/CPAN/Makefile.PL
   branches/CPAN/README
   branches/CPAN/lib/
   branches/CPAN/lib/Finance/
   branches/CPAN/lib/Finance/GeniusTrader.pm
   branches/CPAN/t/
   branches/CPAN/t/00-load.t
   branches/CPAN/t/boilerplate.t
   branches/CPAN/t/pod-coverage.t
   branches/CPAN/t/pod.t
Log:
Add default module files

Added: branches/CPAN/.svnignore
===================================================================
--- branches/CPAN/.svnignore	                        (rev 0)
+++ branches/CPAN/.svnignore	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,10 @@
+blib*
+Makefile
+Makefile.old
+Build
+_build*
+pm_to_blib*
+*.tar.gz
+.lwpcookies
+Finance-GeniusTrader-*
+cover_db


Property changes on: branches/CPAN/.svnignore
___________________________________________________________________
Added: svn:executable
   + *

Added: branches/CPAN/Changes
===================================================================
--- branches/CPAN/Changes	                        (rev 0)
+++ branches/CPAN/Changes	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,5 @@
+Revision history for Finance-GeniusTrader
+
+0.01    Date/time
+        First version, released on an unsuspecting world.
+


Property changes on: branches/CPAN/Changes
___________________________________________________________________
Added: svn:executable
   + *

Added: branches/CPAN/MANIFEST
===================================================================
--- branches/CPAN/MANIFEST	                        (rev 0)
+++ branches/CPAN/MANIFEST	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,8 @@
+Changes
+MANIFEST
+Makefile.PL
+README
+lib/Finance/GeniusTrader.pm
+t/00-load.t
+t/pod-coverage.t
+t/pod.t


Property changes on: branches/CPAN/MANIFEST
___________________________________________________________________
Added: svn:executable
   + *

Added: branches/CPAN/Makefile.PL
===================================================================
--- branches/CPAN/Makefile.PL	                        (rev 0)
+++ branches/CPAN/Makefile.PL	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,13 @@
+use inc::Module::Install;
+
+name     'Finance-GeniusTrader';
+all_from 'lib/Finance/GeniusTrader.pm';
+author   'Erik Colson <ec...@ec...>';
+license  'gpl';
+
+build_requires 'Test::More';
+
+auto_install;
+
+WriteAll;
+


Property changes on: branches/CPAN/Makefile.PL
___________________________________________________________________
Added: svn:executable
   + *

Added: branches/CPAN/README
===================================================================
--- branches/CPAN/README	                        (rev 0)
+++ branches/CPAN/README	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,51 @@
+Finance-GeniusTrader
+
+The README is used to introduce the module and provide instructions on
+how to install the module, any machine dependencies it may have (for
+example C compilers and installed libraries) and any other information
+that should be provided before the module is installed.
+
+A README file is required for CPAN modules since CPAN extracts the README
+file from a module distribution so that people browsing the archive
+can use it to get an idea of the module's uses. It is usually a good idea
+to provide version information here so that people can decide whether
+fixes for the module are worth downloading.
+
+
+INSTALLATION
+
+To install this module, run the following commands:
+
+	perl Makefile.PL
+	make
+	make test
+	make install
+
+SUPPORT AND DOCUMENTATION
+
+After installing, you can find documentation for this module with the
+perldoc command.
+
+    perldoc Finance::GeniusTrader
+
+You can also look for information at:
+
+    RT, CPAN's request tracker
+        http://rt.cpan.org/NoAuth/Bugs.html?Dist=Finance-GeniusTrader
+
+    AnnoCPAN, Annotated CPAN documentation
+        http://annocpan.org/dist/Finance-GeniusTrader
+
+    CPAN Ratings
+        http://cpanratings.perl.org/d/Finance-GeniusTrader
+
+    Search CPAN
+        http://search.cpan.org/dist/Finance-GeniusTrader/
+
+
+COPYRIGHT AND LICENCE
+
+Copyright (C) 2009 Erik Colson
+
+This program is released under the following license: gpl
+


Property changes on: branches/CPAN/README
___________________________________________________________________
Added: svn:executable
   + *

Added: branches/CPAN/lib/Finance/GeniusTrader.pm
===================================================================
--- branches/CPAN/lib/Finance/GeniusTrader.pm	                        (rev 0)
+++ branches/CPAN/lib/Finance/GeniusTrader.pm	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,106 @@
+package Finance::GeniusTrader;
+
+use warnings;
+use strict;
+
+=head1 NAME
+
+Finance::GeniusTrader - The great new Finance::GeniusTrader!
+
+=head1 VERSION
+
+Version 0.01
+
+=cut
+
+our $VERSION = '0.01';
+
+
+=head1 SYNOPSIS
+
+Quick summary of what the module does.
+
+Perhaps a little code snippet.
+
+    use Finance::GeniusTrader;
+
+    my $foo = Finance::GeniusTrader->new();
+    ...
+
+=head1 EXPORT
+
+A list of functions that can be exported.  You can delete this section
+if you don't export anything, such as for a purely object-oriented module.
+
+=head1 FUNCTIONS
+
+=head2 function1
+
+=cut
+
+sub function1 {
+}
+
+=head2 function2
+
+=cut
+
+sub function2 {
+}
+
+=head1 AUTHOR
+
+Erik Colson, C<< <eco at ecocode.net> >>
+
+=head1 BUGS
+
+Please report any bugs or feature requests to C<bug-finance-geniustrader at rt.cpan.org>, or through
+the web interface at L<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Finance-GeniusTrader>.  I will be notified, and then you'll
+automatically be notified of progress on your bug as I make changes.
+
+
+
+
+=head1 SUPPORT
+
+You can find documentation for this module with the perldoc command.
+
+    perldoc Finance::GeniusTrader
+
+
+You can also look for information at:
+
+=over 4
+
+=item * RT: CPAN's request tracker
+
+L<http://rt.cpan.org/NoAuth/Bugs.html?Dist=Finance-GeniusTrader>
+
+=item * AnnoCPAN: Annotated CPAN documentation
+
+L<http://annocpan.org/dist/Finance-GeniusTrader>
+
+=item * CPAN Ratings
+
+L<http://cpanratings.perl.org/d/Finance-GeniusTrader>
+
+=item * Search CPAN
+
+L<http://search.cpan.org/dist/Finance-GeniusTrader/>
+
+=back
+
+
+=head1 ACKNOWLEDGEMENTS
+
+
+=head1 COPYRIGHT & LICENSE
+
+Copyright 2009 Erik Colson, all rights reserved.
+
+This program is released under the following license: gpl
+
+
+=cut
+
+1; # End of Finance::GeniusTrader


Property changes on: branches/CPAN/lib/Finance/GeniusTrader.pm
___________________________________________________________________
Added: svn:executable
   + *

Added: branches/CPAN/t/00-load.t
===================================================================
--- branches/CPAN/t/00-load.t	                        (rev 0)
+++ branches/CPAN/t/00-load.t	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,9 @@
+#!perl -T
+
+use Test::More tests => 1;
+
+BEGIN {
+	use_ok( 'Finance::GeniusTrader' );
+}
+
+diag( "Testing Finance::GeniusTrader $Finance::GeniusTrader::VERSION, Perl $], $^X" );


Property changes on: branches/CPAN/t/00-load.t
___________________________________________________________________
Added: svn:executable
   + *

Added: branches/CPAN/t/boilerplate.t
===================================================================
--- branches/CPAN/t/boilerplate.t	                        (rev 0)
+++ branches/CPAN/t/boilerplate.t	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,55 @@
+#!perl -T
+
+use strict;
+use warnings;
+use Test::More tests => 3;
+
+sub not_in_file_ok {
+    my ($filename, %regex) = @_;
+    open( my $fh, '<', $filename )
+        or die "couldn't open $filename for reading: $!";
+
+    my %violated;
+
+    while (my $line = <$fh>) {
+        while (my ($desc, $regex) = each %regex) {
+            if ($line =~ $regex) {
+                push @{$violated{$desc}||=[]}, $.;
+            }
+        }
+    }
+
+    if (%violated) {
+        fail("$filename contains boilerplate text");
+        diag "$_ appears on lines @{$violated{$_}}" for keys %violated;
+    } else {
+        pass("$filename contains no boilerplate text");
+    }
+}
+
+sub module_boilerplate_ok {
+    my ($module) = @_;
+    not_in_file_ok($module =>
+        'the great new $MODULENAME'   => qr/ - The great new /,
+        'boilerplate description'     => qr/Quick summary of what the module/,
+        'stub function definition'    => qr/function[12]/,
+    );
+}
+
+TODO: {
+  local $TODO = "Need to replace the boilerplate text";
+
+  not_in_file_ok(README =>
+    "The README is used..."       => qr/The README is used/,
+    "'version information here'"  => qr/to provide version information/,
+  );
+
+  not_in_file_ok(Changes =>
+    "placeholder date/time"       => qr(Date/time)
+  );
+
+  module_boilerplate_ok('lib/Finance/GeniusTrader.pm');
+
+
+}
+


Property changes on: branches/CPAN/t/boilerplate.t
___________________________________________________________________
Added: svn:executable
   + *

Added: branches/CPAN/t/pod-coverage.t
===================================================================
--- branches/CPAN/t/pod-coverage.t	                        (rev 0)
+++ branches/CPAN/t/pod-coverage.t	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,18 @@
+use strict;
+use warnings;
+use Test::More;
+
+# Ensure a recent version of Test::Pod::Coverage
+my $min_tpc = 1.08;
+eval "use Test::Pod::Coverage $min_tpc";
+plan skip_all => "Test::Pod::Coverage $min_tpc required for testing POD coverage"
+    if $@;
+
+# Test::Pod::Coverage doesn't require a minimum Pod::Coverage version,
+# but older versions don't recognize some common documentation styles
+my $min_pc = 0.18;
+eval "use Pod::Coverage $min_pc";
+plan skip_all => "Pod::Coverage $min_pc required for testing POD coverage"
+    if $@;
+
+all_pod_coverage_ok();


Property changes on: branches/CPAN/t/pod-coverage.t
___________________________________________________________________
Added: svn:executable
   + *

Added: branches/CPAN/t/pod.t
===================================================================
--- branches/CPAN/t/pod.t	                        (rev 0)
+++ branches/CPAN/t/pod.t	2009-07-25 23:51:05 UTC (rev 675)
@@ -0,0 +1,12 @@
+#!perl -T
+
+use strict;
+use warnings;
+use Test::More;
+
+# Ensure a recent version of Test::Pod
+my $min_tp = 1.22;
+eval "use Test::Pod $min_tp";
+plan skip_all => "Test::Pod $min_tp required for testing POD" if $@;
+
+all_pod_files_ok();


Property changes on: branches/CPAN/t/pod.t
___________________________________________________________________
Added: svn:executable
   + *

[GT] Re: RE: Re: RE: svn CPAN branch

[Erik C. <ec...@ec...>]

On 25 Jul 2009, at 22:05, Weigert, Thomas wrote:

> Not sure what you are doing wrong, but there is no authentication  
> required on this branch. Did you type
>
> svn <command>  https://devel.geniustrader.org:8082/svn/branches/CPAN
>
> You need to access via the url.

Hi Thomas,

I've tried this:

svn co https://devel.geniustrader.org:8082/svn/branches/CPAN

then apply changes
then svn diff ---> shows the diff correctly
and svn status ---> correct

then svn ci

This is output :

================================================

mini:CPAN ec$ svn status
A      t
A      t/boilerplate.t
A      t/pod.t
A      t/pod-coverage.t
A      t/00-load.t
A      lib
A      lib/Finance
A      lib/Finance/GeniusTrader.pm
A      MANIFEST
A      Makefile.PL
A      .svnignore
A      Changes
A      README
mini:CPAN ec$ svn ci
Authentication realm: <https://devel.geniustrader.org:8082>  
GeniusTrader Subversion Repository
Password for 'ec':
Authentication realm: <https://devel.geniustrader.org:8082>  
GeniusTrader Subversion Repository
Username:
Password for '':
Authentication realm: <https://devel.geniustrader.org:8082>  
GeniusTrader Subversion Repository
Username:
Password for '':
svn: Commit failed (details follow):
svn: MKACTIVITY of '/svn/!svn/act/ 
ac508eb7-8e6f-0410-99c8-96780f153f9b': authorization failed (https://devel.geniustrader.org:8082 
)
svn: Your commit message was left in a temporary file:
svn:    '/private/tmp/CPAN/svn-commit.tmp'

==================================================

if I use
   svn ci https://devel.geniustrader.org:8082/svn/branches/CPAN
I get this

svn: 'https://devel.geniustrader.org:8082/svn/branches' is not a  
working copy
svn: Can't open file 'https://devel.geniustrader.org:8082/svn/branches/.svn/entries' 
: No such file or directory

==================================================

Where am I wrong ?
--
erik

[GT] RE: Re: RE: svn CPAN branch

[Weigert, T. <we...@ms...>]

Not sure what you are doing wrong, but there is no authentication required on this branch. Did you type

svn <command>  https://devel.geniustrader.org:8082/svn/branches/CPAN

You need to access via the url.

Th.


-----Original Message-----
From: Erik Colson [mailto:ec...@ec...]
Sent: Sat 7/25/2009 3:01 PM
To: de...@ge...
Subject: [GT] Re: RE: svn CPAN branch
 

On 25 Jul 2009, at 17:32, Weigert, Thomas wrote:

> I think anybody can commit there. Did you try?

tried and got this:
authorization failed: Could not authenticate to server: rejected Basic  
challenge

missing something ?
--
erik

[GT] Re: RE: svn CPAN branch

[Erik C. <ec...@ec...>]

On 25 Jul 2009, at 17:32, Weigert, Thomas wrote:

> I think anybody can commit there. Did you try?

tried and got this:
authorization failed: Could not authenticate to server: rejected Basic  
challenge

missing something ?
--
erik

[GT] Re: Re: RE: Re: Re: RE: Re: Re: Script names

[Nicholas K. <nku...@gm...>]

I am in favor of the following:

* prepending "gt-" to script names, in order to avoid file name collisions
as mentioned previously, and to notate that these scripts belong to the gt
package.  This follows with OSS/dpkg/etc setup and matches other open source
projects.  Eye candy is unimportant to me.
* using "-" as delimiter.  To match other open source projects.
* creating a wrapper, such that we can do something like "gt backtest ..."
or "gt indicator I:EMA" rather than "gt-display-indicator blah blah"

I think these would be good for the CPAN integration, in order to
standardize GT to fit with other cpan packages.

-Nick

On Sat, Jul 25, 2009 at 11:11 AM, Perl Trader <per...@gm...> wrote:

> Weigert, Thomas wrote:
>
>> Interesting. My $PATH is three lines long....
>>
>>
> Good for you. :) I'm so much for simple solutions. Standardized as much as
> possible. If it's possible to fit something new in the existing framework,
> it always a good idea to me.
>
> Of course, there's nothing wrong with a long $PATH, it's just a matter of
> ones taste, what to allow and what not.
>
>  Also, I am not sure why you say that you have to install two repos. You
>> just do
>>
>> svn co https://devel.geniustrader.org:8082/svn/trunk
>>
>> and you get everything at once.
>>
>
> Sorry Thomas, but that is not what the official GeniusTrader website
> preaches. It suggests to pull from _two_ trees and it even provides _two_
> tar.gz archives to download for those without svn access.
>
> As a complete newbie at a time (not long ago) I did what the official page
> instructed me to do. I now know better, but...
>
> Let's do now what will be best for the new users that'll come. I'm sure we
> oldtimers will adapt to any change easily, it's the new users that I have in
> mind when I propose intrusive changes. All things we can do now to make
> their life easier when they first encounter GT will pay in the long term, I
> believe.
>
> --
> PerlTrader
>

[GT] Re: RE: Re: Re: RE: Re: Re: Script names

[Perl T. <per...@gm...>]

Weigert, Thomas wrote:
> Interesting. My $PATH is three lines long....
> 

Good for you. :) I'm so much for simple solutions. Standardized as much 
as possible. If it's possible to fit something new in the existing 
framework, it always a good idea to me.

Of course, there's nothing wrong with a long $PATH, it's just a matter 
of ones taste, what to allow and what not.

> Also, I am not sure why you say that you have to install two repos. You just do
> 
> svn co https://devel.geniustrader.org:8082/svn/trunk
> 
> and you get everything at once. 

Sorry Thomas, but that is not what the official GeniusTrader website 
preaches. It suggests to pull from _two_ trees and it even provides 
_two_ tar.gz archives to download for those without svn access.

As a complete newbie at a time (not long ago) I did what the official 
page instructed me to do. I now know better, but...

Let's do now what will be best for the new users that'll come. I'm sure 
we oldtimers will adapt to any change easily, it's the new users that I 
have in mind when I propose intrusive changes. All things we can do now 
to make their life easier when they first encounter GT will pay in the 
long term, I believe.

-- 
PerlTrader

[GT] RE: Re: Re: RE: Re: Re: Script names

[Weigert, T. <we...@ms...>]

Interesting. My $PATH is three lines long....

Also, I am not sure why you say that you have to install two repos. You just do

svn co https://devel.geniustrader.org:8082/svn/trunk

and you get everything at once. 

Th.


-----Original Message-----
From: Perl Trader [mailto:per...@gm...]
Sent: Sat 7/25/2009 10:35 AM
To: de...@ge...
Subject: [GT] Re: Re: RE: Re: Re: Script names
 


So true. GT is the first software project EVER that _forced_ me to add 
Scripts directory to my $PATH. It is of course not the only solution, 
but was the simplest when I first encountered GT, because of many 
scripts it has. So my $PATH that for years was just ~/bin:<system paths> 
is now ~/bin:~/bin/app/gt/Scripts:<system paths> and I definitely don't 
like that and looking forward to change it to what it was before.

The other nuissance that I encountered as a newbie to GT is two trees to 
pull from repo to make things work. Never before saw something like 
that. doc, contrib and other non-essential stuff in other tree or 
packaged separately - yes, but never two different repos for a basic 
functionality, that's just odd.

I'll be so happy when those two things get resolved and GT starts 
looking like numerous other software projects I have installed. That'll 
be the day. :)
-- 
PerlTrader

[GT] Re: Re: RE: Re: RE: Re: Re: Script names

[Perl T. <per...@gm...>]

Perl Trader wrote:
> Erik Colson wrote:
>> I propose to write a wrapper script called 'gt' as this is very 
>> important to me in an effort to standardize gt.
>> I propose to also add a script in contrib which will allow a user to 
>> install symlinks in a directory of his choice.
> 
> If this is more acceptable to others than my proposition, I'm all for 
> it. And would obviously drop my idea to prefix every script with gt- 
> because this solves it even better, IMHO.
> 
> Give me just few minutes to check ther isn't any major software package 
> under that simple name...

This is actually such a great example of why I voted for gt- prefix that 
I can't resist the temptation to explain it in detail.

There's a command in Debian that is able to tell in which package is 
some file, even if that package is not installed. Because I use it once 
a year, I obviously can't remember the name of the exact command. All I 
know is that it starts with apt- (that's easy to remember :)). So I type 
apt-<TAB> and get this:

# apt-
apt-cache             apt-ftparchive        apt-mark
apt-cdrom             apt-get               apt-rdepends
apt-config            apt-iselect           apt-sortpkgs
apt-extracttemplates  apt-key               apt-src
apt-file              apt-listchanges

Now it's much easier from there, I try apt-cache but it's not it, I try 
apt-file and voila, that is exactly what I looked for.

apt-file search /usr/bin/gt\$ comes empty, meaning we're free to use 
/usr/bin/gt

One reason why I find this good enough is that Debian is the largest 
distribution of software out there. So, if it's not among Debians 26000 
or so software packages, we're pretty sure it's not taken. And we should 
take it right away, if I may add. :)

To see what happens when there's a clash, check this page and the 
relevant changelog entry copied below:

https://lists.ubuntu.com/archives/ubuntu-changes-auto/2005-October/002216.html

Added /usr/bin/git and /usr/bin/cg back in, because they're no longer 
disposable. Renamed /usr/bin/git to /usr/bin/gt to avoid the name 
collision with GNU Interactive Tools. Renamed /usr/bin/cg to 
/usr/bin/cog to avoid the name collision with cgvg. Yes, the Debian 
Cogito is now incompatible with the rest of the world! Yay!

-- 
PerlTrader

[GT] Re: Re: RE: Re: RE: Re: Re: Script names

[Perl T. <per...@gm...>]

Erik Colson wrote:
> 
> On 25 Jul 2009, at 17:10, Weigert, Thomas wrote:
> 
>>
>> I think the real reason for changing the name of the scripts by 
>> prefixing with gt would be to avoid collisions with other files 
>> already in the bin directory. Of course, another way to avoid this is 
>> to install into a subdirectory of bin, such as $prefix/bin/gt/. That 
>> way, you can have the best of all worlds: command line expansion by 
>> typing /bin/gt/ and hitting tab, immediate access to scripts by 
>> putting /bin/gt into your path, no change in name.
> 
> It is unusual to add subdirs in PREFIX/bin.
> I might be wrong here, but that might be a common agreement...

You're not wrong, I believe it's against the FHS (file hierarchy 
standard) to which most if not all linux distributions adhere. Quick 
check: I have 4386 executables in /usr/bin and _not a single_ directory 
in there. Even X11R6 was forced to behave, so recently distros are 
shipping even with numerous X11 binaries right where they should be, in 
/usr/bin just like all other software.

Even if we decide to go that path, and try to force /usr/bin/gt or 
similar, distro vendors would simply ignore our attempt and put the 
binaries where they want to, which is /usr/bin in 99% of cases.

> I propose to write a wrapper script called 'gt' as this is very 
> important to me in an effort to standardize gt.
> I propose to also add a script in contrib which will allow a user to 
> install symlinks in a directory of his choice.

If this is more acceptable to others than my proposition, I'm all for 
it. And would obviously drop my idea to prefix every script with gt- 
because this solves it even better, IMHO.

Give me just few minutes to check ther isn't any major software package 
under that simple name...
-- 
PerlTrader

[GT] RE: svn CPAN branch

[Erik C. <ec...@ec...>]

On 25 Jul 2009, at 17:32, Weigert, Thomas wrote:

>
> I think anybody can commit there. Did you try?
>
> Th.

I'll try later this evening.
Please don't apply patches before I do as I have a bunch of commits  
that would probably break ;)

--
erik

[GT] Re: RE: svn CPAN branch

[Perl T. <per...@gm...>]

Weigert, Thomas wrote:
> I think anybody can commit there. Did you try? 
> 

Oh, really? Didn't know that was possible.

But, being a svn newbie, would it still be OK that I send patch which 
somebody else then applies? It's not that svn is a rocket science, but I 
would still like to contribute my time to the project, instead of 
learning to use svn properly, at this time.
-- 
PerlTrader

[GT] Re: Re: RE: Re: Re: Script names

[Perl T. <per...@gm...>]

Erik Colson wrote:
> 
> On 25 Jul 2009, at 16:51, Weigert, Thomas wrote:
> 
>> 2. Adding a prefix: The only reason cited was to use command line 
>> expansion to locate gt scripts. That does not seem a valid reason for 
>> making that change.
>>
>> 3. Creating a wrapper script gt: Certainly it does not hurt, but as 
>> you  use gt more you will find that you will use only a few scripts, 
>> or none at all, depending on how you use gt. (It is quite interesting 
>> that different users focus on different scripts for their investment 
>> analysis.) The scripts are not really all part of one large system, in 
>> that sense. Note that there is also an attempt at building a shell 
>> which a user might invoke to perform analysis (anashell); improving 
>> that might be more worthwhile than writing the wrapper script.
> 
> Thomas,
> 
> Currently, users do add the bin-path of geniustrader to their path. By 
> following cpan standard module layout, scripts are being installed to 
> PREFIX/bin and modules in site_perl directory. The PREFIX/bin dir is 
> also where users have lots of other stuff installed also. So the prefix 
> 'gt' would be great to group those commands when doing 'ls' or other stuff.
> Installing to PREFIX/bin will make the PATH setting not needed anymore, 
> which make installation a little easier to new users.
> This is why I started this CPAN work: "get more users = get more 
> developers = get more code contributions". HOW: Standard installation, 
> painless configuration, just work out of the box, widely known by CPAN 
> and perhaps articles...
> 

So true. GT is the first software project EVER that _forced_ me to add 
Scripts directory to my $PATH. It is of course not the only solution, 
but was the simplest when I first encountered GT, because of many 
scripts it has. So my $PATH that for years was just ~/bin:<system paths> 
is now ~/bin:~/bin/app/gt/Scripts:<system paths> and I definitely don't 
like that and looking forward to change it to what it was before.

The other nuissance that I encountered as a newbie to GT is two trees to 
pull from repo to make things work. Never before saw something like 
that. doc, contrib and other non-essential stuff in other tree or 
packaged separately - yes, but never two different repos for a basic 
functionality, that's just odd.

I'll be so happy when those two things get resolved and GT starts 
looking like numerous other software projects I have installed. That'll 
be the day. :)
-- 
PerlTrader

[GT] RE: svn CPAN branch

[Weigert, T. <we...@ms...>]

I think anybody can commit there. Did you try? 

Th.

-----Original Message-----
From: Erik Colson [mailto:ec...@ec...]
Sent: Sat 7/25/2009 10:30 AM
To: de...@ge...
Subject: [GT] svn CPAN branch
 

On 25 Jul 2009, at 16:03, Weigert, Thomas wrote:

> The CPAN branch on SVN has been created:
>
> https://devel.geniustrader.org:8082/svn/branches/CPAN
>
> Th.


Thomas,

Did you give me a commit bit or should I send you patches ?

--
erik

[GT] svn CPAN branch

[Erik C. <ec...@ec...>]

On 25 Jul 2009, at 16:03, Weigert, Thomas wrote:

> The CPAN branch on SVN has been created:
>
> https://devel.geniustrader.org:8082/svn/branches/CPAN
>
> Th.


Thomas,

Did you give me a commit bit or should I send you patches ?

--
erik

[GT] Re: RE: Re: RE: Re: Re: Script names

[Erik C. <ec...@ec...>]

On 25 Jul 2009, at 17:10, Weigert, Thomas wrote:

>
> I think the real reason for changing the name of the scripts by  
> prefixing with gt would be to avoid collisions with other files  
> already in the bin directory. Of course, another way to avoid this  
> is to install into a subdirectory of bin, such as $prefix/bin/gt/.  
> That way, you can have the best of all worlds: command line  
> expansion by typing /bin/gt/ and hitting tab, immediate access to  
> scripts by putting /bin/gt into your path, no change in name.

It is unusual to add subdirs in PREFIX/bin.
I might be wrong here, but that might be a common agreement...

I propose to write a wrapper script called 'gt' as this is very  
important to me in an effort to standardize gt.
I propose to also add a script in contrib which will allow a user to  
install symlinks in a directory of his choice.

I think this can make everybody happy ?

--
erik

[GT] Re: RE: Re: RE: Re: Re: Script names

[Perl T. <per...@gm...>]

Perl Trader wrote:
> Weigert, Thomas wrote:
>> All that said, it is not the biggest deal either.
> 
> True. Let's get the repo directory hierarchy right, we can always decide 
> on this one later.

"Later" being after we have other important stuff converted, namely GT:: 
-> Finance::GeniusTrader rename, but before we make the first official 
upload to the CPAN repo.

-- 
PerlTrader

[GT] Re: RE: Re: Re: Script names

[Erik C. <ec...@ec...>]

On 25 Jul 2009, at 16:51, Weigert, Thomas wrote:

> 2. Adding a prefix: The only reason cited was to use command line  
> expansion to locate gt scripts. That does not seem a valid reason  
> for making that change.
>
> 3. Creating a wrapper script gt: Certainly it does not hurt, but as  
> you  use gt more you will find that you will use only a few scripts,  
> or none at all, depending on how you use gt. (It is quite  
> interesting that different users focus on different scripts for  
> their investment analysis.) The scripts are not really all part of  
> one large system, in that sense. Note that there is also an attempt  
> at building a shell which a user might invoke to perform analysis  
> (anashell); improving that might be more worthwhile than writing the  
> wrapper script.

Thomas,

Currently, users do add the bin-path of geniustrader to their path. By  
following cpan standard module layout, scripts are being installed to  
PREFIX/bin and modules in site_perl directory. The PREFIX/bin dir is  
also where users have lots of other stuff installed also. So the  
prefix 'gt' would be great to group those commands when doing 'ls' or  
other stuff.
Installing to PREFIX/bin will make the PATH setting not needed  
anymore, which make installation a little easier to new users.
This is why I started this CPAN work: "get more users = get more  
developers = get more code contributions". HOW: Standard installation,  
painless configuration, just work out of the box, widely known by CPAN  
and perhaps articles...

We must keep existing users of course, but if they could already  
install GeniusTrader from svn, they probably won't be hurt too much by  
issuing "cpan Finance::GeniusTrader" to install from CPAN. And then  
calling a contrib script which would make it backwards compatible by  
using aliases etc ?

I didn't know about the shell project: it would be nice to have such a  
shell interface to gt, however I don't see this as part of the  
CPANifying work.

--
erik

[GT] Re: RE: Re: RE: Re: Re: Script names

[Perl T. <per...@gm...>]

Weigert, Thomas wrote:
> I think the real reason for changing the name of the scripts by prefixing with gt would be to avoid collisions with other files already in the bin directory. Of course, another way to avoid this is to install into a subdirectory of bin, such as $prefix/bin/gt/. That way, you can have the best of all worlds: command line expansion by typing /bin/gt/ and hitting tab, immediate access to scripts by putting /bin/gt into your path, no change in name.
> 

One of the reason, yeah. The other one being plain eye candy.

> All that said, it is not the biggest deal either.

True. Let's get the repo directory hierarchy right, we can always decide 
on this one later.

> If you insist, I would suggest to use "gt" as prefix, i.e., gtgraphics, gtscan, etc. The dash or underbar is just another key to hit...

On this one I disagree, it's ugly to me. The current binaries already 
use delimiters ("_") to make it prettier on the eye, why not continue 
with that practice?

gt_display_indicator looks much better than gtdisplay_indicator to me.
-- 
PerlTrader

[GT] RE: Re: RE: Re: Re: Script names

[Weigert, T. <we...@ms...>]

I think the real reason for changing the name of the scripts by prefixing with gt would be to avoid collisions with other files already in the bin directory. Of course, another way to avoid this is to install into a subdirectory of bin, such as $prefix/bin/gt/. That way, you can have the best of all worlds: command line expansion by typing /bin/gt/ and hitting tab, immediate access to scripts by putting /bin/gt into your path, no change in name.

All that said, it is not the biggest deal either.

If you insist, I would suggest to use "gt" as prefix, i.e., gtgraphics, gtscan, etc. The dash or underbar is just another key to hit...

Th.

-----Original Message-----
From: Perl Trader [mailto:per...@gm...]
Sent: Sat 7/25/2009 10:03 AM
To: de...@ge...
Subject: [GT] Re: RE: Re: Re: Script names
 
Weigert, Thomas wrote:
> 
> 2. Adding a prefix: The only reason cited was to use command line expansion to locate gt scripts. That does not seem a valid reason for making that change.
> 

OK, nothing to add to this, we just have different opinions and that's it.

Once again we would need more opinions on the matter to come to a better 
conclusion, but GT user base is soooo small at the moment. I'd say with 
at least 10 votes on the matter, and 7:3 majority we would surely know 
what to do, right? Now we're only 2:1 which is not nearly enough to make 
an educated decision.

[GT] Re: Re: RE: Re: RE: Script names

[Perl T. <per...@gm...>]

Erik Colson wrote:
> 
> On 25 Jul 2009, at 16:39, Weigert, Thomas wrote:
> 
>> I am ok with dropping the .pl extension. I am not in favor of the prefix.
> 
> OK
> 
>> The CPAN installer would allow you to do anything you want on 
>> installation, so if you really want to enable the prefix, add an 
>> option to the installer that adds the prefix when installing into the 
>> bin directory. (Actually, that could be used for dropping the .pl also.)
> 
> you didn't tell me your idea about having:
> - one main script calling the others
> - a script which will create aliases to make current commands work
> 
>> P.S. The svn is not a good example, as svn is invoked as "svn 
>> <command> <args>...." so nobody ever sees the awkwardly named commands.
> 
> hmmm....
> am I the only one to have these in bin ?
> /bin/svn
> /bin/svndumpfilter
> /bin/svnserve
> /bin/svnversion
> /bin/svnadmin
> /bin/svnlook
> /bin/svnsync
> 

No.

svn
svn-populate-node-origins-index
svnadmin
svnauthz-validate
svndumpfilter
svnlook
svnmucc
svnnotify
svnpath
svnserve
svnsync
svnversion
svnweb-install
svnweb-server

Although svn is not such a great example. Here's where I got my 
inspiration and what works well for me (with a little help of 
completion, of course):

dpkg
dpkg-architecture
dpkg-buildpackage
dpkg-checkbuilddeps
dpkg-deb
dpkg-depcheck
dpkg-distaddfile
dpkg-divert
dpkg-genbuilddeps
dpkg-genchanges
dpkg-gencontrol
dpkg-gensymbols
dpkg-name
dpkg-parsechangelog
dpkg-query
dpkg-repack
dpkg-scanpackages
dpkg-scansources
dpkg-shlibdeps
dpkg-source
dpkg-split
dpkg-statoverride
dpkg-trigger
dpkg-vendor

apt
apt-cache
apt-cdrom
apt-config
apt-extracttemplates
apt-file
apt-ftparchive
apt-get
apt-key
apt-listchanges
apt-mark
apt-rdepends
apt-sortpkgs
apt-src

bluetooth-agent
bluetooth-analyzer
bluetooth-applet
bluetooth-browse
bluetooth-properties
bluetooth-sendto
bluetooth-wizard

db4.7_archive
db4.7_checkpoint
db4.7_codegen
db4.7_deadlock
db4.7_dump
db4.7_hotbackup
db4.7_load
db4.7_printlog
db4.7_recover
db4.7_stat
db4.7_upgrade
db4.7_verify

dbus-binding-tool
dbus-cleanup-sockets
dbus-daemon
dbus-launch
dbus-monitor
dbus-send
dbus-uuidgen

dh_auto_build
dh_auto_clean
dh_auto_configure
dh_auto_install
dh_auto_test
dh_bugfiles
dh_builddeb
dh_clean
dh_compress
dh_desktop
dh_fixperms
dh_gconf
dh_gencontrol
dh_gstscancodecs
dh_gtkmodules
dh_icons
dh_install
dh_installcatalogs
dh_installchangelogs
dh_installcron
dh_installdeb
dh_installdebconf
dh_installdefoma
dh_installdirs
dh_installdocs
dh_installemacsen
dh_installexamples
dh_installifupdown
dh_installinfo
dh_installinit
dh_installlogcheck
dh_installlogrotate
dh_installman
dh_installmanpages
dh_installmenu
dh_installmime
dh_installmodules
dh_installpam
dh_installppp
dh_installtex
dh_installudev
dh_installwm
dh_installxfonts
dh_installxmlcatalogs
dh_link
dh_lintian
dh_listpackages
dh_make
dh_makeshlibs
dh_md5sums
dh_movefiles
dh_pangomodules
dh_perl
dh_pidgin
dh_prep
dh_pycentral
dh_pysupport
dh_python
dh_quilt_patch
dh_quilt_unpatch
dh_scrollkeeper
dh_shlibdeps
dh_strip
dh_suidregister
dh_testdir
dh_testroot
dh_testversion
dh_undocumented
dh_upx
dh_usrlocal

expect
expect_autoexpect
expect_autopasswd
expect_cryptdir
expect_decryptdir
expect_dislocate
expect_ftp-rfc
expect_kibitz
expect_lpunlock
expect_mkpasswd
expect_multixterm
expect_passmass
expect_rftp
expect_rlogin-cwd
expect_timed-read
expect_timed-run
expect_tknewsbiff
expect_tkpasswd
expect_unbuffer
expect_weather
expect_xkibitz
expect_xpstat

foomatic-combo-xml
foomatic-compiledb
foomatic-configure
foomatic-datafile
foomatic-perl-data
foomatic-ppd-options
foomatic-ppd-to-xml
foomatic-ppdfile
foomatic-printjob
foomatic-rip
foomatic-searchprinter

And this list goes on... sorry for spam. :)

-- 
PerlTrader

[GT] Re: RE: Re: RE: Script names

[Erik C. <ec...@ec...>]

On 25 Jul 2009, at 16:39, Weigert, Thomas wrote:

> I am ok with dropping the .pl extension. I am not in favor of the  
> prefix.

OK

> The CPAN installer would allow you to do anything you want on  
> installation, so if you really want to enable the prefix, add an  
> option to the installer that adds the prefix when installing into  
> the bin directory. (Actually, that could be used for dropping  
> the .pl also.)

you didn't tell me your idea about having:
- one main script calling the others
- a script which will create aliases to make current commands work

> P.S. The svn is not a good example, as svn is invoked as "svn  
> <command> <args>...." so nobody ever sees the awkwardly named  
> commands.

hmmm....
am I the only one to have these in bin ?
/bin/svn
/bin/svndumpfilter
/bin/svnserve
/bin/svnversion
/bin/svnadmin
/bin/svnlook
/bin/svnsync

--
erik

[GT] Re: RE: Re: Re: Script names

[Perl T. <per...@gm...>]

Weigert, Thomas wrote:
> Let me summarize again....
> 
> 1. If dropping the .pl is a big deal, go ahead.
> 
> 2. Adding a prefix: The only reason cited was to use command line expansion to locate gt scripts. That does not seem a valid reason for making that change.
> 
> 3. Creating a wrapper script gt: Certainly it does not hurt, but as you  use gt more you will find that you will use only a few scripts, or none at all, depending on how you use gt. (It is quite interesting that different users focus on different scripts for their investment analysis.) The scripts are not really all part of one large system, in that sense. Note that there is also an attempt at building a shell which a user might invoke to perform analysis (anashell); improving that might be more worthwhile than writing the wrapper script.
> 

OK, nothing to add to this, we just have different opinions and that's it.

Once again we would need more opinions on the matter to come to a better 
conclusion, but GT user base is soooo small at the moment. I'd say with 
at least 10 votes on the matter, and 7:3 majority we would surely know 
what to do, right? Now we're only 2:1 which is not nearly enough to make 
an educated decision.
-- 
PerlTrader

[GT] Re: RE: CPANifying questions

[Perl T. <per...@gm...>]

Erik Colson wrote:
> 
> On 25 Jul 2009, at 16:30, Weigert, Thomas wrote:
> 
>> I suggest to not delete anything. There are a number of items that we 
>> are less than useful (partial scripts, incomplete packages, partial 
>> documentation). Still we keep them around as it may come in handy.
>> For example, how do we know that there is not somebody using the 
>> OptimizeGT.pm package (this package supposedly increases runtime 
>> performance by manipulating the loaded code). I did not try it, but 
>> maybe somebody relies on it?
>>
>> Let's focus on the porting process. Rationalization and cleanup can 
>> come later based on community consensus.
> 
> I'm not 100% behind this, but I can understand your point.
> Just keep in mind that OptimizeGT.pm won't work without root access and 
> will be left broken by me (Some dir changes etc will be needed). This 
> will also be the case for Windows_Installer.
> 
> It might be a good idea to let those stuff 'broken' just to figure out 
> if anybody wants to use them ?
> 

I'm definitely on the same track with you Eric, and on all accounts 
(renaming binaries and this issue).

OptimizeGT.pm is a dirty hack. As all such, it has it's usage in 
specific situations. But that typically means putting it somewhere out 
of the way of the new users, in some contrib/ or similar directory. 
Meaning, it's there for advanced users to play with it, but it is not 
officialy supported.

-- 
PerlTrader

[GT] Re: RE: RE: CPANifying questions

[Erik C. <ec...@ec...>]

On 25 Jul 2009, at 16:32, Weigert, Thomas wrote:

> One more thing...
>
> Using CPAN install there is a difference between what is in the  
> build directory and what actually gets installed. Clearly you don't  
> want to install the web site, or the windows installer, but there is  
> no reason to not have it in the build directory.
>
> Th.


agree

--
erik

[GT] RE: Re: Re: Script names

[Weigert, T. <we...@ms...>]

Let me summarize again....

1. If dropping the .pl is a big deal, go ahead.

2. Adding a prefix: The only reason cited was to use command line expansion to locate gt scripts. That does not seem a valid reason for making that change.

3. Creating a wrapper script gt: Certainly it does not hurt, but as you  use gt more you will find that you will use only a few scripts, or none at all, depending on how you use gt. (It is quite interesting that different users focus on different scripts for their investment analysis.) The scripts are not really all part of one large system, in that sense. Note that there is also an attempt at building a shell which a user might invoke to perform analysis (anashell); improving that might be more worthwhile than writing the wrapper script.

Th.


-----Original Message-----
From: Perl Trader [mailto:per...@gm...]
Sent: Sat 7/25/2009 9:42 AM
To: de...@ge...
Subject: [GT] Re: Re: Script names
 

I just though simple renaming would be much easier to do at this point 
and still streamline things effectively. But having only one binary to 
call would be even better, of course. The problem I see with that 
approach is that current scripts are so different in nature and 
arguments they accept. So it would be lots of work to accomplish that 
goal in acceptable manner. Not that I wouldn't like to see it done, 
eventually. ;)

It's just my opinion that now that we're ready to make big changes by 
cpanifying GT, changing namespace and heavily moving things around, we 
should actually look at the broader picture. In such picture renaming 
scripts is one small additional effort to make things easier for a 
complete newbie. I understand that won't be well accepted among people 
that have lots of stuff built around the current GT, but we already 
heavily broke any perl script they might have that uses GT:: namespace. 
Also we agreed that we'll keep trunk as it is, for anybody who's not 
willing to adopt many changes we plan in the near future. So everybody 
can choose what fits him best.

My strong opinion is that if we're EVER to rename the scripts, NOW is 
the (only) good moment. Because as soon as we get the packages on the 
CPAN, and some distribution picks our work, the user base could easily 
multiply and THEN it would be unwise to make such intrusive changes like 
mass renames. Then our hands would be tied.

So, I won't push hard for this, but I just wanted to share my thoughts 
on the matter more clearly. This is actually the answer to your reply, 
Thomas. In simple words, it is "now or never". :)
-- 
PerlTrader