Displaying 20 results from an estimated 10000 matches similar to: "Automatic traceback"
2009 Nov 24
1
ow to have R automatically print traceback upon errors
Hi,
I wonder how to have R automatically print stack trace produced by
traceback upon errors during interactive uses. I tried the suggestions on
http://old.nabble.com/Automatically-execute-traceback-when-execution-of-script-causes-error--td22368483.html#a22368775
and used options(error = recover)
options(showErrorCalls = T)
It just produces an extra message like "recover called
2009 Mar 06
1
Automatically execute traceback when execution of script causes error?
Hi
I am using R scripts which are running remotely. To make debugging
easier, I would like to have the possibility to execute traceback()
automatically when an error occurs. Is this possible?
OS: Linux
Thanks
Rainer
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Faculty of Science
Natural
2007 Dec 01
2
Sweave: Variables in code chunk headers
I would like to be able to do something like this:
<<echo=F,fig=T,width=mywidth>>=
...
@
with mywidth set in a previous code chunk. Is there a way to do this in
Sweave?
(Sorry for two questions in a row, I have been saving these up.)
--
Michael
2007 Dec 01
2
Sweave: Variables in code chunk headers
I would like to be able to do something like this:
<<echo=F,fig=T,width=mywidth>>=
...
@
with mywidth set in a previous code chunk. Is there a way to do this in
Sweave?
(Sorry for two questions in a row, I have been saving these up.)
--
Michael
2025 Jan 19
3
[External] Re: Parser For Line Number Tracing
On Sun, 19 Jan 2025, Ivo Welch wrote:
> Hi Duncan ? Wonderful. Thank you. Bug or no bug, I think it would be
> a huge improvement for user-friendliness if R printed the last line by
> default *every time* a script dies. Most computer languages do so.
>
> Should I file it as a request for improvement to the R code
> development team? Maybe R can be improved at a very low cost
2025 Jan 20
2
[External] Re: Parser For Line Number Tracing
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
2007 Jun 22
1
Lattice: hiding only some strips
I am using R 2.4.0 and lattice to produce some xyplots conditioned on a
factor and a shingle. The shingle merely chops up the data along the
x-axis, so it is easy to identify which part of the shingle a panel is
in by looking at the x-axis markings. I only want to have a strip at the
top for the factor.
Is this possible? I looked into calculateGridLayout() and it seems to me
that there
2007 Jul 03
1
Lattice: shifting strips to left of axes
Consider this plot:
xyplot(mpg ~ disp | cyl, mtcars, strip=F, strip.left=T, layout=c(1, 3),
scales=list(relation="free"),
par.settings=list(strip.background=list(col="transparent")))
I want to have the "cyl" strip labels on the left side of the axis. Is
this possible?
Failing that, is it possible to remove the left axis and display it on
the right
2025 Jan 20
1
[External] Re: Parser For Line Number Tracing
Sorry, I'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
2025 Jan 19
1
[External] Re: Parser For Line Number Tracing
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
2025 Jan 21
1
[External] Re: Parser For Line Number Tracing
And now I've found the elusive bug in show.error.locations = TRUE as
well, and posted a patch for that too.
Back to the original topic of this thread: I think most users should
routinely use
options(show.error.locations = 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
2004 Mar 12
1
Re: [R] No traceback available when using try(...) (PR#6669)
On Fri, 12 Mar 2004 11:44:14 -0500, "Roger D. Peng" <rpeng@jhsph.edu>
wrote :
>Funny, it works for me on R-patched
>
> > f <- function(a) { return(log(a)) }
> > f("A")
>Error in log(x) : Non-numeric argument to mathematical function
> > traceback()
>2: log(a)
>1: f("A")
> > try(f("A"))
>Error in log(x) :
2004 Mar 11
2
No traceback available when using try(...)
Hello,
1. The Situation :
------------------------
The stack traceback is not available when error ouccured in a try(....)
-- test.R --------------------------------
f<-function(a){
return ( log(a) )
}
try(f("A"))
traceback()
-------------------------------------------
I get the following message :
> try(f("A"))
Error in log(x) : Non-numeric argument to mathematical
2011 Nov 25
2
options(errorfn=traceback)
Dear R experts---I may have asked this in the past, but I don't think
I figured out how to do this. I would like to execute traceback()
automatically if my R program dies---every R programI ever invoke. I
guessed that I could have wrapped my entire R code into
tryCatch(
... oodles of R code
,
error = function(e) traceback(),
finally = cat("done")
}
but the traceback docs tell
2003 Oct 28
1
no traceback in R-patched
Has something changed with traceback's in R-patched? When I running the
examples for ?traceback, I get
> foo <- function(x) { print(1); bar(2) }
> bar <- function(x) { x + a.variable.which.does.not.exist }
> foo(2) # gives a strange error
[1] 1
Error in bar(2) : Object "a.variable.which.does.not.exist" not found
> traceback()
No traceback available
2004 Jun 14
2
.Traceback
Hi!
Is there a way to write the information stored in the .Traceback variable to a file?
When I try it with dump()
".Traceback" <-
list("dump(.Traceback, file = \"Mytraceback.R\")")
Or there are other ways to write this information on the disk if an error occurs?
Eryk
2004 Mar 12
1
Re: [R] No traceback available when using try(...) (PR#6667)
On Fri, 12 Mar 2004 12:28:48 +0100, Edouard DUCHESNAY
<duchesnay@shfj.cea.fr> wrote :
>> > 1. The Situation :
>> > ------------------------
>> > The stack traceback is not available when error ouccured in a try(....)
>>
>> It's a bug in 1.8.1. It has been fixed.
>>
>> -thomas
>I have patched R (Version 1.8.1 Patched (2004-03-11))
2019 Jul 11
1
Documentation tweak for ?traceback
The addition of `.traceback` in r70207 adds one more function to the call stack when invoking `traceback()`.? This changes the output of one of the examples to include the error handler call:
> options(error = function() traceback(2))
> foo(2)
[1] 1
Error in bar(2) : object 'a.variable.which.does.not.exist' not found
3: (function ()
?? traceback(2))() at #1
2: bar(2) at #1
1:
2018 Aug 08
2
[PATCH nbdkit] python: Try harder to print the full traceback on error.
The tracebacks are compressed into a single line because we're using
PyObject_Str, but they are just about usable if not very readable.
For example you would see an error like this:
nbdkit: error: ./python-exception.py: config_complete: error: ['Traceback (most recent call last):\n', ' File "./python-exception.py", line 54, in config_complete\n raise_error1()\n',
2025 Jan 19
1
[External] Re: Parser For Line Number Tracing
understood.
but, please, consider not people like me but unwary beginners and
students of R. I have used R now for decades, and even I am baffled
by it. Couldn't you make R code easier to debug not only for people
like me (who can indeed tweak their environments) but also for novice
users?
On Sun, Jan 19, 2025 at 8:46?AM <luke-tierney at uiowa.edu> wrote:
>
> On Sun, 19 Jan