Error line numbers are wrong

[rubenarslan]

Sorry if this rather belongs in Rstudio.
Debugging Rmds was easier with knitr, because it sent you to the right line number when an error occurred. Now the default view is the "Issues" view in Rstudio. Not only is this view a bit cramped, it contains superfluous information (like the trace "Calls: ... withCallingHandlers -> withVisible -> eval -> eval -> plot" – everything from Anonymous to plot is just related to knitr internals, I don't care about it and it confuses our B.Sc.s).
You cannot copy the entries in the Issues view.

The output view is more useful, but it only says Quitting from lines 19-21 (test.Rmd), ie. it gives you only an approximate line number.
The line number in "Issues" is precise, but it can be completely off. One instance where I could pinpoint it: if I source an R script inside a chunk, all errors after the source statements will be pinned to the top of the chunk.

Here's a reproducible script:

```{r}
source("~/Any_old_file.R")
plot(car)
```

I hope bugs relating to this can be fixed and that debugging Rmds becomes easier in general.
I've had some fairly difficult to debug problems recently where these changes made them very tough to crack.
Usually I simply execute a file with Command-Shift-S in a fresh session so that I can debug in the session.
This is not my favourite way though, because this way I don't benefit from the cache, and some of my Rmd files take hours to execute.

I would love to be able to pick up inside the session when rmarkdown errors out, I don't know if that's possible though.

[jjallaire]

Thanks for this feedback. I think you are correct that debug-ability of Rmd isn't great, and I'm sure there are some simple things we can do (like the ones you suggest) to improve this. This will probably be a combination of IDE work and rmarkdown package work, and we hope to take this on soon.

[rubenarslan]

Wonderful. In the meanwhile, have you collected somewhere the reason why the line number for a bug reset to the first line a code chunk? I know it happens when I source, but it also happens without that sometimes (to be honest, I'm still trying to fix one particular error :-).

[jjallaire]

I'm not sure whether error information more granular than that is available
from the evaluate package (which is what knitr uses for executing code
chunks). @yihui do you know whether we can be more precise than the range
of lines containing the chunk?

On Mon, Feb 23, 2015 at 12:39 AM, Ruben C. Arslan [email protected]
wrote:

Wonderful. In the meanwhile, have you collected somewhere the reason why
the line number for a bug reset to the first line a code chunk? I know it
happens when I source, but it also happens without that sometimes (to be
honest, I'm still trying one particular error :-).

—
Reply to this email directly or view it on GitHub
#381 (comment).

[rubenarslan]

Well usually the line number is right, so I think it's mostly about picking the most appropriate line from the trace, I've been able to identify two exceptions:

1. If an R script is sourced anywhere in the chunk, any errors are attributed to the top line (even if it's empty).
2. When using a user-defined function where the error occurs somewhere in that function's internals.

I found this issue in evaluate, I think it is about some of the same stuff: r-lib/evaluate#37

[yihui]

@rubenarslan For debugging, you can compile the document in an interactive R session instead of clicking the button in RStudio, since it is not easy to debug in a non-interactive R session. Take the following minimal file test.Rmd as an example:

```{r}
f = function(x) {
  x
  g = function() stop('Foo')
  g()
}
f(1)
```

When you compile it via rmarkdown::render('test.Rmd') in the R console in RStudio, you will see two options

 Show Traceback
 Rerun with Debug

If you show traceback, you see

processing file: test.Rmd
  |......................                                           |  33%
label: unnamed-chunk-1
Quitting from lines 2-8 (test.Rmd) 
 Error in g() : Foo 
19 stop("Foo") at <text>#3
18 g() at <text>#4
...

First, knitr tells you the error came from lines 2-8, and you can find that code chunk; then there are line numbers like #3 in the traceback, which tells you which line in the code chunk signaled the error. In your case, source() will also tell you the line numbers by default in an interactive R session (use source(keep.source = TRUE) if you want this behavior explicitly).

You can click Rerun with Debug in RStudio if you want to debug the code interactively, but you should type sink() after you rerun. Then you should be in a familiar world of browser(). Hope this helps.

[rubenarslan]

@yihui thanks, I know I can do that, but it used to be that it didn't need to do so as often (with knitr, as opposed to rmarkdown, but maybe I'm just making different mistakes these days). My reports often take hours to generate, so I love the fact that Rstudio quickly spawns them in another process.
Is there a very good reason why Rstudio does not spawn a new interactive session by default and renders there? That way, I would be able to jump in and trace errors even when I didn't expect them (i.e. almost always). It would also allow me to call warnings() (this is related to the other bug I reported with Matrix doing something odd with withCallingHandlers).

Are there plans to make Rstudio able to spawn/manage more than one extra process? If often have multiple reports to re-generate once I fixed a bug in cleaning scripts etc. and mostly I three of four cores are idle.
I guess I can already have multiple projects open at the same time, but that's not as convenient and doesn't really make sense when all reports belong to the same project.

[Deleetdk]

Is there any update on debugging with .Rmd? I'm experimenting with switching to R Notebook, but the debugging is terrible compared to working with .R files.

[rubenarslan]

Would also be interested if there's any documented workflows that people know of that do testing (like devtools/R CMD check for packages) for Rmd files?

[yihui]

@Deleetdk No update. Sorry.

@rubenarslan I don't have a better suggestion other than calling render() in an interactive R session. For your question "why RStudio does not render Rmd in an interactive R session by default", I guess this question has been asked many times, and the answer is for better reproducibility. We understand that in certain cases it may be desirable to render Rmd in an interactive R session, but we don't want to surprise users when they find the reports are not reproducible by other people in a different R session. If you want to use an interactive R session, you can either file a feature request to the RStudio IDE (support.rstudio.com), or write an RStudio addin by yourself to execute rmarkdown::render() in the current R session (https://rstudio.github.io/rstudioaddins/).

For your last question, you may see ropensci/unconf17#38 (I forgot the name of the package that they developed and you can ask them).

Would also be interested if there's any documented workflows that people know of that do testing (like devtools/R CMD check for packages) for Rmd files?

I'm closing this issue because I feel there isn't much we can do in the rmarkdown package to improve debug-ability.

[rubenarslan]

@yihui my suggestion would have been a fresh interactive session, not the current one with all its state/loaded packages. Just so that after it fails or emits too many warnings to be shown, I can run warnings() or traceback() Are the error line numbers in the report still wrong sometimes? I haven't checked this in a while.

[Deleetdk]

One particularly annoying thing with debugging in R notebooks is that when you are inside browser() and print a data frame, it doesn't get printed to the console. It gets printed to the notebook. But because the notebook is paused due to browser, nothing actually happens. The only work around I know is to use View. Very annoying!

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.