scinotes_debugger

Description

SciNotes runs a file with the debugger: the execution stops on the breakpoints of its lines and of the functions it calls, then goes on step by step. While it is stopped, the editor shows the line about to run, the mouse shows the values of the variables, and the console runs commands in the stopped function.

The commands are in the Debug menu, and the main ones in the toolbar:

On macOS, Ctrl is Cmd. The shortcuts are changed in the preferences, like the other shortcuts of Scilab. Save and execute, which used F5, now uses Ctrl+F5 and runs the file without the debugger.

Debug mode

F5 puts Scilab in debug mode, and Scilab stays in it when the execution ends: the status bars of SciNotes and of the console turn orange, and the prompt of the console becomes debug>. In debug mode, the breakpoints also stop a function called from the console, or by the callback of a graphical user interface: write the function in SciNotes, run its file once with F5, then call it as usual.

Stop Debugging (Shift+F5), or running a file without the debugger (Save and execute, or the Execute menu), leaves the debug mode.

Breakpoints

Click in the margin left of the line numbers, or press F9, to add or remove a breakpoint on a line. A dot shows it:

• red: Scilab stops on it;

• pale: not in effect yet. The file is not saved, or the line cannot be reached (its tooltip says why);

• grey: disabled;

• with a mark inside: it stops on a condition, or every N passes;

• a red ring: set by another debug client, it cannot be changed from SciNotes.

A breakpoint on a line with no code (blank, comment, end) moves to the next line that runs code. On a line with several instructions, it stops before the first one.

Right-click a breakpoint to change it:

• Enabled: a disabled breakpoint stays in the file but does not stop.

• Condition: a Scilab expression, evaluated where the breakpoint is. The execution stops when it is true, for example i == 10 or x < 0. An expression that fails, or that gives no value, stops too.

• Pause every N passes: a whole number. The execution stops once every N times the line is reached: with 100, on the 100th pass, the 200th, and so on.

A breakpoint has a condition or a number of passes, not both. Enter or a click outside the panel applies the change, Escape or its × button discards it.

The breakpoints belong to the files, not to the tabs: they stay when a file is closed, and a breakpoint in a file that is not open still stops the execution, which opens it. They are kept from one session to the next in SCIHOME/scinotes-breakpoints.json (see SCIHOME). Save as copies the breakpoints of a file to the new one.

The breakpoints follow their lines when the file is edited, but Scilab only gets them when the file is saved: Scilab runs the file as it is on disk.

When the execution stops

The line about to run is highlighted, with an arrow in the margin. On a line with several instructions, a mark shows the next one. The window comes to the front, opening the file if needed, so that the shortcuts reach it. With several SciNotes windows, the file is shown in the one that has it open.

Rest the mouse on a variable to see its value; a field (s.a.b) or a selection on one line is evaluated too. The value is the one of the function stopped in, and when nothing runs, the one of the console. Nothing is shown while the execution runs.

The console prompt becomes break>. A command typed in the console runs in the stopped function: it can display or change its variables. The variable browser shows them too. In the console, resume goes on and abort ends the execution; in debug mode, pause in the code, or Ctrl+C in the console, stops it like F6.

The status bar of SciNotes tells the state: Execution running, Paused on breakpoint, Execution paused, Execution completed, and the key that leaves the debug mode.

If the file was changed since it was run, a yellow banner says so: Scilab runs the code as it was, and the lines shown may not match it.

Stop on an error

In debug mode, an error stops the execution on the line that raised it, before it is reported: the line and the status bar turn red, and the error message is shown at the end of the line. The variables can be read as on a breakpoint, but the steps are disabled: F5 or Shift+F5 end the execution, and the error is then displayed in the console. An error caught by try or by execstr(..., "errcatch") does not stop.

Run to cursor

Ctrl+F10 runs until the line of the cursor, as if it had a breakpoint used once. When the execution is stopped, it goes on to that line. When nothing runs, the file is saved and run with the debugger. It is refused when the file was changed since the stopped execution started.

Remarks

• The breakpoints set with debug in the console stop the execution, and SciNotes shows the stop, but they do not appear in the margin.

• SciNotes has no view of the call stack or of the variables: use the console and the variable browser.

• A function of a library stops on the breakpoints of its .sci file, when it is next to the .bin file the library loads.

• Other clients of the Debug Adapter Protocol, such as Visual Studio Code with the Scilab extension, can debug Scilab too (see debug). Their breakpoints are shown in SciNotes as red rings.

See also

• scinotes — Scinotes: Embedded Scilab text editor
• debug — Среда отладки CLI в Scilab
• pause — временно приостанавливает выполнение и разрешает инструкции в консоли.
• resume — выполнение возврата или возобновление и копирование некоторых локальных переменных
• abort — прерывание исполнения
• browsevar — браузер переменных Scilab

History