[R] dump.frames and global environment

[Jannis]

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)
>>>>
>>>
>>
>