Skip to content
Prev 57188 / 63424 Next

[External] Mitigating Stalls Caused by Call Deparse on Error

Luke, thanks for considering the issue.? I would like to
try to separate the problem into two parts, as I _think_ 
your comments address primarily part 2 below:

1. How can we avoid significant and possibly crippling
?? stalls on error with these non-standard calls.
2. What is the best way to view these non-standard calls.

I agree that issue 2. requires further thought and 
discussion under a wishlist issue ([on bugzilla now][1]).? 
While I did raise issue 2., the patch itself makes no
attempt to resolve it.

The proposed patch resolves issue 1., which is a big
 usability problem.? Right now if you have the misfortune of
 using `do.call` with a big object and trigger an error, you 
have the choice of waiting a possibly long time for 
the deparse to complete, or killing your entire R session
 externally.

It seems a shame to allow a big usability issue for `do.call` 
to remain when there is a simple solution at hand, especially
since the complete deparse of large objects likely serves no
purpose in this case. Obviously, if storing the actual calls
 instead of their deparsed equivalents in .Traceback causes 
problems I'm not anticipating, then that's different.? 
Is that the case?

Best,

Brodie.

[1]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17580
On Sunday, July 14, 2019, 8:52:45 AM EDT, Tierney, Luke <luke-tierney at uiowa.edu> wrote:
This is probably best viewed in the context of other issue with
displaying calls, such as issues arising from calls constructed in
non-standard evaluation contexts. Might be good to move to a wishlist
item in bugzilla.

Best,

luke
On Sat, 13 Jul 2019, brodie gaslam via R-devel wrote: