On Wed, 20 May 2009, Dirk Eddelbuettel wrote:
On 20 May 2009 at 13:54, Prof Brian Ripley wrote:
| On Mon, 18 May 2009, Dirk Eddelbuettel wrote:
|
| >
| > I was trying to be cute with a company-internal package and used
| >
| > if (Sys.info()["sysname"]=="Windows") {
| > update.packages(repos="http://some.where.internal/R";, ask=FALSE)
| > }
|
| The commonly used test is .Platform$OS.type == "windows": that value
| is computed at installation so will be marginally faster.
Thanks. I once knew about, yet I always forget it. Somehow the Sys.*
connotation wins.
| > but that of course fails as the package itself is loaded and cannot be
| > upgraded (as it contains a dll) when loaded. Smart move by the OS.
|
| It's not only Windows that has that problem, but it does at least
| report it. Some Unixen used (at least) to let you replace a DSO which
| is in use, and then crash the process using the DSO.
|
| That's an issue with automated updating of R packages in a centrally
| managed system, so we do it during 'at risk' periods when activity is
| expected to be low.
|
| > Can anybody suggest a workaround, other than introducing a dll-free wrapper
| > package that can in fact test for the local packages before it would load
| > them?
|
| Can you not run a check of up-to-date-ness in the .onLoad hook for the
| package? If you load the DLL in that hook, this can be run before the
| DLL is loaded. This would need either each package only to update
| itself or the check to be in all packages that might get updated.
That is exactly what I tried: R/zzz.R using the .onLoad function, before any
actual package code is used. But (maybe because of the NAMESPACE) this seems
to be after the dll is loaded, and I am in a deadlock.
You would need not to use UseDynLib in the NAMESPACE, but load the DLL
in the .onLoad via library.dynam.
| You could unload the loaded namespace, provided it has a .onUnload()
| action that calls library.dynam.unload(), re-install then re-load.
| However, we've seen instances where unloading and re-loading a DLL in
| a session did not work (crashes etc) for various reasons -- it does
| not for example re-load and hence re-initialize any dependendent DLLs.
That never worked for me.
| > Placing the test into Rprofile.site is not a valid answer as that file is
| > hiding on each user's drive and out of my reach.
I will (at least for now) recommend to people to copy the upgrade statement
into their ~/.Rprofile files.
Thanks, Dirk
--
Three out of two people have difficulties with fractions.
--
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
