Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
POC, not done, needs discussion with @lionel- about what this should look like. Part of a larger plan to stop inlining the heck out of everything when we do an R function call - see posit-dev/positron#2797
This technically addresses posit-dev/positron#4008 and is motivated by it
The problem in that issue is that when
r_format(x)
calls the R levelharp_format(x)
, it inlinesx
into the call. This means that whenharp_format()
errors and the R traceback is captured, the inlined version ofx
is captured in the R traceback, which we then print in the Output pane.In this case
x
was an absolutely massive brmsfit object with elements in it that we don't know how to format, causing an error to get thrown fromharp_format()
, causing it to get inlined.There are really two things to address here:
First off, we actually expect
harp_format()
to error sometimes, so when we propagate itsResult
upward, do we really want the full traceback report to be provided whenever thatError
is eventually logged? It feels to me like this is an "expected" error in some cases, and seeing the full traceback is noisy and misleading. I really just want to see themessage
, I think.Secondly, I think we need to invest in some infrastructure that allows us to replicate rlang's
eval_with_x()
idea. i.e. create a child env, define variables in it, and evaluate in that child env. This avoids the inline problem and results in cleaner tracebacks. I'd really like for this to be hooked intoRCall
andRFunction
somehow, but I think we need to talk about the idea some more.This PR starts by adding
try_eval_with_x()
, but it feels like the wrong level of abstractionReprex:
Run
Then go to the Variables pane and try and expand
mod_miss
.Before:
Note that the
R backtrace
contains the entire inlined object.After (note that we still noisily show the R thread traceback here, but at least we can tell what is going on):