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: Thomas W. <we...@ms...> - 2009-11-17 14:44:36
|
Chia Liang, pretty cool.... this would be a great addition to GT. Sure beats the charts I render statically from the png created by graphics.pl, once you add scales etc. Can svg dynamically resize the vertical scales as you render which would be nice when scrolling as the market changes (make vertical scale cover the lowest and highest bar in view)? Th. Chia-liang Kao wrote: > In case you are curious about this new chart thingy, i setup a demo at > http://home.clkao.org:3997/d/TX/day > > > |
|
From: Chia-liang K. <cl...@cl...> - 2009-11-17 13:15:32
|
In case you are curious about this new chart thingy, i setup a demo at http://home.clkao.org:3997/d/TX/day It might be a bit slow, but it's meant to be for localhost use. Again, it's pretty rough at the moment and can use some help. Enjoy! 2009/11/15 Chia-liang Kao <cl...@cl...>: > Hi all, > > I just published a charting tool for GT with raphaeljs: > http://github.com/clkao/Finance-GeniusTrader-Chart. > > In summary, it's a web/svg-based interactive GT chart that allows you > to browse through all the data in DB, with a cursor that shows you the > values for the column you are looking at. Sorry that I don't have a > demo setup somewhere. > > It's still quite rough and a bit slow, but it can already do quite a > bit, including dynamic paging. look at the javascript in > template/default.html, it's quite similar to how the current > graphics.pl defines zones and graphical objects. I am going to add > overlays for trade histories from system or csv when i have time. but > please feel free to hack on it. > > warning: this requires a lot of bleeding edge modules, and a modern > browser that supports SVG! > > You'll need the CPAN branch of GT (or my cpan-pu branch on github for > better performance), Plack and Tatsumaki from CPAN, after installing > all deps, run: > > % plackup -p 3997 > > and then visit http://localhost:3997/d/TX/day, change TX and day to > some code/timeframe you have in the database. > > Cheers, > CLK > |
|
From: Chia-liang K. <cl...@cl...> - 2009-11-15 16:55:55
|
Hi all, I just published a charting tool for GT with raphaeljs: http://github.com/clkao/Finance-GeniusTrader-Chart. In summary, it's a web/svg-based interactive GT chart that allows you to browse through all the data in DB, with a cursor that shows you the values for the column you are looking at. Sorry that I don't have a demo setup somewhere. It's still quite rough and a bit slow, but it can already do quite a bit, including dynamic paging. look at the javascript in template/default.html, it's quite similar to how the current graphics.pl defines zones and graphical objects. I am going to add overlays for trade histories from system or csv when i have time. but please feel free to hack on it. warning: this requires a lot of bleeding edge modules, and a modern browser that supports SVG! You'll need the CPAN branch of GT (or my cpan-pu branch on github for better performance), Plack and Tatsumaki from CPAN, after installing all deps, run: % plackup -p 3997 and then visit http://localhost:3997/d/TX/day, change TX and day to some code/timeframe you have in the database. Cheers, CLK |
|
From: Robert A. S. <ra...@ac...> - 2009-11-13 08:51:07
|
Chia-liang Kao wrote: > Hi Robert, > > Thanks for looking! > > 2009/11/13 Robert A. Schmied <ra...@ac...>: > >>>Actually, I forgot i did some refactoring on an unfinished branch... >>>see the topic/graphics-improvements branch on my github repo, in >>>particular the commit: >>> >>> >>>http://github.com/clkao/finance-geniustrader/commit/2aab2187c5a8f1468478d92411b0b928093fa603 >>> >>>Instead of using the bar high/low directly from prices, it makes the >>>buysellarrow object taking datasource for high/low (which actually >>>means sell/buy arrow positioning) for rendering the arrows. >>> >>>Cheers, >>>CLK >>> >> >>CLK and jon >> >>i evaluated the referenced changes clk made to BuySellArrows, but found the >>changes to the api made it unusable with respect to the original version. in >>addition i also dislike slipping in yet another otherwise unannounced perl >>prerequisite (is it even necessary? meaning is there a way we could avoid >>requiring these versions of min and max?). never the less i've been >>intending to >>query clk to better explain how to use it and request that it be given a >>different name. > > > First of all, I should have pointed at the branch and diff that is > ported to CPAN branch: > http://gist.github.com/233510 > > (you can also fork from: > http://github.com/clkao/finance-geniustrader/tree/CPAN/topic/graphics-improvements) > > so right, it was work in progress and it didn't work well yet. It > might be better to simply converge the two modules and factor out the > same code (having the old prices_ds usage passed for a function taking > high_ds, low_ds). I think my original intention was for this > graphics::object module to fallback to the old behaviour if only > prices_ds is given. It depends on how we drive from graphics.pl... In > any case I'd like to see the two modes sharing code base. i'm in favor of that but until it works like BuySellArrows.pm does now it should not be named BuySellArrows.pm. i'd suggest the development proceed under a new name and once it is working either it can be renamed or simply replace the current BuySellArrows.pm. > > And also List::Util has been in perl core since 5.7.3, so it's not > quite an external dependency. yea! this is the worst kind. things that get slipped into perl along the way. this sort of non-dependency dependency isn't typically mentioned in the install instructions (after all it's a perl internal), and unless something (the apps?) say it must be perl 5.7.3 things don't work so good. i'd like to keep gt working on perl as old as ... well lets just say v5.6.2. > >>within this thread jon provided the name so with the hacks i've made since >>and >>just now are included in the newly christened graphic object >>BuySellPricesArrows. >>i've left the keys used to control the colors unchanged, but don't object if >>they are altered to be specifically for BuySellPricesArrows. >> >>if someone can finish it (e.g update pod, correct usage examples, and >>provide >>changes needed to drive it via graphic.pl and or backtest.pl) it could be >>another >>useful graphic object ... >> >> >>aloha >> >>ras >> > > followup to jon edwards posting: > Thank you guys !! > > ras, > > I don't mind changing graphics.pl, backtest.pl (I've not cracked that > yet), POD, examples, etc. if I can figure out what to change. > > Currently graphic.pl doesn't like the new BuySellPricesArrows.pm > Can't call method "get" on an undefined value at > /usr/lib/perl5/vendor_perl/GT/Graphics/Object/BuySellPricesArrows.pm > line 149. that's exactly the same place where i ran out of energy. > > Line 149 my ($low, $high) = map { $self->{$_}->get($i) } qw(low_ds > high_ds); > > I assume it's because graphics.pl needs the additional parms for the > init but this is where I'm getting confused with this code. (and I > thought I knew perl more then I appear to). Would the high, low, min > max come from the $ds_s object created in graphics.pl ? Assuming so > is there something I can read to understand these data structures so > I know how to make references to data elements ? without a better understanding of what the arguments are supposed to be i cannot be of much help. clk can you offer any specifics? aloha ras > > Thank you, Jon |
|
From: Jon E. <fo...@ho...> - 2009-11-13 06:12:35
|
Thank you guys !!
ras,
I don't mind changing graphics.pl, backtest.pl (I've not cracked that yet), POD, examples, etc. if I can figure out what to change.
Currently graphic.pl doesn't like the new BuySellPricesArrows.pm
Can't call method "get" on an undefined value at /usr/lib/perl5/vendor_perl/GT/Graphics/Object/BuySellPricesArrows.pm line 149.
Line 149
my ($low, $high) = map { $self->{$_}->get($i) } qw(low_ds high_ds);
I assume it's because graphics.pl needs the additional parms for the init but this is where I'm getting confused with this code. (and I thought I knew perl more then I appear to).
Would the high, low, min max come from the $ds_s object created in graphics.pl ?
Assuming so is there something I can read to understand these data structures so I know how to make references to data elements ?
Thank you,
Jon
> Date: Fri, 13 Nov 2009 09:50:56 +0800
> From: cl...@cl...
> To: de...@ge...
> Subject: [GT] Re: Re: BuySellArrows.pm Trigger Prices
>
> Hi Robert,
>
> Thanks for looking!
>
> 2009/11/13 Robert A. Schmied <ra...@ac...>:
> >> Actually, I forgot i did some refactoring on an unfinished branch...
> >> see the topic/graphics-improvements branch on my github repo, in
> >> particular the commit:
> >>
> >>
> >> http://github.com/clkao/finance-geniustrader/commit/2aab2187c5a8f1468478d92411b0b928093fa603
> >>
> >> Instead of using the bar high/low directly from prices, it makes the
> >> buysellarrow object taking datasource for high/low (which actually
> >> means sell/buy arrow positioning) for rendering the arrows.
> >>
> >> Cheers,
> >> CLK
> >>
> >
> > CLK and jon
> >
> > i evaluated the referenced changes clk made to BuySellArrows, but found the
> > changes to the api made it unusable with respect to the original version. in
> > addition i also dislike slipping in yet another otherwise unannounced perl
> > prerequisite (is it even necessary? meaning is there a way we could avoid
> > requiring these versions of min and max?). never the less i've been
> > intending to
> > query clk to better explain how to use it and request that it be given a
> > different name.
>
> First of all, I should have pointed at the branch and diff that is
> ported to CPAN branch:
> http://gist.github.com/233510
>
> (you can also fork from:
> http://github.com/clkao/finance-geniustrader/tree/CPAN/topic/graphics-improvements)
>
> so right, it was work in progress and it didn't work well yet. It
> might be better to simply converge the two modules and factor out the
> same code (having the old prices_ds usage passed for a function taking
> high_ds, low_ds). I think my original intention was for this
> graphics::object module to fallback to the old behaviour if only
> prices_ds is given. It depends on how we drive from graphics.pl... In
> any case I'd like to see the two modes sharing code base.
>
> And also List::Util has been in perl core since 5.7.3, so it's not
> quite an external dependency.
>
> > within this thread jon provided the name so with the hacks i've made since
> > and
> > just now are included in the newly christened graphic object
> > BuySellPricesArrows.
> > i've left the keys used to control the colors unchanged, but don't object if
> > they are altered to be specifically for BuySellPricesArrows.
> >
> > if someone can finish it (e.g update pod, correct usage examples, and
> > provide
> > changes needed to drive it via graphic.pl and or backtest.pl) it could be
> > another
> > useful graphic object ...
> >
> >
> > aloha
> >
> > ras
> >
_________________________________________________________________
Hotmail: Trusted email with Microsoft's powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/
http://clk.atdmt.com/GBL/go/177141664/direct/01/
|
|
From: Chia-liang K. <cl...@cl...> - 2009-11-13 03:01:16
|
Hi Robert, Thanks for looking! 2009/11/13 Robert A. Schmied <ra...@ac...>: >> Actually, I forgot i did some refactoring on an unfinished branch... >> see the topic/graphics-improvements branch on my github repo, in >> particular the commit: >> >> >> http://github.com/clkao/finance-geniustrader/commit/2aab2187c5a8f1468478d92411b0b928093fa603 >> >> Instead of using the bar high/low directly from prices, it makes the >> buysellarrow object taking datasource for high/low (which actually >> means sell/buy arrow positioning) for rendering the arrows. >> >> Cheers, >> CLK >> > > CLK and jon > > i evaluated the referenced changes clk made to BuySellArrows, but found the > changes to the api made it unusable with respect to the original version. in > addition i also dislike slipping in yet another otherwise unannounced perl > prerequisite (is it even necessary? meaning is there a way we could avoid > requiring these versions of min and max?). never the less i've been > intending to > query clk to better explain how to use it and request that it be given a > different name. First of all, I should have pointed at the branch and diff that is ported to CPAN branch: http://gist.github.com/233510 (you can also fork from: http://github.com/clkao/finance-geniustrader/tree/CPAN/topic/graphics-improvements) so right, it was work in progress and it didn't work well yet. It might be better to simply converge the two modules and factor out the same code (having the old prices_ds usage passed for a function taking high_ds, low_ds). I think my original intention was for this graphics::object module to fallback to the old behaviour if only prices_ds is given. It depends on how we drive from graphics.pl... In any case I'd like to see the two modes sharing code base. And also List::Util has been in perl core since 5.7.3, so it's not quite an external dependency. > within this thread jon provided the name so with the hacks i've made since > and > just now are included in the newly christened graphic object > BuySellPricesArrows. > i've left the keys used to control the colors unchanged, but don't object if > they are altered to be specifically for BuySellPricesArrows. > > if someone can finish it (e.g update pod, correct usage examples, and > provide > changes needed to drive it via graphic.pl and or backtest.pl) it could be > another > useful graphic object ... > > > aloha > > ras > |
|
From: Robert A. S. <ra...@ac...> - 2009-11-13 01:44:15
|
strangespider wrote:
> Hi,
>
> I observed a problem with the extension in the module Text.pm
>
>
> =item DB::text::file_extension string
>
> To be appended to the code file name when
> searching the data file. For instance, if the data file is called EURUSD.csv
> this variable would have the value '.csv' (without the quotes).
>
> The default file_extension is '.txt'.
>
>
> You can find this setting here:
> Finance::GeniusTrader::Conf::default('DB::Text::file_extension', '.txt');
>
>
>
>
>
> I can set the extension in the ~/.gt/options file, e.g you have csv-files:
> DB::text::file_extension .csv
>
> But how can I unset any extensions? My files are just the symbol name with no extension.
> IBM
> QQQQ
> ...
>
> At the moment I edited
> Finance::GeniusTrader::Conf::default('DB::Text::file_extension', '.txt');
> in the Text.pm file to
> Finance::GeniusTrader::Conf::default('DB::Text::file_extension', '');
>
>
>
> Am I doing something wrong with the options file?
>
>
> Best regards
>
strangespider
please evaluate the following patch, relative to trunk branch (sorry) and report.
i don't use the text database much ...
aloha
ras
|
|
From: Robert A. S. <ra...@ac...> - 2009-11-12 20:49:46
|
strangespider wrote:
> Hi,
>
> I observed a problem with the extension in the module Text.pm
>
>
> =item DB::text::file_extension string
>
> To be appended to the code file name when
> searching the data file. For instance, if the data file is called EURUSD.csv
> this variable would have the value '.csv' (without the quotes).
>
> The default file_extension is '.txt'.
>
>
> You can find this setting here:
> Finance::GeniusTrader::Conf::default('DB::Text::file_extension', '.txt');
>
>
>
>
>
> I can set the extension in the ~/.gt/options file, e.g you have csv-files:
> DB::text::file_extension .csv
>
> But how can I unset any extensions? My files are just the symbol name with no extension.
> IBM
> QQQQ
> ...
>
> At the moment I edited
> Finance::GeniusTrader::Conf::default('DB::Text::file_extension', '.txt');
> in the Text.pm file to
> Finance::GeniusTrader::Conf::default('DB::Text::file_extension', '');
>
>
>
> Am I doing something wrong with the options file?
>
>
> Best regards
>
aloha strangespider
the default extension is '.txt' and there is no way (that i've been able to
find) to set it to be a null (empty) string.
so you have two (at least) choices:
1) change your text database files to comply
or
2) use your changed version of GT/DB/Text.pm
note that with the change to GT/DB/Text.pm many of the examples that use
the sample database 13000 will fail unless you explicitly define the .txt
extension, or change the sample database file naming and remove the extension.
but since you seem to be referencing the cpaned gt these pod examples are
likely not working anyway.
maybe there's enough interest to find a way to allow the user to set the
file extension to include the empty string, but it shouldn't override the
current default .txt extension ...
would something like
$self->{'extension'} = "GT::Conf::get('DB::Text::file_extension')";
work? or does GT::Conf::get need to be changed to return an empty string
if the keys' value is the empty string?
ras
|
|
From: Robert A. S. <ra...@ac...> - 2009-11-12 20:11:10
|
Chia-liang Kao wrote: > 2009/11/12 Jon Edwards <fo...@ho...>: > >>>If you have a S:Generic-based trigger, the signal is always determined >>>at the end of the bar, and drawing the arrow near the CLOSE of the bar >>>should be close enough. What you describe might be more interesting >>>if you have a ChannelBreakout based trigger, where the triggering >>>price might not be the end of the bar, and to show this on the chart >>>you'll need to modify BuySellArrow to accept another price data source >>>and render the arrows accordingly, which is slightly complicated. >>>(this answers (2) >> >>That's exactly what I have in mind to do (e.g. BuySellPricesArrows.pm ) >>Where I'm struggling is how to pass this other price data source. Digging >>through >>the code, namely CrossOverUp.pm where the decision is made, it seems I >>would >>want 'calc' but a couple of attempts at doing that have not been successful. >>Any suggestions or examples I can look at for help ? > > > > Actually, I forgot i did some refactoring on an unfinished branch... > see the topic/graphics-improvements branch on my github repo, in > particular the commit: > > http://github.com/clkao/finance-geniustrader/commit/2aab2187c5a8f1468478d92411b0b928093fa603 > > Instead of using the bar high/low directly from prices, it makes the > buysellarrow object taking datasource for high/low (which actually > means sell/buy arrow positioning) for rendering the arrows. > > Cheers, > CLK > CLK and jon i evaluated the referenced changes clk made to BuySellArrows, but found the changes to the api made it unusable with respect to the original version. in addition i also dislike slipping in yet another otherwise unannounced perl prerequisite (is it even necessary? meaning is there a way we could avoid requiring these versions of min and max?). never the less i've been intending to query clk to better explain how to use it and request that it be given a different name. within this thread jon provided the name so with the hacks i've made since and just now are included in the newly christened graphic object BuySellPricesArrows. i've left the keys used to control the colors unchanged, but don't object if they are altered to be specifically for BuySellPricesArrows. if someone can finish it (e.g update pod, correct usage examples, and provide changes needed to drive it via graphic.pl and or backtest.pl) it could be another useful graphic object ... aloha ras |
|
From: GeniusTrader S. <ra...@ge...> - 2009-11-12 17:03:46
|
Author: clkao
Date: 2009-11-12 17:03:44 +0100 (Thu, 12 Nov 2009)
New Revision: 708
Modified:
branches/CPAN/lib/Finance/GeniusTrader/Tools.pm
Log:
In check_dates, only convert to DAY if timeframe is larger than DAY
Modified: branches/CPAN/lib/Finance/GeniusTrader/Tools.pm
===================================================================
--- branches/CPAN/lib/Finance/GeniusTrader/Tools.pm 2009-11-06 13:41:04 UTC (rev 707)
+++ branches/CPAN/lib/Finance/GeniusTrader/Tools.pm 2009-11-12 16:03:44 UTC (rev 708)
@@ -737,11 +737,11 @@
}
# timeframe relative date conversions
- if ( $start && $timeframe != $DAY ) {
+ if ( $start && $timeframe > $DAY ) {
$start = Finance::GeniusTrader::DateTime::convert_date($start, $DAY, $timeframe);
}
- if ( $end && $timeframe != $DAY ) {
+ if ( $end && $timeframe > $DAY ) {
$end = Finance::GeniusTrader::DateTime::convert_date($end, $DAY, $timeframe);
}
|
|
From: Chia-liang K. <cl...@cl...> - 2009-11-12 15:31:12
|
2009/11/12 Jon Edwards <fo...@ho...>: >> If you have a S:Generic-based trigger, the signal is always determined >> at the end of the bar, and drawing the arrow near the CLOSE of the bar >> should be close enough. What you describe might be more interesting >> if you have a ChannelBreakout based trigger, where the triggering >> price might not be the end of the bar, and to show this on the chart >> you'll need to modify BuySellArrow to accept another price data source >> and render the arrows accordingly, which is slightly complicated. >> (this answers (2) > > That's exactly what I have in mind to do (e.g. BuySellPricesArrows.pm ) > Where I'm struggling is how to pass this other price data source. Digging > through > the code, namely CrossOverUp.pm where the decision is made, it seems I > would > want 'calc' but a couple of attempts at doing that have not been successful. > Any suggestions or examples I can look at for help ? Actually, I forgot i did some refactoring on an unfinished branch... see the topic/graphics-improvements branch on my github repo, in particular the commit: http://github.com/clkao/finance-geniustrader/commit/2aab2187c5a8f1468478d92411b0b928093fa603 Instead of using the bar high/low directly from prices, it makes the buysellarrow object taking datasource for high/low (which actually means sell/buy arrow positioning) for rendering the arrows. Cheers, CLK |
|
From: Jon E. <fo...@ho...> - 2009-11-12 14:57:27
|
Thank you.
See follow up below.
Jon
> Date: Thu, 12 Nov 2009 13:27:59 +0800
> From: cl...@cl...
> To: de...@ge...
> Subject: [GT] Re: BuySellArrows.pm Trigger Prices
>
> Jon.
>
> 2009/11/12 Jon Edwards <fo...@ho...>:
> > Using graphic.pl and specifying the below add line for BuySellArrows.pm I
> > get the arrows as expected.
> > What I'd also like to see is the price at which that was triggered; in this
> > case it would be when those EMAs cross. Looking at the code I'm having
> > trouble trying to understand a couple of things.
>
> If you have a S:Generic-based trigger, the signal is always determined
> at the end of the bar, and drawing the arrow near the CLOSE of the bar
> should be close enough. What you describe might be more interesting
> if you have a ChannelBreakout based trigger, where the triggering
> price might not be the end of the bar, and to show this on the chart
> you'll need to modify BuySellArrow to accept another price data source
> and render the arrows accordingly, which is slightly complicated.
> (this answers (2)
That's exactly what I have in mind to do (e.g. BuySellPricesArrows.pm )
Where I'm struggling is how to pass this other price data source. Digging through
the code, namely CrossOverUp.pm where the decision is made, it seems I would
want 'calc' but a couple of attempts at doing that have not been successful.
Any suggestions or examples I can look at for help ?
>
> > 1) The basic flow from BuySellArrows.pm to invoking e.g. CrossOverUp.pm.
> > Does BuySellArrows.pm invoke Generic.pm which in turn invokes CrossOverUp.pm
> > ? I'm just not seeing this flow yet.
>
> IIRC all the graph objects are expecting some kind of DataSource, in
> this cause it's the system's signal, which is a generic crossoverup
> signal.
>
> > 2) There seems to be 2 main structures passed around : self and calc.
> > CrossOverUp.pm seems to use calc for determining the trigger/arrow price but
> > how to get that known in BuySellArrows.pm
> >
> > --add=BuySellArrows(Systems::Generic {S::Generic::CrossOverUp {I:EMA 3}
> > {I:EMA 7}} {S::Generic::CrossOverDown {I:EMA 3} {I:EMA 7}} )
> >
> > Thank you,
> > Jon
> >
> > ________________________________
> > Windows 7: Unclutter your desktop. Learn more.
_________________________________________________________________
Windows 7: Unclutter your desktop.
http://go.microsoft.com/?linkid=9690331&ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen:112009 |
|
From: <fr....@ti...> - 2009-11-12 13:21:26
|
Sorry for the other mails, i had prolems with email client, this is the right mail: ------------ I understand, the only mistake i see is in the definition of money management. In backtest_multy this system_file definition is incorrect, since the PortfolioManager add to all the systems 2 MoneyManagenment Rules SY:System1|OF:OF1|TF:TF1|CS:CS1|MM: Basic SY:System2|OF:OF2|TF:TF2|CS:CS2|MM:FixedSum 99800 and you get the analysis with no operations(dont know exactly why, im still debbuging). Sorry again Francesco Gamberale >The backtest files where made consistent in their arguments. So please, >if you find that there had been some mistakes in this convergence, >highlight these and we shall fix it. But not by converting to the old >version but to an improved version that remains consistent with the >other scripts. > >There is no usage of an xml format anywhere else, so we should avoid >that or provide it as an alternative everywhere... > >Th. > >fr. gam...@ti... wrote: >> hi again, >> >> as i wrote in a previous post im still using an old version of GT. >> Reading the history of mailing list i noticed that the backtest_multi.pl was >> changed because nobody know the format of xml file. I use the old >> backtest_multi.pl quite a lot and can give examples of the xml file format. >> >> I can use the new one without problems but the new format doesnt fit to the >> backtest_multi.pl logic: >> in backtest_multi.pl you need only one MoneyManagement for all the systems, in >> the old format you had a xml fileld different from the system definition, in >> backtest_multi.pl gives an error. > > >before i change all my other programs that use the xml format id like to know > >if what i wrote will make restore the previous version of backtest_multi.pl or > >is not enough important. Passa a Tiscali Tutto Incluso Light: telefono + adsl 8 Mb senza limiti a soli 9,95 euro al mese fino al 01/04/2010. Gratis la Sim Tiscali Mobile con 25 euro di traffico. L’offerta è valida solo se attivi entro il 12/11/09 http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw |
|
From: strangespider <str...@we...> - 2009-11-12 12:15:15
|
Hi,
I observed a problem with the extension in the module Text.pm
=item DB::text::file_extension string
To be appended to the code file name when
searching the data file. For instance, if the data file is called EURUSD.csv
this variable would have the value '.csv' (without the quotes).
The default file_extension is '.txt'.
You can find this setting here:
Finance::GeniusTrader::Conf::default('DB::Text::file_extension', '.txt');
I can set the extension in the ~/.gt/options file, e.g you have csv-files:
DB::text::file_extension .csv
But how can I unset any extensions? My files are just the symbol name with no extension.
IBM
QQQQ
...
At the moment I edited
Finance::GeniusTrader::Conf::default('DB::Text::file_extension', '.txt');
in the Text.pm file to
Finance::GeniusTrader::Conf::default('DB::Text::file_extension', '');
Am I doing something wrong with the options file?
Best regards
|
|
From: Chia-liang K. <cl...@cl...> - 2009-11-12 06:38:13
|
Jon.
2009/11/12 Jon Edwards <fo...@ho...>:
> Using graphic.pl and specifying the below add line for BuySellArrows.pm I
> get the arrows as expected.
> What I'd also like to see is the price at which that was triggered; in this
> case it would be when those EMAs cross. Looking at the code I'm having
> trouble trying to understand a couple of things.
If you have a S:Generic-based trigger, the signal is always determined
at the end of the bar, and drawing the arrow near the CLOSE of the bar
should be close enough. What you describe might be more interesting
if you have a ChannelBreakout based trigger, where the triggering
price might not be the end of the bar, and to show this on the chart
you'll need to modify BuySellArrow to accept another price data source
and render the arrows accordingly, which is slightly complicated.
(this answers (2))
> 1) The basic flow from BuySellArrows.pm to invoking e.g. CrossOverUp.pm.
> Does BuySellArrows.pm invoke Generic.pm which in turn invokes CrossOverUp.pm
> ? I'm just not seeing this flow yet.
IIRC all the graph objects are expecting some kind of DataSource, in
this cause it's the system's signal, which is a generic crossoverup
signal.
> 2) There seems to be 2 main structures passed around : self and calc.
> CrossOverUp.pm seems to use calc for determining the trigger/arrow price but
> how to get that known in BuySellArrows.pm
>
> --add=BuySellArrows(Systems::Generic {S::Generic::CrossOverUp {I:EMA 3}
> {I:EMA 7}} {S::Generic::CrossOverDown {I:EMA 3} {I:EMA 7}} )
>
> Thank you,
> Jon
>
> ________________________________
> Windows 7: Unclutter your desktop. Learn more.
|
|
From: Jon E. <fo...@ho...> - 2009-11-12 06:11:19
|
Hello All.
Using graphic.pl and specifying the below add line for BuySellArrows.pm I get the arrows as expected.
What I'd also like to see is the price at which that was triggered; in this case it would be when those EMAs cross. Looking at the code I'm having trouble trying to understand a couple of things.
1) The basic flow from BuySellArrows.pm to invoking e.g. CrossOverUp.pm. Does BuySellArrows.pm invoke Generic.pm which in turn invokes CrossOverUp.pm ? I'm just not seeing this flow yet.
2) There seems to be 2 main structures passed around : self and calc. CrossOverUp.pm seems to use calc for determining the trigger/arrow price but how to get that known in BuySellArrows.pm
--add=BuySellArrows(Systems::Generic {S::Generic::CrossOverUp {I:EMA 3} {I:EMA 7}} {S::Generic::CrossOverDown {I:EMA 3} {I:EMA 7}} )
Thank you,
Jon
_________________________________________________________________
Windows 7: Unclutter your desktop.
http://go.microsoft.com/?linkid=9690331&ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen:112009 |
|
From: Thomas W. <we...@ms...> - 2009-11-11 08:08:40
|
Tielman,
could you please write up your experience of connecting to MySQL as a
little tutorial. We can add this into the documentation, and it will
greatly help subsequent users?
RAS,
yes, a good error message here would be beneficial....
Th.
Robert A. Schmied wrote:
> Tielman Esterhuizen wrote:
>> Thanks again Thomas.
>>
>> SOLVED> Problem was that I did not have "DB::module genericdbi" in my
>> options file. I picked this up while reading through Conf.pm.
>>
>> Can anyone contribute to the documentation? What is the process?
>>
>
> aloha Tielman
>
> you can post any changes you'd like to see to the list either as actual
> diffs of the current pod or text that you think is better than the
> current doc text.
>
>
> certainly this documentation needs to be improved, but in addition,
> i'd argue that the gt tool kit could/should be made smart enough to
> detect this missing requirement and give the user useful feedback.
> looks like the place for this could be GT::Eval::create_db_object
> and or GT::Eval::create_standard_object ...
>
> maybe something like
>
> our $db;
> sub create_db_object {
> my $db_module = GT::Conf::get("DB::module");
>
> unless ( defined $db_module ) {
> GT::Conf::load();
> }
> unless ( defined ( $db_module = GT::Conf::get("DB::module") ) ) {
> my $msg = join "", "$::prog_name: Error: ",
> "gt configuration error: key \"DB::module\" not found.\n",
> "this key must be defined with a value ",
> "that names the GT DB module name you are using.\n",
> "examples\n\"DB::module genericdbi\"\n",
> "\"DB::module Text\"",
> "\n";
> die "$msg";
> }
> unless ( defined $db ) {
> $db = create_standard_object("DB::" .
> GT::Conf::get("DB::module"));
> }
> return $db;
> }
>
>
>
|
|
From: jecxz112 <jec...@te...> - 2009-11-11 05:38:35
|
Robert A. Schmied wrote: > aloha jecxz112 > > you might want to post your original issue to dirk directly > "Dirk Eddelbuettel" <ed...@de...> and or to the beancounter (bc) > complaint > lists (methinks they might live at cpan and or debian linux sites). > > but as i recall the update script altered some database tables and > changed > a version variable that bc uses to tickle the 'run update_bc' message. > (version tuple in beancounter table). > since sqlite was added to bc well after the need for database table > changes > was known the original sqlite setup schema was already correct. but i > think > the variable update is still needed ... so long as you ran the script > once > things should be ok. > > the larger problem i found with stock bc on postgresql (a very long > time ago) > was when beancounter is initially setup and updated via scripts the > types for > volume and ave_volume (stockprices, stockinfo) are integer. this type > is too > small to hold large volume days for indexes like nasdaq 100 or dow 30 > back in > the day when trading volumes were larger. > > you might want to check that the sqlite type used for these tuples is > sufficiently large enough. for postgresql i'm using bigint. this may > have been factored into more recent versions ... > > Thank you, Robert for the information. I had tried to find a 'proper' place to report/ get feedback on this issue, but had little luck. Fortunately I had played with Perl a bit in the past and so eventually was able to sort out the error messages I was getting. As I'm quite new to this whole financial bit with bc, smtm and GT, I'm just trying to get them to run so I can see what they do and what it all means to me. I'm by no means a heavy trader, but would like to look it over so I can decide whether it is something I want to consider and get at least enough knowledge 'to be dangerous' as one of my former co-workers used to put it. -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml |
|
From: Robert A. S. <ra...@ac...> - 2009-11-10 22:48:13
|
posted to de...@ge... by direction of dirk 'beancounter' Eddelbuettel ras > On 10 November 2009 at 11:12, Robert A. Schmied wrote: > | jecxz112 wrote: > | > jecxz112 wrote: > | > > | >> After recently getting started on the financial stuff and finding GT > | >> folks were using beancounter for some data acquisition, I tried to > | >> make beancounter 0.8.8 run under Windows (using sqlite3) and after a > | >> fair bit of fiddling succeeded - up to a point. > | >> > | >> When I run it now, I tells me I must run update_beancounter, but from > | >> all I can see, despite the claims on the beancounter site, > | >> update_beancounter has no sqlite support - unless it is implicit somehow. > | >> > | >> Is anyone else running update_beancounter under Windows with sqlite. - > | >> and if so, what is the secret, > | >> short of writing my own SQLite support into update_beancounter? > | >> > | >> TIA > | >> > | > This may no longer be an issue; I have been able to create the sqlite DB > | > with setup_beancounter properly and beancounter no longer asks me to run > | > update_beancounter. > | > > | > :-) > | > > | > | aloha jecxz112 > | > | you might want to post your original issue to dirk directly > | "Dirk Eddelbuettel" <ed...@de...> and or to the beancounter (bc) complaint > | lists (methinks they might live at cpan and or debian linux sites). > | > | but as i recall the update script altered some database tables and changed > | a version variable that bc uses to tickle the 'run update_bc' message. > | (version tuple in beancounter table). > > Right. Just alter it by hand. "Use the source, Luke." > > And feel free to provide a patch to the update script. > > Dirk > > | since sqlite was added to bc well after the need for database table changes > | was known the original sqlite setup schema was already correct. but i think > | the variable update is still needed ... so long as you ran the script once > | things should be ok. > | > | the larger problem i found with stock bc on postgresql (a very long time ago) > | was when beancounter is initially setup and updated via scripts the types for > | volume and ave_volume (stockprices, stockinfo) are integer. this type is too > | small to hold large volume days for indexes like nasdaq 100 or dow 30 back in > | the day when trading volumes were larger. > | > | you might want to check that the sqlite type used for these tuples is > | sufficiently large enough. for postgresql i'm using bigint. this may > | have been factored into more recent versions ... > | > | > | ras > | > | > > -- Three out of two people have difficulties with fractions. |
|
From: Robert A. S. <ra...@ac...> - 2009-11-10 20:22:39
|
jecxz112 wrote: > jecxz112 wrote: > >> After recently getting started on the financial stuff and finding GT >> folks were using beancounter for some data acquisition, I tried to >> make beancounter 0.8.8 run under Windows (using sqlite3) and after a >> fair bit of fiddling succeeded - up to a point. >> >> When I run it now, I tells me I must run update_beancounter, but from >> all I can see, despite the claims on the beancounter site, >> update_beancounter has no sqlite support - unless it is implicit somehow. >> >> Is anyone else running update_beancounter under Windows with sqlite. - >> and if so, what is the secret, >> short of writing my own SQLite support into update_beancounter? >> >> TIA >> > This may no longer be an issue; I have been able to create the sqlite DB > with setup_beancounter properly and beancounter no longer asks me to run > update_beancounter. > > :-) > aloha jecxz112 you might want to post your original issue to dirk directly "Dirk Eddelbuettel" <ed...@de...> and or to the beancounter (bc) complaint lists (methinks they might live at cpan and or debian linux sites). but as i recall the update script altered some database tables and changed a version variable that bc uses to tickle the 'run update_bc' message. (version tuple in beancounter table). since sqlite was added to bc well after the need for database table changes was known the original sqlite setup schema was already correct. but i think the variable update is still needed ... so long as you ran the script once things should be ok. the larger problem i found with stock bc on postgresql (a very long time ago) was when beancounter is initially setup and updated via scripts the types for volume and ave_volume (stockprices, stockinfo) are integer. this type is too small to hold large volume days for indexes like nasdaq 100 or dow 30 back in the day when trading volumes were larger. you might want to check that the sqlite type used for these tuples is sufficiently large enough. for postgresql i'm using bigint. this may have been factored into more recent versions ... ras |
|
From: jecxz112 <jec...@te...> - 2009-11-10 04:49:15
|
jecxz112 wrote: > After recently getting started on the financial stuff and finding GT > folks were using beancounter for some data acquisition, I tried to > make beancounter 0.8.8 run under Windows (using sqlite3) and after a > fair bit of fiddling succeeded - up to a point. > > When I run it now, I tells me I must run update_beancounter, but from > all I can see, despite the claims on the beancounter site, > update_beancounter has no sqlite support - unless it is implicit somehow. > > Is anyone else running update_beancounter under Windows with sqlite. - > and if so, what is the secret, > short of writing my own SQLite support into update_beancounter? > > TIA > This may no longer be an issue; I have been able to create the sqlite DB with setup_beancounter properly and beancounter no longer asks me to run update_beancounter. :-) > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.425 / Virus Database: 270.14.58/2493 - Release Date: 11/09/09 19:40:00 > > -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml |
|
From: jecxz112 <jec...@te...> - 2009-11-10 01:45:59
|
After recently getting started on the financial stuff and finding GT folks were using beancounter for some data acquisition, I tried to make beancounter 0.8.8 run under Windows (using sqlite3) and after a fair bit of fiddling succeeded - up to a point. When I run it now, I tells me I must run update_beancounter, but from all I can see, despite the claims on the beancounter site, update_beancounter has no sqlite support - unless it is implicit somehow. Is anyone else running update_beancounter under Windows with sqlite. - and if so, what is the secret, short of writing my own SQLite support into update_beancounter? TIA -- Fight Spam - report it with wxSR http://www.columbinehoney.net/wxSR.shtml |
|
From: Robert A. S. <ra...@ac...> - 2009-11-09 21:05:10
|
Tielman Esterhuizen wrote:
> Thanks again Thomas.
>
> SOLVED> Problem was that I did not have "DB::module genericdbi" in my options
> file. I picked this up while reading through Conf.pm.
>
> Can anyone contribute to the documentation? What is the process?
>
aloha Tielman
you can post any changes you'd like to see to the list either as actual
diffs of the current pod or text that you think is better than the
current doc text.
alternatively or in addition, the gt wiki (see gt home page, box in
upper right for the url) can be edited by anyone, just register and
login, the only prerequisite (iirc) is that you must also be on a gt
list. the wiki user config page has an example with a beancounter db
module and does show the required key-value pair "DB::module bean"
directive.
i did a quick looksee but
a) didn't see anything that specifically indicated the key "DB::module"
was only needed for Text, but may have missed it, and
b) on the other hand i also didn't see any thing that adequately noted
that this key is required for every database interface.
certainly this documentation needs to be improved, but in addition,
i'd argue that the gt tool kit could/should be made smart enough to
detect this missing requirement and give the user useful feedback.
looks like the place for this could be GT::Eval::create_db_object
and or GT::Eval::create_standard_object ...
maybe something like
our $db;
sub create_db_object {
my $db_module = GT::Conf::get("DB::module");
unless ( defined $db_module ) {
GT::Conf::load();
}
unless ( defined ( $db_module = GT::Conf::get("DB::module") ) ) {
my $msg = join "", "$::prog_name: Error: ",
"gt configuration error: key \"DB::module\" not found.\n",
"this key must be defined with a value ",
"that names the GT DB module name you are using.\n",
"examples\n\"DB::module genericdbi\"\n",
"\"DB::module Text\"",
"\n";
die "$msg";
}
unless ( defined $db ) {
$db = create_standard_object("DB::" . GT::Conf::get("DB::module"));
}
return $db;
}
aloha
ras
<< snip >>
>
> --
> Tielman Esterhuizen
> Consultant
> Eirteic Consulting (Australia) Pty Ltd
>
> Mobile: +61 (0) 406 538534
> Office: +61 (0) 299 400288
> Fax: +61 (0) 299400478
> email: tie...@ei...
> web: http://www.eirteic.com
>
|
|
From: Tielman E. <tes...@ei...> - 2009-11-08 21:19:29
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="sans-serif">Thanks again Thomas.<br>
<br>
SOLVED> Problem was that I did not have "DB::module genericdbi" in
my options file. I picked this up while reading through Conf.pm. <br>
<br>
Can anyone contribute to the documentation? What is the process?<br>
<br>
Kind regards,<br>
Tielman<br>
<br>
</font><br>
Thomas Weigert wrote:
<blockquote cite="mid:4AF...@ms..." type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
I don't know about the documentation, but please look at the code of
Eval.pm around where your call fails. You will see that it used
DB::module... Th.<br>
<br>
Tielman Esterhuizen wrote:
<blockquote cite="mid:4AF...@ei..." type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<font face="sans-serif">Thanks Thomas.<br>
<br>
You're right DB::module is not set, but as far the documentation states
this is only used when using a Text file as datasource - I'm using a
mysql db. <br>
<br>
Kind regards,<br>
Tielman<br>
</font><br>
Thomas Weigert wrote:
<blockquote cite="mid:4AF...@ms..." type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
>From the error message you are trying to load a module with an
empty
name, see below. So you want to examine what module it is trying to
load and try to understand why the name is empty. I would guess that
you did not define DB::module in your options file which tells what
data base module to use to load your data....<br>
<br>
Th.<br>
<br>
Tielman Esterhuizen wrote:
<blockquote cite="mid:4AF...@ei..." type="cite"><font
face="sans-serif">Use of uninitialized value in concatenation (.) or
string at
../GT/Eval.pm line 87.<br>
Can't locate GT/DB/.pm in @INC (@INC contains: .. /etc/perl
/usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5
/usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
/usr/local/lib/site_perl .) at (eval 28) line 1.</font></blockquote>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Tielman Esterhuizen
Consultant
Eirteic Consulting (Australia) Pty Ltd
Mobile: +61 (0) 406 538534
Office: +61 (0) 299 400288
Fax: +61 (0) 299400478
email: <a class="moz-txt-link-abbreviated" href="mailto:tie...@ei...">tie...@ei...</a>
web: <a class="moz-txt-link-freetext" href="http://www.eirteic.com">http://www.eirteic.com</a>
</pre>
</body>
</html>
|
|
From: Thomas W. <we...@ms...> - 2009-11-08 20:55:02
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I don't know about the documentation, but please look at the code of
Eval.pm around where your call fails. You will see that it used
DB::module... Th.<br>
<br>
Tielman Esterhuizen wrote:
<blockquote cite="mid:4AF...@ei..." type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<font face="sans-serif">Thanks Thomas.<br>
<br>
You're right DB::module is not set, but as far the documentation states
this is only used when using a Text file as datasource - I'm using a
mysql db. <br>
<br>
Kind regards,<br>
Tielman<br>
</font><br>
Thomas Weigert wrote:
<blockquote cite="mid:4AF...@ms..." type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
>From the error message you are trying to load a module with an
empty
name, see below. So you want to examine what module it is trying to
load and try to understand why the name is empty. I would guess that
you did not define DB::module in your options file which tells what
data base module to use to load your data....<br>
<br>
Th.<br>
<br>
Tielman Esterhuizen wrote:
<blockquote cite="mid:4AF...@ei..." type="cite"><font
face="sans-serif">Use of uninitialized value in concatenation (.) or
string at
../GT/Eval.pm line 87.<br>
Can't locate GT/DB/.pm in @INC (@INC contains: .. /etc/perl
/usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5
/usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
/usr/local/lib/site_perl .) at (eval 28) line 1.</font></blockquote>
</blockquote>
<pre class="moz-signature" cols="72"><a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://www.eirteic.com"></a>
</pre>
</blockquote>
</body>
</html>
|