Skip to content

save/load and package namespaces

10 messages · Jamie Olson, Jeff Newmiller, David Winsemius +1 more

#
Stop being surprised. Loaded packages are not part of "envir" (whatever that is), nor are they part of the global environment.  You have to reload any packages needed separately from the load call.
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
--------------------------------------------------------------------------- 
Sent from my phone. Please excuse my brevity.
Jamie Olson <inspired2apathy at gmail.com> wrote:

            
#
On Nov 7, 2012, at 9:50 AM, Jamie Olson wrote:

            
None. That's what require() or library() or source() are for.
You need to read more carefully:

?ls
?objects
?search
`ls` with default settings only lists data and function objects that the user has defined. The history mechanism could be used to restore packages that were loaded during a session.

?history

You should be able to see this by looking at what ls() produces. It does not generally return a listing of items in loaded packages.
#
On 07/11/2012 12:50 PM, Jamie Olson wrote:
None are loaded or saved when you save the object, but the names of some 
are saved.  For example,

library(Hmisc)  # not normally loaded/attached
x <- zoom # copy a function from Hmisc
save(x, file="x.RData")

This will save a copy of a function from Hmisc to the file, but the 
function's environment is the Hmisc namespace.  To properly load that 
function via

load("x.RData")

R will load the referenced namespace.  You will see it appear in 
loadedNamespaces() after the load (assuming you still have Hmisc available).

I believe this will also happen if you try to load an S4 object; you'll 
need to be able to load the namespace of its class.

Duncan Murdoch
#
On 12-11-07 6:20 PM, Jamie Olson wrote:
It should only happen for objects that have an environment associated 
with them.  Functions do, S4 objects do, formulas do, but S3 objects 
don't (unless they happen to contain something that does).

If the environment is globalenv() (the user environment), it's no big 
deal.  It's only when a package namespace is there (as with functions 
exported from a package) that you create the dependency.

Duncan Murdoch
5 days later
#
On 13/11/2012 1:45 PM, Jamie Olson wrote:
The source is here: 
https://svn.r-project.org/R/trunk/src/main/serialize.c.  It's not the 
simplest code, but if you look, you can see that the empty, base and 
global environments are handled specially (by just writing a marker, not 
their contents).  Package and namespace environments are handled by 
writing out a string describing them.  Other environments are saved by 
saving their parent, their content, their hash table, and their attributes.

So yfun would be saved, along with its environment, but the parent of 
that environment is globalenv(), so just the marker is saved.

Duncan Murdoch