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

[GT] Porting to CPAN ?

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

On 21 Jul 2009, at 01:24, Perl Trader wrote:

>>
>> Of course it would be better to put geniustrader under Finance::GT,  
>> but that's just a dream right now :)
>
> Technically, I don't think that would be as difficult as you might  
> think. I have some experience in factoring work like that, so I  
> think it could be done in a day or two (adequate amounts of beer &  
> pizza preordered, household folks relocated to safe place :)). But  
> obviously, that would be only part of the whole job. OTOH, if  
> everybody finds some piece of the work and take care of that part,  
> we could do it all together. For example, you could be our guide,  
> telling us what needs to be done in order to get accepted for  
> inclusion in CPAN. I've never applied any module there, so don't  
> know the rules.


I'd be happy to help in this job, and even take it on me... Please  
everybody, I don't want to push things in this direction (I have some  
kind of viable workaround with Alien::GeniusTrader), but if developers  
are wanting this, I'll be glad to put my energy in this.

Here comes a list of tasks involved :
- merge GT and Scripts to one repo
- and modify the directory tree as I mentioned in another post.
- Change the namespace of all modules according to CPAN standards.  
That would probably be Finance::GT.
- Check modules for good practices (well, this can be done afterwards)
- configure standard tests (pod-coverage, critic, kwalitee etc)
- write a test template

(This list is just some kind of ideal situation to reach; I'm  
definitely open to discussion about this)

1 to 3 are very big changes. And that would probably make a major  
release update ;)
That won't happen in 2 days I think :)

BTW you might want to take a look at this: http://ecocode.net/files/fq/fq-testreport.html
This is a report regenerated once a day for all tests of  
Finance::Quote on the master branch. Very handy !

When I receive a patch, my first task is to create a branch and write  
a test (or ask for a test to the submitter). Then I apply the patch  
locally. If it brakes another (existing) test, I check the code or  
just report it to the submitter, which then corrects the code. Once  
tests pass and no other tests fail, I merge the branch into master.
This is nothing I invented; It is widely used for even huge projects.  
The maintainers task is to guide developers when they submit patches,  
not to write the code himself ( although he probably does ;) ).
Limiting the maintainer job in this way will improve the project  
development as commits will have more chances to reach trunk!
And of course, I don't handle all patches immediately. And that's  
where Cpan's RT tool comes in handy. It gives me an up to date list of  
untreated patches :) look here: http://rt.cpan.org/Public/Dist/Display.html?Name=Finance-Quote

--
erik

[GT] Re: Help needed with getting beancounter to work on Windows

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

Ah... yes. The lack of bash is probably why it doesn't run. I tried using
winbash and some other windows bash port but it just doesn't support the
requisite comments. Tough luck then. Thanks anyway. Beancounter itself seems
to run fine. And having looked at setup_beancounter, it mostly just creates
database tables. I could probably reimplement it in another language that
runs on my machine.

Regards,
Weng Khong


On Sun, Jul 19, 2009 at 7:20 AM, Robert A. Schmied <ra...@ac...> wrote:

> Weng Khong Lim wrote:
>
>> Hi all,
>> After seeing the discussions on beancounter, I've decided to try an
>> install
>> it. Using the ActiveState Perl Package Manager, I installed beancounter
>> 0.8.4 and intend to run it with sqlite3 as its database. While beancounter
>> seems to run properly, I can't get setup_beancounter to run. The error
>> message is "No Perl script found in input". Has anyone come across this
>> problem before?
>>
>> Regards,
>> Weng Khong
>>
>>
>
> aloha weng
>
> 0.8.4 seems a bit old, but more importantly setup_beancounter is a
> /bin/bash
> script -- does windows support that?
>
> if it does and the error message is giving valid useful info,
> setup_beancounter
> does execute beancounter after setting up the database. make sure that the
> location
> you have for perl is the same one at the top of the file 'beancounter'.
>
> assuming you have a windows that supports /bin/bash you might consider
> using
> these four lines to launch perl scripts. it seems to be a portable scheme.
> add them verbatim on the first four lines of the beancounter file.
> #!/bin/bash -- # perl, to stop looping
> # the following must be on two lines
> eval 'exec perl -S $0 ${1+"$@"}'
> if 0;
>
>
> good luck
>
> ras
>

[GT] Re: Geniustrader community development changes

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

Hi all,

Would it be worth it to come up with an issue-tracking tool like Bugzilla to
help in the reporting and tracking of bugs? Or would it be overkill?

Regards,
Weng Khong

On Tue, Jul 21, 2009 at 12:48 AM, Thomas Weigert <we...@ms...> wrote:

> Erik,
>
> I do not see any problems with changing the directory layout if that
> makes sense. As you know, svn allows you to impose any repository
> structure that fits your process. I also have often wondered why the
> trunk is arranged as is.
>
> All that said, if we change as you say below, every file in scripts has
> to be updated, in that we need to replace the directory in the use lib
> clause to use lib '../lib'. Maybe that can be avoided?
>
> But if you are already messing with the directory structure, why not
> also rename "Scripts" to "bin"?
>
> Th.
>
> Erik Colson wrote:
> >
> >>     • Having more test cases would be a great thing. Probably the
> >> biggest item here is to put the infrastructure in place to perform
> >> these tests and create some examples. If anybody could tackle that,
> >> this would be phantastic. If we can benefit from emulating how
> >> testing is done on CPAN, let's do it.
> >
> > I can help with this. Would it be a big pain to adopt following
> > directory structure ?
> >
> > trunk
> >    |--- lib --- GT
> >    |--- Scripts
> >    |--- t
> >
> > I know, currently Scripts and GT are separated repos, but still asking
> > myself why and this is probably a good time to ask ;) Think that
> > Scripts might fail tests due to a change in GT. This can be checked by
> > running script tests against a specific version of GT, but this won't
> > help since there are no version releases of GT anymore...
> >
> > The structure above is usual on CPAN and having GT below lib makes the
> > prove tool behave correctly without specific options.
> >
> >
>

[GT] Re: Geniustrader community development changes

[Thomas W. <we...@ms...>]

Erik,

I do not see any problems with changing the directory layout if that
makes sense. As you know, svn allows you to impose any repository
structure that fits your process. I also have often wondered why the
trunk is arranged as is.

All that said, if we change as you say below, every file in scripts has
to be updated, in that we need to replace the directory in the use lib
clause to use lib '../lib'. Maybe that can be avoided?

But if you are already messing with the directory structure, why not
also rename "Scripts" to "bin"?

Th.

Erik Colson wrote:
>
>>     • Having more test cases would be a great thing. Probably the
>> biggest item here is to put the infrastructure in place to perform
>> these tests and create some examples. If anybody could tackle that,
>> this would be phantastic. If we can benefit from emulating how
>> testing is done on CPAN, let's do it.
>
> I can help with this. Would it be a big pain to adopt following
> directory structure ?
>
> trunk
>    |--- lib --- GT
>    |--- Scripts
>    |--- t
>
> I know, currently Scripts and GT are separated repos, but still asking
> myself why and this is probably a good time to ask ;) Think that
> Scripts might fail tests due to a change in GT. This can be checked by
> running script tests against a specific version of GT, but this won't
> help since there are no version releases of GT anymore...
>
> The structure above is usual on CPAN and having GT below lib makes the
> prove tool behave correctly without specific options.
>
>

[GT] Re: Re: Geniustrader community development changes

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

Erik Colson wrote:
> 
> On 21 Jul 2009, at 01:05, Thomas Weigert wrote:
> 
>> Dear all,
>>
>> thanks for all the great discussion and ideas that were floated 
>> recently. As a long-term user and also developer of a small part of 
>> the functionality of GT I'd like to make the following comments:
>>
> 
> this is most welcome :)
> 
>>     • Having more test cases would be a great thing. Probably the 
>> biggest item here is to put the infrastructure in place to perform 
>> these tests and create some examples. If anybody could tackle that, 
>> this would be phantastic. If we can benefit from emulating how testing 
>> is done on CPAN, let's do it.
> 
> I can help with this. Would it be a big pain to adopt following 
> directory structure ?
> 
> trunk
>    |--- lib --- GT
>    |--- Scripts
>    |--- t
> 
> I know, currently Scripts and GT are separated repos, but still asking 
> myself why and this is probably a good time to ask ;) Think that Scripts 
> might fail tests due to a change in GT. This can be checked by running 
> script tests against a specific version of GT, but this won't help since 
> there are no version releases of GT anymore...

I would be soooo happy if this was implemented. Having to work with two 
separate trees (GT/Scripts) is really painful for me, and the layout 
you're proposing would greatly improve my working environment.

Thank you for that suggestion, and thank you Thomas for a great summary 
of last few days' conversation on the list.
-- 
PerlTrader

[GT] Re: Geniustrader community development changes

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

On 21 Jul 2009, at 01:05, Thomas Weigert wrote:

> Dear all,
>
> thanks for all the great discussion and ideas that were floated  
> recently. As a long-term user and also developer of a small part of  
> the functionality of GT I'd like to make the following comments:
>

this is most welcome :)

> 	• Having more test cases would be a great thing. Probably the  
> biggest item here is to put the infrastructure in place to perform  
> these tests and create some examples. If anybody could tackle that,  
> this would be phantastic. If we can benefit from emulating how  
> testing is done on CPAN, let's do it.

I can help with this. Would it be a big pain to adopt following  
directory structure ?

trunk
    |--- lib --- GT
    |--- Scripts
    |--- t

I know, currently Scripts and GT are separated repos, but still asking  
myself why and this is probably a good time to ask ;) Think that  
Scripts might fail tests due to a change in GT. This can be checked by  
running script tests against a specific version of GT, but this won't  
help since there are no version releases of GT anymore...

The structure above is usual on CPAN and having GT below lib makes the  
prove tool behave correctly without specific options.

> 	• Migrating GT to CPAN. Again this would be a great enhancement in  
> usability, as there would be many improvements coming with this  
> migration, such as test infrastructure, configuration enhancement,  
> dependency documentation and analysis, installation improvement. For  
> sure this would grow the community.

right !

> 	• Transition to another version control system. I am not in favor  
> of migrating to git. Those who have been developing know how to use  
> svn and there really is nothing broken with svn. Yes, there are  
> advantages of a distributed repository, but I think the benefit is  
> minor and does not warrant the upheaval.

well, I definitely won't start a war about this ;)

> 	• Increased community involvement in committing changes. My  
> experience in other community driven projects is that there is a  
> benefit in separating a stable trunk from the bleeding edge.  
> Therefore, I propose that we continue with the style of RAS  
> protecting the stable trunk. Let's have an experimental branch where  
> people can freely check in as long as it meets the community  
> standards. (By the way, that was the original intention of the exp  
> branch.)

good to me. In my idea, tests are the answer to the problem of taking  
commits from bleed to trunk.

> 	• Basic design principles. It would be good if the community  
> process were governed by basic principles that we all ascribe to, so  
> that there won't be bickering about additions that people make.
> I greatly welcome the greater involvement in the development of GT.  
> GT is a great tool which those of us who have been around have  
> adopted to various different uses. Hopefully many others will be  
> able to do so as well and benefit from its capabilities and  
> consequentially contribute to its further improvement.

I wouldn't have said that better ;)

--
erik

[GT] Re: Re: Re: Re: comment and continuation lines in gt files ...

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

Erik Colson wrote:
> 
> On 20 Jul 2009, at 20:58, Perl Trader wrote:
> 
>> to make. It would probably be quite rude if someone of us would take 
>> it and put on the CPAN without their explicit permission.
> 
> I partly disagree here. I mean, if the creators did publish geniustrader 
> as open source, they are probably willing to extend user base as much as 
> possible, possibly motivating new developers to join etc... So this 
> should go in the correct direction, isn't it ? (However I wouldn't do it 
> without any support of anybody and especially if the creators would 
> disagree)

In a way, you're right. GT being open source, under GPL license, every 
user of GT has the right to download it, use and change it to his will, 
and distribute it further, as long as he passes all those rights 
unharmed (three basic GPL freedoms). So, technically looking, putting 
the source on the CPAN is covered with licence. But I still think it 
would be more than polite to ask the original maintainers about their 
thoughts on that before any real action.

But, as I'm not inclined to push for CPAN at this time, I'll stop here 
and let others decide should the effort be spent in that direction.

> As I'm the current maintainer of Finance::Quote and Finance::QuoteDB on 
> cpan, I'd like to offer easy geniustrader installation to current users. 
> I really don't enjoy having to specify GT's path in scripts etc, and for 
> this, I'm not the only one.
> So I figured another solution: I registered the Alien::GeniusTrader 
> namespace and am planning to make this module install the latest version 
> of trunk automatically and would also add the GT dir to @INC so that 
> there would be no need to specify it anymore.
> 
> hey, that might solve the #!/usr/bin/perl problem also :)

That is a nice idea. Wish you luck!

> Of course it would be better to put geniustrader under Finance::GT, but 
> that's just a dream right now :)

Technically, I don't think that would be as difficult as you might 
think. I have some experience in factoring work like that, so I think it 
could be done in a day or two (adequate amounts of beer & pizza 
preordered, household folks relocated to safe place :)). But obviously, 
that would be only part of the whole job. OTOH, if everybody finds some 
piece of the work and take care of that part, we could do it all 
together. For example, you could be our guide, telling us what needs to 
be done in order to get accepted for inclusion in CPAN. I've never 
applied any module there, so don't know the rules.

And you're right that additional developers would be good for the 
project, couldn't agree more.

-- 
PerlTrader

[GT] Geniustrader community development changes

[Thomas W. <we...@ms...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dear all,<br>
<br>
thanks for all the great discussion and ideas that were floated
recently. As a long-term user and also developer of a small part of the
functionality of GT I'd like to make the following comments:<br>
<br>
<ol>
  <li><u>Having more test cases</u> would be a great thing. Probably
the biggest item here is to put the infrastructure in place to perform
these tests and create some examples. If anybody could tackle that,
this would be phantastic. If we can benefit from emulating how testing
is done on CPAN, let's do it.</li>
  <li><u>Migrating GT to CPAN</u>. Again this would be a great
enhancement in usability, as there would be many improvements coming
with this migration, such as test infrastructure, configuration
enhancement, dependency documentation and analysis, installation
improvement. For sure this would grow the community.</li>
  <li>Transition to another version control system. <u>I am not in
favor of migrating to git</u>. Those who have been developing know how
to use svn and there really is nothing broken with svn. Yes, there are
advantages of a distributed repository, but I think the benefit is
minor and does not warrant the upheaval.</li>
  <li>I<u>ncreased community involvement in committing changes</u>. My
experience in other community driven projects is that there is a
benefit in separating a stable trunk from the bleeding edge. Therefore,
I propose that we continue with the style of RAS protecting the stable
trunk. Let's have an experimental branch where people can freely check
in as long as it meets the community standards. (By the way, that was
the original intention of the exp branch.)</li>
  <li><u>Basic design principles</u>. It would be good if the community
process were governed by basic principles that we all ascribe to, so
that there won't be bickering about additions that people make.</li>
</ol>
I greatly welcome the greater involvement in the development of GT. GT
is a great tool which those of us who have been around have adopted to
various different uses. Hopefully many others will be able to do so as
well and benefit from its capabilities and consequentially contribute
to its further improvement.<br>
<br>
Best regards, Th.<br>
</body>
</html>

[GT] Re: Re: Re: comment and continuation lines in gt files ...

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

On 20 Jul 2009, at 20:58, Perl Trader wrote:

> to make. It would probably be quite rude if someone of us would take  
> it and put on the CPAN without their explicit permission.

I partly disagree here. I mean, if the creators did publish  
geniustrader as open source, they are probably willing to extend user  
base as much as possible, possibly motivating new developers to join  
etc... So this should go in the correct direction, isn't it ? (However  
I wouldn't do it without any support of anybody and especially if the  
creators would disagree)

As I'm the current maintainer of Finance::Quote and Finance::QuoteDB  
on cpan, I'd like to offer easy geniustrader installation to current  
users. I really don't enjoy having to specify GT's path in scripts  
etc, and for this, I'm not the only one.
So I figured another solution: I registered the Alien::GeniusTrader  
namespace and am planning to make this module install the latest  
version of trunk automatically and would also add the GT dir to @INC  
so that there would be no need to specify it anymore.

hey, that might solve the #!/usr/bin/perl problem also :)

Of course it would be better to put geniustrader under Finance::GT,  
but that's just a dream right now :)

best
--
erik

[GT] Re: Re: Re: comment and continuation lines in gt files ...

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

hi ras,

On 20 Jul 2009, at 14:25, Robert A. Schmied wrote:

> i investestigated that (very superfically) when you mentioned it a
> while back. there's nothing (very little) save the fact that gt is
> written in perl, that adheres to cpan standards. it looked to me
> to require a lot of work just to get the code base standard compliant.
> and that doesn't even include the need for a test methodology. is
> that a fair assessment?
>

the biggest issue would be the name space. probably it should be moved  
from GT:: to Finance::GT::

> i'd be willing to assist, but i'm not the codes owner, just a user
> and custodian. seems to me a commitment to move from the current
> source location to another is only something that can be made by
> the owner.
>

putting geniustrader on cpan is by no way related to moving the  
source. But if you ask for it I'd definitely be interested if the  
source moved to a git repository instead of svn :)

> then there's the actual work. i don't see an awful lot of volunteers
> to activity assist with making change. they'd like change, but don't
> even want to individually evaluate a change and post a report about  
> it.


ras, I'm a basic user of GT. There are parts of GT I don't even need/ 
use. So I stick to trunk and try to use what is available. I never  
apply patches from the list. I'm afraid this would bring my  
installation to a weird situation in which I probably wouldn't be able  
to apply official commits from trunk.
That's a reason why I currently am not a tester of patches. And may be  
this can also be the case for others ?
I'll definitely have to change this point of view, but then: is there  
a list of available patches with a description which are currently not  
applied to trunk and for which the developer is waiting for feedback ?

regards
--
erik

[GT] Re: perl location line extract from comment and continuation lines

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

Robert A. Schmied wrote:
> 
> yes except for reasons that you are not familiar with, and are therefore
> in no position to presume it can be solved with such a simple minded 
> solution.

Fine.

> ugly agreed, but if it solves the problem portably, what's the problem?
> 

There's no spoon er... problem. ;)

> and exactly who are you to dictate where perl should be installed on
> my systems, not to mention anyone elses.

Hey, that is just my opinion, you're free to disagree. I can't dictate 
you anything, let alone where you'll put your perl, of course.

It's just that I like simple, standardized solution that work for 
everybody (or the majority). Except it's so damn hard to find good 
examples for that nowadays. :(

Let's for the moment forget how ugly that line is and concentrate on 
another pitfalls. You understand that you're opening another can of 
worms there, what if somebody doesn't have bash? What if he has it but 
it is in /usr/local/bin and he's not willing to make a symlink?

I just don't see that as a nice solution, but if it makes you happy, 
commit it, I'll cope.

> and par for many of the discussions of late, the question still remains
> unanswered:
> -- does it fail or work on your system?

No, it does not.

% cat a.pl
#!/bin/bash -- # perl, to stop looping
# the following must be on two lines
eval 'exec perl -S $0 ${1+"$@"}'
if 0;

print "x";
% ./a.pl
/bin/bash: -- # perl, to stop looping: invalid option
Usage:	/bin/bash [GNU long option] [option] ...
	/bin/bash [GNU long option] [option] script-file ...
GNU long options:
	--debug
	--debugger
	--dump-po-strings
	--dump-strings
	--help
	--init-file
	--login
	--noediting
	--noprofile
	--norc
	--posix
	--protected
	--rcfile
	--restricted
	--verbose
	--version
	--wordexp
Shell options:
	-irsD or -c command or -O shopt_option		(invocation only)
	-abefhkmnptuvxBCHP or -o option

-- 
PerlTrader

[GT] perl location line extract from comment and continuation lines

[Robert A. S. <ra...@ac...>]

Perl Trader wrote:
> Robert A. Schmied wrote:

< snip >

> 
>> then there's the darned #! perl location line -- i cannot run directly
>> from the svn repository script directory because it's not correct for
>> my platform (and no i have no interest in making my platform comply)
> 
> 
> Simple ln -s /usr/local/bin/perl /usr/bin/perl can't be that hard?

yes except for reasons that you are not familiar with, and are therefore
in no position to presume it can be solved with such a simple minded solution.

>> #!/bin/bash -- # perl, to stop looping
>> # the following must be on two lines
>> eval 'exec perl -S $0 ${1+"$@"}'
>> if 0;
> 
> 
> That's just plain ugly, IMNSHO. Maybe I'm too tough on the subject, but 
> I really think Perl should be at /usr/bin/perl and that's the end of 
> story. If it's not, at least point that location to wherever your real 
> perl installation is and problem solved.

ugly agreed, but if it solves the problem portably, what's the problem?

and exactly who are you to dictate where perl should be installed on
my systems, not to mention anyone elses.

and par for many of the discussions of late, the question still remains
unanswered:
 -- does it fail or work on your system?


ras

< snip >

[GT] Re: Re: comment and continuation lines in gt files ...

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

Erik Colson wrote:
> 
> On 20 Jul 2009, at 03:19, Robert A. Schmied wrote:
> 
>> then there's the darned #! perl location line -- i cannot run directly
>> from the svn repository script directory because it's not correct for
>> my platform (and no i have no interest in making my platform comply)
>> but i also accept that my line isn't any better, so any change should to
>> portable to (all|most|some) of the main stream platforms (maybe it 
>> already is ;-).
> 
> hmm...
> 
> I already asked (with no answer) why GT is not part of cpan...
> This is such a thing that would be automagically solved if it was.. 
> (based on Module::Install)

I saw your suggestion and gave it some though, but haven't replied, sorry.

It's my opinion that at this time GT is probably too raw and unpolished 
for inclusion in CPAN. OTOH, there just isn't enough developers to spend 
time on polishing the damn thing (and same goes for that regression 
suite mentioned a few times already). Finally, I think that is a 
decision only for the original developers Raphael & Fabien to make. It 
would probably be quite rude if someone of us would take it and put on 
the CPAN without their explicit permission.

-- 
PerlTrader

[GT] Re: trunk graphic.pl continuation and comment lines gconf files

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

Robert A. Schmied wrote:
> the attached patch for trunk graphic.pl adds my flavor of continuation
> and comment line handling for graphic configuration files.

This is really great usability improvement so fire up your svn client 
and blast away. :)

I lost my sanity trying to edit that multi-line system for Emily, but if 
I had this, eh... :)
-- 
PerlTrader

[GT] Re: [PATCH] output filename option for Scripts/graphic.pl

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

Gregory Margo wrote:
> Patch to add an output filename option to graphic.pl.
> 
> I added this code to my own version of graphic.pl a long time ago,
> but never got around to sending it in; seems like a good idea now.
> 

I like it. Let's get it in, so I can test it. :)

-- 
PerlTrader

[GT] Re: Re: comment and continuation lines in gt files ...

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

Robert A. Schmied wrote:

> well i don't consider myself (or my platform, or my coding) to be superior

C'mon, Solaris really ain't that much different from Linux. I mean, it's 
slower, more obscure and now that Oracle got it not assured to survive 
:), but think about the pain that Windows users go through. And actually 
most of them still succeed in installing GT.

> to anyone elses'. in addition, i've only got one platform and it isn't

Yeah, but I think this is not supposed to be a competition context, but 
rather a community effort. Also superiority is not measured only by 
coding skills, but also by willingness to help and experience that comes 
only with time (being active with the project). So you're actually the 
supreme being on this list, you just have to admit it to youself. :)

Not to mention repository access :), but with power comes 
responsibility, of course.

> but i also have a change consideration that others don't share --
>   a change that materially alters the api of a script is
>   something to avoid unless there's a really good reason.

Yeah, I understand that.

> then there's the darned #! perl location line -- i cannot run directly
> from the svn repository script directory because it's not correct for
> my platform (and no i have no interest in making my platform comply)

Simple ln -s /usr/local/bin/perl /usr/bin/perl can't be that hard?

I've just checked few Solaris machines around, and they ALL have 
/bin/perl & /usr/bin/perl symlinked to /usr/local/bin/perl, obviously it 
works very well.

> #!/bin/bash -- # perl, to stop looping
> # the following must be on two lines
> eval 'exec perl -S $0 ${1+"$@"}'
> if 0;

That's just plain ugly, IMNSHO. Maybe I'm too tough on the subject, but 
I really think Perl should be at /usr/bin/perl and that's the end of 
story. If it's not, at least point that location to wherever your real 
perl installation is and problem solved.

> so to bottom line this -- i have no problem committing any change
> (even one i don't necessarily agree with when)
> * there is some discussion from other users that it is a desirable
>   change
> * has been evaluated by someone other than the submitter to ensure
>   it doesn't break things -- that's the primary reason why most
>   of my changes are not committed -- no feedback from evaluators

Aha, reading that paragraph I think a have an idea where the subtle 
problem lies. So called Catch 22. :)

- people are hesitant to apply patches (that are in many cases moving 
targets) and mess they copy and make it harder to sync with repository. 
So you don't get your comments because everybody's thinking: Nah, I'll 
pull when it gets commited.

- you on the other hand won't apply it without people testing it, but 
there aren't any people testing it because it hasn't yet been commited!

Do you see my point?

Repositories are so great for breaking, you get to keep both pieces. :)

> but if browsing thru the devel archive isn't your cuppa tea then you
> might miss out of some good changes that have already been discovered,
> proposed and are waiting for evaluation and validation. sorry, but
> that's the gt devel forum operational legacy ...

It's really hard and tedious, there are over 3000 articles and user 
experience is really not that great, there's no search engine, 
attachement names are lost etc... And it's not fun, after all. If 
patches weren't applied when they were submitted (with original 
developer around to explain things), how probable is that they're gonna 
be applied now, one, two or three years later?

This discussion won't die soon, it seems, but at least we got traffic on 
the list, something good oughta come out of all that. :)
-- 
PerlTrader

[GT] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Help With My first system

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

Thomas Weigert wrote:
> Oops.... that was not the response I had hoped to elicit.....
> 
> My hope was that you (and anybody else who cares) would be participating
> in bringing the exp branch up to the latest and greatest, so that at
> some later point the keepers of the trunk would feel confident to decide
> to merge all of the exp branch back to the trunk....
> 

The exp branch is one year old, many fixes found it's way to the trunk 
in the meantime. So it's not easy anymore, it was neglected for far too 
long.

I spent many hours trying to bring trunk to exp (the other way around), 
because it's actually the easier task to do. I had to go through less 
revisions to accomplish that. The other good reason for that approach is 
that trunk is more "developmental" now, after exp was effectively 
abandoned a year ago.

If you really would like to revive exp back, IMHO the easiest way is to 
start from scratch er.. from the current trunk. Then we can proceed with 
patching. I have one good patch ready for that occassion. All your good 
work from 2008 that I've been able to weed from the exp branch.
-- 
PerlTrader

[GT] Re: [PATCH] output filename option for Scripts/graphic.pl

[Robert A. S. <ra...@ac...>]

Gregory Margo wrote:
> Patch to add an output filename option to graphic.pl.
> 
> I added this code to my own version of graphic.pl a long time ago,
> but never got around to sending it in; seems like a good idea now.
> 
> 
> 
> Index: Scripts/graphic.pl
> ===================================================================
> --- Scripts/graphic.pl	(revision 673)
> +++ Scripts/graphic.pl	(working copy)
> @@ -38,6 +38,7 @@
>  		    [ --width=200 ] [ --height=230 ] [ --logarithmic ] \
>  		    [ additional graphical elements ] \
>                      [ --file=conf ] [ --driver={GD|ImageMagick} ] \
> +                    [ --out=imagefile ] \
>  		    <code>
>  
>  Use "graphic.pl --man" to list all available options
> @@ -285,6 +286,11 @@
>  configurationfile conf. Each line in this file corresponds to a
>  command line parameter. Lines starting with # are ignored.
>  
> +=item --out=imagefile
> +
> +Send image output to specified file.
> +If not specified, output goes to stdout.
> +
>  =back
>  
>  =head2 Examples
> @@ -319,6 +325,7 @@
>  my $filename = "";
>  my $opt_driver = "";
>  my $man = 0;
> +my $out_filename = "";
>  
>  Getopt::Long::Configure("pass_through","auto_help");
>  GetOptions("file=s" => \$filename );
> @@ -345,6 +352,7 @@
>  	   "logarithmic!" => \$logarithmic, "add=s" => \@add,
>  	   "option=s" => \@options, "title=s" => \$title,
>  	   "file=s" => \$filename, "driver=s" => \$opt_driver,
> +	   "out=s" => \$out_filename,
>  	   "man!" => \$man);
>  $timeframe = GT::DateTime::name_to_timeframe($timeframe);
>  
> @@ -777,7 +785,8 @@
>  # Création du graphiqe
>  my $picture = $driver->create_picture($zone);
>  $graphic->display($driver, $picture);
> -$driver->dump($picture);
> +$driver->save_to($picture, $out_filename) if  $out_filename;
> +$driver->dump($picture)                   if !$out_filename;
>  
>  $db->disconnect;
>  
> 
> 


this change proposal is one the exceptional ones, i'm inclined
to commit it to the trunk branch, without any additional testing
on my part, and will do so unless someone objects before too long ...

test cases might include

./graphic.pl 13000 > /tmp/13000_stdout.png
./graphic.pl -out /tmp/13000_fname.png 13000
cmp /tmp/13000_stdout.png /tmp/13000_fname.png


ras

[GT] Re: comment and continuation lines in gt files ...

[Robert A. S. <ra...@ac...>]

Greg Jessup wrote:
> I'm on board with a combination of Erik and Nick. There should have a test
> base, and a couple of people should test it and signoff (hopefully on
> different platforms). As long as there is objection, commit away.
                                           ^^
                        i think you mean NO objection?

> In addition, there should be downloads available for previously stable
> versions. This would allow someone to quickly rollback, or new users coming
> in that experience a problem to try an earlier version.
> 
> my 2 cents.

i'm fine with this (the users have started to speak), but

while it's relatively easy to talk about workflow like
- start a branch
- write a test
  (which should fail) to illustrate the problem
  or
  set the TODO-flag for the new feature
- write the code to solve it
- commit commit commit
- merge into master when all available tests pass

it's a whole other thing when it comes to compliance and application.
but if you really study the wf methodology it really isn't much
different than the informal devel list based scheme gt has used ...
 - propose a change
 - discuss the change
 - implement
 - and evaluate the change
 - commit the change

from my observations, there are exceptions, but usually a change is
proposed and then nothing. even if requests are made for more info
regarding the change -- nothing. even when volunteers are sought to
evaluate the change -- nothing. few are the changes that meet each
criterion set forth without some additional discussion.

look at the above workflow, it defines a process that adds a huge
amount of brand new work, the test, to any change proposal. consider the amount
of work needed to adequately test the continuation and comment line changes
across any files read by gt code. i'm not saying it cannot be done,
i am saying given the level of constructive contribution this project has
had in the recent past i don't envision a lot of compliance with that
aspect of the process. the result, a flood of branches that shouldn't
be merged without test and probably a worse situation, repository wise,
than exists now.

don't misunderstand, i like the methodology, it mitigates the risk
by virtue of the test requirement, i just don't envision that
being complied with.

i don't have any answers, i'm just a guy trying to contribute some
time and for my part ensure the gt code base remains stable. to do
that i don't commit commit commit just because i can. i don't consider
my proposed changes different than anyone elses, so when i post one
i'm looking for positive feedback before i will commit it. additionally,
my time is no more or less valuable than anyone elses, so if you see
a posting that asks for assistance on a change or a posting that is in
an area of gt that you use regularly or have an interest in, step up
and contribute. if you evaluate a change you find in the devel archive
from years past and think it's fine or not just say so.



anyone want to propose a methodology for labels (tags?) so versions can
be easily identified and just as easily tagged.

anyone want to formulate a testing methodology and initial test set (base)?

is there widespread discontent with my basic reluctance to allow
change in a user facing api when there are ways to work around it?



ras

> 
> greg
> 
> 
> 
> On Mon, Jul 20, 2009 at 6:25 AM, Erik Colson <ec...@ec...> wrote:
> 
> 
>>On 20 Jul 2009, at 03:19, Robert A. Schmied wrote:
>>
>> then there's the darned #! perl location line -- i cannot run directly
>>
>>>from the svn repository script directory because it's not correct for
>>>my platform (and no i have no interest in making my platform comply)
>>>but i also accept that my line isn't any better, so any change should to
>>>portable to (all|most|some) of the main stream platforms (maybe it already
>>>is ;-).
>>>
>>
>>hmm...
>>
>>I already asked (with no answer) why GT is not part of cpan...
>>This is such a thing that would be automagically solved if it was.. (based
>>on Module::Install)
>>
>>regards
>>--
>>erik
>>
> 
> 

[GT] Re: Re: trunk graphic.pl continuation and comment lines gconf files

[Robert A. S. <ra...@ac...>]

Greg Jessup wrote:
> I ran the graphic.pl from the previous script, and had some issues finding
> SMA.pm
> I commented the following lines...
> #use OptimizeGT;
> #use lib $OptimizeGT::newpath;

if you aren't using those you've done the right thing. if you want to
use them (and they are not in the repository (more of a question than statement)
you'll have to dig around in the devel archive. OptimizeGT lives in
scripts (why oliver put it there, well i know why ...).

> 
> What do they do? What is OptimizeGT?

it edits on the fly the tool kit code (all the code) and makes 'optimizations'
that improves performance. (whether it does or not is open for argument, but the
process can, has, and occasional still does lead to "why didn't that change
do anything? confusion" and hard to explain errors that later cannot be reproduced).

> 
> Once that was done, I got this error.
> 
> 
> "my" variable $volume_scale masks earlier declaration in same scope on
> this line   "my $volume_scale = $q3_vol + ( 1.5 * ( $q3_vol - $q1_vol ) );"
> Its 694 in mine...probably around 684 on yours as I have some extra env
> stuff I have to throw in for my host perl env.

yep -- the my on the statement
    my $volume_scale = $q3_vol + ( 1.5 * ( $q3_vol - $q1_vol ) );
is extraneous



please note: i didn't pass those scripts to the list with the intent
that they replace the official versions, it was just an expedient means
to get the continuation and comment line change context 'out there'.

you will find these versions may these work differently than those you've
been using and are in the repository on either branch. they are hacks,
unpolished, neither vacuumed nor straightened up and not intended as anything
more an informational dump.


ras


> 
> -Greg
> 
> 
> 
> On Sun, Jul 19, 2009 at 10:23 PM, Robert A. Schmied <ra...@ac...> wrote:
> 
> 
>>the attached patch for trunk graphic.pl adds my flavor of continuation
>>and comment line handling for graphic configuration files.
>>
>>but when applied, graphic.pl fails a trivial regression test
>>
>>./graphic.pl --timeframe=week --start=2007-07-18 --end=2009-07-18 IBM >
>>/tmp/IBM.png
>>
>>where it seems to ignore the time frame setting.
>>
>>it probably fails without the patch, but now that it's applied ...
>>
>>i don't know if it's just something else missing in my trunk gt
>>repository or something else missing from graphic.pl, or something
>>else altogether. i don't think the patch will affect or effect the
>>timeframe processing in trunk graphic.pl at all, but without second
>>and third ... opinions i don't want to commit it.
>>
>>
>>but for my money this is how ./graphic.pl with --timeframe=week should
>>work:
>>
>>./graphic.pl --timeframe=week --start=2007-21 --end=2009-21 IBM >
>>/tmp/IBM.png
>>
>>it's just a difference of opinion, that's all.
>>
>>aloha
>>
>>ras
>>
> 
> 

[GT] Re: trunk graphic.pl continuation and comment lines gconf files

[Greg J. <gr...@gr...>]

I ran the graphic.pl from the previous script, and had some issues finding
SMA.pm
I commented the following lines...
#use OptimizeGT;
#use lib $OptimizeGT::newpath;

What do they do? What is OptimizeGT?

Once that was done, I got this error.


"my" variable $volume_scale masks earlier declaration in same scope on
this line   "my $volume_scale = $q3_vol + ( 1.5 * ( $q3_vol - $q1_vol ) );"
Its 694 in mine...probably around 684 on yours as I have some extra env
stuff I have to throw in for my host perl env.

-Greg



On Sun, Jul 19, 2009 at 10:23 PM, Robert A. Schmied <ra...@ac...> wrote:

> the attached patch for trunk graphic.pl adds my flavor of continuation
> and comment line handling for graphic configuration files.
>
> but when applied, graphic.pl fails a trivial regression test
>
> ./graphic.pl --timeframe=week --start=2007-07-18 --end=2009-07-18 IBM >
> /tmp/IBM.png
>
> where it seems to ignore the time frame setting.
>
> it probably fails without the patch, but now that it's applied ...
>
> i don't know if it's just something else missing in my trunk gt
> repository or something else missing from graphic.pl, or something
> else altogether. i don't think the patch will affect or effect the
> timeframe processing in trunk graphic.pl at all, but without second
> and third ... opinions i don't want to commit it.
>
>
> but for my money this is how ./graphic.pl with --timeframe=week should
> work:
>
> ./graphic.pl --timeframe=week --start=2007-21 --end=2009-21 IBM >
> /tmp/IBM.png
>
> it's just a difference of opinion, that's all.
>
> aloha
>
> ras
>

[GT] Re: Re: comment and continuation lines in gt files ...

[Robert A. S. <ra...@ac...>]

Erik Colson wrote:
> 
> On 20 Jul 2009, at 03:19, Robert A. Schmied wrote:
> 
>> then there's the darned #! perl location line -- i cannot run directly
>> from the svn repository script directory because it's not correct for
>> my platform (and no i have no interest in making my platform comply)
>> but i also accept that my line isn't any better, so any change  should to
>> portable to (all|most|some) of the main stream platforms (maybe it  
>> already is ;-).
> 
> 
> hmm...
> 
> I already asked (with no answer) why GT is not part of cpan...
> This is such a thing that would be automagically solved if it was..  
> (based on Module::Install)
> 
> regards
> -- 
> erik
> 

aloha erik

i investestigated that (very superfically) when you mentioned it a
while back. there's nothing (very little) save the fact that gt is
written in perl, that adheres to cpan standards. it looked to me
to require a lot of work just to get the code base standard compliant.
and that doesn't even include the need for a test methodology. is
that a fair assessment?

i'd be willing to assist, but i'm not the codes owner, just a user
and custodian. seems to me a commitment to move from the current
source location to another is only something that can be made by
the owner.

then there's the actual work. i don't see an awful lot of volunteers
to activity assist with making change. they'd like change, but don't
even want to individually evaluate a change and post a report about it.

ras

[GT] Re: Re: comment and continuation lines in gt files ...

[Greg J. <gr...@gr...>]

I'm on board with a combination of Erik and Nick. There should have a test
base, and a couple of people should test it and signoff (hopefully on
different platforms). As long as there is objection, commit away.
In addition, there should be downloads available for previously stable
versions. This would allow someone to quickly rollback, or new users coming
in that experience a problem to try an earlier version.

my 2 cents.

greg



On Mon, Jul 20, 2009 at 6:25 AM, Erik Colson <ec...@ec...> wrote:

>
> On 20 Jul 2009, at 03:19, Robert A. Schmied wrote:
>
>  then there's the darned #! perl location line -- i cannot run directly
>> from the svn repository script directory because it's not correct for
>> my platform (and no i have no interest in making my platform comply)
>> but i also accept that my line isn't any better, so any change should to
>> portable to (all|most|some) of the main stream platforms (maybe it already
>> is ;-).
>>
>
> hmm...
>
> I already asked (with no answer) why GT is not part of cpan...
> This is such a thing that would be automagically solved if it was.. (based
> on Module::Install)
>
> regards
> --
> erik
>

[GT] Re: comment and continuation lines in gt files ...

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

On 20 Jul 2009, at 03:19, Robert A. Schmied wrote:

> then there's the darned #! perl location line -- i cannot run directly
> from the svn repository script directory because it's not correct for
> my platform (and no i have no interest in making my platform comply)
> but i also accept that my line isn't any better, so any change  
> should to
> portable to (all|most|some) of the main stream platforms (maybe it  
> already is ;-).

hmm...

I already asked (with no answer) why GT is not part of cpan...
This is such a thing that would be automagically solved if it was..  
(based on Module::Install)

regards
--
erik

[GT] Re: Re: comment and continuation lines in gt files ...

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

On 20 Jul 2009, at 04:13, Nicholas Kuechler wrote:

> Hi all,
>
> My opinion is that patches, updates, etc. should be committed unless  
> someone objects.  This would bring the primary branch more up to  
> date, and as others have mentioned, would include a lot of new,  
> useful patches, indicators, tools, etc.
>
> So, in my opinion, commit away!

I do agree with the "commit often" principle.
I can however agree with the principle that trunk should be ...eh...  
stable ;)
And therefor I understand Robert etc not wishing to push commits to  
trunk until they are known to work properly.
This is some kind of known vicious circle which makes an open source  
project stall or risks to be forked :(
Probably GeniusTrader reached that point now...

I think this could be solved by having a test base. This is something  
that doesn't have to be worked on for days at one time. It can be the  
result of applying following workflow:

If you find a bug:
- start a branch
- write a test (which should fail) to illustrate the problem
- write the code to solve it
- commit commit commit
- merge into master when all available tests pass

If you wish to add a new feature:
- start a branch
- write a test and set the TODO-flag for it.
- write the code
- commit commit commit
- merge into master when all available tests pass

just my 2c

--
erik