debugging

The built-in debugger lets you see what's happening in your code so you can find problems and fix them. When you are in debugging mode, you can set breakpoints to pause the script, examine values, and see how the code is executing line by line.

to enable debugging mode

picture
To run your script in debugging mode, use the debug button (instead of the regular run button). When running in debug mode, you can pause your script at any time, and it will pause automatically at each breakpoint you have set in your code.

setting breakpoints

picture
While debugging, you can set breakpoints. When you set a breakpoint the code will pause on that line, enabling you to see what is going on in your code. Note that you cannot set breakpoints while editing code (you need to be in debug mode).
In order to set a breakpoint, select a statement and tap on the toggle breakpoint button (that's the button with the big red dot). Notice a small red dot appearing on the left side of the statement. In order to remove a breakpoint, tap the same button again.
You can set multiple breakpoints in the same script.

the debugger interface

While debugging, you cannot edit the script. Instead, you will have several new abilities:
  • go to current statement (that is about to be executed)
  • show the current stack trace (the list of all currently active actions)
  • go back to wall (which will be frozen, but reflects the state of the script)
You can also toggle breakpoints with the breakpoint button.

stepping through the code

The top or left panel has four new buttons: continue, step in, step over, and step out. These buttons determine how the next step will be executed while debugging.
picture
There are four buttons to run or step through the code:
  • continue runs the script from the spot where it was frozen, just as it would be run in normal mode, until it pauses or stops as described above.
  • step in takes one step of execution, just as step over does, but if the current statement is an action call, the execution will go inside the action called and you can debug the script from that point.
  • step over takes one step of execution up to the next visible script statement, without going into actions.
  • The step out button can be seen as the opposite of step in: if you are inside a action call, the execution will run until the end of the current action and stop right after the call in the calling action. It should be noted, however, that pressing this button in a top-level action or an event will result in running the whole script until it pauses or stops, as described above.

pausing and stopping

After you start debugging, you can choose to continue the execution of the script. It may pause or stop for one of the following reasons:
  • It pauses when a breakpoint you have set is hit.
  • It pauses when you tap the pause button on the wall.
  • It stops when the script crashes.
  • It stops when the script reaches the end of its regular execution.

viewing the current script state

While the script execution is frozen, you can view the current state by selecting statements in the code. Selecting any statement results in a panel showing data and local variables that are relevant to the currently selected statement. You can tap some values to see more details.

switching between wall and code

picture
While debugging, you can switch between the wall and the code view.
  • To go from the code to the wall, tap go back wall.
  • To go back to the editor from the wall, tap the back button. Note that the back button works differently in debugging mode.

coverage

While you are debugging, lines of code that already got executed are colored in a subtle way. You can also collected coverage information without debugging; see coverage for more information.

profiling

If you are debugging a performance problem, you might want to use the built-in profiling tool; see profiling for more information.

show me the videos!

  • a quick step-by-step tutorial
  • in-depth description of the debugger