search for: findfun3

I've posted a patch to bugs.r-project.org that fixes the traceback() issue. It's not specific to findFun3; you get the same problem with errors from expressions like 1 + "a" In my testing, I occasionally saw cases where show.error.locations = TRUE didn't work. I'll try to track down a reproducible case, and perhaps a patch to fix it. Duncan Murdoch On 2025-01-20 9:37 a.m.,...

...ations = TRUE) e.g. in their .Rprofile. That will often speed up bug fixes, especially if my patch is incorporated. Duncan Murdoch On 2025-01-20 5:56 p.m., Duncan Murdoch wrote: > I've posted a patch to bugs.r-project.org that fixes the traceback() > issue. It's not specific to findFun3; you get the same problem with > errors from expressions like > > 1 + "a" > > In my testing, I occasionally saw cases where show.error.locations = > TRUE didn't work. I'll try to track down a reproducible case, and > perhaps a patch to fix it. > >...

...'m not seeing the first problem now: options(show.error.locations = TRUE) works fine. Not sure what I did wrong before. I'm still seeing `traceback()` failing to report the attempt to call nofunction(). I suppose this is because a context is never set up for the failed call. Perhaps findFun3 could set up a fake context so that traceback() adds one more entry? Duncan Murdoch On 2025-01-19 3:39 p.m., Duncan Murdoch wrote: > Thanks for pointing out the options. Using > > options(show.error.locations = TRUE) > > works on Ivo's example, but it doesn't show...

Thanks for pointing out the options. Using options(show.error.locations = TRUE) works on Ivo's example, but it doesn't show a location if the error happens in a function that doesn't have srcrefs, because the known location isn't on the top of the stack. Perhaps TRUE (and maybe "top"?) should look back through the stack until it finds a known location, and