Mention debugonce()?

[jennybc]

Maybe in the debug() section here:

https://whattheyforgot.org/debugging-r-code.html#debugging-others-code

[jimhester]

I have literally never used this myself (barely ever used debug() either for that matter), but sure ;)

[jennybc]

Hmmm, I have been using debugonce() lately 🤔. Context: debugging things in another package . For example, I used it when figuring out that devtools / remotes problem. I wanted to call devtools but drop into the debugger when I entered remotes:::combine_deps().

And I think I used when I was doing revdep checks (and PRs) for tibble v2.x. Once you figure out who's screaming, you do debugonce() on that, then rerun the test.

[jennybc]

What would your workflow be in those situations?

[jimhester]

Generally when I am that far into the weeds debugging something I am planning on fixing it and sending a PR, so generally I do the standard clone + load_all() + browser() thing.

But I can see how it would be useful and we probably should mention it.

[jennybc]

It's true that I was in the the source package at that point. So I think I did eventually use browser().

[jimhester]

Thinking about this more I guess I typically use options(error = recover) when there is something in another package where you could potentially use debugonce()

[jennybc]

I think an interesting axis on which to compare all of these is how ephemeral they are, i.e. what it feels like to turn the debugging approach ON and OFF. I suspect that influences what we are choosing in different situations.

[jennybc]

And also the affordances in our preferred working environment, e.g. RStudio vs. emacs/vim, whether you have the source package yet or not, etc.