The dust debugger — dust_browser • dust2

Control browser-based debugging of dust models. This help page documents three functions that can be used to control if and how the browser is enabled. You can't enter the debugger from any of these functions; it is only enabled if present in your C++ code (or if using odin2 if you have enabled it).

Usage

dust_browser_enabled(value = TRUE)

dust_browser_verbosity(level)

dust_browser_continue()

Arguments

value: Logical, TRUE for where the debugger should be enabled, FALSE otherwise.
level: The verbosity level, as a string. This must be one of the values quiet (prevents informational messages), normal (prints a single line on entry) and verbose (prints several informational messages on entry). The default is normal.

Value

Both dust_browser_enabled and dust_browser_verbosity return the previous value of the option they are setting.

Details

dust2 includes an extremely simple debugging system, and if you are reading this message, there's a good chance you are inside it. It is built on top of R's browser() and so all the usual tips, tricks and issues for working with this apply. We recommend setting the R option browserNLdisabled = TRUE to avoid surprises from pressing <enter>.

You can press n or c to proceed to the next enabled iteration
You can press Q to quit the browser (this will end up as an error by the time you have control back)

These commands are established by browser, and can't be disabled. This means that if you have an variable called n you will need to work with it as (n) (i.e. in parentheses). This applies to all of browser's command variables (c, f, n, s, r and Q); please see browser for more information.

By the time the environment has been created, some variables from your model will have been copied into the environment; you can see these by running ls() and write expressions involving these objects. Changes that you make in R are not (currently) propagated back into the running system.

If you enable the debugger, you may have very many iterations to get through before control is returned back to the console. You can run dust_debug_continue() to prevent entry into the debugger until control is passed back to you; this means the time series will run to completion and then the next time you run the system the debugger will be triggered again. Alternatively, you can run dust_debug_enabled(FALSE) to disable all calls to the debugger.