Thanks again, Hendrik, for your help. Your suggestion would work. You
could even wrap the save image and the dump.frames command in one
function that is called when an error occours.
I now, however, wrapped a dummy function around the call to source
that starts my script and supplies a copy of the global environment to
this function. As a result, i can access all neccessary objects while
debugging. The open question to me is whether a default behaviour of
dump.frames which saves the global anvironment automatically would help
others as well .... ?
Cheers
Jannis
On 24.07.2012 17:58, Henrik Singmann wrote:
I somehow was unsure whether or not your procedure was interactive or
not. But when it is non-interactive, your problem remains: "If recover
is called in non-interactive mode, it behaves like dump.frames" (and
will likely not save the global environment."
The only othjer idea I have is that you could save the global
environment occasionally in your script and load it with the dumpoed data:
save.image(file = "save.RData")
#after crash:
load("save.RData")
Best,
Henrik
Am 24.07.2012 17:45, schrieb Jannis:
Thanks, Henrik for your reply. Well, the reason (until now) was that I
thought recover would only work in interactive sessions. The question,
however, no would be how to save the error object an daccess it later.
Additionally, are you sure that the content of the global environment
is saved with recover? The handling looks very much the same as
browsing dum.frame objects.
Cheers
Jannis
On 24.07.2012 16:25, Henrik Singmann wrote:
Dear Jannis,
is there any specific reason you use dump.frames instead of recover? As
far as I see it, options(error = recover) would allow to access the
global environment.
And as ?recover tells you: "The use of recover largely supersedes
dump.frames as an error option, unless you really want to wait to look
at the error. If recover is called in non-interactive mode, it behaves
like dump.frames. For computations involving large amounts of data,
recover has the advantage that it does not need to copy out all the
environments in order to browse in them. If you do decide to quit
interactive debugging, call dump.frames directly while browsing in any
frame (see the examples)."
However, as I haven't used dump.frames ever, this is not really an
answer to your question.
Hope it helps,
Henrik
Am 24.07.2012 16:10, schrieb Jannis:
Dear list members,
I am trying to use dump.frames to debug some code that i run non
interactively. I use the following method:
dump.frames.mod = function() {
dump.frames(dumpto = 'test', to.file = TRUE)
quit(save = 'no', status = 10)
}
options(error = dump.frames.mod)
Is there any way to acess the content of the global environment from
the *.rda file created in case of an error?
When I run the following, for example, I would like to access the
contents of a,b and c from the debugging file:
dump.frames.mod = function() {
dump.frames(dumpto = 'test', to.file = TRUE)
quit(save = 'no', status = 10)
}
options(error = dump.frames.mod)
#uncomment with care:
#rm(list=ls())
a = 2
source('testscript.R', local = TRUE)
load('test.rda')
debugger(test)
testscript.R in this testcase contains:
b = 2
c = 3
plot(d)
The only way I found is wrapping a function around the lines of code
but this would mean changing a lot of code.
Any Ideas?
Cheers
Jannis
> sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-unknown-linux-gnu (64-bit)
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
