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

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

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

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

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

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!

-Nick



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

> Perl Trader wrote:
>
>> Robert A. Schmied wrote:
>>
>>  it seems that only the official scan.pl has the subject features
>>>
>>> so to provide a good set of diffs will be difficult and time consuming
>>> (not something i have interest in -- everyone can find whatever i've
>>> posted on the devel archive in the past regarding the subject changes and
>>> improvements). applying them may also be challenging unless you can get
>>> into the details of patch, the diff file and maybe do some of the work
>>> manually -- expecting 'patch -i patchfile file' to work is asking for too
>>> much given the changes that may have occurred between now and then.
>>>
>>> that said however, i will endeavor committing the subject change to
>>> the main branch, but since that will take time you might want to
>>> see if other changes have any interest ...
>>>
>>> my current graphic.pl -- don't expect it to work with some manual
>>> editing on your part
>>>
>>>
>>> my current scan.pl -- don't expect it to work with some manual
>>> editing on your part
>>>
>>>
>>> my current backtest.pl -- don't expect it to work with some manual
>>> editing on your part
>>>
>>>
>>> my current backtest_many.pl -- don't expect it to work with some manual
>>> editing on your part
>>>
>>>
>>> guidance -- if you get perl messages like GT::... not found
>>> comment out the offending 'use GT::...;' line
>>>
>>> failures to locate a specific method 'calculator' or 'parse_date_str'
>>> may be difficult to work around ... see if the entire offending perl
>>> statement block can be commented.
>>>
>>> ras
>>>
>>>
>> OK, thanks. This should be little more helpful than searching for a 2 year
>> old patch.
>>
>> Although the question still remains. I'm sure you have plethora of nice
>> improvements in there, why haven't you commited them to the main tree?
>>
>
> well i don't consider myself (or my platform, or my coding) to be superior
> to anyone elses'. in addition, i've only got one platform and it isn't
> in the main stream and there isn't a reasonably well defined and
> encompassing way to do practical regression testing on changes. that alone
> would be a great improvement. need not be comprehensive, but should
> exercise,
> within reason, the scripts and the important bits of the tool kit ...
>
> then there's the way this forum has worked in the past:
>  it's always been a discussion forum:
>  post a problem, patch or whatever and discuss it,
>  maybe reach a consensus, or maybe not
>  then someone with privilege and the time formulates
>  a patch if appropriate and commits it.
>
> the exp branch is an new thing doesn't fit in the legacy model.
>
> with reference to the first paragraph, when i post a potential change
> and get no feedback, no discussion, etc i have to assume no one is
> interested
> or there are problems with the change or whatever, so i go on about my
> business
> but my local version will probably have that change, because if i take the
> trouble to formulate a posting on it i think it's good and it works for me
> ...
>
> similarly if i see a patch and start a discussion about it but get
> no feedback i may add it to my local version or not ...
>
> 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.
> the current scripts that use GT:Tools::check_dates break (no thomas will
> object
> to that characterization) alter then, the old standard user api for date
> strings on the command line (and possibly other places). now i don't like
> having to change date string to match the time frame setting but i also
> have a significant investment in work that relies on that scheme and see
> little point in changing all of it when the scripts could themselves
> deal with that (my versions of the scripts do). instead, the api was
> changed to only accept yyyy-mm-dd format and then internally reformat
> them appropriately to match the time frame. by itself that's great, but
> it breaks my existing infrastructure and i will not adopt that type of
> change when either form of date string could be accepted and made to
> work correctly.
>
> as a result many of the scripts do not align with my versions, as a
> result it's very difficult to get any sort of reasonable diff sets between
> them. the continuation and comment line is just one of a bunch, i was
> really
> surprised to see it's in exp branch but not on trunk, except for scan.pl.
> it's possible it was backed out when another change was applied, but that's
> neither here nor there.
>
> 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 ;-).
>
> i think the five lines (5th one is blank line) following this para will
> do the job, but cannot validate it without voices from users of
> many different platforms. add these lines 'verbatim' to the top of
> a script and report go/nogo and tell the list as much about your
> platform as you care to. it seems to work fine here (but that's
> to be expected right?):
> go SunOS 5.10 sun4u sparc, GNU bash version 3.00.16(1), perl v5.6.2
>
> #!/bin/bash -- # perl, to stop looping
> # the following must be on two lines
> eval 'exec perl -S $0 ${1+"$@"}'
> if 0;
>
>
> making this change would be a big improvement in my ability to validate
> that a change in my local script repository isn't defective at run time.
>
>
>> It's much easier when people who work together have a common tree to start
>> with. That's why version control systems were invented, to allow many people
>> to work on the same tree. And of course, to be able to track changes and
>> easily revert problematic ones. Now that your tree has diverged so much, I
>> understand it's a problem to extract specific changes out, but that wouldn't
>> be the case if they were commited as they were developed. Gradually.
>>
>> Don't get me wrong, I admire your work very much. It's just that
>> development model of GT is sooo confusing to me. As if I'm pushed to have my
>> own tree and get detached from the main one. But then I'll finish just like
>> you, having nice stuff in my tree which only I'll be able to use, because it
>> will be close to impossible to extract the goods separately and produce
>> clean patches that can be applied to subversion repository.
>>
>> I hope all I have written makes some sense.
>> --
>> PerlTrader
>>
>
> 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
> * has reasonable (some/any) supporting information that documents
>   - what the change is about
>   - what is changed
>   - what if any effect there is on user api, input or output
>   - how the change can be evaluated (before/after)
>
> @ i probably violate these submittal criteria more than most.
> @ hopefully these criteria are reasonably consistent with similar
>  expositions on the same topic.
>
> and if there is a proposed change posted that looks interesting and you've
> tested it and consider it good and useful, but see that it hasn't been
> committed, post a reply to that proposed change and remind the list about
> it. maybe it was overlooked, maybe i'm just waiting to hear from a tester
> ...
>
> and if i decline to commit it there are others with privilege that might
> be more flexible.
>
> 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 ...
>
> aloha
>
>
> ras
>
>

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

[Gregory M. <gm...@pa...>]

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;
 


-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregory H. Margo
gmargo at yahoo/com, gmail/com, pacbell/net; greg at margofamily/org

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

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

Perl Trader wrote:
> Robert A. Schmied wrote:
> 
>> it seems that only the official scan.pl has the subject features
>>
>> so to provide a good set of diffs will be difficult and time consuming
>> (not something i have interest in -- everyone can find whatever i've
>> posted on the devel archive in the past regarding the subject changes and
>> improvements). applying them may also be challenging unless you can get
>> into the details of patch, the diff file and maybe do some of the work
>> manually -- expecting 'patch -i patchfile file' to work is asking for too
>> much given the changes that may have occurred between now and then.
>>
>> that said however, i will endeavor committing the subject change to
>> the main branch, but since that will take time you might want to
>> see if other changes have any interest ...
>>
>> my current graphic.pl -- don't expect it to work with some manual
>> editing on your part
>>
>>
>> my current scan.pl -- don't expect it to work with some manual
>> editing on your part
>>
>>
>> my current backtest.pl -- don't expect it to work with some manual
>> editing on your part
>>
>>
>> my current backtest_many.pl -- don't expect it to work with some manual
>> editing on your part
>>
>>
>> guidance -- if you get perl messages like GT::... not found
>> comment out the offending 'use GT::...;' line
>>
>> failures to locate a specific method 'calculator' or 'parse_date_str'
>> may be difficult to work around ... see if the entire offending perl
>> statement block can be commented.
>>
>> ras
>>
> 
> OK, thanks. This should be little more helpful than searching for a 2 
> year old patch.
> 
> Although the question still remains. I'm sure you have plethora of nice 
> improvements in there, why haven't you commited them to the main tree?

well i don't consider myself (or my platform, or my coding) to be superior
to anyone elses'. in addition, i've only got one platform and it isn't
in the main stream and there isn't a reasonably well defined and
encompassing way to do practical regression testing on changes. that alone
would be a great improvement. need not be comprehensive, but should exercise,
within reason, the scripts and the important bits of the tool kit ...

then there's the way this forum has worked in the past:
  it's always been a discussion forum:
  post a problem, patch or whatever and discuss it,
  maybe reach a consensus, or maybe not
  then someone with privilege and the time formulates
  a patch if appropriate and commits it.

the exp branch is an new thing doesn't fit in the legacy model.

with reference to the first paragraph, when i post a potential change
and get no feedback, no discussion, etc i have to assume no one is interested
or there are problems with the change or whatever, so i go on about my business
but my local version will probably have that change, because if i take the
trouble to formulate a posting on it i think it's good and it works for me ...

similarly if i see a patch and start a discussion about it but get
no feedback i may add it to my local version or not ...

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.
the current scripts that use GT:Tools::check_dates break (no thomas will object
to that characterization) alter then, the old standard user api for date
strings on the command line (and possibly other places). now i don't like
having to change date string to match the time frame setting but i also
have a significant investment in work that relies on that scheme and see
little point in changing all of it when the scripts could themselves
deal with that (my versions of the scripts do). instead, the api was
changed to only accept yyyy-mm-dd format and then internally reformat
them appropriately to match the time frame. by itself that's great, but
it breaks my existing infrastructure and i will not adopt that type of
change when either form of date string could be accepted and made to
work correctly.

as a result many of the scripts do not align with my versions, as a
result it's very difficult to get any sort of reasonable diff sets between
them. the continuation and comment line is just one of a bunch, i was really
surprised to see it's in exp branch but not on trunk, except for scan.pl.
it's possible it was backed out when another change was applied, but that's
neither here nor there.

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

i think the five lines (5th one is blank line) following this para will
do the job, but cannot validate it without voices from users of
many different platforms. add these lines 'verbatim' to the top of
a script and report go/nogo and tell the list as much about your
platform as you care to. it seems to work fine here (but that's
to be expected right?):
go SunOS 5.10 sun4u sparc, GNU bash version 3.00.16(1), perl v5.6.2

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


making this change would be a big improvement in my ability to validate
that a change in my local script repository isn't defective at run time.

> 
> It's much easier when people who work together have a common tree to 
> start with. That's why version control systems were invented, to allow 
> many people to work on the same tree. And of course, to be able to track 
> changes and easily revert problematic ones. Now that your tree has 
> diverged so much, I understand it's a problem to extract specific 
> changes out, but that wouldn't be the case if they were commited as they 
> were developed. Gradually.
> 
> Don't get me wrong, I admire your work very much. It's just that 
> development model of GT is sooo confusing to me. As if I'm pushed to 
> have my own tree and get detached from the main one. But then I'll 
> finish just like you, having nice stuff in my tree which only I'll be 
> able to use, because it will be close to impossible to extract the goods 
> separately and produce clean patches that can be applied to subversion 
> repository.
> 
> I hope all I have written makes some sense.
> -- 
> PerlTrader

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
 * has reasonable (some/any) supporting information that documents
    - what the change is about
    - what is changed
    - what if any effect there is on user api, input or output
    - how the change can be evaluated (before/after)

@ i probably violate these submittal criteria more than most.
@ hopefully these criteria are reasonably consistent with similar
  expositions on the same topic.

and if there is a proposed change posted that looks interesting and you've
tested it and consider it good and useful, but see that it hasn't been
committed, post a reply to that proposed change and remind the list about
it. maybe it was overlooked, maybe i'm just waiting to hear from a tester ...

and if i decline to commit it there are others with privilege that might
be more flexible.

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

aloha


ras

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

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

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

Th.

Perl Trader wrote:
> Thomas Weigert wrote:
>> I understand your frustration.
>>
>> As background, you should know that Robert is extremely conscientious.
>> So he is very worried about changes that he makes breaking things for
>> other people. So he is very careful about committing items, which
>> sometimes has the unfortunate side effect you experience now.
>>
>> So what many users of GT have done is merge the patches from the mail
>> archive, but I realize that is almost impossible for some who come in
>> new.
>>
>> That was part of the reason why I started the exp branch. But then I got
>> side tracked with other responsibilities, and not all what I use is
>> merged into that branch. But basically the idea of the exp branch is
>> that one can merge in new features there and test them and the goal
>> would be to later bring them into the trunk. The continuation line fixes
>> should have been in the exp. If they are not, I am embarassed and
>> apologize.
>>
>
> OK, I pushed a little bit, but at least I now understand that things
> really work that way.
>
> I'll then proceed to work on my own branch, just like everybody else.
> With numerous small patches applied locally, trees will diverge quite
> fast. It's not really important at the moment, because I have no extra
> useful staff to provide. But at some point I'll contribute something
> that will attract attention of others, and it won't be easy to apply
> to the main tree. I can then send my whole tree, or big patch against
> the latest revision, I guess. And problem solved. In a way..
>
> OK, my apologies for being frustrated in the public :), but I had to
> try. I won't make comments on this topic anymore. From now on I'll
> just go with the flow.

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

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

Thomas Weigert wrote:
> I understand your frustration.
> 
> As background, you should know that Robert is extremely conscientious.
> So he is very worried about changes that he makes breaking things for
> other people. So he is very careful about committing items, which
> sometimes has the unfortunate side effect you experience now.
> 
> So what many users of GT have done is merge the patches from the mail
> archive, but I realize that is almost impossible for some who come in new.
> 
> That was part of the reason why I started the exp branch. But then I got
> side tracked with other responsibilities, and not all what I use is
> merged into that branch. But basically the idea of the exp branch is
> that one can merge in new features there and test them and the goal
> would be to later bring them into the trunk. The continuation line fixes
> should have been in the exp. If they are not, I am embarassed and apologize.
> 

OK, I pushed a little bit, but at least I now understand that things 
really work that way.

I'll then proceed to work on my own branch, just like everybody else. 
With numerous small patches applied locally, trees will diverge quite 
fast. It's not really important at the moment, because I have no extra 
useful staff to provide. But at some point I'll contribute something 
that will attract attention of others, and it won't be easy to apply to 
the main tree. I can then send my whole tree, or big patch against the 
latest revision, I guess. And problem solved. In a way..

OK, my apologies for being frustrated in the public :), but I had to 
try. I won't make comments on this topic anymore. From now on I'll just 
go with the flow.
-- 
PerlTrader

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

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

I understand your frustration.

As background, you should know that Robert is extremely conscientious.
So he is very worried about changes that he makes breaking things for
other people. So he is very careful about committing items, which
sometimes has the unfortunate side effect you experience now.

So what many users of GT have done is merge the patches from the mail
archive, but I realize that is almost impossible for some who come in new.

That was part of the reason why I started the exp branch. But then I got
side tracked with other responsibilities, and not all what I use is
merged into that branch. But basically the idea of the exp branch is
that one can merge in new features there and test them and the goal
would be to later bring them into the trunk. The continuation line fixes
should have been in the exp. If they are not, I am embarassed and apologize.

Th.

Perl Trader wrote:
> Yeah, and guess what, it works for Robert, too. But not for me. And
> not for anybody else. Because both of you are not using the official
> distribution. You've effectively forked it and have something similar,
> but not the same as everybody else.
>
>

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

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

I am having same issue as Perl Trader with the continuations. Which file do
I need to pull from the unoffical branch. Can someone just put the path up
in this thread.

thanks

greg

On Sun, Jul 19, 2009 at 5:05 PM, Perl Trader <per...@gm...> wrote:

> Thomas Weigert wrote:
>
>> Continuation lines are working on my installation... we added these long
>> time ago...
>>
>
> Yeah, and guess what, it works for Robert, too. But not for me. And not for
> anybody else. Because both of you are not using the official distribution.
> You've effectively forked it and have something similar, but not the same as
> everybody else.
>
>  Another tip when you start building systems: Rely on aliases. These
>> allow you to package up portions of a system in small chunks that you
>> reuse. Makes it much easier to understand....
>>
>
> That's the general idea, yes. That first bigger system I made for Emily was
> an exercise in masochism, as i said. :) Next one will be heavy on aliases.
>
> And if I understand correctly, because I pulled your code from exp branch,
> I'll be even able to have recursive aliases, which is a *great* addition.
> Actually, only two of us will be able to use that feature, but nobody else.
> This is hilarious... :)
>
> Actually I spent lots of time, prepared and sent the patch that would
> bridge exp to trunk and pull all good features you put there, but there's
> nobody to merge it. I've since found and fixed two small errors and can
> provide those patches, too, but they come on top of the original one.
> --
> PerlTrader
>

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

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

Thomas Weigert wrote:
> Continuation lines are working on my installation... we added these long
> time ago...

Yeah, and guess what, it works for Robert, too. But not for me. And not 
for anybody else. Because both of you are not using the official 
distribution. You've effectively forked it and have something similar, 
but not the same as everybody else.

> Another tip when you start building systems: Rely on aliases. These
> allow you to package up portions of a system in small chunks that you
> reuse. Makes it much easier to understand....

That's the general idea, yes. That first bigger system I made for Emily 
was an exercise in masochism, as i said. :) Next one will be heavy on 
aliases.

And if I understand correctly, because I pulled your code from exp 
branch, I'll be even able to have recursive aliases, which is a *great* 
addition. Actually, only two of us will be able to use that feature, but 
nobody else. This is hilarious... :)

Actually I spent lots of time, prepared and sent the patch that would 
bridge exp to trunk and pull all good features you put there, but 
there's nobody to merge it. I've since found and fixed two small errors 
and can provide those patches, too, but they come on top of the original 
one.
-- 
PerlTrader

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

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

Robert A. Schmied wrote:
> it seems that only the official scan.pl has the subject features
> 
> so to provide a good set of diffs will be difficult and time consuming
> (not something i have interest in -- everyone can find whatever i've
> posted on the devel archive in the past regarding the subject changes and
> improvements). applying them may also be challenging unless you can get
> into the details of patch, the diff file and maybe do some of the work
> manually -- expecting 'patch -i patchfile file' to work is asking for too
> much given the changes that may have occurred between now and then.
> 
> that said however, i will endeavor committing the subject change to
> the main branch, but since that will take time you might want to
> see if other changes have any interest ...
> 
> my current graphic.pl -- don't expect it to work with some manual
> editing on your part
> 
> 
> my current scan.pl -- don't expect it to work with some manual
> editing on your part
> 
> 
> my current backtest.pl -- don't expect it to work with some manual
> editing on your part
> 
> 
> my current backtest_many.pl -- don't expect it to work with some manual
> editing on your part
> 
> 
> guidance -- if you get perl messages like GT::... not found
> comment out the offending 'use GT::...;' line
> 
> failures to locate a specific method 'calculator' or 'parse_date_str'
> may be difficult to work around ... see if the entire offending perl
> statement block can be commented.
> 
> ras
> 

OK, thanks. This should be little more helpful than searching for a 2 
year old patch.

Although the question still remains. I'm sure you have plethora of nice 
improvements in there, why haven't you commited them to the main tree?

It's much easier when people who work together have a common tree to 
start with. That's why version control systems were invented, to allow 
many people to work on the same tree. And of course, to be able to track 
changes and easily revert problematic ones. Now that your tree has 
diverged so much, I understand it's a problem to extract specific 
changes out, but that wouldn't be the case if they were commited as they 
were developed. Gradually.

Don't get me wrong, I admire your work very much. It's just that 
development model of GT is sooo confusing to me. As if I'm pushed to 
have my own tree and get detached from the main one. But then I'll 
finish just like you, having nice stuff in my tree which only I'll be 
able to use, because it will be close to impossible to extract the goods 
separately and produce clean patches that can be applied to subversion 
repository.

I hope all I have written makes some sense.
-- 
PerlTrader

[GT] Re: Help With My first system

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

Erik Colson wrote:
> 
> On 19 Jul 2009, at 21:17, Perl Trader wrote:
> 
>> Thank you for demo file. Unfortunately it's not working here, I get  
>> this:
>>
>> % graphic.pl --file simple_continue.gconf 13000 >! demo.png
> 
> 
> isn't there supposed to be an '=' after --file ?

yes indeed!

but as a terrible typist i'd likely use


 % graphic.pl -f simple_continue.gconf ibm > ibm.png

just so in three or thirteen attempts to type it, i'd finally get it


> 
> -- 
> erik
> 

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

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

Continuation lines are working on my installation... we added these long
time ago...

Another tip when you start building systems: Rely on aliases. These
allow you to package up portions of a system in small chunks that you
reuse. Makes it much easier to understand....

Th.

Perl Trader wrote:
> Robert A. Schmied wrote:
>> Perl Trader wrote:
>>
>
> I think I'll write it from scratch. It should be faster and easier for
> me then go hunting for some 2 years old patch, which was never applied
> and is now probably obsolete.
>
> This doesn't make sense, you're posting examples for newbies with
> continuation lines that can't possibly work for them. Like they don't
> have enough trouble as it is.
>
> I can't possibly understand how such great (if not essential) feature
> is not yet commited, I just can't...

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

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

it seems that only the official scan.pl has the subject features

so to provide a good set of diffs will be difficult and time consuming
(not something i have interest in -- everyone can find whatever i've
posted on the devel archive in the past regarding the subject changes and
improvements). applying them may also be challenging unless you can get
into the details of patch, the diff file and maybe do some of the work
manually -- expecting 'patch -i patchfile file' to work is asking for too
much given the changes that may have occurred between now and then.

that said however, i will endeavor committing the subject change to
the main branch, but since that will take time you might want to
see if other changes have any interest ...

my current graphic.pl -- don't expect it to work with some manual
editing on your part


my current scan.pl -- don't expect it to work with some manual
editing on your part


my current backtest.pl -- don't expect it to work with some manual
editing on your part


my current backtest_many.pl -- don't expect it to work with some manual
editing on your part


guidance -- if you get perl messages like GT::... not found
comment out the offending 'use GT::...;' line

failures to locate a specific method 'calculator' or 'parse_date_str'
may be difficult to work around ... see if the entire offending perl
statement block can be commented.

ras

[GT] Re: graphics.pl works, but .png has errors.

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

Greg Jessup wrote:
> RAS...you are genius. "if ./graphic.pl is sending stderr to the file that
> will cause
> the problem"...

yea -- that's why i mentioned the stat for the png file, but you never
picked up on it and i sorta forgot about it. if you mentioned explicitly
the file had data and or had attached it the epiphany would have been
much faster

oh -- the importance of supplying (or asking) for enough information to help
those seeking help cannot be overstated


> I had added some print statements to some of the PMs and scripts a few days
> back when I was starting to get up to speed with GT. I ended up
> re-downloading everything...and Walla!!!!
> 
> Thanks Again...for the brainstorm.
> 
> 

humm -- seems to me I've done that too, but not lately ;-)

seems to me that's why i've learned to hate (too strong), dislike (better),
have cloned (better yet), graphic.pl into chart.pl that does a lot of stuff,
well, better. including not requiring the redirection of the image data, or
more specifically i think, doesn't write image data to stdout by default.

but i'm not ready to release chart.pl on the world just yet, and don't
think that sort of change adheres to the generalized policy "make no
changes to current user api".

yes. it's a bad design, but many, including me, rely on it working that
awful way. newbees just have to learn that's the way of it and maybe
build their own (or plead, beg, or buy) a wrapper for it that hides these
sharp edges so they don't cut themselves too badly ;-)

ras




<< snip >>

[GT] Re: Re: Re: Re: Re: Re: Re: graphics.pl works, but .png has errors.

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

On 19 Jul 2009, at 21:49, Greg Jessup wrote:

> RAS...you are genius. "if ./graphic.pl is sending stderr to the file  
> that will cause
> the problem"...

maybe a good reason to separate STDERR from STDOUT...
adding a --output=file option to graphic.pl would be a solution.  
Leaving default to actual behaviour if --output isn't specified would  
make it backwards compatible.

Just a thought

--
erik

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

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

On 19 Jul 2009, at 21:17, Perl Trader wrote:

> Thank you for demo file. Unfortunately it's not working here, I get  
> this:
>
> % graphic.pl --file simple_continue.gconf 13000 >! demo.png

isn't there supposed to be an '=' after --file ?

--
erik

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

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

Robert A. Schmied wrote:
> Perl Trader wrote:
>> Robert A. Schmied wrote:
>>   > yes -- i missed that aspect out completely.
>>
>>> ok it's my belief that all script apps that read sys-sig-indic 
>>> descriptions
>>> (and in case of graphic.pl graphic directives (which look a lot like 
>>> sys-sig-indic descriptions but are really what i call graphic 
>>> directives)
>>> from files now understand both continuation lines and comments lines in
>>> files of that sort. (i don't know if thomas has adopted them on the 
>>> dev branch)
>>>
>>> the script apps might include: graphic.pl, scan.pl, and maybe one or 
>>> more of the
>>> backtests.
>>>
>>> display_* don't read that info from a file so they may not be able to 
>>> handle it.
>>>
>>> so if you put your BuySellArrows graphic directive into a graphic 
>>> config file
>>> (gconf) and add continuation line chars appropriately it is easier 
>>> for us
>>> humans to read and parse and fix and change
>>>
>>> comments are introduced this the char '#', and extend to the logical 
>>> end of the
>>> line --- logical is significant, if the line is continued so is the 
>>> comment. this
>>> is good -- comment out an entire multiline directive with a single 
>>> '#' but has
>>> risks too -- don't try to comment out bits inside a multiline group
>>>
>>
>> Thank you for demo file. Unfortunately it's not working here, I get this:
>>
>> % graphic.pl --file simple_continue.gconf 13000 >! demo.png
>> Text("contination line works", \ is not a valid object description at 
>> /home/perltrader/Scripts/graphic.pl line 825.
>> Use of uninitialized value $func in pattern match (m//) at 
>> /home/perltrader/Scripts/graphic.pl line 607.
>>
>> where last line is repeated many times.
>>
>> Are you sure that you don't have a local patch applied that provide 
>> you that nice feature? I tested with virgin svn trunk revision 673, 
>> just to be on the safe side, and no, I can't use continuation.
> 
> 
> i'll look at main branch, but was my belief these changes got committed
> if they haven't that's not a good thing ... at least from my prospective
> others may have a different one.
> 
> you can find the changes in the devel archive looks like around oct 2007
> and onward

I think I'll write it from scratch. It should be faster and easier for 
me then go hunting for some 2 years old patch, which was never applied 
and is now probably obsolete.

This doesn't make sense, you're posting examples for newbies with 
continuation lines that can't possibly work for them. Like they don't 
have enough trouble as it is.

I can't possibly understand how such great (if not essential) feature is 
not yet commited, I just can't...
-- 
PerlTrader

[GT] Re: Re: Re: Re: Re: Re: Re: graphics.pl works, but .png has errors.

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

RAS...you are genius. "if ./graphic.pl is sending stderr to the file that
will cause
the problem"...
I had added some print statements to some of the PMs and scripts a few days
back when I was starting to get up to speed with GT. I ended up
re-downloading everything...and Walla!!!!

Thanks Again...for the brainstorm.


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

> Robert A. Schmied wrote:
>
>> Greg Jessup wrote:
>>
>>  do you get data from
>>>>
>>>> ./display_indicator.pl  --timeframe=week I:Prices IBM
>>>> or
>>>> ./display_indicator.pl  --timeframe=week I:Prices 13000
>>>>
>>>>
>>>
>>> Yes...output looks like this
>>> ./display_indicator.pl  --timeframe=week I:Prices IBM
>>>
>>> Prices[]            [2009-23] = 107.2400
>>> Prices[]            [2009-24] = 108.2100
>>> Prices[]            [2009-25] = 105.8900
>>> Prices[]            [2009-26] = 105.6800
>>> Prices[]            [2009-27] = 101.7300
>>> Prices[]            [2009-28] = 100.8300
>>> Prices[]            [2009-29] = 115.4200
>>>
>>> very odd indeed. 13000 is in the sample text base db, ibm not unless
>>> you've
>>>
>>>  added it.
>>>>
>>>
>>>
>>>
>>>
>>> I have toggled the sample text and beancounter to eliminate the db as a
>>> factor.
>>>
>>>
>>> please send the entire
>>>
>>>  graphic config data and command line, plus maybe your $HOME/.gt/options_
>>>>
>>>
>>>
>>>
>>>  ok so no additional data passed to graphic.pl via a file command is
>> completely:
>>
>> ./graphic.pl --timeframe=week  13000 > test.png
>> or
>> ./graphic.pl --timeframe=week  IBM > IBM.png
>>
>> neither work, but ./display_indicator.pl  --timeframe=week I:Prices IBM
>> works
>>
>> i'm a bit stumped -- given that a more complex ./graphic.pl example does
>> work
>> try the attached gconfig file with this comamnd line
>>
>> ./graphic.pl --file simple_continue.gconf --end 'yesterday' IBM >
>> /tmp/IBM.png
>>
>>
>> ras
>>
>
>
> if this fails -- i dunno -- i'd say bad browser, but that's wrong, you
> can use in for the working example.
>
> are the png files zero bytes long, or are they just corrupt png? in the
> latter case, if ./graphic.pl is sending stderr to the file that will cause
> the problem
>
> as a csh'er i'd do
> ( ./graphic.pl --timeframe=week   IBM > /tmp/IBM.png ) >& /dev/tty
> but a (b|ba|k)sh'er might use
> ./graphic.pl --timeframe=week   IBM > /tmp/IBM.png 2> /dev/tty
>
> ras
>
>
>
>>
>>
>>> DB::module bean
>>>
>>> DB::bean::dbname beancounter
>>> DB::bean::dbhost localhost
>>> DB::bean::dbport 3306
>>> DB::bean::dbuser user
>>> DB::bean::dbpasswd password
>>> DB::bean::db mysql
>>>
>>> # relying on DB::Text defaults for sample database access
>>>
>>> Brokers::module SelfTrade
>>> Path::Font::Arial /usr/share/fonts/default/TrueType/arial.ttf
>>> Path::Font::Courier /usr/share/fonts/default/TrueType/couri.ttf
>>> Path::Font::Times /usr/share/fonts/default/TrueType/times.ttf
>>>
>>> Analysis::ReferenceTimeFrame year
>>>
>>> #Graphic::BackgroundColor black
>>> #Graphic::ForegroundColor white
>>>
>>> Aliases::Global::TFS    SY:TFS 50 10|CS:SY:TFS
>>> Aliases::Global::SMA    SY:SMA 50 10|CS:SY:TFS
>>> Aliases::Global::TFS[]  SY:TFS #1 #2|CS:SY:TFS #1|CS:Stop:Fixed #3
>>> Aliases::Global::3EMA SY:Generic { @S:3EMAlong 60 90 120 } { @S:3EMAshort
>>> 60
>>> 90 120 }
>>> Aliases::Global::3EMALong SY:Generic { @S:3EMAlong 60 90 120 }
>>> Aliases::Global::3EMALong[] SY:Generic { @S:3EMAlong 60 90 120 }
>>> Aliases::Global::3EMA[] SY:Generic { @S:3EMAlong #1 #2 #3 } {
>>> @S:3EMAshort
>>> #1 #2 #3 }
>>> Aliases::Global::2SMA SY:Generic { @S:2SMAlong #1 #2 }
>>> Aliases::Global::2SMA[] SY:Generic { @S:2SMAlong #1 #2 } { @S:2SMAlong #1
>>> #2
>>> }
>>>
>>> #MACD simple
>>> Aliases::Global::MCD    \
>>> SY:Generic    \
>>> {S:G:CrossOverUp {I:MACD/3} 0}    \
>>> {S:G:CrossOverDown {I:MACD/3} 0}
>>>
>>>
>>>
>>> On Sun, Jul 19, 2009 at 2:20 PM, Robert A. Schmied <ra...@ac...> wrote:
>>>
>>>
>>>  Greg Jessup wrote:
>>>>
>>>>
>>>>  Does not seem to be a problem with timeframe. No mater what I run, I
>>>>> get
>>>>> and
>>>>> errored png file which I can not open. I ran a demo script found in
>>>>> this
>>>>> thread
>>>>> http://www.geniustrader.org/lists/devel/msg01179.html
>>>>> And it created the file fine, so I don't believe its a GD issue..but
>>>>> not
>>>>> 100% positive. Running that script leads me to believe, its installed
>>>>> ok.
>>>>>
>>>>> I am using beancounter on mysql. but have tried changing to text as
>>>>> well.
>>>>> Neither seem to work. No error form the script, just with the png.
>>>>> Any issue going from Linux to windows with the png? I am running
>>>>> graphic.pl
>>>>> on linux but viewing it with Firefox via windows. Although the i did
>>>>> the
>>>>> same with the test script mentioned above and saw the graphic just
>>>>> fine.....
>>>>> this is wierd.
>>>>>
>>>>> -Greg
>>>>>
>>>>> On Sun, Jul 19, 2009 at 1:31 PM, Robert A. Schmied <ra...@ac...>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> < snip >
>>>>
>>>> greg
>>>>
>>>> so you can create png images using something ( please send the entire
>>>> graphic config data and command line, plus maybe your $HOME/.gt/options_
>>>>
>>>> but you cannot create png images using
>>>>
>>>> ./graphic.pl --timeframe=week  13000 > test.png
>>>> or
>>>> ./graphic.pl --timeframe=week  IBM > IBM.png
>>>>
>>>> very odd indeed. 13000 is in the sample text base db, ibm not unless
>>>> you've
>>>> added it.
>>>>
>>>>
>>>> do you get data from
>>>>
>>>> ./display_indicator.pl  --timeframe=week I:Prices IBM
>>>> or
>>>> ./display_indicator.pl  --timeframe=week I:Prices 13000
>>>>
>>>>
>>>>
>>>> ras
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> #
>> # nb -- options in this file will override those on the command line
>> #
>> # graphic default: candlevol, candlevolplace, barchart, line, none
>> --type=candle
>>
>> --timeframe=day
>>
>> # by default 6 months
>> --start='27 weeks ago'
>>
>>
>> --add=Text("contination line works", \
>>  2, 50, left, center, large, blue, arial)
>>
>> #
>> # add 50 day volume moving average on the automatic volume histogram
>> #
>> --add=Switch-Zone(1)
>>
>> --add=Curve(Indicators::EMA 22 {Indicators::Prices VOLUME}, brown)
>> --add=Text("22 bar volume ema", 2, 100, left, center, small, brown, arial)
>>
>>
>
>

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

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

Perl Trader wrote:
> Robert A. Schmied wrote:
>   > yes -- i missed that aspect out completely.
> 
>> ok it's my belief that all script apps that read sys-sig-indic 
>> descriptions
>> (and in case of graphic.pl graphic directives (which look a lot like 
>> sys-sig-indic descriptions but are really what i call graphic directives)
>> from files now understand both continuation lines and comments lines in
>> files of that sort. (i don't know if thomas has adopted them on the 
>> dev branch)
>>
>> the script apps might include: graphic.pl, scan.pl, and maybe one or 
>> more of the
>> backtests.
>>
>> display_* don't read that info from a file so they may not be able to 
>> handle it.
>>
>> so if you put your BuySellArrows graphic directive into a graphic 
>> config file
>> (gconf) and add continuation line chars appropriately it is easier for us
>> humans to read and parse and fix and change
>>
>> comments are introduced this the char '#', and extend to the logical 
>> end of the
>> line --- logical is significant, if the line is continued so is the 
>> comment. this
>> is good -- comment out an entire multiline directive with a single '#' 
>> but has
>> risks too -- don't try to comment out bits inside a multiline group
>>
> 
> Thank you for demo file. Unfortunately it's not working here, I get this:
> 
> % graphic.pl --file simple_continue.gconf 13000 >! demo.png
> Text("contination line works", \ is not a valid object description at 
> /home/perltrader/Scripts/graphic.pl line 825.
> Use of uninitialized value $func in pattern match (m//) at 
> /home/perltrader/Scripts/graphic.pl line 607.
> 
> where last line is repeated many times.
> 
> Are you sure that you don't have a local patch applied that provide you 
> that nice feature? I tested with virgin svn trunk revision 673, just to 
> be on the safe side, and no, I can't use continuation.


i'll look at main branch, but was my belief these changes got committed
if they haven't that's not a good thing ... at least from my prospective
others may have a different one.

you can find the changes in the devel archive looks like around oct 2007
and onward

ras

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

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

Robert A. Schmied wrote:
  > yes -- i missed that aspect out completely.
> ok it's my belief that all script apps that read sys-sig-indic descriptions
> (and in case of graphic.pl graphic directives (which look a lot like 
> sys-sig-indic descriptions but are really what i call graphic directives)
> from files now understand both continuation lines and comments lines in
> files of that sort. (i don't know if thomas has adopted them on the dev 
> branch)
> 
> the script apps might include: graphic.pl, scan.pl, and maybe one or 
> more of the
> backtests.
> 
> display_* don't read that info from a file so they may not be able to 
> handle it.
> 
> so if you put your BuySellArrows graphic directive into a graphic config 
> file
> (gconf) and add continuation line chars appropriately it is easier for us
> humans to read and parse and fix and change
> 
> comments are introduced this the char '#', and extend to the logical end 
> of the
> line --- logical is significant, if the line is continued so is the 
> comment. this
> is good -- comment out an entire multiline directive with a single '#' 
> but has
> risks too -- don't try to comment out bits inside a multiline group
> 

Thank you for demo file. Unfortunately it's not working here, I get this:

% graphic.pl --file simple_continue.gconf 13000 >! demo.png
Text("contination line works", \ is not a valid object description at 
/home/perltrader/Scripts/graphic.pl line 825.
Use of uninitialized value $func in pattern match (m//) at 
/home/perltrader/Scripts/graphic.pl line 607.

where last line is repeated many times.

Are you sure that you don't have a local patch applied that provide you 
that nice feature? I tested with virgin svn trunk revision 673, just to 
be on the safe side, and no, I can't use continuation.
-- 
PerlTrader

[GT] Re: Re: Re: Re: Re: Re: graphics.pl works, but .png has errors.

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

Robert A. Schmied wrote:
> Greg Jessup wrote:
> 
>>> do you get data from
>>>
>>> ./display_indicator.pl  --timeframe=week I:Prices IBM
>>> or
>>> ./display_indicator.pl  --timeframe=week I:Prices 13000
>>>
>>
>>
>> Yes...output looks like this
>> ./display_indicator.pl  --timeframe=week I:Prices IBM
>>
>> Prices[]            [2009-23] = 107.2400
>> Prices[]            [2009-24] = 108.2100
>> Prices[]            [2009-25] = 105.8900
>> Prices[]            [2009-26] = 105.6800
>> Prices[]            [2009-27] = 101.7300
>> Prices[]            [2009-28] = 100.8300
>> Prices[]            [2009-29] = 115.4200
>>
>> very odd indeed. 13000 is in the sample text base db, ibm not unless 
>> you've
>>
>>> added it.
>>
>>
>>
>>
>> I have toggled the sample text and beancounter to eliminate the db as a
>> factor.
>>
>>
>> please send the entire
>>
>>> graphic config data and command line, plus maybe your $HOME/.gt/options_
>>
>>
>>
> ok so no additional data passed to graphic.pl via a file command is 
> completely:
> 
> ./graphic.pl --timeframe=week  13000 > test.png
> or
> ./graphic.pl --timeframe=week  IBM > IBM.png
> 
> neither work, but ./display_indicator.pl  --timeframe=week I:Prices IBM
> works
> 
> i'm a bit stumped -- given that a more complex ./graphic.pl example does 
> work
> try the attached gconfig file with this comamnd line
> 
> ./graphic.pl --file simple_continue.gconf --end 'yesterday' IBM > 
> /tmp/IBM.png
> 
> 
> ras


if this fails -- i dunno -- i'd say bad browser, but that's wrong, you
can use in for the working example.

are the png files zero bytes long, or are they just corrupt png? in the
latter case, if ./graphic.pl is sending stderr to the file that will cause
the problem

as a csh'er i'd do
( ./graphic.pl --timeframe=week   IBM > /tmp/IBM.png ) >& /dev/tty
but a (b|ba|k)sh'er might use
./graphic.pl --timeframe=week   IBM > /tmp/IBM.png 2> /dev/tty

ras


> 
> 
>>
>> DB::module bean
>>
>> DB::bean::dbname beancounter
>> DB::bean::dbhost localhost
>> DB::bean::dbport 3306
>> DB::bean::dbuser user
>> DB::bean::dbpasswd password
>> DB::bean::db mysql
>>
>> # relying on DB::Text defaults for sample database access
>>
>> Brokers::module SelfTrade
>> Path::Font::Arial /usr/share/fonts/default/TrueType/arial.ttf
>> Path::Font::Courier /usr/share/fonts/default/TrueType/couri.ttf
>> Path::Font::Times /usr/share/fonts/default/TrueType/times.ttf
>>
>> Analysis::ReferenceTimeFrame year
>>
>> #Graphic::BackgroundColor black
>> #Graphic::ForegroundColor white
>>
>> Aliases::Global::TFS    SY:TFS 50 10|CS:SY:TFS
>> Aliases::Global::SMA    SY:SMA 50 10|CS:SY:TFS
>> Aliases::Global::TFS[]  SY:TFS #1 #2|CS:SY:TFS #1|CS:Stop:Fixed #3
>> Aliases::Global::3EMA SY:Generic { @S:3EMAlong 60 90 120 } { 
>> @S:3EMAshort 60
>> 90 120 }
>> Aliases::Global::3EMALong SY:Generic { @S:3EMAlong 60 90 120 }
>> Aliases::Global::3EMALong[] SY:Generic { @S:3EMAlong 60 90 120 }
>> Aliases::Global::3EMA[] SY:Generic { @S:3EMAlong #1 #2 #3 } { 
>> @S:3EMAshort
>> #1 #2 #3 }
>> Aliases::Global::2SMA SY:Generic { @S:2SMAlong #1 #2 }
>> Aliases::Global::2SMA[] SY:Generic { @S:2SMAlong #1 #2 } { @S:2SMAlong 
>> #1 #2
>> }
>>
>> #MACD simple
>> Aliases::Global::MCD    \
>> SY:Generic    \
>> {S:G:CrossOverUp {I:MACD/3} 0}    \
>> {S:G:CrossOverDown {I:MACD/3} 0}
>>
>>
>>
>> On Sun, Jul 19, 2009 at 2:20 PM, Robert A. Schmied <ra...@ac...> wrote:
>>
>>
>>> Greg Jessup wrote:
>>>
>>>
>>>> Does not seem to be a problem with timeframe. No mater what I run, I 
>>>> get
>>>> and
>>>> errored png file which I can not open. I ran a demo script found in 
>>>> this
>>>> thread
>>>> http://www.geniustrader.org/lists/devel/msg01179.html
>>>> And it created the file fine, so I don't believe its a GD issue..but 
>>>> not
>>>> 100% positive. Running that script leads me to believe, its 
>>>> installed ok.
>>>>
>>>> I am using beancounter on mysql. but have tried changing to text as 
>>>> well.
>>>> Neither seem to work. No error form the script, just with the png.
>>>> Any issue going from Linux to windows with the png? I am running
>>>> graphic.pl
>>>> on linux but viewing it with Firefox via windows. Although the i did 
>>>> the
>>>> same with the test script mentioned above and saw the graphic just
>>>> fine.....
>>>> this is wierd.
>>>>
>>>> -Greg
>>>>
>>>> On Sun, Jul 19, 2009 at 1:31 PM, Robert A. Schmied <ra...@ac...> wrote:
>>>>
>>>>
>>>>
>>>>
>>>
>>> < snip >
>>>
>>> greg
>>>
>>> so you can create png images using something ( please send the entire
>>> graphic config data and command line, plus maybe your $HOME/.gt/options_
>>>
>>> but you cannot create png images using
>>>
>>> ./graphic.pl --timeframe=week  13000 > test.png
>>> or
>>> ./graphic.pl --timeframe=week  IBM > IBM.png
>>>
>>> very odd indeed. 13000 is in the sample text base db, ibm not unless 
>>> you've
>>> added it.
>>>
>>>
>>> do you get data from
>>>
>>> ./display_indicator.pl  --timeframe=week I:Prices IBM
>>> or
>>> ./display_indicator.pl  --timeframe=week I:Prices 13000
>>>
>>>
>>>
>>> ras
>>>
>>>
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> #
> # nb -- options in this file will override those on the command line
> #
> # graphic default: candlevol, candlevolplace, barchart, line, none
> --type=candle
> 
> --timeframe=day
> 
> # by default 6 months
> --start='27 weeks ago'
> 
> 
> --add=Text("contination line works", \
>   2, 50, left, center, large, blue, arial)
> 
> #
> # add 50 day volume moving average on the automatic volume histogram
> #
> --add=Switch-Zone(1)
> 
> --add=Curve(Indicators::EMA 22 {Indicators::Prices VOLUME}, brown)
> --add=Text("22 bar volume ema", 2, 100, left, center, small, brown, arial)
> 

[GT] Re: Re: Re: Re: Re: graphics.pl works, but .png has errors.

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

Greg Jessup wrote:
>>do you get data from
>>
>>./display_indicator.pl  --timeframe=week I:Prices IBM
>>or
>>./display_indicator.pl  --timeframe=week I:Prices 13000
>>
> 
> 
> Yes...output looks like this
> ./display_indicator.pl  --timeframe=week I:Prices IBM
> 
> Prices[]            [2009-23] = 107.2400
> Prices[]            [2009-24] = 108.2100
> Prices[]            [2009-25] = 105.8900
> Prices[]            [2009-26] = 105.6800
> Prices[]            [2009-27] = 101.7300
> Prices[]            [2009-28] = 100.8300
> Prices[]            [2009-29] = 115.4200
> 
> very odd indeed. 13000 is in the sample text base db, ibm not unless you've
> 
>>added it.
> 
> 
> 
> I have toggled the sample text and beancounter to eliminate the db as a
> factor.
> 
> 
> please send the entire
> 
>>graphic config data and command line, plus maybe your $HOME/.gt/options_
> 
> 
ok so no additional data passed to graphic.pl via a file command is completely:

./graphic.pl --timeframe=week  13000 > test.png
or
./graphic.pl --timeframe=week  IBM > IBM.png

neither work, but ./display_indicator.pl  --timeframe=week I:Prices IBM
works

i'm a bit stumped -- given that a more complex ./graphic.pl example does work
try the attached gconfig file with this comamnd line

./graphic.pl --file simple_continue.gconf --end 'yesterday' IBM > /tmp/IBM.png


ras


> 
> DB::module bean
> 
> DB::bean::dbname beancounter
> DB::bean::dbhost localhost
> DB::bean::dbport 3306
> DB::bean::dbuser user
> DB::bean::dbpasswd password
> DB::bean::db mysql
> 
> # relying on DB::Text defaults for sample database access
> 
> Brokers::module SelfTrade
> Path::Font::Arial /usr/share/fonts/default/TrueType/arial.ttf
> Path::Font::Courier /usr/share/fonts/default/TrueType/couri.ttf
> Path::Font::Times /usr/share/fonts/default/TrueType/times.ttf
> 
> Analysis::ReferenceTimeFrame year
> 
> #Graphic::BackgroundColor black
> #Graphic::ForegroundColor white
> 
> Aliases::Global::TFS    SY:TFS 50 10|CS:SY:TFS
> Aliases::Global::SMA    SY:SMA 50 10|CS:SY:TFS
> Aliases::Global::TFS[]  SY:TFS #1 #2|CS:SY:TFS #1|CS:Stop:Fixed #3
> Aliases::Global::3EMA SY:Generic { @S:3EMAlong 60 90 120 } { @S:3EMAshort 60
> 90 120 }
> Aliases::Global::3EMALong SY:Generic { @S:3EMAlong 60 90 120 }
> Aliases::Global::3EMALong[] SY:Generic { @S:3EMAlong 60 90 120 }
> Aliases::Global::3EMA[] SY:Generic { @S:3EMAlong #1 #2 #3 } { @S:3EMAshort
> #1 #2 #3 }
> Aliases::Global::2SMA SY:Generic { @S:2SMAlong #1 #2 }
> Aliases::Global::2SMA[] SY:Generic { @S:2SMAlong #1 #2 } { @S:2SMAlong #1 #2
> }
> 
> #MACD simple
> Aliases::Global::MCD    \
> SY:Generic    \
> {S:G:CrossOverUp {I:MACD/3} 0}    \
> {S:G:CrossOverDown {I:MACD/3} 0}
> 
> 
> 
> On Sun, Jul 19, 2009 at 2:20 PM, Robert A. Schmied <ra...@ac...> wrote:
> 
> 
>>Greg Jessup wrote:
>>
>>
>>>Does not seem to be a problem with timeframe. No mater what I run, I get
>>>and
>>>errored png file which I can not open. I ran a demo script found in this
>>>thread
>>>http://www.geniustrader.org/lists/devel/msg01179.html
>>>And it created the file fine, so I don't believe its a GD issue..but not
>>>100% positive. Running that script leads me to believe, its installed ok.
>>>
>>>I am using beancounter on mysql. but have tried changing to text as well.
>>>Neither seem to work. No error form the script, just with the png.
>>>Any issue going from Linux to windows with the png? I am running
>>>graphic.pl
>>>on linux but viewing it with Firefox via windows. Although the i did the
>>>same with the test script mentioned above and saw the graphic just
>>>fine.....
>>>this is wierd.
>>>
>>>-Greg
>>>
>>>On Sun, Jul 19, 2009 at 1:31 PM, Robert A. Schmied <ra...@ac...> wrote:
>>>
>>>
>>>
>>>
>>
>>< snip >
>>
>>greg
>>
>>so you can create png images using something ( please send the entire
>>graphic config data and command line, plus maybe your $HOME/.gt/options_
>>
>>but you cannot create png images using
>>
>>./graphic.pl --timeframe=week  13000 > test.png
>>or
>>./graphic.pl --timeframe=week  IBM > IBM.png
>>
>>very odd indeed. 13000 is in the sample text base db, ibm not unless you've
>>added it.
>>
>>
>>do you get data from
>>
>>./display_indicator.pl  --timeframe=week I:Prices IBM
>>or
>>./display_indicator.pl  --timeframe=week I:Prices 13000
>>
>>
>>
>>ras
>>
>>
> 
> 

[GT] Re: Help With My first system

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

Perl Trader wrote:
> Robert A. Schmied wrote:
> 
>> Perl Trader wrote:
>>
>>> Robert A. Schmied wrote:
>>>
>>>> putting it altogether (with continuation lines and abbreviating where
>>>> possible) i have
>>>>
>>>> { S:G:And \
>>>>  { S:G:Above { I:SMA {I:Price CLOSE} 200 } } \
>>>>  { S:G:Above { I:SMA {I:Price CLOSE}   5 } } \
>>>> \
>>>>  { S:G:And \
>>>>     { S:G:Below \
>>>>       { I:G:PeriodAgo 2 {I:Price HIGH} } \
>>>>       { I:G:PeriodAgo 3 {I:Price HIGH} } \
>>>>     } \
>>>>     { S:G:Below \
>>>>       { I:G:PeriodAgo 2 {I:Price LOW} } \
>>>>       { I:G:PeriodAgo 3 {I:Price LOW} } \
>>>>    } \
>>>>  } \
>>>> \
>>>>  { S:G:Below \
>>>>    { I:Price LOW { I:G:PeriodAgo 1 {I:Price LOW} } } \
>>>>  } \
>>>> } \
>>>> { S:G:False } \
>>>
>>>
>>>
>>> Robert, where do you put such system with continuation lines? How can 
>>> it be used?
>>>
>>
>> havn't gotten that far yet
>>
>>> I tried to do such thing in graphic.conf, in --add=BuySellArrows 
>>> line, but it's not working, getting lots of errors right away.
>>
>>
>> but this is a place to start, but if it errors out then you need to
>> piece-meal individual bits with display_indicator and _signal to diagnose
>> the problems ...
>>
> 
> Huh, I think I've been misundertood. I'm asking only about support for 
> continuation lines, not about this specific system.

yes -- i missed that aspect out completely. 

ok it's my belief that all script apps that read sys-sig-indic descriptions
(and in case of graphic.pl graphic directives (which look a lot like 
sys-sig-indic descriptions but are really what i call graphic directives)
from files now understand both continuation lines and comments lines in
files of that sort. (i don't know if thomas has adopted them on the dev branch)

the script apps might include: graphic.pl, scan.pl, and maybe one or more of the
backtests.

display_* don't read that info from a file so they may not be able to handle it.

so if you put your BuySellArrows graphic directive into a graphic config file
(gconf) and add continuation line chars appropriately it is easier for us
humans to read and parse and fix and change

comments are introduced this the char '#', and extend to the logical end of the
line --- logical is significant, if the line is continued so is the comment. this
is good -- comment out an entire multiline directive with a single '#' but has
risks too -- don't try to comment out bits inside a multiline group

ras


> 
> Check this out:
> 
> --add=BuySellArrows(SY:Generic {S:G:And {S:G:Or {S:G:And {S:G:Above 
> {I:G:PeriodAgo 4 {I:STO/3 3 2 2 2}} 80 } {S:G:Above {I:G:PeriodAgo 4} 
> {I:G:PeriodAgo 4 {I:SMA 50}}}} {S:G:And {S:G:Below {I:G:PeriodAgo 4 
> {I:STO/3 3 2 2 2}} 20} {S:G:Below {I:G:PeriodAgo 4} {I:G:PeriodAgo 4 
> {I:SMA 50}}}}} {S:G:Above {I:Prices HIGH} {I:G:PeriodAgo 4 {I:Prices 
> HIGH}}}} {S:G:And {S:G:Or {S:G:And {S:G:Above {I:G:PeriodAgo 4 {I:STO/3 
> 3 2 2 2}} 80 } {S:G:Above {I:G:PeriodAgo 4} {I:G:PeriodAgo 4 {I:SMA 
> 50}}}} {S:G:And {S:G:Below {I:G:PeriodAgo 4 {I:STO/3 3 2 2 2}} 20} 
> {S:G:Below {I:G:PeriodAgo 4} {I:G:PeriodAgo 4 {I:SMA 50}}}}} {S:G:Below 
> {I:Prices LOW} {I:G:PeriodAgo 4 {I:Prices LOW}}}})
> 
> That is a line I sent Emily, trying to model his system. Obviously part 
> od graphic.conf file which I feed to graphic.pl via --file option. It is 
> *completely* unreadable, and was major PITA to code.
> 
> Now, if I try to break it down to just 2 lines, and put continuation 
> like you do ("\" character at the end of the first line), it immediately 
> doesn't work and spits lots of errors. It seemsto me that BuySellArrows 
> expects everything to be in one line, and won't work otherwise.

sounds like your graphic.pl is still in cripple mode, if the attached
gconf doesn't work then try the other gt branch -- you will likely need
the gt branch too not just the scripts

./graphic.pl --file simple_continue.gconf --end 'yesterday' IBM > /tmp/IBM.png

> 
> So my question is, how and where do you use such nice systems you post 
> with continuation lines? I can't make it work. Do you have a patch for 
> GT that provides that feature?

[GT] Re: Re: Re: Re: graphics.pl works, but .png has errors.

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

>
> do you get data from
>
> ./display_indicator.pl  --timeframe=week I:Prices IBM
> or
> ./display_indicator.pl  --timeframe=week I:Prices 13000
>

Yes...output looks like this
./display_indicator.pl  --timeframe=week I:Prices IBM

Prices[]            [2009-23] = 107.2400
Prices[]            [2009-24] = 108.2100
Prices[]            [2009-25] = 105.8900
Prices[]            [2009-26] = 105.6800
Prices[]            [2009-27] = 101.7300
Prices[]            [2009-28] = 100.8300
Prices[]            [2009-29] = 115.4200

very odd indeed. 13000 is in the sample text base db, ibm not unless you've
> added it.


I have toggled the sample text and beancounter to eliminate the db as a
factor.


please send the entire
> graphic config data and command line, plus maybe your $HOME/.gt/options_


DB::module bean

DB::bean::dbname beancounter
DB::bean::dbhost localhost
DB::bean::dbport 3306
DB::bean::dbuser user
DB::bean::dbpasswd password
DB::bean::db mysql

# relying on DB::Text defaults for sample database access

Brokers::module SelfTrade
Path::Font::Arial /usr/share/fonts/default/TrueType/arial.ttf
Path::Font::Courier /usr/share/fonts/default/TrueType/couri.ttf
Path::Font::Times /usr/share/fonts/default/TrueType/times.ttf

Analysis::ReferenceTimeFrame year

#Graphic::BackgroundColor black
#Graphic::ForegroundColor white

Aliases::Global::TFS    SY:TFS 50 10|CS:SY:TFS
Aliases::Global::SMA    SY:SMA 50 10|CS:SY:TFS
Aliases::Global::TFS[]  SY:TFS #1 #2|CS:SY:TFS #1|CS:Stop:Fixed #3
Aliases::Global::3EMA SY:Generic { @S:3EMAlong 60 90 120 } { @S:3EMAshort 60
90 120 }
Aliases::Global::3EMALong SY:Generic { @S:3EMAlong 60 90 120 }
Aliases::Global::3EMALong[] SY:Generic { @S:3EMAlong 60 90 120 }
Aliases::Global::3EMA[] SY:Generic { @S:3EMAlong #1 #2 #3 } { @S:3EMAshort
#1 #2 #3 }
Aliases::Global::2SMA SY:Generic { @S:2SMAlong #1 #2 }
Aliases::Global::2SMA[] SY:Generic { @S:2SMAlong #1 #2 } { @S:2SMAlong #1 #2
}

#MACD simple
Aliases::Global::MCD    \
SY:Generic    \
{S:G:CrossOverUp {I:MACD/3} 0}    \
{S:G:CrossOverDown {I:MACD/3} 0}



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

> Greg Jessup wrote:
>
>> Does not seem to be a problem with timeframe. No mater what I run, I get
>> and
>> errored png file which I can not open. I ran a demo script found in this
>> thread
>> http://www.geniustrader.org/lists/devel/msg01179.html
>> And it created the file fine, so I don't believe its a GD issue..but not
>> 100% positive. Running that script leads me to believe, its installed ok.
>>
>> I am using beancounter on mysql. but have tried changing to text as well.
>> Neither seem to work. No error form the script, just with the png.
>> Any issue going from Linux to windows with the png? I am running
>> graphic.pl
>> on linux but viewing it with Firefox via windows. Although the i did the
>> same with the test script mentioned above and saw the graphic just
>> fine.....
>> this is wierd.
>>
>> -Greg
>>
>> On Sun, Jul 19, 2009 at 1:31 PM, Robert A. Schmied <ra...@ac...> wrote:
>>
>>
>>
>>
> < snip >
>
> greg
>
> so you can create png images using something ( please send the entire
> graphic config data and command line, plus maybe your $HOME/.gt/options_
>
> but you cannot create png images using
>
> ./graphic.pl --timeframe=week  13000 > test.png
> or
> ./graphic.pl --timeframe=week  IBM > IBM.png
>
> very odd indeed. 13000 is in the sample text base db, ibm not unless you've
> added it.
>
>
> do you get data from
>
> ./display_indicator.pl  --timeframe=week I:Prices IBM
> or
> ./display_indicator.pl  --timeframe=week I:Prices 13000
>
>
>
> ras
>
>

[GT] Re: Help With My first system

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

./display_indicator.pl  --timeframe=week I:Prices Greg Jessup wrote:
> This is great info RAS. I really appreciate it. Once I get my graphic.pl
> issue worked out. I will continue to read on, but what you did was translate
> plain english to GT code for me. That should speed up my progress.
> 

give us a command line or usage context and we can take the next steps
without having to manufacture them ...

> thanks again.
> 

just trying to be helpful, friendly and generally fun to be around ;-)

> -Greg

ras

ps -- crap gotta watch those pesky 'Re: ' strings

raphael -- if your listening (reading) can't you come up with a perl
regex that will choke them off?

-- ras

< snip >