so should I use reg.finalizer or overwrite .Last()? If I use
reg.finalizer, what should be the environment that I specify? The
straight forward solution would be to have a hook .onExit that a
package could specify to make sure that the code was unloaded before
the program terminates, that way I don't overwrite .Last if if has
another purpose.
-Andrew
On Tue, Nov 16, 2010 at 11:27 AM, Charles C. Berry <cbe...@tajo.ucsd.edu> wrote:
> On Tue, 16 Nov 2010, Andrew Redd wrote:
>
>> Just found in the documentation for getHook that packages are not
>> unloaded on quit. How should I force a package to unload on quit?
>
> See
>
> ?q
>
>
> HTH,
>
> Chuck
>
>>
>> -Andrew
>>
>> On Tue, Nov 16, 2010 at 10:25 AM, Andrew Redd <amr...@gmail.com> wrote:
>>>
>>> Are packages unloaded on quit so that the .Last.lib or .onUnload are
>>> called for packages?
>>>
>>> -Andrew
>>>
>>> On Fri, Nov 12, 2010 at 3:52 PM, Andrew Redd <amr...@gmail.com> wrote:
>>>>
>>>> Perhaps you could help me make some sense of this. Here is a printout
>>>> of my sessions.
>>>> ---
>>>> toys$R -q
>>>>>
>>>>> library(test2)
>>>>> gpualloctest()
>>>>
>>>> testing allocation on gpu
>>>> C Finished
>>>> Collecting Garbage
>>>> done.
>>>>>
>>>>> q()
>>>>
>>>> Save workspace image? [y/n/c]: n
>>>>
>>>> *** caught segfault ***
>>>> address 0x7f12ec1add50, cause 'memory not mapped'
>>>>
>>>> Possible actions:
>>>> 1: abort (with core dump, if enabled)
>>>> 2: normal R exit
>>>> 3: exit R without saving workspace
>>>> 4: exit R saving workspace
>>>> Selection: 1
>>>> aborting ...
>>>> Segmentation fault
>>>> toys$R -q
>>>>>
>>>>> library(test2)
>>>>> gpualloctest()
>>>>
>>>> testing allocation on gpu
>>>> C Finished
>>>> Collecting Garbage
>>>> done.
>>>>>
>>>>> library.dynam.unload('test2',system.file(package='test2'))
>>>>> q()
>>>>
>>>> Save workspace image? [y/n/c]: n
>>>> toys$
>>>> ---
>>>>
>>>> I have a in the test2/R/zzz.R file
>>>> ---
>>>> .onUnload <- function(libpath)
>>>> library.dynam.unload("test2", libpath)
>>>> ---
>>>>
>>>> so the code should be unloaded. But it appears that it is not from
>>>> errors when I explicitly unload the test2.so it does not through a
>>>> segfault. Why would this be happening? and how do I circumvent it.
>>>>
>>>> thanks,
>>>> Andrew
>>>>
>>>>
>>>> On Fri, Nov 12, 2010 at 3:32 PM, Prof Brian Ripley
>>>> <rip...@stats.ox.ac.uk> wrote:
>>>>>
>>>>> On Fri, 12 Nov 2010, Andrew Redd wrote:
>>>>>
>>>>>> I have a package that I'm developing that I need to unload the
>>>>>> library. Long story short I figured out that the leaving the compiled
>>>>>> code loaded lead to a segmentation fault, but unloading the code will
>>>>>> fix it. I've read the documentation and it appears that there are
>>>>>> several ways to do this? What is the popper accepted current standard
>>>>>> for unloading compiled code?
>>>>>
>>>>> Depends how you loaded it: you basically reverse the process.
>>>>>
>>>>>> The options as I understand them are:
>>>>>> 1. dyn.unload
>>>>>> 2. library.dynam.unload
>>>>>> used with either
>>>>>> A. .Last.lib
>>>>>> B. .onUnload
>>>>>>
>>>>>> If it makes a difference my package does use a NAMESPACE so the
>>>>>> package is loaded through useDynLib.
>>>>>
>>>>> So you need an .onUnload action calling library.dynam.unload.
>>>>>
>>>>> Slightly longer version: you need the DLL loaded whilst the namepace is
>>>>> in
>>>>> use, so it has to be in .onUnload, and useDynLib calls library.dynam so
>>>>> you
>>>>> need library.dynam.unload to do the housekeeping around dyn.unload
>>>>> which
>>>>> matches what library.dynam does around dyn.load.
>>>>>
>>>>> There are quite a lot of examples to look at, including in R itself.
>>>>> MASS is
>>>>> one example I've just checked.
>>>>>
>>>>> Having said all that, my experience is that unloading the DLL often
>>>>> does not
>>>>> help if you need to load it again (and that is why e.g. tcltk does not
>>>>> unload its DLL).
>>>>>
>>>>>> Thanks,
>>>>>> Andrew Redd
>>>>>>
>>>>>> ______________________________________________
>>>>>> R-devel@r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>>
>>>>>
>>>>> --
>>>>> Brian D. Ripley, rip...@stats.ox.ac.uk
>>>>> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
>>>>> University of Oxford, Tel: +44 1865 272861 (self)
>>>>> 1 South Parks Road, +44 1865 272866 (PA)
>>>>> Oxford OX1 3TG, UK Fax: +44 1865 272595
>>>>>
>>>>
>>>
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> Charles C. Berry Dept of Family/Preventive
> Medicine
> cbe...@tajo.ucsd.edu UC San Diego
> http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
