Menu
▾
▴
geniustrader-devel — participate in geniustrader development, ask for help, suggest improvements, etc
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(32) |
Oct
(144) |
Nov
(14) |
Dec
(44) |
| 2002 |
Jan
(16) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(65) |
Nov
(4) |
Dec
(30) |
| 2003 |
Jan
(84) |
Feb
(101) |
Mar
(58) |
Apr
(30) |
May
(138) |
Jun
(336) |
Jul
(36) |
Aug
(12) |
Sep
(8) |
Oct
(4) |
Nov
(12) |
Dec
(12) |
| 2004 |
Jan
(186) |
Feb
(274) |
Mar
(248) |
Apr
(18) |
May
(104) |
Jun
(48) |
Jul
(144) |
Aug
(98) |
Sep
(60) |
Oct
(72) |
Nov
(32) |
Dec
(130) |
| 2005 |
Jan
(84) |
Feb
(130) |
Mar
(50) |
Apr
(106) |
May
(240) |
Jun
(154) |
Jul
(66) |
Aug
(82) |
Sep
(36) |
Oct
(18) |
Nov
(14) |
Dec
(4) |
| 2006 |
Jan
(68) |
Feb
(2) |
Mar
(14) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(50) |
Dec
(4) |
| 2007 |
Jan
(14) |
Feb
(42) |
Mar
(70) |
Apr
(30) |
May
(8) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(88) |
Nov
(168) |
Dec
(2) |
| 2008 |
Jan
(56) |
Feb
(372) |
Mar
(446) |
Apr
(112) |
May
(144) |
Jun
(94) |
Jul
(208) |
Aug
(90) |
Sep
(26) |
Oct
(10) |
Nov
(2) |
Dec
|
| 2009 |
Jan
|
Feb
(8) |
Mar
|
Apr
(46) |
May
(188) |
Jun
(120) |
Jul
(448) |
Aug
(202) |
Sep
(4) |
Oct
(72) |
Nov
(154) |
Dec
(2) |
| 2010 |
Jan
(58) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(68) |
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(11) |
| 2011 |
Jan
(6) |
Feb
(11) |
Mar
(8) |
Apr
(10) |
May
(4) |
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
|
| 2012 |
Jan
|
Feb
(13) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(31) |
Aug
(21) |
Sep
(2) |
Oct
(1) |
Nov
(29) |
Dec
(17) |
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
(25) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(4) |
Nov
(11) |
Dec
|
| 2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Delix <del...@t-...> - 2012-07-08 16:43:32
|
On Sun, 08 Jul 2012 09:32:42 -0700 "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > Delix wrote: > > On Sat, 07 Jul 2012 10:35:20 -0700 > > "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > aloha delix > > thanks for taking the time to improve the users wiki. those tweaks should be helpful > the new users. no problem, mate However,as I don't have write access to the starting pages(only to the wiki), for noobies it would be important to have the testing section corrected there, too. Additionally, if this is a general issue of the backtest modul and not something special, I'll correct this in the backtest wiki pages. But I think, somebody with GT experience should check this out first. Cheers,delix > > gt users take note -- shell escapes are always required in sys-sig-indic descriptions > that are being passed on the command line. the csh is especially annoying in that respect > so much so that even tho i've been weaned on it i find the bash/ksh much more convenient > when trying to develop/diagnose a new complex sys-sig-indic descriptions with lots of > curly and square brackets ... but this isn't only gt related, the csh is brain dead when > it comes to trying to include the ' char in a multiple word argument. > > also note that sys-sig-indic description strings cannot be 'broken' midstring with a > shell '\' continuation line char, (at least not in my experience). the whole sys-sig-indic > desc must be contiguous. > > again thanks delix for the wiki revision. > > aloha > > ras > > > > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- Delix <lin...@t-...> |
|
From: Robert A. S. <ra...@ac...> - 2012-07-08 16:32:51
|
Delix wrote: > On Sat, 07 Jul 2012 10:35:20 -0700 > "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > > >>Delix wrote: >> >>>Hi again ! >>>Sorry for being back so soon... >>>I went on with the installation and started the tests as written in the wiki. >>>the display-indicator.pl test was successful without any problems >>> >>>However, the backtest.pl tests failed. >> >>ok assuming your backtest command is >> >> backtest.pl TFS 13000 >> >>and your gt options file contains >>Aliases::Global::TFS SY:TFS 50 10 | CS:SY:TFS >> >>and using the text based database i'm getting >> >>localhost:(Scripts)-ras [ 327 ] % backtest.pl TFS 13000 >>the requested timeframe "" is not in the list of available timeframes >> "" >> >>so something is truly amiss someplace -- looks like backtest.pl requires an explicit timeframe argument >>this might be due to the nature of file based prices data ... >> >> >>localhost:(Scripts)-ras [ 326 ] % backtest.pl -timeframe day TFS 13000 > > > > Yeah -- that's it !!! With the -timeframe day option I get the same output. > > I check the http://geniustrader.org/first_use.html page again and there is only the suggestion of > the tests without any timeframe option. > So it should be enough to correct the wiki page :) > > Thx again for the quick response and help ! > > Edit : I guess the first attempt to send this answer landed in your personal mailbox.... > aloha delix thanks for taking the time to improve the users wiki. those tweaks should be helpful the new users. gt users take note -- shell escapes are always required in sys-sig-indic descriptions that are being passed on the command line. the csh is especially annoying in that respect so much so that even tho i've been weaned on it i find the bash/ksh much more convenient when trying to develop/diagnose a new complex sys-sig-indic descriptions with lots of curly and square brackets ... but this isn't only gt related, the csh is brain dead when it comes to trying to include the ' char in a multiple word argument. also note that sys-sig-indic description strings cannot be 'broken' midstring with a shell '\' continuation line char, (at least not in my experience). the whole sys-sig-indic desc must be contiguous. again thanks delix for the wiki revision. aloha ras |
|
From: Delix <del...@t-...> - 2012-07-08 07:58:33
|
On Sat, 07 Jul 2012 10:35:20 -0700 "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > Delix wrote: > > Hi again ! > > Sorry for being back so soon... > > I went on with the installation and started the tests as written in the wiki. > > the display-indicator.pl test was successful without any problems > > > > However, the backtest.pl tests failed. > > ok assuming your backtest command is > > backtest.pl TFS 13000 > > and your gt options file contains > Aliases::Global::TFS SY:TFS 50 10 | CS:SY:TFS > > and using the text based database i'm getting > > localhost:(Scripts)-ras [ 327 ] % backtest.pl TFS 13000 > the requested timeframe "" is not in the list of available timeframes > "" > > so something is truly amiss someplace -- looks like backtest.pl requires an explicit timeframe argument > this might be due to the nature of file based prices data ... > > > localhost:(Scripts)-ras [ 326 ] % backtest.pl -timeframe day TFS 13000 Yeah -- that's it !!! With the -timeframe day option I get the same output. I check the http://geniustrader.org/first_use.html page again and there is only the suggestion of the tests without any timeframe option. So it should be enough to correct the wiki page :) Thx again for the quick response and help ! Edit : I guess the first attempt to send this answer landed in your personal mailbox.... -- Delix <lin...@t-...> |
|
From: Robert A. S. <ra...@ac...> - 2012-07-07 18:16:41
|
gt'ers there's an updated Build.PL available -- see "for the bold ..." para on http://geniustrader.org/first_use.html. it has the correct geniustrader url -- thanks jae plus a bunch of extra operating environment checks, things like ensuring cwd is Scripts, and Scripts is writable and the toolkit dir is ../GT Scripts relative. for brand new users it can be used to help figure out what perl modules are missing ... for current users or users having trouble it will look over your options file checking the database module settings and it will validate every font path for both existence and file type (if the *nix 'file' util is found. this latter might be non-portable, in terms of the text string defined for a truetype file. if you run into issues where Build.PL claims a fontpath file isn't truetype, but that fontface works fine with graphic.pl please contact me, thanks. enjoy aloha ras |
|
From: Robert A. S. <ra...@ac...> - 2012-07-07 17:35:29
|
Delix wrote:
> Hi again !
> Sorry for being back so soon...
> I went on with the installation and started the tests as written in the wiki.
> the display-indicator.pl test was successful without any problems
>
> However, the backtest.pl tests failed.
ok assuming your backtest command is
backtest.pl TFS 13000
and your gt options file contains
Aliases::Global::TFS SY:TFS 50 10 | CS:SY:TFS
and using the text based database i'm getting
localhost:(Scripts)-ras [ 327 ] % backtest.pl TFS 13000
the requested timeframe "" is not in the list of available timeframes
""
so something is truly amiss someplace -- looks like backtest.pl requires an explicit timeframe argument
this might be due to the nature of file based prices data ...
localhost:(Scripts)-ras [ 326 ] % backtest.pl -timeframe day TFS 13000
## Analysis of SY:TFS 50 10|CS:SY:TFS 50|MM:Basic
History of the portfolio :
--------------------------
Short position (0) on alcatel before it acquired lucent (13000)
2000-09-21 Sell 119 at 82.6000
2000-12-07 Buy 119 at 68.9000
Long position (1) on alcatel before it acquired lucent (13000)
2000-12-07 Buy 160 at 68.9000
2000-12-20 Sell 160 at 64.5500
Long position (2) on alcatel before it acquired lucent (13000)
2001-01-15 Buy 159 at 67.5000
2001-01-26 Sell 159 at 61.3500
Short position (3) on alcatel before it acquired lucent (13000)
2001-01-26 Sell 159 at 61.3500
2001-10-18 Buy 159 at 15.9200
Long position (4) on alcatel before it acquired lucent (13000)
2001-10-18 Buy 990 at 15.9200
2001-12-21 Sell 990 at 17.7000
Short position (5) on alcatel before it acquired lucent (13000)
2001-12-21 Sell 1048 at 17.7000
2002-01-02 Buy 1048 at 19.0000
Long position (6) on alcatel before it acquired lucent (13000)
2002-01-04 Buy 818 at 21.5000
2002-01-15 Sell 818 at 18.3000
Short position (7) on alcatel before it acquired lucent (13000)
2002-01-15 Sell 777 at 18.3000
2002-03-11 Buy 777 at 18.5900
Long position (8) on alcatel before it acquired lucent (13000)
2002-03-11 Buy 757 at 18.5900
2002-03-12 Sell 757 at 18.0800
## Global analysis (full portfolio always invested)
Analysis of the portfolio (2000-09-13 00:00:00 / 2002-10-04 00:00:00)
-----------------------------------------------------
Performance : 32.6% ( 15.1%) Buy & Hold : 2.9% ( 1.4%) () => by year
MaxDrawDown : 28.3% B&H MaxDrawDown : 97.6%
Best performance : 84.9% Worst performance : -2.8%
Net gain : 3264.89 Gross gain : 4350.62
Trades statistics
Number of trades : 9 Trades/Year : 4.38
Number of gains : 3 Number of losses : 6 Win. ratio : 33.3%
Max consec. win : 2 Max consec. loss : 4 Expectancy : 0.05
Average gain : 30.36% Average loss : -8.02% Avg. perf : 3.19%
Biggest gain : 73.58% Biggest loss : -15.81% Profit fac : 3.79
Sum of gains : 10335.07 Sum of losses : -7070.18 Risk of ruin : 48.6%
feel encouraged to correct the wiki example if this is the problem
... but this might not have solved your exact problem.
if not please send the following:
your complete options file
the complete command line for cmd in question
all the output from the cmd, tty text, text/html and image files
> The error message I got was:
>
> "no data available to generate data. at ../GT/Tools.pm line 463"
i don't find a message string like that in any of the gt code base i have available
that line number with a lot of fuzz suggests there's a problem with the TFS alias.
you do have that alias defined?
are you using a gt you've pulled from someplace other than geniustrader.org?
if you did get it there which branch did you download? we recommend the trunk head
or the exp head. the cpan branch is very out-of-date.
any other fork of gt (from other webplaces) kind of puts you in youareonyourown
vis-a-vis this mailing list.
>
> I checked this line and saw this is a problem of the timeframe. The according line in the options file is the same as supposed for the tests in the wiki -- nothing changed.
>
> Then I checked the modules. As I use an ArchLinux-based system I use the PKGBUILD files from
> https://aur.archlinux.org/packages.php?ID=45764
> Most likely it is a missing dependency or something similar. Can you tell me what perl moduls must be installed to get the backtests running. I think, I'll be able then to figure out by myself, what Arch packages I need additionally.
download Build.PL into gt/Scripts and run it
% Build.PL
it will analyze your platform, perl, dependencies and your options file.
there will be a new version of Build.PL available in the 'for the bold ...' para
at http://geniustrader.org/first_use.html in the next 12 hours or so, but the one
there now should be adequate for a local computer.
forward the output here if you get stumped.
> Thanks again !
|
|
From: Delix <del...@t-...> - 2012-07-07 14:16:25
|
Hi again ! Sorry for being back so soon... I went on with the installation and started the tests as written in the wiki. the display-indicator.pl test was successful without any problems However, the backtest.pl tests failed. The error message I got was: "no data available to generate data. at ../GT/Tools.pm line 463" I checked this line and saw this is a problem of the timeframe. The according line in the options file is the same as supposed for the tests in the wiki -- nothing changed. Then I checked the modules. As I use an ArchLinux-based system I use the PKGBUILD files from https://aur.archlinux.org/packages.php?ID=45764 Most likely it is a missing dependency or something similar. Can you tell me what perl moduls must be installed to get the backtests running. I think, I'll be able then to figure out by myself, what Arch packages I need additionally. Thanks again ! -- Delix <lin...@t-...> |
|
From: Jon E. <fo...@ho...> - 2012-07-07 03:11:29
|
For anyone else that run RAS' Build.pl be sure to place Build.plin PATH_TO/geniustrader/Scripts where scripts such as select_combination.plis located. Build.pl looks at these and will edit them (if you answer 'y') to conform to your perl path. If I've said anything incorrectly do let me know. Thank you,Jon > Date: Fri, 6 Jul 2012 10:42:36 -0700 > From: ra...@ac... > To: gen...@li... > CC: gen...@li... > Subject: Re: [GT] Font Problem Direction Help > > Robert A. Schmied wrote: > > Jon Edwards wrote: > > > >>I'm sure this is caused by something missing from the server I'm > >>attempting to run GT on butnot sure if my thinking is correct. > >>Running graphics.pl I get a whole bunch of ... graphic.pl: error: GD: > >>unable to generate text string, failing string: "Oct"error message: > >>Could not find/open font at > >>/home/palm/geniustrader/GT/Graphics/Driver/GD.pm line 582. Is this > >>due to missing c gd library libgd as mentioned in the documents or > >>something else ?If that's the case according to the same document I > >>can use one of SVG, Postscript::Simple or ImageMagick or is it > >>Image::Magick ?If I go down the alternate approach would I need to > >>change anything in GT or just install one or all of those modules ? > >>Thank you all ! Jon > >> > > > > > > aloha jon > > > > that error message is emitted from the custom ras hack version > > (available on request). it results when a text string bounding > > box fails to return the string bounding box coordinates. > > > > the error message is from either the perl GD module or the gd c library. > > and as it indicates, the font file being used isn't found. the best guess > > would be a bad font key-value setting or bad font file (not a truetype file). > > > > i don't think one can build/install the perl GD module without an > > appropriate gd c library, but i guess it would be possible for an > > os distribution to pair incompatible versions of them or ship the > > perl GD module without a gd c library. it's also possible to mis-configure > > perl so it might find incompatible versions of things... > > > > as i recall there's a lot of info about perl gd and gd c lib in the > > user's wiki i think. if you cannot find it yell and i will search it out. > > > > > > questions: > > > > * what does your $HOME/gt/option file font key-value lines look like? > > do the values list absolute paths to true type font files? > > > > * can you get any textual graphics to work or do they all fail? > > a minimal graphic.pl chart might be > > graphic.pl IBM -driver GD -out graphs/IBM.png > > this would use the default (arial) font for title and axis labels > > the addition of --add='text( "0123456789", 2, 85, left, center, large, black, fixed)' > > > > the font names (eg arial, fixed, times, courier) used in the graphics.pl > > graphic descriptions correspond to the perl font variables $FONT_ARIAL, > > $FONT_TIMES and $FONT_FIXED and in *ras hack gt versions* $FONT_HELVETICA > > plus an absolute path to a *ttf font file*: > > --add='text( "0123456789", 2, 65, left, center, large, black, /usr/openwin/lib/X11/fonts/TrueType/VeraBI.ttf )' > > > > * what does the ras hack Build.PL report? -- it should get an enhancement > > to check and validate a users $HOME/.gt/options font configuration > > ( assuming it doesn't yet ). (this perl script is generally available > > from http://geniustrader.org/first_use.html, look for 'for the bold and adventurous') > > > > > > > > if it isn't a simple font configuration issue: > > > > * have you tried to build and install the gd c library (first) and > > then the perl GD module or either one or none? > > > > * are you sure that perl is finding the correct versions of perl GD module > > and gd c library > > > > recommendations as to other gt graphic drivers: > > gd is the only one i use and enhance. the svg driver should work > > but it has not had a lot of support or enhancement. the others are > > real old and unmaintained. > > > > so if you live in your browser and it supports svg then that might > > be an acceptable option, but the others probably aren't. > > > > > > aloha > > > > ras > > > > > > gt'ers > > given the missing generic users gt configuration file ($HOME/.gt/options) > and general complexity of things that go into it plus the extensive perl > prerequisites needed by GT i've hacked together a perl script built around > perl module Module::Build (yet another perl prerequisite). > > anyway, you can download it from http://geniustrader.org/experimental/Build.PL > into the gt Scripts dir and have it analyze your host computer, perl and gt > installation vis-a-vis known gt criteria. > > just do something like > > $ pushd my/gt/Scripts > $ ./Build.PL > > to read what Build.PL might actually do try > > $ perldoc Build.PL > > this new version should flag and help diagnose the font problems commented on > by jon above and delix previously, but only if it is used to analyze the users > (faulty) gt options file. > > i'm not necessarily completely happy with the output format, but it's better > than nothing. > > yell if i've done something non-portable ... > > aloha > > ras > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ |
|
From: Robert A. S. <ra...@ac...> - 2012-07-06 17:42:53
|
Robert A. Schmied wrote: > Jon Edwards wrote: > >>I'm sure this is caused by something missing from the server I'm >>attempting to run GT on butnot sure if my thinking is correct. >>Running graphics.pl I get a whole bunch of ... graphic.pl: error: GD: >>unable to generate text string, failing string: "Oct"error message: >>Could not find/open font at >>/home/palm/geniustrader/GT/Graphics/Driver/GD.pm line 582. Is this >>due to missing c gd library libgd as mentioned in the documents or >>something else ?If that's the case according to the same document I >>can use one of SVG, Postscript::Simple or ImageMagick or is it >>Image::Magick ?If I go down the alternate approach would I need to >>change anything in GT or just install one or all of those modules ? >>Thank you all ! Jon >> > > > aloha jon > > that error message is emitted from the custom ras hack version > (available on request). it results when a text string bounding > box fails to return the string bounding box coordinates. > > the error message is from either the perl GD module or the gd c library. > and as it indicates, the font file being used isn't found. the best guess > would be a bad font key-value setting or bad font file (not a truetype file). > > i don't think one can build/install the perl GD module without an > appropriate gd c library, but i guess it would be possible for an > os distribution to pair incompatible versions of them or ship the > perl GD module without a gd c library. it's also possible to mis-configure > perl so it might find incompatible versions of things... > > as i recall there's a lot of info about perl gd and gd c lib in the > user's wiki i think. if you cannot find it yell and i will search it out. > > > questions: > > * what does your $HOME/gt/option file font key-value lines look like? > do the values list absolute paths to true type font files? > > * can you get any textual graphics to work or do they all fail? > a minimal graphic.pl chart might be > graphic.pl IBM -driver GD -out graphs/IBM.png > this would use the default (arial) font for title and axis labels > the addition of --add='text( "0123456789", 2, 85, left, center, large, black, fixed)' > > the font names (eg arial, fixed, times, courier) used in the graphics.pl > graphic descriptions correspond to the perl font variables $FONT_ARIAL, > $FONT_TIMES and $FONT_FIXED and in *ras hack gt versions* $FONT_HELVETICA > plus an absolute path to a *ttf font file*: > --add='text( "0123456789", 2, 65, left, center, large, black, /usr/openwin/lib/X11/fonts/TrueType/VeraBI.ttf )' > > * what does the ras hack Build.PL report? -- it should get an enhancement > to check and validate a users $HOME/.gt/options font configuration > ( assuming it doesn't yet ). (this perl script is generally available > from http://geniustrader.org/first_use.html, look for 'for the bold and adventurous') > > > > if it isn't a simple font configuration issue: > > * have you tried to build and install the gd c library (first) and > then the perl GD module or either one or none? > > * are you sure that perl is finding the correct versions of perl GD module > and gd c library > > recommendations as to other gt graphic drivers: > gd is the only one i use and enhance. the svg driver should work > but it has not had a lot of support or enhancement. the others are > real old and unmaintained. > > so if you live in your browser and it supports svg then that might > be an acceptable option, but the others probably aren't. > > > aloha > > ras > gt'ers given the missing generic users gt configuration file ($HOME/.gt/options) and general complexity of things that go into it plus the extensive perl prerequisites needed by GT i've hacked together a perl script built around perl module Module::Build (yet another perl prerequisite). anyway, you can download it from http://geniustrader.org/experimental/Build.PL into the gt Scripts dir and have it analyze your host computer, perl and gt installation vis-a-vis known gt criteria. just do something like $ pushd my/gt/Scripts $ ./Build.PL to read what Build.PL might actually do try $ perldoc Build.PL this new version should flag and help diagnose the font problems commented on by jon above and delix previously, but only if it is used to analyze the users (faulty) gt options file. i'm not necessarily completely happy with the output format, but it's better than nothing. yell if i've done something non-portable ... aloha ras |
|
From: Jon E. <fo...@ho...> - 2012-07-05 14:27:34
|
Aloha RAS !! Thank you for the help once again !! Indeed my problem was caused by invalid reference to the TTF font files in .gt/optionse.g. Path::Font::Arial Thank you,Jon > Date: Wed, 4 Jul 2012 11:14:15 -0700 > From: ra...@ac... > To: gen...@li... > Subject: Re: [GT] Font Problem Direction Help > > Jon Edwards wrote: > > > > I'm sure this is caused by something missing from the server I'm > > attempting to run GT on butnot sure if my thinking is correct. > > Running graphics.pl I get a whole bunch of ... graphic.pl: error: GD: > > unable to generate text string, failing string: "Oct"error message: > > Could not find/open font at > > /home/palm/geniustrader/GT/Graphics/Driver/GD.pm line 582. Is this > > due to missing c gd library libgd as mentioned in the documents or > > something else ?If that's the case according to the same document I > > can use one of SVG, Postscript::Simple or ImageMagick or is it > > Image::Magick ?If I go down the alternate approach would I need to > > change anything in GT or just install one or all of those modules ? > > Thank you all ! Jon > > > > aloha jon > > that error message is emitted from the custom ras hack version > (available on request). it results when a text string bounding > box fails to return the string bounding box coordinates. > > the error message is from either the perl GD module or the gd c library. > and as it indicates, the font file being used isn't found. the best guess > would be a bad font key-value setting or bad font file (not a truetype file). > > i don't think one can build/install the perl GD module without an > appropriate gd c library, but i guess it would be possible for an > os distribution to pair incompatible versions of them or ship the > perl GD module without a gd c library. it's also possible to mis-configure > perl so it might find incompatible versions of things... > > as i recall there's a lot of info about perl gd and gd c lib in the > user's wiki i think. if you cannot find it yell and i will search it out. > > > questions: > > * what does your $HOME/gt/option file font key-value lines look like? > do the values list absolute paths to true type font files? > > * can you get any textual graphics to work or do they all fail? > a minimal graphic.pl chart might be > graphic.pl IBM -driver GD -out graphs/IBM.png > this would use the default (arial) font for title and axis labels > the addition of --add='text( "0123456789", 2, 85, left, center, large, black, fixed)' > > the font names (eg arial, fixed, times, courier) used in the graphics.pl > graphic descriptions correspond to the perl font variables $FONT_ARIAL, > $FONT_TIMES and $FONT_FIXED and in *ras hack gt versions* $FONT_HELVETICA > plus an absolute path to a *ttf font file*: > --add='text( "0123456789", 2, 65, left, center, large, black, /usr/openwin/lib/X11/fonts/TrueType/VeraBI.ttf )' > > * what does the ras hack Build.PL report? -- it should get an enhancement > to check and validate a users $HOME/.gt/options font configuration > ( assuming it doesn't yet ). (this perl script is generally available > from http://geniustrader.org/first_use.html, look for 'for the bold and adventurous') > > > > if it isn't a simple font configuration issue: > > * have you tried to build and install the gd c library (first) and > then the perl GD module or either one or none? > > * are you sure that perl is finding the correct versions of perl GD module > and gd c library > > recommendations as to other gt graphic drivers: > gd is the only one i use and enhance. the svg driver should work > but it has not had a lot of support or enhancement. the others are > real old and unmaintained. > > so if you live in your browser and it supports svg then that might > be an acceptable option, but the others probably aren't. > > > aloha > > ras > > > > > > > > ------------------------------------------------------------------------ > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference Exclusive live event will cover all > > the ways today's security and threat landscape has changed and how IT > > managers can respond. Discussions will include endpoint security, > > mobile security and the latest in malware threats. > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ |
|
From: Robert A. S. <ra...@ac...> - 2012-07-04 20:40:32
|
Delix wrote: > On Wed, 04 Jul 2012 11:14:53 -0700 > "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > > >>Delix wrote: >> >>>Hi all ! May be it was not the best idea I ever had, but I'm trying >>>at the moment to get familiar with Perl by starting to use >>>geniustrader.... Hope this makes nobody upset :) >> >>why would you think that might make someone upset? > > > Usually beginners should start with "hello world" and not with such complex things like GT :-) yes, but that's only about a 15-30min exercise and then it's time to go for a higher hurdle, gt and prerequisite (along with any good perl book is probably all you will need) > >>frankly this might be a good choice, because you will >>likely have exposure to a wide variety of perl, from >>the object-oriented flavor of gt to the more procedural >>of beancounter plus the wide variety in all the associated >>prerequisite modules. >> >> >>>Now I'm facing already the first hurdle when it comes to the >>>.gt/option file : in /usr/share/fonts/TTF/ my system keeps the >>>Liberation*.ttf files, which are described on the Debian wiki pages >>>as being compatible to Arial,Times an Courier. However, it is not >>>clear to me what files I have to use for GT and how it should be >>>written exactely in the options file. Actually, I found some messages >>>about fonts in the mailing list archive, but they are incomplete. >>>So,can you please help me out with some hints ? Thx, delix >> >> >>aloha Delix >> >>welcome to gt, hopefully we can get your font configuration setup correctly. >> >>frankly the font scheme used by gt is awful, but when configured correctly it >>seems to work fine and once configured there is little reason to change it so >>the pain is a one-time thing. >> >>the thing to recognize is the key, say Path::Font::Arial can have any value >>that represents a truetype font file, so this key-value pairing is fine: >> >> Path::Font::Helvetica /absolute/path/to/font/TrueType/LucidaTypewriterRegular.ttf >> >>if the value does indeed yield a truetype font file. >> >>first off you might try the web site -- there are two places that discuss font >>configuration, they are the getting install & setup page and the GT Config File >>page (about 1/2 way down) in the user's wiki. if you can write a better explanation >>than the one in the wiki please do so, and if you want to write a general fonts >>guidance (in pod or plain ascii) based on your experiences getting things configured >>i will see if it can be turned into official gt font config documentation ... >> >>meantime i'll give you what guidance i can in form of an example based on the >>locations of font files on a solaris system and explain what i change from these >>following three font config lines (from example on >>http://geniustrader.org/first_use.html web page) >> >> Path::Font::Arial /usr/X11R6/lib/X11/fonts/TrueType/arial.ttf >> Path::Font::Courier /usr/X11R6/lib/X11/fonts/TrueType/couri.ttf >> Path::Font::Times /usr/X11R6/lib/X11/fonts/TrueType/times.ttf >> >>solaris puts fonts in /usr/openwin/lib/X11/fonts, with truetype fonts >>in the subdir TrueType (capitals on unix and linux are significant). >> >>so here are my font configuration key-values >> >> # $FONT_ARIAL >> Path::Font::Arial /usr/openwin/lib/X11/fonts/TrueType/Arial.ttf >> # alias VeraMono as $FONT_FIXED >> Path::Font::Courier /usr/openwin/lib/X11/fonts/TrueType/VeraMono.ttf >> # $FONT_TIMES >> Path::Font::Times /usr/openwin/lib/X11/fonts/TrueType/TimesNewRoman.ttf >> >> >>ok, so it's likely you've already figured out this much but you still >>want to use your Liberation fonts. so just decide which Liberation faces >>you want to use for each of the gt defined fonts and assign the key-values >>accordingly. > > > I would guess then > Path::Font::Arial /usr/share/fonts/TTF/LiberationSans-Regular.ttf > Path::Font::Courier /usr/share/fonts/TTF/LiberationMono-Regular.ttf > Path::Font::Times /usr/share/fonts/TTF/LiberationSerif_Regular.ttf > > should be the right choice. > Instead the -Regular extension I have -Bold, -Italic,and so on -- that seems obviously the wrong option. ah! feel free to set the gt font key values to whatever truetype font file pathname that gives you the best image output. there's nothing in gt (or perl gd or even gd c lib) that makes Path::Font::Times from being set to .../LiberationSerif_BoldItalic.ttf if that gives you the look you want. grep thru the code for '$FONT_' to see default settings of gt config font keys are used for what parts of the image parts (titles, axis labels, etc) > > And then there is nothing else I have to change ? Wow , couldn't believe it can be so easy :-)) > > >>here are the gt defined font names (or keys) defined in GT/Graphics/Driver.pm: >> >> $FONT_ARIAL $FONT_TIMES $FONT_HELVETICA >> $FONT_SANS_SERIF $FONT_FIXED $FONT_PROPORTIONNAL $FONT_SERIF >> >>and here are how they are assigned (by default) in same module) >> >>$FONT_ARIAL = GT::Conf::get("Path::Font::Arial") >>|| die("Undefined font.\nPlease set the Path::Font::Arial value in the ~/.gt/options file.\n"); >>$FONT_TIMES = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; >>$FONT_HELVETICA = GT::Conf::get("Path::Font::Arial") || $FONT_ARIAL; >>$FONT_SANS_SERIF = GT::Conf::get("Path::Font::Arial") || $FONT_ARIAL; >>$FONT_FIXED = GT::Conf::get("Path::Font::Courier") || $FONT_ARIAL; >>$FONT_PROPORTIONNAL = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; >>$FONT_SERIF = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; >> >>note the perl variable name to gt font key associations -- that is the >>awful part, but how it works. >> >> >>these probably deserve an update to the following: >> >>$FONT_ARIAL = GT::Conf::get("Path::Font::Arial") >> || die( >>"Undefined font.\nPlease set the Path::Font::Arial value in the ~/.gt/options file.\n" >> ); >>$FONT_TIMES = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; >>$FONT_HELVETICA = GT::Conf::get("Path::Font::Helvetica") || $FONT_ARIAL; >>$FONT_SANS_SERIF = GT::Conf::get("Path::Font::Arial") || $FONT_ARIAL; >>$FONT_FIXED = GT::Conf::get("Path::Font::Courier") || $FONT_ARIAL; >>$FONT_PROPORTIONNAL = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; >>$FONT_SERIF = GT::Conf::get("Path::Font::Symbol") || $FONT_ARIAL; > > > this is really helpful to figure out what the font is supposed to look like -- maybe this is > all the problem was about > >> >>note carefully that in the absence of a key-value for any of the >>'other' font faces $FONT_ARIAL will be used, and if that font is >>unavailable or just misconfigured there will be no font graphics at all. >> >> >>hopefully some of this will help you get going, feel free to respond with >>questions if things continue to fail. but for us to help you much further >>we will need more details -- your complete $HOME/.gt/options file, maybe >>the output from `ls -l /usr/share/fonts/TTF`, the gt command line you are using, >>and any/all output from command including tty text and any graphic image >>file created, even if not an image file. >> >> >>good luck and enjoy the ride >> >>ras >> > > > Thanks a lot for the quick response and the very detailed descriptions. > I'm almost sure this won't be the last time I'll have to ask for some support :-)) > > I'm really glad to have found GT and the friendly welcome. I do some volunteer work > for a Liunx distri (ConnochaetOS) and do know how time consuming the maintainance and > user support can get. So I'll do my very best to solve problems on my own and see where > I can support the GT team and GT. > Thanks again -- great work ! thanks for the kind words -- feel free to yell for help if the myriad docs don't help or make things worse. and feel free to fix/enhance the user's wiki or submit improvements. sometime those too close to the code cannot explain things from a users viewpoint. ras |
|
From: Delix <del...@t-...> - 2012-07-04 20:14:23
|
On Wed, 04 Jul 2012 11:14:53 -0700 "Robert A. Schmied" <ra...@ac...> hatte geschrieben : > Delix wrote: > > Hi all ! May be it was not the best idea I ever had, but I'm trying > > at the moment to get familiar with Perl by starting to use > > geniustrader.... Hope this makes nobody upset :) > > why would you think that might make someone upset? Usually beginners should start with "hello world" and not with such complex things like GT :-) > > frankly this might be a good choice, because you will > likely have exposure to a wide variety of perl, from > the object-oriented flavor of gt to the more procedural > of beancounter plus the wide variety in all the associated > prerequisite modules. > > > > > Now I'm facing already the first hurdle when it comes to the > > .gt/option file : in /usr/share/fonts/TTF/ my system keeps the > > Liberation*.ttf files, which are described on the Debian wiki pages > > as being compatible to Arial,Times an Courier. However, it is not > > clear to me what files I have to use for GT and how it should be > > written exactely in the options file. Actually, I found some messages > > about fonts in the mailing list archive, but they are incomplete. > > So,can you please help me out with some hints ? Thx, delix > > > aloha Delix > > welcome to gt, hopefully we can get your font configuration setup correctly. > > frankly the font scheme used by gt is awful, but when configured correctly it > seems to work fine and once configured there is little reason to change it so > the pain is a one-time thing. > > the thing to recognize is the key, say Path::Font::Arial can have any value > that represents a truetype font file, so this key-value pairing is fine: > > Path::Font::Helvetica /absolute/path/to/font/TrueType/LucidaTypewriterRegular.ttf > > if the value does indeed yield a truetype font file. > > first off you might try the web site -- there are two places that discuss font > configuration, they are the getting install & setup page and the GT Config File > page (about 1/2 way down) in the user's wiki. if you can write a better explanation > than the one in the wiki please do so, and if you want to write a general fonts > guidance (in pod or plain ascii) based on your experiences getting things configured > i will see if it can be turned into official gt font config documentation ... > > meantime i'll give you what guidance i can in form of an example based on the > locations of font files on a solaris system and explain what i change from these > following three font config lines (from example on > http://geniustrader.org/first_use.html web page) > > Path::Font::Arial /usr/X11R6/lib/X11/fonts/TrueType/arial.ttf > Path::Font::Courier /usr/X11R6/lib/X11/fonts/TrueType/couri.ttf > Path::Font::Times /usr/X11R6/lib/X11/fonts/TrueType/times.ttf > > solaris puts fonts in /usr/openwin/lib/X11/fonts, with truetype fonts > in the subdir TrueType (capitals on unix and linux are significant). > > so here are my font configuration key-values > > # $FONT_ARIAL > Path::Font::Arial /usr/openwin/lib/X11/fonts/TrueType/Arial.ttf > # alias VeraMono as $FONT_FIXED > Path::Font::Courier /usr/openwin/lib/X11/fonts/TrueType/VeraMono.ttf > # $FONT_TIMES > Path::Font::Times /usr/openwin/lib/X11/fonts/TrueType/TimesNewRoman.ttf > > > ok, so it's likely you've already figured out this much but you still > want to use your Liberation fonts. so just decide which Liberation faces > you want to use for each of the gt defined fonts and assign the key-values > accordingly. I would guess then Path::Font::Arial /usr/share/fonts/TTF/LiberationSans-Regular.ttf Path::Font::Courier /usr/share/fonts/TTF/LiberationMono-Regular.ttf Path::Font::Times /usr/share/fonts/TTF/LiberationSerif_Regular.ttf should be the right choice. Instead the -Regular extension I have -Bold, -Italic,and so on -- that seems obviously the wrong option. And then there is nothing else I have to change ? Wow , couldn't believe it can be so easy :-)) > > here are the gt defined font names (or keys) defined in GT/Graphics/Driver.pm: > > $FONT_ARIAL $FONT_TIMES $FONT_HELVETICA > $FONT_SANS_SERIF $FONT_FIXED $FONT_PROPORTIONNAL $FONT_SERIF > > and here are how they are assigned (by default) in same module) > > $FONT_ARIAL = GT::Conf::get("Path::Font::Arial") > || die("Undefined font.\nPlease set the Path::Font::Arial value in the ~/.gt/options file.\n"); > $FONT_TIMES = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; > $FONT_HELVETICA = GT::Conf::get("Path::Font::Arial") || $FONT_ARIAL; > $FONT_SANS_SERIF = GT::Conf::get("Path::Font::Arial") || $FONT_ARIAL; > $FONT_FIXED = GT::Conf::get("Path::Font::Courier") || $FONT_ARIAL; > $FONT_PROPORTIONNAL = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; > $FONT_SERIF = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; > > note the perl variable name to gt font key associations -- that is the > awful part, but how it works. > > > these probably deserve an update to the following: > > $FONT_ARIAL = GT::Conf::get("Path::Font::Arial") > || die( > "Undefined font.\nPlease set the Path::Font::Arial value in the ~/.gt/options file.\n" > ); > $FONT_TIMES = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; > $FONT_HELVETICA = GT::Conf::get("Path::Font::Helvetica") || $FONT_ARIAL; > $FONT_SANS_SERIF = GT::Conf::get("Path::Font::Arial") || $FONT_ARIAL; > $FONT_FIXED = GT::Conf::get("Path::Font::Courier") || $FONT_ARIAL; > $FONT_PROPORTIONNAL = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; > $FONT_SERIF = GT::Conf::get("Path::Font::Symbol") || $FONT_ARIAL; this is really helpful to figure out what the font is supposed to look like -- maybe this is all the problem was about > > > note carefully that in the absence of a key-value for any of the > 'other' font faces $FONT_ARIAL will be used, and if that font is > unavailable or just misconfigured there will be no font graphics at all. > > > hopefully some of this will help you get going, feel free to respond with > questions if things continue to fail. but for us to help you much further > we will need more details -- your complete $HOME/.gt/options file, maybe > the output from `ls -l /usr/share/fonts/TTF`, the gt command line you are using, > and any/all output from command including tty text and any graphic image > file created, even if not an image file. > > > good luck and enjoy the ride > > ras > Thanks a lot for the quick response and the very detailed descriptions. I'm almost sure this won't be the last time I'll have to ask for some support :-)) I'm really glad to have found GT and the friendly welcome. I do some volunteer work for a Liunx distri (ConnochaetOS) and do know how time consuming the maintainance and user support can get. So I'll do my very best to solve problems on my own and see where I can support the GT team and GT. Thanks again -- great work ! -- Delix <lin...@t-...> |
|
From: Robert A. S. <ra...@ac...> - 2012-07-04 18:33:27
|
Jon Edwards wrote: > > I'm sure this is caused by something missing from the server I'm > attempting to run GT on butnot sure if my thinking is correct. > Running graphics.pl I get a whole bunch of ... graphic.pl: error: GD: > unable to generate text string, failing string: "Oct"error message: > Could not find/open font at > /home/palm/geniustrader/GT/Graphics/Driver/GD.pm line 582. Is this > due to missing c gd library libgd as mentioned in the documents or > something else ?If that's the case according to the same document I > can use one of SVG, Postscript::Simple or ImageMagick or is it > Image::Magick ?If I go down the alternate approach would I need to > change anything in GT or just install one or all of those modules ? > Thank you all ! Jon > aloha jon that error message is emitted from the custom ras hack version (available on request). it results when a text string bounding box fails to return the string bounding box coordinates. the error message is from either the perl GD module or the gd c library. and as it indicates, the font file being used isn't found. the best guess would be a bad font key-value setting or bad font file (not a truetype file). i don't think one can build/install the perl GD module without an appropriate gd c library, but i guess it would be possible for an os distribution to pair incompatible versions of them or ship the perl GD module without a gd c library. it's also possible to mis-configure perl so it might find incompatible versions of things... as i recall there's a lot of info about perl gd and gd c lib in the user's wiki i think. if you cannot find it yell and i will search it out. questions: * what does your $HOME/gt/option file font key-value lines look like? do the values list absolute paths to true type font files? * can you get any textual graphics to work or do they all fail? a minimal graphic.pl chart might be graphic.pl IBM -driver GD -out graphs/IBM.png this would use the default (arial) font for title and axis labels the addition of --add='text( "0123456789", 2, 85, left, center, large, black, fixed)' the font names (eg arial, fixed, times, courier) used in the graphics.pl graphic descriptions correspond to the perl font variables $FONT_ARIAL, $FONT_TIMES and $FONT_FIXED and in *ras hack gt versions* $FONT_HELVETICA plus an absolute path to a *ttf font file*: --add='text( "0123456789", 2, 65, left, center, large, black, /usr/openwin/lib/X11/fonts/TrueType/VeraBI.ttf )' * what does the ras hack Build.PL report? -- it should get an enhancement to check and validate a users $HOME/.gt/options font configuration ( assuming it doesn't yet ). (this perl script is generally available from http://geniustrader.org/first_use.html, look for 'for the bold and adventurous') if it isn't a simple font configuration issue: * have you tried to build and install the gd c library (first) and then the perl GD module or either one or none? * are you sure that perl is finding the correct versions of perl GD module and gd c library recommendations as to other gt graphic drivers: gd is the only one i use and enhance. the svg driver should work but it has not had a lot of support or enhancement. the others are real old and unmaintained. so if you live in your browser and it supports svg then that might be an acceptable option, but the others probably aren't. aloha ras > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference Exclusive live event will cover all > the ways today's security and threat landscape has changed and how IT > managers can respond. Discussions will include endpoint security, > mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ |
|
From: Robert A. S. <ra...@ac...> - 2012-07-04 18:30:37
|
Delix wrote: > Hi all ! May be it was not the best idea I ever had, but I'm trying > at the moment to get familiar with Perl by starting to use > geniustrader.... Hope this makes nobody upset :) why would you think that might make someone upset? frankly this might be a good choice, because you will likely have exposure to a wide variety of perl, from the object-oriented flavor of gt to the more procedural of beancounter plus the wide variety in all the associated prerequisite modules. > > Now I'm facing already the first hurdle when it comes to the > .gt/option file : in /usr/share/fonts/TTF/ my system keeps the > Liberation*.ttf files, which are described on the Debian wiki pages > as being compatible to Arial,Times an Courier. However, it is not > clear to me what files I have to use for GT and how it should be > written exactely in the options file. Actually, I found some messages > about fonts in the mailing list archive, but they are incomplete. > So,can you please help me out with some hints ? Thx, delix aloha Delix welcome to gt, hopefully we can get your font configuration setup correctly. frankly the font scheme used by gt is awful, but when configured correctly it seems to work fine and once configured there is little reason to change it so the pain is a one-time thing. the thing to recognize is the key, say Path::Font::Arial can have any value that represents a truetype font file, so this key-value pairing is fine: Path::Font::Helvetica /absolute/path/to/font/TrueType/LucidaTypewriterRegular.ttf if the value does indeed yield a truetype font file. first off you might try the web site -- there are two places that discuss font configuration, they are the getting install & setup page and the GT Config File page (about 1/2 way down) in the user's wiki. if you can write a better explanation than the one in the wiki please do so, and if you want to write a general fonts guidance (in pod or plain ascii) based on your experiences getting things configured i will see if it can be turned into official gt font config documentation ... meantime i'll give you what guidance i can in form of an example based on the locations of font files on a solaris system and explain what i change from these following three font config lines (from example on http://geniustrader.org/first_use.html web page) Path::Font::Arial /usr/X11R6/lib/X11/fonts/TrueType/arial.ttf Path::Font::Courier /usr/X11R6/lib/X11/fonts/TrueType/couri.ttf Path::Font::Times /usr/X11R6/lib/X11/fonts/TrueType/times.ttf solaris puts fonts in /usr/openwin/lib/X11/fonts, with truetype fonts in the subdir TrueType (capitals on unix and linux are significant). so here are my font configuration key-values # $FONT_ARIAL Path::Font::Arial /usr/openwin/lib/X11/fonts/TrueType/Arial.ttf # alias VeraMono as $FONT_FIXED Path::Font::Courier /usr/openwin/lib/X11/fonts/TrueType/VeraMono.ttf # $FONT_TIMES Path::Font::Times /usr/openwin/lib/X11/fonts/TrueType/TimesNewRoman.ttf ok, so it's likely you've already figured out this much but you still want to use your Liberation fonts. so just decide which Liberation faces you want to use for each of the gt defined fonts and assign the key-values accordingly. here are the gt defined font names (or keys) defined in GT/Graphics/Driver.pm: $FONT_ARIAL $FONT_TIMES $FONT_HELVETICA $FONT_SANS_SERIF $FONT_FIXED $FONT_PROPORTIONNAL $FONT_SERIF and here are how they are assigned (by default) in same module) $FONT_ARIAL = GT::Conf::get("Path::Font::Arial") || die("Undefined font.\nPlease set the Path::Font::Arial value in the ~/.gt/options file.\n"); $FONT_TIMES = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; $FONT_HELVETICA = GT::Conf::get("Path::Font::Arial") || $FONT_ARIAL; $FONT_SANS_SERIF = GT::Conf::get("Path::Font::Arial") || $FONT_ARIAL; $FONT_FIXED = GT::Conf::get("Path::Font::Courier") || $FONT_ARIAL; $FONT_PROPORTIONNAL = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; $FONT_SERIF = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; note the perl variable name to gt font key associations -- that is the awful part, but how it works. these probably deserve an update to the following: $FONT_ARIAL = GT::Conf::get("Path::Font::Arial") || die( "Undefined font.\nPlease set the Path::Font::Arial value in the ~/.gt/options file.\n" ); $FONT_TIMES = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; $FONT_HELVETICA = GT::Conf::get("Path::Font::Helvetica") || $FONT_ARIAL; $FONT_SANS_SERIF = GT::Conf::get("Path::Font::Arial") || $FONT_ARIAL; $FONT_FIXED = GT::Conf::get("Path::Font::Courier") || $FONT_ARIAL; $FONT_PROPORTIONNAL = GT::Conf::get("Path::Font::Times") || $FONT_ARIAL; $FONT_SERIF = GT::Conf::get("Path::Font::Symbol") || $FONT_ARIAL; note carefully that in the absence of a key-value for any of the 'other' font faces $FONT_ARIAL will be used, and if that font is unavailable or just misconfigured there will be no font graphics at all. hopefully some of this will help you get going, feel free to respond with questions if things continue to fail. but for us to help you much further we will need more details -- your complete $HOME/.gt/options file, maybe the output from `ls -l /usr/share/fonts/TTF`, the gt command line you are using, and any/all output from command including tty text and any graphic image file created, even if not an image file. good luck and enjoy the ride ras |
|
From: Jon E. <fo...@ho...> - 2012-07-04 16:52:04
|
I'm sure this is caused by something missing from the server I'm attempting to run GT on butnot sure if my thinking is correct. Running graphics.pl I get a whole bunch of ... graphic.pl: error: GD: unable to generate text string, failing string: "Oct"error message: Could not find/open font at /home/palm/geniustrader/GT/Graphics/Driver/GD.pm line 582. Is this due to missing c gd library libgd as mentioned in the documents or something else ?If that's the case according to the same document I can use one of SVG, Postscript::Simple or ImageMagick or is it Image::Magick ?If I go down the alternate approach would I need to change anything in GT or just install one or all of those modules ? Thank you all ! Jon |
|
From: Delix <del...@t-...> - 2012-07-04 07:59:16
|
Hi all ! May be it was not the best idea I ever had, but I'm trying at the moment to get familiar with Perl by starting to use geniustrader.... Hope this makes nobody upset :) Now I'm facing already the first hurdle when it comes to the .gt/option file : in /usr/share/fonts/TTF/ my system keeps the Liberation*.ttf files, which are described on the Debian wiki pages as being compatible to Arial,Times an Courier. However, it is not clear to me what files I have to use for GT and how it should be written exactely in the options file. Actually, I found some messages about fonts in the mailing list archive, but they are incomplete. So,can you please help me out with some hints ? Thx, delix -- Delix <lin...@t-...> |
|
From: Robert A. S. <ra...@ac...> - 2012-02-22 17:36:30
|
Evgeny Shragovich wrote:
> Hi Robert, all,
>
>
> Thank you for your explanations!
aloha evgeny
now that things are 'working' be sure to review the myriad bits of
documentation, both in the perl code (pod) and on the website
-- the FAQ, screenshots and the user guide which is open to all
(after registering) for improving, based on actual user experience.
in addition there are some pod files in GT/Docs/*.pod that might
(possibly) helpful. for example:
% perldoc -t ../GT/Docs/gt_sig-sys-desc.pod
> First of all, I apologize for not mentioning my little fixes and thus
> making your life harder :)
no problem, but if the comma separator wasn't working that would
certainly qualify as a bug ...
and that brings up the recent changes to the trunk-head. if you can
please upgrade to the new files -- they should work without any change
to your configuration files, and warn about a quoted 'marker' value
plus should 'fix' the 1jan1970 date epoch problem.
>
>
> After reviewing my data, I've found the problem which was causing my graphs
> to look "funny".
> It seems that I've mixed up between "Close" and "Adjusted Close" values.
i don't see how i missed that, guess it is time for new glasses ;-)
> So I configured my options file to use "Close" values (instead of "Adjusted
> Close") and the graphs appearance became normal!
>
> I guess that this is what was causing the incorrect CLOSE prices and odd
> data you mentioned.
>
>
> Regards,
> Evgeny
>
best of luck
aloha
ras
< snip >
|
|
From: Evgeny S. <shr...@gm...> - 2012-02-22 07:22:00
|
Hi Robert, all,
Thank you for your explanations!
First of all, I apologize for not mentioning my little fixes and thus
making your life harder :)
After reviewing my data, I've found the problem which was causing my graphs
to look "funny".
It seems that I've mixed up between "Close" and "Adjusted Close" values.
So I configured my options file to use "Close" values (instead of "Adjusted
Close") and the graphs appearance became normal!
I guess that this is what was causing the incorrect CLOSE prices and odd
data you mentioned.
Regards,
Evgeny
>
> Today's Topics:
>
> 1. Re: shragovich initial setup (Robert A. Schmied)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 20 Feb 2012 10:05:06 -0800
> From: "Robert A. Schmied" <ra...@ac...>
> Subject: Re: [GT] shragovich initial setup
> To: gen...@li...
> Message-ID: <4F4...@ac...>
> Content-Type: text/plain; charset="us-ascii"
>
> aloha evgeny
>
> my comments are embedded below
>
> the attached shows why your charts are 'funny' -- basically
> invalid data.
>
> ras
>
>
> Evgeny Shragovich wrote:
> > Hi Robert, gt'ers,
> >
> >
> > Thank you for your analysis and comments!
> >
> > 1) I've corrected the DB::text::marker configuration in my options file.
> > Previously I just set the separator in the Text.pm file itself since it
> was
> > not working for me when setting it in options file.
>
> i've done two things in an effort to aid in this area, one is over-kill,
> the other is pod so it will help no-one. i've added a warning in
> GT:Prices:loadtxt
> that will issue a warning on stderr if $marker is quoted, the pod was
> added to
> GT:DB:Text to caution users *not to quote* any values in their
> $HOME/.gt/options file.
>
> > This was probably due to the fact that I quoted the comma character. Now
> > it's fine.
>
> it would have been helpful if you mention this hack of yours first ...
>
> any other 'fixes' you want to share?
>
> >
> >
> > 2) The DB::text::header_lines - was also corrected.
> >
> >
> > 3) Robert, do you meant that the following characters was appearing in my
> > IBMREV.txt file? :
> >
> > * volume --^^^^^^ ||||
> > ++++---- close*
>
> my mis-communication -- i was attempting to point out that the volume
> field looked *incorrect*.
>
> based on the quoted part cut+paste below it looks like two asterisk
> got embedded into the price data line.
>
> >>3) something appears to be amiss with respect to the market close data
> >>field
> >> 1970-01-02,364.50,365.75,364.**00,364.75,315200,6.60
> >> volume --^^^^^^ ||||
> >> ++++---- close
> >>
> >> but it is just bad data -- the DB::text::fields assigned appear to be
> >>correct.
> >>
>
> removed the asterisk in the bit below:
> 1970-01-02,364.50,365.75,364.00,364.75,315200,6.60
> volume --^^^^^^ ||||
> ++++---- close
>
> the line just above the line(s) containing the words 'volume' and 'close'
> was a line extracted from your ibmrev data file. all dates i looked at to
> investigate the date epoch problem and db:text:field index values had what
> looked like truncated closing values.
>
> more looking (see your abnormality below) has made the issue less
> clear as to what this closing data field problem is, but it is a
> problem that needs correcting.
>
> >
> > If yes, that's strange since I can't see in here locally..
> >
> >
> > 4) Thank you for explaining the limitation with dates prior to
> 1970-01-01.
> > In fact I can live without working with these dates, so I'll just delete
> > all data prior to 1970-01-10 from my files.
> >
> >
> > 5) I installed the missing Perl packages to eliminate future problems:
> > HTML::Mason
> > Log::Log4perl
> > Image::Magick
> > PostScript::Simple
> > SVG
> >
> >
> >
> > Now, after playing around with some dates in screenshot_1.gconf I've
> > encountered* additional abnormality*.
>
> you have not mentioned any corrective action regarding the close price
> problem i note above. by default, close is the price used for any {i:price}
> indicator and is why your chart is the way it is.
>
> check your data files. the attached is a side by side comparison between
> your ibmrev and my *yahoo* ibm close data. not a lot of difference in
> this time-frame but some -- but look closely at the early data -- it is
> really odd.
>
>
> > It seems that for certain time ranges the graph is plotted incorrectly.
> > When I hit these problematic dates, only RED candlesticks appear and
> their
> > parameters (Open, Close, ...) do not reflect the reality.
> >
> > The curious thing about this issue is that I have encountered this
> > abnormality in both files (AREV.txt and IBMREV.txt),
> > but for different time ranges. As an example I've attached an example of
> > IBMREV graph with such abnormality.
> > The graph with similar screenshot_1.gconf settings was plotted correctly!
> > The attached screenshot become normal again around 2011/07 dates!
> >
> >
> > Below is the screenshot_1.gconf I've used:
> > --start=2010-05-05
> > --end=2011-12-12
> > --timeframe=day
> > --title=ScreenShot 1: %c
> > --type=candle
> > --add=MountainBand(Indicators::BOL/2 20 2.0,Indicators::BOL/3 15 2.0, \
> > [160,160,0,100])
> > --add=Curve(Indicators::SMA 100, [0,0,0])
> > --add=Curve(Indicators::SMA 20, [0,0,255])
> > --add=Curve(Indicators::SMA 5, [255,0,0])
> > --add=VotingLine( Systems::Generic \
> > { S:Generic:Above {I:Prices CLOSE} {I:BOL/2 20 2.0} } \
> > { S:Generic:Below {I:Prices CLOSE} {I:BOL/3 15 2.0} }, 4 )
> > --add=New-Zone(6)
> > --add=New-Zone(75)
> > --add=Histogram(Indicators::MACD/3,lightblue)
> > --add=Curve(Indicators::MACD,[0,0,255])
> > --add=Curve(Indicators::MACD/2,[255,0,0])
> > --add=Text(MACD, 50, 50, center, center, giant, [80,160,240,70], times)
> > --add=New-Zone(6)
> > --add=New-Zone(75)
> > --add=Curve(Indicators::ADX/4,[0,0,128])
> > --add=Curve(Indicators::ADX/1,[0,128,0])
> > --add=Curve(Indicators::ADX/2,[199,199,199])
> > --add=Curve(Indicators::ADX/3,[128,0,0])
> > --add=MountainBand(Indicators::Generic::Eval \
> > 0,Indicators::Generic::Eval \
> > min(20,{Indicators::ADX/4}),[128,128,0,100])
> > --add=MountainBand(Indicators::Generic::Eval \
> > min(20,{Indicators::ADX/4}),Indicators::ADX/4,[228,128,0,100])
> > --add=Curve(Indicators::Generic::Eval 20,[0,0,255])
> > --add=Text(ADX, 50, 50, center, center, giant, [80,160,240,70], times)
> >
> >
> > The command I used is:
> > graphic.pl --file screenshot_1.gconf --out 'Screenshot 116.png' IBMREV
> > *
> >
> > P.S.* Initially I assumed that maybe one of the begin/end dates do not
> > exists due to weekends or holidays but that's not the issue.
> >
> >
> >
> > Any idea why such strange behavior might occur?
> >
> >
> > Thanks a lot!!
> > Eugene S
> >
> >
> >
>
>
> << big snip >>
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: evgeny_ibm_close_diff
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
>
> ------------------------------
>
> _______________________________________________
> Geniustrader-devel mailing list
> Gen...@li...
> https://lists.sourceforge.net/lists/listinfo/geniustrader-devel
>
>
> End of Geniustrader-devel Digest, Vol 10, Issue 5
> *************************************************
>
--
Best regards,
Shragovich Evgeny
shr...@gm...
|
|
From: Robert A. S. <ra...@ac...> - 2012-02-20 22:37:41
|
gt'ers
update to trunk-HEAD
i've update a couple files that *should* be all that is needed to
remove the unix date epoch problem -- data files with pre-1jan1970
should work now without problem, but my testing is limited and i
may have missed something.
if you try this new version and run into anything that works wrong
or unexpectely different compared to the prior version report it
and i'll get it fixed immediately.
aloha
ras
ps -- files involved
GT/Prices.pm
GT/DateTime.pm
GT/BackTest.pm
GT/DB/Text.pm
note the files in subdir GT/DateTime are no longer
used/needed but i've not removed them yet -- ras
|
|
From: Robert A. S. <ra...@ac...> - 2012-02-20 18:05:18
|
aloha evgeny
my comments are embedded below
the attached shows why your charts are 'funny' -- basically
invalid data.
ras
Evgeny Shragovich wrote:
> Hi Robert, gt'ers,
>
>
> Thank you for your analysis and comments!
>
> 1) I've corrected the DB::text::marker configuration in my options file.
> Previously I just set the separator in the Text.pm file itself since it was
> not working for me when setting it in options file.
i've done two things in an effort to aid in this area, one is over-kill,
the other is pod so it will help no-one. i've added a warning in GT:Prices:loadtxt
that will issue a warning on stderr if $marker is quoted, the pod was added to
GT:DB:Text to caution users *not to quote* any values in their $HOME/.gt/options file.
> This was probably due to the fact that I quoted the comma character. Now
> it's fine.
it would have been helpful if you mention this hack of yours first ...
any other 'fixes' you want to share?
>
>
> 2) The DB::text::header_lines - was also corrected.
>
>
> 3) Robert, do you meant that the following characters was appearing in my
> IBMREV.txt file? :
>
> * volume --^^^^^^ ||||
> ++++---- close*
my mis-communication -- i was attempting to point out that the volume
field looked *incorrect*.
based on the quoted part cut+paste below it looks like two asterisk
got embedded into the price data line.
>>3) something appears to be amiss with respect to the market close data
>>field
>> 1970-01-02,364.50,365.75,364.**00,364.75,315200,6.60
>> volume --^^^^^^ ||||
>> ++++---- close
>>
>> but it is just bad data -- the DB::text::fields assigned appear to be
>>correct.
>>
removed the asterisk in the bit below:
1970-01-02,364.50,365.75,364.00,364.75,315200,6.60
volume --^^^^^^ ||||
++++---- close
the line just above the line(s) containing the words 'volume' and 'close'
was a line extracted from your ibmrev data file. all dates i looked at to
investigate the date epoch problem and db:text:field index values had what
looked like truncated closing values.
more looking (see your abnormality below) has made the issue less
clear as to what this closing data field problem is, but it is a
problem that needs correcting.
>
> If yes, that's strange since I can't see in here locally..
>
>
> 4) Thank you for explaining the limitation with dates prior to 1970-01-01.
> In fact I can live without working with these dates, so I'll just delete
> all data prior to 1970-01-10 from my files.
>
>
> 5) I installed the missing Perl packages to eliminate future problems:
> HTML::Mason
> Log::Log4perl
> Image::Magick
> PostScript::Simple
> SVG
>
>
>
> Now, after playing around with some dates in screenshot_1.gconf I've
> encountered* additional abnormality*.
you have not mentioned any corrective action regarding the close price
problem i note above. by default, close is the price used for any {i:price}
indicator and is why your chart is the way it is.
check your data files. the attached is a side by side comparison between
your ibmrev and my *yahoo* ibm close data. not a lot of difference in
this time-frame but some -- but look closely at the early data -- it is really odd.
> It seems that for certain time ranges the graph is plotted incorrectly.
> When I hit these problematic dates, only RED candlesticks appear and their
> parameters (Open, Close, ...) do not reflect the reality.
>
> The curious thing about this issue is that I have encountered this
> abnormality in both files (AREV.txt and IBMREV.txt),
> but for different time ranges. As an example I've attached an example of
> IBMREV graph with such abnormality.
> The graph with similar screenshot_1.gconf settings was plotted correctly!
> The attached screenshot become normal again around 2011/07 dates!
>
>
> Below is the screenshot_1.gconf I've used:
> --start=2010-05-05
> --end=2011-12-12
> --timeframe=day
> --title=ScreenShot 1: %c
> --type=candle
> --add=MountainBand(Indicators::BOL/2 20 2.0,Indicators::BOL/3 15 2.0, \
> [160,160,0,100])
> --add=Curve(Indicators::SMA 100, [0,0,0])
> --add=Curve(Indicators::SMA 20, [0,0,255])
> --add=Curve(Indicators::SMA 5, [255,0,0])
> --add=VotingLine( Systems::Generic \
> { S:Generic:Above {I:Prices CLOSE} {I:BOL/2 20 2.0} } \
> { S:Generic:Below {I:Prices CLOSE} {I:BOL/3 15 2.0} }, 4 )
> --add=New-Zone(6)
> --add=New-Zone(75)
> --add=Histogram(Indicators::MACD/3,lightblue)
> --add=Curve(Indicators::MACD,[0,0,255])
> --add=Curve(Indicators::MACD/2,[255,0,0])
> --add=Text(MACD, 50, 50, center, center, giant, [80,160,240,70], times)
> --add=New-Zone(6)
> --add=New-Zone(75)
> --add=Curve(Indicators::ADX/4,[0,0,128])
> --add=Curve(Indicators::ADX/1,[0,128,0])
> --add=Curve(Indicators::ADX/2,[199,199,199])
> --add=Curve(Indicators::ADX/3,[128,0,0])
> --add=MountainBand(Indicators::Generic::Eval \
> 0,Indicators::Generic::Eval \
> min(20,{Indicators::ADX/4}),[128,128,0,100])
> --add=MountainBand(Indicators::Generic::Eval \
> min(20,{Indicators::ADX/4}),Indicators::ADX/4,[228,128,0,100])
> --add=Curve(Indicators::Generic::Eval 20,[0,0,255])
> --add=Text(ADX, 50, 50, center, center, giant, [80,160,240,70], times)
>
>
> The command I used is:
> graphic.pl --file screenshot_1.gconf --out 'Screenshot 116.png' IBMREV
> *
>
> P.S.* Initially I assumed that maybe one of the begin/end dates do not
> exists due to weekends or holidays but that's not the issue.
>
>
>
> Any idea why such strange behavior might occur?
>
>
> Thanks a lot!!
> Eugene S
>
>
>
<< big snip >>
|
|
From: Robert A. S. <ra...@ac...> - 2012-02-20 01:10:10
|
evgeny my responses/comments embedded in context below there's a lot here -- go over it carefully and completely. aloha ras > Subject: > Re: [GT] Using DB::module Text options and data representation with > graphic.pl > From: > Evgeny Shragovich <shr...@gm...> > Date: > Sun, 19 Feb 2012 19:28:02 +0200 > To: > "Robert A. Schmied" <ra...@ac...> > > To: > "Robert A. Schmied" <ra...@ac...> > CC: > gen...@li... > > > Hi Robert, gt'ers! > > > It seems that my last 2 mails were not delivered successfully for some > reason so here I will summarize the progress I've made meanwhile and also > attach requested info. > > > So the first thing I've done - is to install the last version of GT code as > recommended by Robert. > I've created new directory: /home/evgeny/workspace/market/gt_head/ and then > used subversion tool to obtain the code, as follows: > *svn checkout > https://geniustrader.svn.sourceforge.net/svnroot/geniustrader/trunk/ .* > I've changed the path setting accordingly. > > > Then I tried to create some graphs using my EOD data text files. > For example I've chosen 2 files: AREV.txt and IBMREV.txt. > AREV.txt contains EOD data of the following range: > 1999-11-18 ~ 2012-02-03 > And IBMREV.txt: > 1962-01-02 ~ 2012-02-03 > > I managed to create successful plots based on AREV.txt(attached) data file > while modifying the following configuration parameters in > screenshot_1.gconf file: > * Zones > * Timeframes > * Start/End dates > > However I got the following error when trying to create a graph based on my > IBMREV.txt file with similar screenshot_1.gconf file! : > *Day too big - 33605 > 24853 > Cannot handle date (0, 0, 0, 03, 0, 2062) at ../GT/DateTime/Day.pm line 24* yep -- this is the unix date epoch problem -- you can confirm using a command line something like the following using *NON-MODIFIED IBMREV.txt DATA* meaning your original IBMREV.txt data that starts on 1962-01-02 and ends 2012-02-03. $ graphic.pl --file screenshot_1.gconf --out 'ibm_40yrs.png' \ --start 1970-01-05 --end 2012-02-03 IBMREV the date epoch is 1 jan 1970 -- is it coded into os and perl. it counts the seconds since that moment in time. any date-time prior to that will fail. if you *must* analyze market data prior to 1 jan 1970 you will have to install the ras-hack version of gt -- i make it available only upon *request*. it comes in three tarballs, one for the gt top level dir, and each subdir Scripts and GT. tld is 1MB, scripts is 1.1MB and gt is 0.6MB. it is (mostly) user-api compatible with the trunk-HEAD version. ok -- my analyzes are complete -- my findings: your options file needs some changes 1) the default separator (DB::text::marker) is the tab char so you need to add the line DB::text::marker , do not quote the comma character the clue came when i tried: $ ./display_indicator.pl --start 2002-01-02 --end 2002-03-25 I:Prices IBMX DATE and got stuff like Prices[DATE] [2002-01-02,120.60,121.50,119.80,121.50,6862800,106.46] = 2002-01-02,120.60,121.50,119.80,121.50,6862800,106.46 Prices[DATE] [2002-01-03,121.50,124.22,120.25,123.66,8621700,108.36] = 2002-01-03,121.50,124.22,120.25,123.66,8621700,108.36 and i have made an improvement in GT::Prices to handle this sort of error a little bit more helpfully ... 2) i don't see any header lines in the ibmrev data files but the recent arev.txt data file appears to have a corrupt 1st line so you need to change the line DB::text::header_lines 1 to DB::text::header_lines 0 3) something appears to be amiss with respect to the market close data field 1970-01-02,364.50,365.75,364.00,364.75,315200,6.60 volume --^^^^^^ |||| ++++---- close but it is just bad data -- the DB::text::fields assigned appear to be correct. 4) text based (maybe even databased) data files *without* the ras-hack correcting the unix date epoch issue *cannot* have any dates prior to 1970-01-01. i have confirmed this with your ibm database (IBM.txt) and a modified version starting at 1970-01-02 (IBMX.txt) for both the current trunk-head and with my ras-hack version using this basic command: $ ./display_indicator.pl --start 1970-01-05 --end 1970-01-30 I:Prices <market> 'CLOSE' the ras-hack version works using the non-modified <market> file (note my display_indicator.pl is more designed as a debug tool hence all this extra verbiage) % ./display_indicator.pl --start 1970-01-05 --end 1970-01-30 I:Prices IBM 'CLOSE' Indicator I:Prices has 1 value ... all values selected I:Prices/1 <=> Prices[CLOSE] pre check dates: $start=1970-01-05 $end=1970-01-30 calculator indexes: $first=1988 $last=2007 post check dates: $start=1970-01-05 00:00:00 <=> $first=1988 $end =1970-01-30 00:00:00 <=> $last =2007 timeframe day, time periods 1988 .. 2007 Calculating indicator ... doin' the 99: $ival=99, $nb_val=1 but now: $ival=0, $nb_val=1 indicator name "Prices[CLOSE]" interval: 1988 .. 2007 Prices[CLOSE] [1970-01-05] = 6.6600 Prices[CLOSE] [1970-01-06] = 6.6600 Prices[CLOSE] [1970-01-07] = 6.6700 . . . and for good measure % ./display_indicator.pl --start 1965-01-04 --end 1965-01-15 I:Prices IBM 'CLOSE' Indicator I:Prices has 1 value ... all values selected I:Prices/1 <=> Prices[CLOSE] pre check dates: $start=1965-01-04 $end=1965-01-15 calculator indexes: $first=756 $last=765 post check dates: $start=1965-01-04 00:00:00 <=> $first=756 $end =1965-01-15 00:00:00 <=> $last =765 timeframe day, time periods 756 .. 765 Calculating indicator ... doin' the 99: $ival=99, $nb_val=1 but now: $ival=0, $nb_val=1 indicator name "Prices[CLOSE]" interval: 756 .. 765 Prices[CLOSE] [1965-01-04] = 2.3900 Prices[CLOSE] [1965-01-05] = 2.3800 Prices[CLOSE] [1965-01-06] = 2.4100 Prices[CLOSE] [1965-01-07] = 2.4600 Prices[CLOSE] [1965-01-08] = 2.5100 Prices[CLOSE] [1965-01-11] = 2.4900 Prices[CLOSE] [1965-01-12] = 2.5000 Prices[CLOSE] [1965-01-13] = 2.5000 Prices[CLOSE] [1965-01-14] = 2.5200 Prices[CLOSE] [1965-01-15] = 2.5600 the gt trunk-head fails when <market> is IBM: Can't handle date (0, 0, 0, 02, 0, 162) at ../GT/DateTime/Day.pm line 24 but is fine when <market> is IBMX: Calculating indicator Prices[CLOSE] ... Prices[CLOSE] [1970-01-05] = 6.3700 Prices[CLOSE] [1970-01-06] = 6.3700 Prices[CLOSE] [1970-01-07] = 6.3800 Prices[CLOSE] [1970-01-08] = 6.3900 Prices[CLOSE] [1970-01-09] = 6.3800 Prices[CLOSE] [1970-01-12] = 6.3600 Prices[CLOSE] [1970-01-13] = 6.4700 Prices[CLOSE] [1970-01-14] = 6.4600 Prices[CLOSE] [1970-01-15] = 6.6000 Prices[CLOSE] [1970-01-16] = 6.3900 Prices[CLOSE] [1970-01-19] = 6.0500 Prices[CLOSE] [1970-01-20] = 6.1600 Prices[CLOSE] [1970-01-21] = 6.1400 Prices[CLOSE] [1970-01-22] = 6.1600 Prices[CLOSE] [1970-01-23] = 6.1600 Prices[CLOSE] [1970-01-26] = 6.0300 Prices[CLOSE] [1970-01-27] = 5.9700 Prices[CLOSE] [1970-01-28] = 5.9000 Prices[CLOSE] [1970-01-29] = 5.8500 Prices[CLOSE] [1970-01-30] = 5.8000 note the incorrect close price values, but the indicator works. and lastly using the trunk-head and modified <market> file and this line % graphic.pl --file /tmp/evgeny_screenshot_1.gconf --out /tmp/ibm_not50yrs.png \ --start 1970-01-05 --end 2012-02-03 IBMX your chart is attached notice that it isn't 50 years of data, because the gconf file specifies --start=2011-01-03 --end=2012-02-10 which override the command line, but comment these two lines out (e.g. # --start=2011-01-03 # --end=2012-02-10 and run the command % graphic.pl --file /tmp/evgeny_screenshot_1.gconf --out /tmp/ibm_50yrs.png \ --start 1970-01-05 --end 2012-02-03 IBMX and it takes a long, long, long, long, long time ... i canceled it after 20 or more minutes ... but it was working and would write the image if computer resources allowed/ > > I tried to modify the IBMREV.txt file and deleted most of the data in it, > leaving only a shorter range of dates (I renamed the file to IBMREVV.txt > and attached it to this mail): > 1962-01-02 ~ 1965-07-28 (only 3 years) > I changed the range accordingly in screenshot_1.gconf to be: > --start=1964-01-01 > --end=1964-12-12 > But in this case I've received a *similar* error. you are still using data prior to the unix date epoch. > > > I ran the (revised) Build.pl script and below are the results (Please note > that I had some errors of type: > *Bareword "Test::More" not allowed while "strict subs" in use at ./Build.PL > line 100*. So I had to comment "use strict" line to get the script working). interesting, with my old perl 5.6.2 i don't have that issue ... could be old version of Module::Build, i'm using 0.2805 could be i don't understand the implications of use strict but it's been removed in the next version. > > *Build.PL release: 1.16 > GT release is: not available expected -- you don't have the ras-hack version > > Checking prerequisites... > requires: > ! HTML::Mason is not installed i'm thinking 'HTML::Mason' is important if you use any of the html stuff ... check the documentation for things like backtest*.pl, and scan.pl. > ! Log::Log4perl is not installed only needed for in-depth debugging and logging > recommends: > * Image::Magick is not installed > * PostScript::Simple is not installed > * SVG is not installed > > Checking optional features... > beancounter............disabled > requires: > ! Finance::BeanCounter is not installed > beancounter_support....disabled > requires: > ! Finance::BeanCounter is not installed > ! Statistics::Descriptive is not installed > odbc_support...........disabled > requires: > ! DBD::ODBC is not installed > pg_support.............disabled > requires: > ! DBD::Pg is not installed > sqlite2_support........disabled > requires: > ! DBD::SQLite2 is not installed > > ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the > versions > of the modules indicated above before proceeding with this installation > > Run 'Build installdeps' to install missing prerequisites. > > No 'module_name' was provided and it could not be inferred > from other properties. This will prevent a packlist from > being written for this file. Please set either 'module_name' > or 'dist_version_from' in Build.PL. > yea! you have the perl module DBI, which is absolutely needed for GT if you > intend to use any sql based price database. let's see which DBI/DBD drivers > you have available ... > mysql, SQLite, > > > CSV > humm: you have perl modules needed to use the GT CSV driver. > THIS IS TOTALLY EXPERIMENTAL that means that you are on your own with this > -- refer to pod in GT/DB/CSV.pm. > > MySQL > facinating! it is nice that you have perl modules needed to use a mysql > based database so a beancounter installation could run on a mysql db. > > SQLite > ok! you have the perl modules needed for sqlite db support, so a > beancounter > installation could run on this sqlite db. > > genericdb > humm: you have perl modules needed to use any sql database with GT if you > can define the necessary sql statments needed to query the database for > prices (open, high, low, close, volume and date tuples are needed per > symbol), plus optionally the securities name. for more details refer > to the pod in GT/DB/genericdb.pm. > > > excellent! your platform supports symlinks, so if you want i can create > symlinks for each of the gt application scripts without that damned .pl > extension ... it saves a bit of typing the command lines. > > do you want the symlinks? y/[n]* > > > It seems that the output of the script is similar to the previous one. yep -- helpful when analyzing new-install problems remotely > > > Please find attached tar with following files: > 1. AREV.txt > 2. IBMREVV.txt > 3. options > 4. Screenshot 111.png - Example of a graph based on AREV.txt file > 5. screenshot_1.gconf > > > Please let me know if any more info needed and I will provide it as soon as > possible! hope all this helps some ... to summarize: a) you need to fix a couple things in your options file. b) you need to be aware that gconf clauses over-ride command line options. it's a long-standing defect that i may have worked around in ras-hack. c) you need to limit all market data files to start after 1 jan 1970 or request and use the ras-hack gt version. d) there might be something amiss with your closing market data, at least for the ibm example data. please keep us posted on your progress or lack thereof ... ras > > > Thanks! > Eugene S > > > > > On Thu, Feb 9, 2012 at 12:04 AM, Robert A. Schmied <ra...@ac...> wrote: > > >>Robert A. Schmied wrote: >> >> >>>< prior content removed > >>> >>>evgeny >>> >>> >> >>< snip > >> >> >> >>>3) *Build.PL* different output is to be expected ... >>> i don't like the message >>> Date::Manip (6.25) is installed, but we need version < 6.0 >>> will look into it -- this could be an issue, but i don't know how >>> A worked but not IBM. >>> >>> >> >>Date::Manip 6 is a complete rewrite, i don't recall if i was unable to >>get it to build with old perl 5.6.2 or what, so that is why i put in the >>caveat >> Date::Manip => '>= 5.44, != 5.45, != 5.46, < 6.0', >> >>i do recall that 5.44 .. 5.46 were ng here. but i figure if 6.25 works >>ok for you then i need to tweak this version check some -- for what it is >>worth i'm at 5.54 and the last rev in the 5 series is 5.56. but cpan is >>only offering version 6.30 now, so you might want to upgrade to that >>version >>there are likely good reasons for not listing earlier 6 series versions. >> >> >>by the way -- the unix date epoch problem isn't related to Date::Manip >>but to general perl/os limitations. my experimental solution has revised >>gts' date handling methods to not use any of problematic perl/os >>facilities. >> >>and the reason i haven't committed it (and much other ras-hack) is >>primarily >>due to contentious issues regarding gt app-script option handling and other >>gt resource file directory paths. see the devel archive for the dirty >>details. >> >> >>please keep us informed regarding your progress, and yell if you continue >>to >>run into problems ... >> >> >>aloha >> >>ras >> >> >>< snip > >> > > |
|
From: Robert A. S. <ra...@ac...> - 2012-02-19 01:10:57
|
gt'ers just checking if the list is wedged ... aloha ras |
|
From: Robert A. S. <ra...@ac...> - 2012-02-08 22:04:14
|
Robert A. Schmied wrote:
> < prior content removed >
>
> evgeny
>
< snip >
>
> 3) *Build.PL* different output is to be expected ...
> i don't like the message
> Date::Manip (6.25) is installed, but we need version < 6.0
> will look into it -- this could be an issue, but i don't know how
> A worked but not IBM.
>
Date::Manip 6 is a complete rewrite, i don't recall if i was unable to
get it to build with old perl 5.6.2 or what, so that is why i put in the
caveat
Date::Manip => '>= 5.44, != 5.45, != 5.46, < 6.0',
i do recall that 5.44 .. 5.46 were ng here. but i figure if 6.25 works
ok for you then i need to tweak this version check some -- for what it is
worth i'm at 5.54 and the last rev in the 5 series is 5.56. but cpan is
only offering version 6.30 now, so you might want to upgrade to that version
there are likely good reasons for not listing earlier 6 series versions.
by the way -- the unix date epoch problem isn't related to Date::Manip
but to general perl/os limitations. my experimental solution has revised
gts' date handling methods to not use any of problematic perl/os facilities.
and the reason i haven't committed it (and much other ras-hack) is primarily
due to contentious issues regarding gt app-script option handling and other
gt resource file directory paths. see the devel archive for the dirty details.
please keep us informed regarding your progress, and yell if you continue to
run into problems ...
aloha
ras
< snip >
|
|
From: Robert A. S. <ra...@ac...> - 2012-02-08 21:13:26
|
Evgeny Shragovich wrote:
> Hi folks!
>
>
>
> First of all I want to say that I am very glad to discover such a
> comprehensive project and express my admiration to all who took a part of
> it! It seems that is just what I've been looking for! :)
>
>
< rest of message snipped >
evgeny and gt'ers in general
gconf file format is generally one graphic.pl graphic-directive per line.
continuation lines are supported in some versions of gt and those generally
require the line contin char '\' to be immediately followed by a 'newline sequence'.
having a '\' in a graphic-directive line that isn't at the end-of-the-line is
a bad situation, the results are undefined and will likely be wrong.
in addition, having a '\' in a graphic-directive line using a gt version
that does not deal with gconf continuation lines is also a bad situation
since this character is unexpected wherever it occurs.
versions of graphic.pl that support or not gconf continuation lines:
the current trunk{HEAD} is one of them, the exp{HEAD} may or may not.
the static tarballs at sourceforge and on the gt web pages
(http://geniustrader.org/development.html (static tarballs) and
(http://geniustrader.org/download) may or may not -- these versions
are old and no longer recommended.
download from (http://geniustrader.org/development.html) and use either
the svn repo (you can clone only a specific branch or entire repo and
you only need GT and Script, never website) or download tarballs for either
trunk or exp branches. these tarballs are generated on the fly and are the
HEAD versions of the selected branch.
aloha
ras
|
|
From: Robert A. S. <ra...@ac...> - 2012-02-08 19:55:48
|
< prior content removed >
evgeny
1) recommendation -- arrange to get one of the trunk{HEAD} or
the exp{HEAD} versions. trunk{HEAD} is the most current.
a) you can keep your current version if you like, just
install the new version in a parallel top level dir
eg $ ls -F ~/workspace/market
gt/
$ mkdir ~/workspace/market/gt_head
$ ls -F ~/workspace/market
gt/
gt_head/
install the new version (subdirs GT and Scripts in gt_head dir
b) your HOME/.gt/ config dir will be shared
2) os -- good at least we are not dealing with toy m$ os
3) *Build.PL* different output is to be expected ...
i don't like the message
Date::Manip (6.25) is installed, but we need version < 6.0
will look into it -- this could be an issue, but i don't know how
A worked but not IBM.
the symlinks are only a convenience, saves having to type .pl when
typing a command line. (i don't type well, and am lazy and crazy, and
*nix as opposed to that m$ toy os did not ever need an extension to
clue it as to how to deal with a file). otherwise it makes no difference.
4) prices datafile naming convention.
i'm thinking *REV.txt indicates ascending date ordering.
suggest something more along the lines of <symbol>.rtxt (or <symbol>.revtxt)
review in some detail the pod (plain old documentation) for GT/BD/Text.pm.
especially keys DB::text::file_extension and DB::text::file_extension.
consider what you might want to do with sub_eod data.
5) the *screenshot_1.gconf* and execution methodology
assuming an installation like this
gt_version_top_level/GT
/Scripts
which is how the perl gt app-scripts are coded to locate the gt toolkit modules
we recommend running the applications directly from the Scripts dir
$ cd <whatever>gt_version_top_level/Scripts
$ ./graphic.pl --file screenshot_1.gconf --out 'graphs/sc5.png' IBMREV
in this case screenshot_1.gconf must be in cwd. if that isn't the case graphic.pl
will either use its defaults and proceed or die and bitch. if it proceeds it
will write the chart image into Scripts subdir graphs (which must likely have to
already exist) on filename sc5.png.
but you can keep gconfs anyplace you like, just inform graphic.pl like this:
$ ./graphic.pl --file $HOME/.gt/gconfs/screenshot_1.gconf ...
or
$ ./graphic.pl --file ../screenshot_1.gconf ...
6) with respect to *IBMREV.txt*
can you plot less than all the data? something like
$ graphic.pl --file screenshot_1.gconf --out 'Screenshot 5.png' \
--start 1970-01-05 --end 2012-02-03 IBMREV
*oh oh oh* -- trying to pull the start date out of /tmp/IBM_REV.txt and it
hit me square in the face -- your data set extends well past the unix date
epoch (1jan1970) so that is probably the issue
confirm with the command line above. i don't think any of these epoch fixes
of mine have made it into the repository so the only fix for this problem is
my custom, as yet still developmental version of gt. contact me directly if
you are interested.
7) *screenshot_1.gconf* -- you've got embedded '\' chars (line contination chars)
that are not at the end of lines
line 24:
--add=MountainBand(Indicators::Generic::Eval \ min(20,{Indicators::ADX/4}),Indicators::ADX/4,[228,128,0,100])
change it to two lines:
--add=MountainBand(Indicators::Generic::Eval \
min(20,{Indicators::ADX/4}),Indicators::ADX/4,[228,128,0,100])
or remove the '\' char altogether
i counted four lines like this
make sure there isn't any 'stray' whitespace after the terminating \
aloha
ras
|
|
From: Robert A. S. <ra...@ac...> - 2012-02-07 17:30:45
|
Evgeny Shragovich wrote:
> Hi folks!
>
>
>
> First of all I want to say that I am very glad to discover such a
> comprehensive project and express my admiration to all who took a part of
> it! It seems that is just what I've been looking for! :)
>
>
>
> I was going through the documentation for few days right now and I even
> made some progress.
>
> However I encountered few problems (I'm sure there will be more.. :) ) so I
> thought maybe I could find some help here..
>
>
> I have stocks end-of-day data which is saved in text files per stock
> symbol, for example: MSFT.txt, GOOG.txt ...
>
> Hence I decided (at least on the first stages) to use the DB::module Text.
>
>
> 1. The format of the text files I have is slightly different from the
> source data I found on site so I made all relevant configuration in the
> ~/.gt/options file including setting the following parameters:
> DB::text::directory
> DB::text::marker
> DB::text::header_lines
> DB::text::format
> DB::text::datetime
> DB::text::open
> DB::text::low
> DB::text::high
> DB::text::close
> DB::text::volume
>
> Then I tried to do some tests with *graphic.pl*, and got some pretty
> reasonable output with one text files but got the following error while
> trying it with another file (with exactly similar format):
>
> *evgeny@evgeny-desktop:~/workspace/market/gt/GT$ graphic.pl --file
> screenshot_1.gconf --out 'Screenshot 5.png' IBMREV*
> *Day too big - 33604 > 24853*
>
aloha Evgeny (or should i use eugene or gene?)
one of gt's largest user-facing problems is simply terrible error reporting
if you care to forward (to me or list -- your choice)
your $HOME/.gt/options
your screenshot_1.gconf
your IBMREV.txt file (only the relevant time period please)
entire command line plus all the terminal output plus anything
that gets written to 'Screenshot 5.png'
i will look into this issue.
some things jump out right away ...
*) please describe your gt installation and execution scheme.
*) what host platform are you using?
*) what version/source of gt are you on?
there are a number of 'forks' not on sourceforge -- those i'm unable to help you with.
from the gt homepage itself (http://geniustrader.org/), there are a number of different
forms all are a little different: svn: trunk, and the branches: exp and cpan.
sourceforge provides a couple of VERY OLD tarballs -- update if you are using
one of these ...
use the http://geniustrader.org/development.html page to access the code base
*) gt uses a lot of perl add-on modules: that error message might be a problem
from one of the date manipulating ones. i've attached an experimental perl
script that evaluates the current state of your platform (mostly the perl platform)
and reports things. feel free to run it and forward the results if you like.
it needs to be executable or have perl run it (perl Build.PL). and it goes into
the gt Scripts dir.
here's the output on my system:
% Build.PL
Checking prerequisites...
Looks good
Checking features:
sql_file_support.......enabled
pg_support.............enabled
sqlite2_support........disabled
- DBD::SQLite2 is not installed
dbi_support............enabled
odbc_support...........disabled
- DBD::ODBC is not installed
mysql_support..........disabled
- DBD::mysql is not installed
beancounter_support....enabled
beancounter............enabled
sqlite_support.........enabled
yea! you have the perl module DBI, which is absolutely needed for GT if you
intend to use any sql based price database. let's see which DBI/DBD drivers
you have available ...
SQLite, CSV, Pg,
BeanCounter
OK! you have beancounter installed and ready to go refer to the pod in
module GT/DB/bean.pm (e.g. perldoc GT/DB/bean.pm) for configuration details.
CSV
humm: you have perl modules needed to use the GT CSV driver.
THIS IS TOTALLY EXPERIMENTAL that means that you are on your own with this
-- refer to pod in GT/DB/CSV.pm.
Posgresql support
well well: you have the perl modules needed for postgresql db support so a
beancounter installation could run on a postgresql database repository.
SQLite
ok! you have the perl modules needed for sqlite db support, so a beancounter
installation could run on this sqlite db.
genericdb
humm: you have perl modules needed to use any sql database with GT if you
can define the necessary sql statments needed to query the database for
prices (open, high, low, close, volume and date tuples are needed per
symbol), plus optionally the securities name. for more details refer
to the pod in GT/DB/genericdb.pm.
the distribution uses a shebang line that differs from your perl config version.
to upgrade the gt perl app scripts you can simply insert the following line
#!/usr/local/bin/perl
as the first line of each of the following 12 files:
select_combination.pl
anashell.pl
analyze_backtest.pl
display_signal.pl
backtest.pl
display_system.pl
manage_portfolio.pl
backtest_multi.pl
display_indicator.pl
scan.pl
backtest_many.pl
graphic.pl
if you want i will do it for you automagically? y/[n] n
fine! be that way, i really don't care, but you could be heading for trouble.
excellent! your platform supports symlinks, so if you want i can create
symlinks for each of the gt application scripts without that damned .pl
extension ... it saves a bit of typing the command lines.
do you want the symlinks? y/[n] n
i'm thinking it presumes gt is not 'installed' in the cpan sense, but
run from it's source location. (e.g. the gt top-level-dir containing GT and Scripts subdirs)
please describe you installation and execution scheme.
> I tried to figure out what was causing this error but with no luck.
>
>
> 2. When I was looking at the graph which I *did *succeed to plot (using
> different stock file), I noticed 3 things:
> 2.1 I do not see the whole time period but the last 6 months. How can I
> change that?
% perldoc -t graphic.pl
> 2.2 I understand that graph appearance can be configured in the *
> screenshot_1.gconf* file but I could not find where this file is located
> or should be located?
anyplace you like, so long as graphic.pl can locate it. if it's not in the
current working directory (cwd) then the path needs to be included with the
filename -- i don't think there are any provisions for gconf file search paths,
but that isn't something i checked on.
% pwd
% /usr/local/src/genius_trader/Scripts
% graphic.pl --file $HOME/.gt/6_mon_chart.gconf ...
note -- there is nothing (if i recall correctly) special about the extension
.gconf -- it's just a convention (of mine) in an attempt to keep my sanity
in a Scripts dir containing over a thousand files --- crazy i am crazy
> 2.3 I see that the data was automatically represented in daily
> resolution. Is there a way to show weekly/monthly candles?
yep!
% perldoc -t graphic.pl
older, but otherwise pod documentation is also on line (http://geniustrader.org/doc/)
but trust the code and that means perldoc -t { scriptfile | perl_module_file }
>
> 3. I realized that in order for all scripts to work properly the data in
> the text files must go from the oldest records on top of the file and the
> newest at the bottom.However my files are order is exactly reversed. Of
> course I can write some simple script to reverse the order of the records
> in the files but I wonder if there is some configuration which could be
> changed to achieve that?
i believe there is a configure item for this
% pwd
/usr/local/src/genius_trader/Scripts
% perldoc -t ../GT/DB/Text.pm
...
DB::text::order 0 | 1 (default is 0)
0 - file is ordered by date ascending, the default gt standard.
1 - file is ordered by descending date.
This feature allows the user flexibility to use files with either
date order.
...
aloha
ras
>
>
>
> I hope that's not too much questions to ask for the first timer.
>
> I will be very thankful for any help!
>
>
> Thanks in advance!
>
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
|
54 messages has been excluded from this view by a project administrator.
