[RkWard-devel] handling of loaded packages?

[SJR]

Am Sonntag, 7. Januar 2007 21:34 schrieb Thomas Friedrichsmeier:
> On Saturday 06 January 2007 01:47, SJR wrote:
> > while fiddling around with some packages I was wondering how to handle
> > loaded packages. The usual way is require(). Then the package is loaded
> > and kept in the workspace.
> > This is also happening in some of the coming new plug-ins e.g. the
> > distribution analysis, though very limited. Since RKWard will also handle
> > very sophisticated tasks in future we will require more packages that do
> > not belong to the basics (base, stats, graphics, ...). Should we pay
> > attention to workspace "cleaning procedures".  For example if package YX
> > is not required for, let's say 10 minutes, then package XY is unloaded
> > else kept for the next time frame and so on. Maybe it's "wise" to keep
> > memory usage as low as possible, though I did a little test and there is
> > only little change when some pages are loaded. Loading of packages will
> > be fast anyway. But I don't see a way to do it automatically in R.
>
> Some thoughts:
> 1) The 10 minutes feature would be nice, but somehow we'd need to figure
> out, when a package is used.

Glad to hear this but supprised at the same time.

> Of course, we could check, when it is require 
> ()d, but this would not be enough, since the user may well be using the
> package, without calling require each time.

Here a shot pop up window could help. "Package XY wasn't use since ... . Do 
you want to remove it? ...". A yes or no would be the answer and subsequent 
start the action.

> Also, libraries, which depend 
> on other libraries, typically call require () only when loading, but not
> necessarily in every function. So I'm afraid, I can see no good way of
> doing this. If anybody has some more insight on this, I'm eager to learn
> about it.

Ah, here it comes. I was not aware of this issue. This makes my idea somehow 
useless.

>
> 2) Memory testing is not trivial with R, due to R's strategy of memory
> handling. IIRC it's something like this:
> Allocate memory up to 32MB. When 32MB is hit, try to throw unused object
> away. Hence typically, memory usage will increase until 32MB is hit, then
> stay there for a long time, regardless of what you do. If 32MB is not
> enough to accomodate all active symbols, another chunk of memory is
> allocated. This or something along those lines.
>

I read something about this. In especially the there are many differences to R 
regarding memory usage.

> 3) *Probably* it's not quite as important an issue, as the packages are
> only loaded, if / when the user actually uses the corresponding functions.
> Typically a user will only use so many plugins per session, so not it's
> unlikely that very many libraries will be loaded. A new session will start
> out fresh.
>

Right. It was just an idea to build a tool which handles "simple" things for 
users. Of course this is no real issue.

> Well, I think it hinges on 1). If we can find a satisfactory solution to
> that, we can attack the issue. Else we'll have to hope 3 always applies...
>

3) is sufficient. Actually I am not a heavy user and therefore never 
encountered memory issues but heard about that from time to time here and 
there, that's way I suggested it.

> Regards
> Thomas