moodymudskipper / debugverse

Brainstorming ideas for debugging workflow and tools, not a package (yet ?)
1 stars 0 forks source link

log_next() #39

Open moodymudskipper opened 2 years ago

moodymudskipper commented 2 years ago

This pattern is annoying :

message("computing")
x <- foo(y)
message("done")

Even more annoying if we're timing it, we could wrap the call but it's cumbersome :

my_log_function({
x <- foo(y)
})

I want :

log_next(message = "computing", fun = "foo")
x <- foo(y)

Just like with {progress} we should have a format, by default the message is the first line of code.

By default the fun is either of <-, =, control flow constructs, or { (so basically 95 % of calls we just miss side effects), we could also really do any next call by using the trick I used in {goto}, maybe better.

This might be done in {once}.

logging might be enabled by options, we can see how other logging packages do things. :

log_next(..., skip = isFALSE(getOption("once.log")))

Maybe be smart detecting for loops and apply funs and have an optional progress bar for those (default to TRUE). For while/repeat we can still show the start and elapsed time.

operations that rely on the stack might break.