Debugging EasyLanguage Code – Part I
Why won’t my code verify? Why isn’t it doing what I want it to do? Why is it generating that run-time error message? To answer these questions you must know something about code debugging, the subject of our next few blog entries.
Code problems fall into three categories: syntax errors, logic errors, and run-time errors. This week we’ll discuss syntax errors.
Syntax errors prevent code from verifying (compiling). Luckily, the compiler will generate a verification error message telling you what the problem is and highlighting the place in the code where the compiler believes the problem occurs. Often, it is easy to understand the compiler’s error message and repair the problem. Sometimes, however, the location highlighted by the compiler is not the location of the actual syntax error. Also, the error message the compiler generates may be misleading – it may misdiagnose the problem. For example, a missing comma in a variable declaration statement will lead to the compiler message “Semicolon expected here.” In cases like this, you can proceed as follows:
1) Avoid taking the error message produced by the compiler too literally. Remember that changing syntax by adding “begin” and “end” statements, adding or removing semicolons, or making other changes, can change the logic of your program. Instead, reduce the code to something that will verify, then gradually add code back in until the syntax error recurs. Inspect the code for missing or extraneous punctuation or incorrectly formatted statements.
2) Look for sample code that uses the function or reserved words with which you’re having difficulty. Search the Support Forum (link below) and the TradeStation “work area” – the EasyLanguage analysis techniques and strategies that come with the TradeStation platform. To search the work area, begin by opening any EasyLanguage analysis technique (File -> Open EasyLanguage Document). Then, follow the Edit -> Find in Files menu sequence.
Debugging EasyLanguage Code – Part II
Last week we talked about how to find and fix syntax errors. However, what do you do when your code verifies (compiles), but produces “incorrect” results? We’ll address that question this week. In this installment of our blog on debugging, we’ll review methods that you can use to find and repair logic errors in your EasyLanguage code.
1) Approach debugging methodically. You must have a logical, step-by-step process by which you will isolate the statement in your code that is causing the problem. Random code changes are unlikely to solve the problem.
Follow a process of elimination through which various possible causes of error are checked and eliminated from consideration. You can work either “forward,” from source data through to final output, or “backward,” from the incorrect output back to source data, checking intermediate calculations as you go.
2) Take notes. Debugging is an iterative process and can be complex. Calculations of a given variable often involve calculations of other variables. Keep a record of your troubleshooting activity. Use it to ensure that you don’t needlessly repeat work that you’ve already completed.
3) Use debugging tools like Plot statements, Print statements, and the EasyLanguage debugger.
Plot statements can be used in indicators to display the value of any variable of interest. Plot statements are handy as a debugging tool because they display a variable’s history, and its current value.
Print statements are used to display the values of variables and source data in the EasyLanguage Output Bar. See the User Guide for more information on Print statements.
Another handy way to review the values of variables and data is to use the EasyLanguage debugger. See this presentation for more information:
A recap of EasyLanguage Debugger presentation for the ‘Developers PreConference’:
Warning: The debugger is not as advanced a tool as that found in a Microsoft programming suite. The version that comes with TradeStation 8.0 build 1869 is designed for charting and is unreliable when used with RadarScreen. Additionally, the ‘control’ icons for ‘Go to End of Bar’ and ‘Next BreakPoint’ do exactly the same thing: ‘Next BreakPoint’. If you know the limitations and avoid getting frustrated with ‘expectations’, it can be a powerful tool!
Introduction to the TradeStation Debugger
How to use the Debugger
Advantages of the Debugger
The Debugger is an alternative to display of Print Statement output in the “EasyLanguage Output Bar”
Here are the advantages:
1. Obtain variable values ‘in process’. Print statements always run at the ‘end of the EL run’.
2. Dynamically modify historical variable display while code is running
3. Increase displayed decimals while code is running.
4. Determining Simple vs. Series variables
The procedure for using it
1. Invocation via ‘BreakPoint’
2. Step forward controls
3. Display controls
4. Watchlist Inputs
Invoking the Debugger
There is a one step operation: Insert the Reserved Word “Breakpoint” with a label into your code
BreakPoint( “1” );
Labels are required
Labels can be string variables
Here is how it looks:
We have covered Debugger advantages over ‘print debugging’
The Debugger is useful during any programming session
Debugging EasyLanguage Code – Part III
In the third part of our three part series on EasyLanguage debugging, we’ll discuss a few ways to find the causes of floating point exceptions, a common source of run-time error messages.
If a calculation results in a number that cannot be represented by the computer, a run-time error message may be generated. Such calculations raise “floating-point exceptions”, communications from the CPU that a calculation error has occurred and that the resulting calculated values are not meaningful. Such exceptions are generally trapped by EasyLanguage, which then completes the current code pass, stops EasyLanguage processing of the code, and generates an appropriate error message.
If the exception occurs intermittently, it can be difficult to isolate. Of course, if the error occurs in a predictable manner, for example, when your code is first applied to a chart or when it’s applied to a specific symbol, then it will be easier to troubleshoot the problem.
Here are some techniques to use when troubleshooting floating-point exceptions:
1) Make use of run-time and Print Log error messages. If an attempt is made to print an undefined value to the Print Log, an exception message will be printed there, rather than the non-meaningful value. Of course, once code execution is stopped, a separate error message will be generated in the TradeStation Events Log.
2) If the error is predictable then, by process of elimination, isolate the statement or block of code in which the error occurs. Alternatively, step through the code with the debugger to find the values causing the exception.
3) If the error is unpredictable, use log files. Use Print or FileAppend statements to create a record that can be used to see what values of important variables were just prior to the exception.
4) Inspect calculations for common causes of floating-point exceptions, such as:
a) Raising numbers to large positive powers (overflow). Raising numbers to large negative powers does not generate an underflow in EasyLanguage.
b) Attempting to raise a negative number to a fractional power.
c) Undefined mathematical operations, such as division by 0 (zero).