|
PureBytes Links
Trading Reference Links
|
Y,
Thanks for the excellent summary of many issues related to debugging
with AFL.
I like your suggestion that paired {} () should be highlighted in a
way to make it easy to see that the proper pairs are matched for typo
debugging.
I currently have 31 main include files in my program and I expect it
to grow to 40 soon, then more with additional ones for variations, so
I am very keen on debug support for these. I also use include files
for individual indicators designed for my platform much as others
would use drag and drop files.
I also like your verify syntax idea for includes. I had even given
thought to using the ability to detect undefined variables as a way to
dummy up the missing variables in the includes just for the syntax
checks. However, the repeated effort involved seems too much for the
gain, and I don't want to slow down the code for this. My running
system for trading is usually running over .5 seconds with execution
over just a few thousand bars --and no, I don't do inefficient things
like putting array operations inside a bar loop. I am a realtime
programmer of microcomputers also.
I am using AB in indicator only mode with real time charting,
backtesting, trade signals, chart buttons, etc. on a single futures
contract. I run a 5 second database, but I am mostly working in 1
minute bars. So I am aware of all the various issues you bring up and
most of my suggestions are to make it easier to operate AB in this mode.
A significant amount of my own development efforts have been towards
adapting AFL to the requirements of my realtime chart based trading.
In fact, I have also added additional debugging aids into the platform
(I really only have one AFL program that does everything I want for
trading may different systems). For instance, I can toggle a debug
mode parameter. In this mode, a Bar Inspector information table is
displayed on my chart. Debug statements can be placed in loop code (I
use a lot of loops for complex logic and to speed up the code since
array processing does not let me fully control the number of bars of
history):
DebugVar("Label", Value, Index);
So, I can display a constant or variable text "Label" and a numeric
value for an index = selectedBar, or any other bar formula, or 0 for
non-indexed. Then I can just go clicking on bars and see what my
chosen variables are right on the chart. This is for "real"
debugging. Also the global FP_Debug is always available for putting
in some custom debug code:
if(FP_Debug){ SayAndWait("made it to section 5");
I find that a verbal indicator is often easier to get a quick check on
an internal state than a bunch of traces coming out. The SayAndWait()
function will pause the AFL program until it finishes talking --quite
handy.
I can switch realtime between turning on the debug code and running
clean without editing the AFL -- though I do a lot of editing of AFL
on the fly also.
That is important to me, because I am usually running the program on
live trading data (not auto trading, just manual) while I am adding
and debugging code too. LOL
BR,
Dennis
On Feb 11, 2009, at 3:35 PM, jtoth100 wrote:
> Short summary:
> 1. Optional feature to require all variables to be declared and
> AFL parser to check if all identifier (var and function) is declared.
> 2. Fixed error position info in include files or "Syntax checking"
> for include files.
>
> Hi Dennis,
>
> you are right. Script languages are the easiest.
> I think that AB's greatest advantages are the fast backtester and
> its "special" array processing script language. So I don't mind that
> it
> is a script. For a "quick idea check/strategy development" it is
> great.
> For real time trading on a one minute chart it is an "adventure". The
> programming model and the runtime environment are not designed for
> this
> purpose.
>
> Back to finding bugs. If we talk about typos the most annoying errors
> for me are the missing/extra {, (, ), } in an include file (I use ~
> 10-
> 15 includes. I developed a framework with testable include modules).
> Then comes the variable name mistypes. Then comes the missing function
> argument where the function is in an include. Finding them is "not
> real
> debugging", it is typo error hunting in a script. If my suggestion is
> implemented in AB the variable name mistypes and resulting
> initialization issues of a typo are caught with no "typo hunting"
> effort. They can be caught at parse time (at first parse) even in code
> sections (functions also) that are not executed on each chart refresh
> (e.g. real time trading functions).
>
> I agree with you on include file problem. Anything is better than the
> useless character position info. The "quick and dirty" solution to
> includes could be a special "Verify syntax" feature for include files.
> Syntax validation is now useless for an include file as includes
> usually use other includes where functions are defined. All the syntax
> errors of missing function declarations make is hard to find real
> syntax errors (like a missing ;) in an include file. And the not
> resizable error list at the bottom of the script windows makes it
> impossible anyway.
>
> If we talk about "real" debugging to find program logic errors we have
> to distinguish trading strategy development and real time trading
> logic
> code. They are quite different in the way you write code and how you
> debug them.
>
> In trading strategy development we mostly use AFL in its "intended
> way". We have to think in sets/vectors/matrixes. The programming model
> is static. We mostly work on static data (past), the result is static.
> So its not a big deal. We simple display the static results of
> set/vector/matrix operations on a chart (these are indicators,
> filters,
> explorations). Code path is usually "straight" without branching. To
> debug this logic we have to write debugging code (Plot/PlotShapes
> calls, displaying bar data in tooltip and interpretation window). We
> change the code, run it then we stare at the chart. It is static and
> we
> have time... :)
> AB does not provide any handy tool for this type of debugging. There
> is
> no way to step through the code and display an array variable on the
> chart ad-hoc. You have to change the code. (And version it ... )
> If there would be a "mouse click shortcut" to generate code to plot a
> variable or to "mark" a single variable to be displayed with some
> distinctive style on the chart with its own scale… This type of
> debugging could be easy and fast.
>
> Real time trading system development is quite different. There we need
> an "event driven like" run time environment. The programming model is
> quite dynamic, the data to process changes continuously (e.g. when the
> status of an order changes the code has to react. The indicators on
> the
> actual bar change values continuously and orders have to be send
> according to the changing indicator values). Here we do not use arrays
> but "STATIC variables" to store current state of a system. Code path
> is
> quite fragmented. There are a lot of branching and function calls. I
> do
> not intend to hurt TJ or anyone but AFL and it's runtime environment
> is
> not designed for this.
> To develop a "reliable" system of this type we would need at least a
> code debugger and an exchange simulator. With them we could step
> through the code and see how the state of the system (static variable
> values and code path) changes and to check if all code paths work as
> intended.
> AB does not have a step through debugger so we have to put trace code
> everywhere and print out all interesting variable values to debug
> output and to log files.
> The real catch with this type of programming in AFL is that errors
> (syntax and logical) show up unexpectedly and then they disappear at
> next refresh. AB 5.20's log window is a great deal of help in this.
> But
> that is after the event... If you have a position and it should be
> closed you do not want to bother with mysterious bugs.
> These errors appear and disappear as different code paths are
> executed.
> Stricter language syntax ("option explicit" like required variable
> declaration and stricter parse time checking) does not solve program
> logic bugs but a lot of these sudden syntax errors could be
> eliminated.
>
> Regards
>
> Y
>
>
>
>
> ------------------------------------
>
> **** IMPORTANT ****
> This group is for the discussion between users only.
> This is *NOT* technical support channel.
>
> *********************
> TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail
> directly to
> SUPPORT {at} amibroker.com
> *********************
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> For other support material please check also:
> http://www.amibroker.com/support.html
>
> *********************************
> Yahoo! Groups Links
>
>
>
------------------------------------
**** IMPORTANT ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
*********************
TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
*********************
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
*********************************
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|