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

[GT] RE: CPANifying questions

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

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 ?

--
erik

[GT] RE: Re: RE: Script names

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

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

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.)

Th.

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.


-----Original Message-----
From: Erik Colson [mailto:ec...@ec...]
Sent: Sat 7/25/2009 9:36 AM
To: de...@ge...
Subject: [GT] Re: RE: Script names
 

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

> I am not fond in renaming these files for the following reasons:
>

good, open the discussion ;)

> 1. Let us be careful with gratuitously renaming things as this will  
> break stuff for users who have built up their own infrastructure  
> around the existing GT.

good point. We might provide a script which would create aliases for  
those people ?

> 2. Dropping the .pl extension does not allow me to specialize find  
> commands during development to just look into the scripts. It  
> happens quite often that one searches for the use of something in  
> either the *.pm or the *.pl. No extension, no specializing the  
> search. (However, that can be worked around with multiple searches  
> in specific directories.)

So, you have a workaround ;)

> 3. I see no reason for adding the gt_ or gt- prefix. That just makes  
> the name different than it was and needlessly longer.

This point is not perl related but open source related. Look at git,  
awk, gnupg or others: One script will launch sub-scripts which are  
either located in the same bin-dir (PREFIX/bin) as the main command or  
in a subdir of PREFIX/libexec.
Scripts are meant to be installed in PREFIX/bin, so people don't have  
to add directories to PATH. Also look at svn: it installs multiple  
binaries in PREFIX/bin, but all are prefixed with "svn"...

> I do not believe (3) is a CPAN standard, as there are many  
> counterexamples. Even (2), I believe is not a standard.
>
> However, there may be good reason for (2) due to the windows  
> installation procedure that was mentioned in a different mail.

Dropping .pl for scripts _is_ a 'best practices'. It is supported by  
auto-install and .ppd. Which (to me) makes this a guideline to be  
followed if there are no _very very good_ arguments to keep .pl  
extension.

--
erik

[GT] Re: Re: Script names

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

Erik Colson wrote:
> 
> On 25 Jul 2009, at 15:27, Perl Trader wrote:
> 
>> Scenario 3 (use minus sign, my favorite):
>>
>> gt-analyze-backtest
>> gt-anashell
>> gt-backtest
>> gt-backtest-many
>> gt-backtest-multi
>> gt-display-indicator
>> gt-display-signal
>> gt-display-system
>> gt-graphic
>> gt-manage-portfolio
>> gt-scan
>> gt-select-combination
> 
> ok with this, although I would add my preference:
> 
> gt command [options] args

Hey Eric, I'm so glad you said that. That's exactly what would be mine 
ultimate solution.

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

[GT] Re: RE: Script names

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

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

> I am not fond in renaming these files for the following reasons:
>

good, open the discussion ;)

> 1. Let us be careful with gratuitously renaming things as this will  
> break stuff for users who have built up their own infrastructure  
> around the existing GT.

good point. We might provide a script which would create aliases for  
those people ?

> 2. Dropping the .pl extension does not allow me to specialize find  
> commands during development to just look into the scripts. It  
> happens quite often that one searches for the use of something in  
> either the *.pm or the *.pl. No extension, no specializing the  
> search. (However, that can be worked around with multiple searches  
> in specific directories.)

So, you have a workaround ;)

> 3. I see no reason for adding the gt_ or gt- prefix. That just makes  
> the name different than it was and needlessly longer.

This point is not perl related but open source related. Look at git,  
awk, gnupg or others: One script will launch sub-scripts which are  
either located in the same bin-dir (PREFIX/bin) as the main command or  
in a subdir of PREFIX/libexec.
Scripts are meant to be installed in PREFIX/bin, so people don't have  
to add directories to PATH. Also look at svn: it installs multiple  
binaries in PREFIX/bin, but all are prefixed with "svn"...

> I do not believe (3) is a CPAN standard, as there are many  
> counterexamples. Even (2), I believe is not a standard.
>
> However, there may be good reason for (2) due to the windows  
> installation procedure that was mentioned in a different mail.

Dropping .pl for scripts _is_ a 'best practices'. It is supported by  
auto-install and .ppd. Which (to me) makes this a guideline to be  
followed if there are no _very very good_ arguments to keep .pl  
extension.

--
erik

[GT] RE: RE: CPANifying questions

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

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.


-----Original Message-----
From: Weigert, Thomas [mailto:we...@ms...]
Sent: Sat 7/25/2009 9:30 AM
To: de...@ge...; de...@ge...
Subject: [GT] RE: CPANifying questions
 
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.

Th.

-----Original Message-----
From: Erik Colson [mailto:ec...@ec...]
Sent: Sat 7/25/2009 7:38 AM
To: de...@ge...
Subject: [GT] CPANifying questions
 
Hi all,

I do have some questions about preferences with CPANifying GeniusTrader:

- The "Windows_Installer" directory

   Is this stuff up to date ? Is it still maintained ?
   This shouldn't be part of the CPAN module, but I can add it in a  
"tools" directory if this is still needed.
   Please tell me nobody cares about this and it can safely be  
removed :)

- The "website" directory

   This is a somewhat special case...
   I would like to take the examples in the examples dir, and throw  
away the rest.
   I do understand developers like to have the website in the repo,  
but it shouldn't be installed on all user systems.
   Any arguments against this ?

- The "OptimizeGT.pm" package.

   This is a weird thing: Changing module code at runtime. Is this  
still needed ?

regards
--
erik

[GT] RE: CPANifying questions

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

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.

Th.

-----Original Message-----
From: Erik Colson [mailto:ec...@ec...]
Sent: Sat 7/25/2009 7:38 AM
To: de...@ge...
Subject: [GT] CPANifying questions
 
Hi all,

I do have some questions about preferences with CPANifying GeniusTrader:

- The "Windows_Installer" directory

   Is this stuff up to date ? Is it still maintained ?
   This shouldn't be part of the CPAN module, but I can add it in a  
"tools" directory if this is still needed.
   Please tell me nobody cares about this and it can safely be  
removed :)

- The "website" directory

   This is a somewhat special case...
   I would like to take the examples in the examples dir, and throw  
away the rest.
   I do understand developers like to have the website in the repo,  
but it shouldn't be installed on all user systems.
   Any arguments against this ?

- The "OptimizeGT.pm" package.

   This is a weird thing: Changing module code at runtime. Is this  
still needed ?

regards
--
erik

[GT] Re: Script names

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

On 25 Jul 2009, at 15:27, Perl Trader wrote:

> Scenario 3 (use minus sign, my favorite):
>
> gt-analyze-backtest
> gt-anashell
> gt-backtest
> gt-backtest-many
> gt-backtest-multi
> gt-display-indicator
> gt-display-signal
> gt-display-system
> gt-graphic
> gt-manage-portfolio
> gt-scan
> gt-select-combination

ok with this, although I would add my preference:

gt command [options] args

--
erik

[GT] RE: Script names

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

I am not fond in renaming these files for the following reasons:

1. Let us be careful with gratuitously renaming things as this will break stuff for users who have built up their own infrastructure around the existing GT. 

2. Dropping the .pl extension does not allow me to specialize find commands during development to just look into the scripts. It happens quite often that one searches for the use of something in either the *.pm or the *.pl. No extension, no specializing the search. (However, that can be worked around with multiple searches in specific directories.)

3. I see no reason for adding the gt_ or gt- prefix. That just makes the name different than it was and needlessly longer. 

I do not believe (3) is a CPAN standard, as there are many counterexamples. Even (2), I believe is not a standard.

However, there may be good reason for (2) due to the windows installation procedure that was mentioned in a different mail.

Th.


-----Original Message-----
From: Perl Trader [mailto:per...@gm...]
Sent: Sat 7/25/2009 8:27 AM
To: de...@ge...
Subject: [GT] Script names
 
Here's another suggestion I'm proposing early. Please don't use this as 
an excuse to further delay the cpan porting project, this can be done at 
any time, we can vote for the change in the meantime.

While we're doing such comprehensive changes and moving files around, I 
would suggest we rename the scripts, too. For production quality Perl 
software, it's quite normal to lose that .pl part, and I would also 
suggest we tack gt- prefix at the beginning, so it's obvious they're 
part of the same package. This not only looks better, it's also useful 
for us Unix freaks that are accustomed to type gt-[TAB] and get all the 
possible completions.

Even this simple suggestion has two possible flavors, namely we could 
use "-" or "_" as delimiter. Since GT scripts already use underscore, it 
would seem appropriate to continue using it, but I personaly slightly 
prefer the other way, using "-" and switching to it completely. Instead 
of trying to explain it further with my bad english :), here are the 
examples for you to vote:


Scenario 1 (keep it as it is):

analyze_backtest.pl
anashell.pl
backtest.pl
backtest_many.pl
backtest_multi.pl
display_indicator.pl
display_signal.pl
display_system.pl
graphic.pl
manage_portfolio.pl
scan.pl
select_combination.pl


Scenario 2 (use underscore):

gt_analyze_backtest
gt_anashell
gt_backtest
gt_backtest_many
gt_backtest_multi
gt_display_indicator
gt_display_signal
gt_display_system
gt_graphic
gt_manage_portfolio
gt_scan
gt_select_combination


Scenario 3 (use minus sign, my favorite):

gt-analyze-backtest
gt-anashell
gt-backtest
gt-backtest-many
gt-backtest-multi
gt-display-indicator
gt-display-signal
gt-display-system
gt-graphic
gt-manage-portfolio
gt-scan
gt-select-combination


If we implement this change, it shows up in it's full beauty when the 
CPAN package eventually gets picked up by distribution vendors, or when 
people install CPAN packages by themself, because GT scripts are then 
nicely sorted (in /usr/bin or /usr/local/bin). IMHO, it only helps 
usability.
-- 
PerlTrader

[GT] RE: RE: Announce: CPAN porting project started

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

The CPAN branch on SVN has been created:

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

Th.


-----Original Message-----
From: Erik Colson [mailto:ec...@ec...]
Sent: Sat 7/25/2009 2:03 AM
To: de...@ge...
Subject: [GT]  RE: Announce: CPAN porting project started
 

On 25 Jul 2009, at 06:23, Weigert, Thomas wrote:

> Eric,
>
> I was going to set you up on the svn repository. But nobody ever  
> responded to my question what release of GT you wanted to start out  
> with.
>
> I encourage that you remain on the geniustrader server and not  
> create the appearance of a fork, even if it is with good intention.  
> Things tend to have a tendency to stick....
>
> Th.

Hi Thomas,

Cool ;)

As I said the repo on github should easily be committed to svn. It  
does allow me to work from different computers and also when I'm not  
online. I'm used to that workflow and as I have the ability to commit  
(or generate patches) to the svn repo that shouldn't hurt the actual  
workflow GeniusTrader has now.

So please create the branch and I'll commit there also, considering my  
github repo as a almost private workdir.

If you can give me a commit bit, I might need your help when trying  
out "git-svn dcommit", so stay close ;)

thanks
--
erik

[GT] SVN Commit r674 - branches

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

Author: thomas
Date: 2009-07-25 16:02:44 +0200 (Sat, 25 Jul 2009)
New Revision: 674

Added:
   branches/CPAN/
Log:
Creating the CPAN branch.

[GT] Re: Re: Re: Re: RE: Announce: CPAN porting project started

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

Erik Colson wrote:
> 
> On 25 Jul 2009, at 15:07, Perl Trader wrote:
> 
>> So let's give Thomas some more time to create that cpan repo we agreed 
>> upon. If it doesn't happen in a reasonable amount of time, then I'll 
>> switch to your repository and make my work there. I'd need some basic 
>> instructions on how to use git, to get me started faster. Assuming I'd 
>> have write access to the repository, otherwise I'd just continue 
>> sending patches.
> 
> of course, that's also how I want this to be. I mean the master repo is 
> still svn and this is where it has to be. I just needed that repo for 
> working on _now_ as I won't have much time left over later...

With this I wholeheartedly agree. The weekend has already started and I 
still have no tree to work upon?! :(

Of course, I want it to be THE tree, wouldn't want to lose 10 hours or 
so making intensive changes which then couldn't be applied because 
something big changed under me. Actually, such situtation would 
constitute good enough reason for me to fork yet another repository, but 
where are we then? ;)
-- 
PerlTrader

[GT] Script names

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

Here's another suggestion I'm proposing early. Please don't use this as 
an excuse to further delay the cpan porting project, this can be done at 
any time, we can vote for the change in the meantime.

While we're doing such comprehensive changes and moving files around, I 
would suggest we rename the scripts, too. For production quality Perl 
software, it's quite normal to lose that .pl part, and I would also 
suggest we tack gt- prefix at the beginning, so it's obvious they're 
part of the same package. This not only looks better, it's also useful 
for us Unix freaks that are accustomed to type gt-[TAB] and get all the 
possible completions.

Even this simple suggestion has two possible flavors, namely we could 
use "-" or "_" as delimiter. Since GT scripts already use underscore, it 
would seem appropriate to continue using it, but I personaly slightly 
prefer the other way, using "-" and switching to it completely. Instead 
of trying to explain it further with my bad english :), here are the 
examples for you to vote:


Scenario 1 (keep it as it is):

analyze_backtest.pl
anashell.pl
backtest.pl
backtest_many.pl
backtest_multi.pl
display_indicator.pl
display_signal.pl
display_system.pl
graphic.pl
manage_portfolio.pl
scan.pl
select_combination.pl


Scenario 2 (use underscore):

gt_analyze_backtest
gt_anashell
gt_backtest
gt_backtest_many
gt_backtest_multi
gt_display_indicator
gt_display_signal
gt_display_system
gt_graphic
gt_manage_portfolio
gt_scan
gt_select_combination


Scenario 3 (use minus sign, my favorite):

gt-analyze-backtest
gt-anashell
gt-backtest
gt-backtest-many
gt-backtest-multi
gt-display-indicator
gt-display-signal
gt-display-system
gt-graphic
gt-manage-portfolio
gt-scan
gt-select-combination


If we implement this change, it shows up in it's full beauty when the 
CPAN package eventually gets picked up by distribution vendors, or when 
people install CPAN packages by themself, because GT scripts are then 
nicely sorted (in /usr/bin or /usr/local/bin). IMHO, it only helps 
usability.
-- 
PerlTrader

[GT] Re: Re: CPANifying questions

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

On 25 Jul 2009, at 15:09, Weng Khong Lim wrote:

> If the one you're creating based on Module::Install can install the  
> dependencies (e.g. libxml, imagemagick, etc.) using precompiled ppd,  
> I think that'd be cool. Although I suppose we can add that to the  
> install instructions as it isn't too difficult to manually get them  
> using ActiveState's PPM. The important thing is environment is  
> properly set up (i.e. paths and the .gt/ files). Does  
> Module::Install create executable installers?

PAR generates an encapsulated .exe if you need.
Just notice that using standards as Module::Install will .bat-ify  
scripts in the script-dir. Though we need to remove the .pl extensions  
to meet standards. ( one more thing to add to the roadmap ;-) )

Also we will be able to easily generate the .ppd I think, which would  
be the best solution I can think of...

regards
--
erik

[GT] Re: Re: Re: RE: Announce: CPAN porting project started

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

On 25 Jul 2009, at 15:07, Perl Trader wrote:

> Eric, somehow I still expect Thomas to create that cpan branch on  
> the subversion repository. That was our original idea, right? I  
> believe we need expertise that longer term contributors (Robert and  
> Thomas) posses.

yep, consider my work as only related to this cpanifying so that  
leaves a lot of work to be done be experts ;)

> So let's give Thomas some more time to create that cpan repo we  
> agreed upon. If it doesn't happen in a reasonable amount of time,  
> then I'll switch to your repository and make my work there. I'd need  
> some basic instructions on how to use git, to get me started faster.  
> Assuming I'd have write access to the repository, otherwise I'd just  
> continue sending patches.

of course, that's also how I want this to be. I mean the master repo  
is still svn and this is where it has to be. I just needed that repo  
for working on _now_ as I won't have much time left over later...

--
erik

[GT] Re: CPANifying questions

[Weng K. L. <wen...@gm...>]

If the one you're creating based on Module::Install can install the
dependencies (e.g. libxml, imagemagick, etc.) using precompiled ppd, I think
that'd be cool. Although I suppose we can add that to the install
instructions as it isn't too difficult to manually get them using
ActiveState's PPM. The important thing is environment is properly set up
(i.e. paths and the .gt/ files). Does Module::Install create executable
installers?

WK

On Sat, Jul 25, 2009 at 1:57 PM, Erik Colson <ec...@ec...> wrote:

>
> On 25 Jul 2009, at 14:48, Weng Khong Lim wrote:
>
>  The Windows installer is quite out of date. It works though. So what I did
>> after running the installer is to get the modules up-to-date using svn. The
>> installer does quite a good job in setting everything up in the windows
>> environment, so I think it'll still be useful to those who want to do so.
>>
>
>
> Hi !
>
> Thanks for your advice, although as I'm basing the module on
> Module::Install you might want to take a look at this:
> http://search.cpan.org/dist/Module-Install/lib/Module/
> Install.pod#Module::Install::PAR
> and this:
> http://search.cpan.org/dist/Module-Install/lib/Module/
> Install.pod#Module::Install::Win32
>
> Both do a clean windows install with dependencies, so that might make the
> Windows_Installer unneeded ?
>
> However I've seen modules in included which are not mentioned as required
> on the website install page.
> That's what tend to happen when info is retained on multiple places...
>
> --
> erik
>

[GT] Re: Re: RE: Announce: CPAN porting project started

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

Erik Colson wrote:
> Hi Perl Trader !
> 
> On 25 Jul 2009, at 14:39, Perl Trader wrote:
> 
>> Please start with trunk, it's more up-to-date. Then you can apply the 
>> attached patch to bring most if not all of your
> 
> the github repo started with revision 673 from trunk (that's still the 
> last one now)
> 
>> goodies from the exp branch. Best of both worlds. Then you can move 
>> stuff around to prepare it for CPAN. Then I can start making the 
>> necessary namespace changes, as I promised.
> 
> directory tree and major file movements are done.
> namespace changes are done.
> 
> Your patch is a big one, I'll modify it to reflect current github repo 
> and apply it there.

Yeah, I worked many hours to get it finished, so it better be big. :)
It incorporates many changes Thomas made to the exp branch, namely 
revisions 632 - 643. I had to resolve conflicts, but it all seems just 
fine now (made two fixes later which are incorporated in the patch I 
just sent). Revisions 649 & 650 I leave to Thomas to resolve himself. I 
wasn't so sure about them, don't remember the exact reason anymore.

Eric, somehow I still expect Thomas to create that cpan branch on the 
subversion repository. That was our original idea, right? I believe we 
need expertise that longer term contributors (Robert and Thomas) posses.

So let's give Thomas some more time to create that cpan repo we agreed 
upon. If it doesn't happen in a reasonable amount of time, then I'll 
switch to your repository and make my work there. I'd need some basic 
instructions on how to use git, to get me started faster. Assuming I'd 
have write access to the repository, otherwise I'd just continue sending 
patches.

-- 
PerlTrader

[GT] Re: Re: CPANifying questions

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

On 25 Jul 2009, at 14:48, Weng Khong Lim wrote:

> The Windows installer is quite out of date. It works though. So what  
> I did after running the installer is to get the modules up-to-date  
> using svn. The installer does quite a good job in setting everything  
> up in the windows environment, so I think it'll still be useful to  
> those who want to do so.


Hi !

Thanks for your advice, although as I'm basing the module on  
Module::Install you might want to take a look at this:
http://search.cpan.org/dist/Module-Install/lib/Module/ 
Install.pod#Module::Install::PAR
and this:
http://search.cpan.org/dist/Module-Install/lib/Module/ 
Install.pod#Module::Install::Win32

Both do a clean windows install with dependencies, so that might make  
the Windows_Installer unneeded ?

However I've seen modules in included which are not mentioned as  
required on the website install page.
That's what tend to happen when info is retained on multiple places...

--
erik

[GT] Re: CPANifying questions

[Weng K. L. <wen...@gm...>]

The Windows installer is quite out of date. It works though. So what I did
after running the installer is to get the modules up-to-date using svn. The
installer does quite a good job in setting everything up in the windows
environment, so I think it'll still be useful to those who want to do so.

On Sat, Jul 25, 2009 at 1:38 PM, Erik Colson <ec...@ec...> wrote:

> Hi all,
>
> I do have some questions about preferences with CPANifying GeniusTrader:
>
> - The "Windows_Installer" directory
>
>  Is this stuff up to date ? Is it still maintained ?
>  This shouldn't be part of the CPAN module, but I can add it in a "tools"
> directory if this is still needed.
>  Please tell me nobody cares about this and it can safely be removed :)
>
> - The "website" directory
>
>  This is a somewhat special case...
>  I would like to take the examples in the examples dir, and throw away the
> rest.
>  I do understand developers like to have the website in the repo, but it
> shouldn't be installed on all user systems.
>  Any arguments against this ?
>
> - The "OptimizeGT.pm" package.
>
>  This is a weird thing: Changing module code at runtime. Is this still
> needed ?
>
> regards
> --
> erik
>

[GT] Re: RE: Announce: CPAN porting project started

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

Hi Perl Trader !

On 25 Jul 2009, at 14:39, Perl Trader wrote:

> Please start with trunk, it's more up-to-date. Then you can apply  
> the attached patch to bring most if not all of your

the github repo started with revision 673 from trunk (that's still the  
last one now)

> goodies from the exp branch. Best of both worlds. Then you can move  
> stuff around to prepare it for CPAN. Then I can start making the  
> necessary namespace changes, as I promised.

directory tree and major file movements are done.
namespace changes are done.

Your patch is a big one, I'll modify it to reflect current github repo  
and apply it there.

Please take a look at my questions on the list and tell me your idea!

Afterwards I might push a alpha release to CPAN. cpantesters will  
catch a lot of problems I oversee and sent me reports :)

Then start creating the test templates...

BTW: Github repo is still straight and "git svn dcommit" should apply  
to svn trunk easily ;)
--
erik

[GT] Re: CPANifying questions

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

Erik Colson wrote:
> Hi all,
> 
> I do have some questions about preferences with CPANifying GeniusTrader:
> 
> - The "Windows_Installer" directory
> 
>   Is this stuff up to date ? Is it still maintained ?
>   This shouldn't be part of the CPAN module, but I can add it in a 
> "tools" directory if this is still needed.
>   Please tell me nobody cares about this and it can safely be removed :)
> 
> - The "website" directory
> 
>   This is a somewhat special case...
>   I would like to take the examples in the examples dir, and throw away 
> the rest.
>   I do understand developers like to have the website in the repo, but 
> it shouldn't be installed on all user systems.
>   Any arguments against this ?
> 
> - The "OptimizeGT.pm" package.
> 
>   This is a weird thing: Changing module code at runtime. Is this still 
> needed ?
> 

I'm with you on all accounts. Let's get rid of cruft and concentrate on 
the core issues. If it's reasonable, any specific utility can later be 
added in contrib/, tools/ or such. Let's make the core as simple as 
possible.

-- 
PerlTrader

[GT] Re: RE: Announce: CPAN porting project started

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

Weigert, Thomas wrote:
> Eric,
> 
> I was going to set you up on the svn repository. But nobody ever responded to my question what release of GT you wanted to start out with.
> 

Please start with trunk, it's more up-to-date. Then you can apply the 
attached patch to bring most if not all of your goodies from the exp 
branch. Best of both worlds. Then you can move stuff around to prepare 
it for CPAN. Then I can start making the necessary namespace changes, as 
I promised.

-- 
PerlTrader

[GT] CPANifying questions

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

Hi all,

I do have some questions about preferences with CPANifying GeniusTrader:

- The "Windows_Installer" directory

   Is this stuff up to date ? Is it still maintained ?
   This shouldn't be part of the CPAN module, but I can add it in a  
"tools" directory if this is still needed.
   Please tell me nobody cares about this and it can safely be  
removed :)

- The "website" directory

   This is a somewhat special case...
   I would like to take the examples in the examples dir, and throw  
away the rest.
   I do understand developers like to have the website in the repo,  
but it shouldn't be installed on all user systems.
   Any arguments against this ?

- The "OptimizeGT.pm" package.

   This is a weird thing: Changing module code at runtime. Is this  
still needed ?

regards
--
erik

[GT] RE: Announce: CPAN porting project started

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

On 25 Jul 2009, at 06:23, Weigert, Thomas wrote:

> I was going to set you up on the svn repository. But nobody ever  
> responded to my question what release of GT you wanted to start out  
> with.

Thomas,

you probably overlooked my prior post then ;) :

 >Thomas,
 >
 >Could you create the 'cpan' branch based on trunk ?

--
erik

[GT] RE: Announce: CPAN porting project started

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

On 25 Jul 2009, at 06:23, Weigert, Thomas wrote:

> Eric,
>
> I was going to set you up on the svn repository. But nobody ever  
> responded to my question what release of GT you wanted to start out  
> with.
>
> I encourage that you remain on the geniustrader server and not  
> create the appearance of a fork, even if it is with good intention.  
> Things tend to have a tendency to stick....
>
> Th.

Hi Thomas,

Cool ;)

As I said the repo on github should easily be committed to svn. It  
does allow me to work from different computers and also when I'm not  
online. I'm used to that workflow and as I have the ability to commit  
(or generate patches) to the svn repo that shouldn't hurt the actual  
workflow GeniusTrader has now.

So please create the branch and I'll commit there also, considering my  
github repo as a almost private workdir.

If you can give me a commit bit, I might need your help when trying  
out "git-svn dcommit", so stay close ;)

thanks
--
erik

[GT] RE: Announce: CPAN porting project started

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

Eric,

I was going to set you up on the svn repository. But nobody ever responded to my question what release of GT you wanted to start out with.

I encourage that you remain on the geniustrader server and not create the appearance of a fork, even if it is with good intention. Things tend to have a tendency to stick....

Th.


-----Original Message-----
From: Erik Colson [mailto:ec...@ec...]
Sent: Fri 7/24/2009 11:33 AM
To: de...@ge...
Subject: [GT] Announce: CPAN porting project started
 
Hi all,

I'm currently working on a cpan release of GeniusTrader  
(Finance::GeniusTrader). The reasons I have for this were already  
posted/discussed here, so I won't recap them.

As I do have some time for this _now_ (and couldn't handle svk nor svn  
in a snapshot :/) I temporarily forked to project to github here: http://github.com/ecocode/GeniusTrader-CPAN/tree/master

This is temporary. I needed a repo to work on and hopefully for others  
to join / test stuff. I hope the work will hit trunk on the svn repo  
once it is done (that's not my decision). git-svn should allow me to  
either sent a (big) patch or to commit the git history to svn repo  
directly ( I never tried that however ).

I started the fork from svn/trunk revision 673. I'll try to  
incorporate new trunk revisions on the CPAN fork. Please do understand  
that I won't allow other patches if they are not related to the  
CPANifying of the project. So don't submit those patches to me, but  
instead sent your patches on the mailing list for inclusion in the svn  
trunc or exp branches. If you want to join the CPANifying project,  
please tell me urgently. As I said, I do have some free time now but  
that will not last forever and therefor any help will be appreciated.

I'm sorry if this might come over as an intrusion in the GeniusTrader  
project. This is by no means my intention. I don't want to take over  
the GeniusTrader project; it is the result of intensive work of cool  
developers who happen to have good financial knowledge also and I am  
very grateful for this.

regards
--
erik