`ark` discussion notes

I had the pleasure of getting to chat a bit with @lionel- at `posit::conf` and just wanted to track a few notes that came out of the discussion.

### tips for `debugadapter`

- Recommendation to use `later`. From what I can tell, this will allow for easy management of a background thread that can affect the global environment. Quick POC:
```r
i <- 0
f <- function() { i <<- i + 1; later::later(f, 1) }
f()
# wait n seconds.. Sys.sleep will not work because bg thread can't use interrupts
i
# [1]
```
looks like a totally viable solution to me. I don't really care about non-interruptable code as we just need to periodically listen for new state from the adapter at the top level. In fact, it might even offer a better alternative to running the debugger in a separate process.
- Lionel mentioned a few edge cases where either the source isn't known (not yet sourced.. if there were other cases I forgot them)
- Lionel mentioned foreseen challenges with getting the source from lines sent to the console from a selection, suggesting that it might require a wrapping function for sending code with a "faked" srcref.

### learnings from `debugadapter` for `ark`

- Mentioned that managing `trace()` insertions of `browser()` statements was painful. `trace` will affect the function's body, meaning that multiple insertions need to account for the difference between source and traced version of the code (ie, a breakpoint at line 10 in the file open in a user's editor might actually want to insert a new `browser()` at line 11 because a `browser()` statement has already been inserted at some point above). This is otherwise an attractive option, since the browser statement can be inserted at an arbitrary location (easily found with [`utils::findLineNum()`](https://github.com/dgkf/debugadapter/blob/main/R/breakpoints.R#L69))
- `debug()` simplifies this, as it will not insert code. However it introduces a new challenge - that `debug()` always enters the debug prompt upon entering a debugged function. Currently, I automatically [step through the function until a breakpoint is hit](https://github.com/dgkf/debugadapter/blob/main/R/debug_prompt.R#L45-L46). This still emits all the debug prompt output, so you get a bunch of messages as R steps through the lines of the function. Definitely still room for improvement.

### for both.. potential bug?

- Mentioned bug with `debug()`, in which the `condition` argument seems to have no effect. Might be a base R bug, or at least a devel R bug.
```r
options(browser.hook = function(hook, condition, envir) { print(condition) })
f <- function() { print("123"); browser(condition = list(origin = "browser")) }
debug(f, condition = list(origin = "globalenv"))
f()
# ...
#> debug at #1: browser(condition = list(origin = "browser"))
#> NULL # debug() condition output
#> $origin # browser() condition output
#> [1] "browser"
```