Re: [Rd] Auto-upgrading a package under Windows ?
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.
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.
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.
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.
--
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] install.packages now intentionally references .Rprofile?
A post on the Bioconductor mailing list
https://stat.ethz.ch/pipermail/bioconductor/2009-May/027700.html
suggests that install.packages now references .Rprofile (?), whereas
in R-2-8 it did not. Is this intentional?
The example is, in .Rprofile
library(utils)
install.packages("Biobase",
repos="http://bioconductor.org/packages/2.4/bioc";)
then starting R from the command line results in repeated downloads
of Biobase
mtmor...@mm:~/tmp> R --quiet
trying URL
'http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz'
Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
opened URL
==
downloaded 1.9 Mb
trying URL
'http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz'
Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
opened URL
==
downloaded 1.9 Mb
^C
Execution halted
> sessionInfo()
R version 2.9.0 Patched (2009-05-20 r48588)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Martin
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Auto-upgrading a package under Windows ?
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 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.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setWinProgressBar() on closed bar crashes R (PR#13709)
Full_Name: Richard D. Morey Version: 2.8.1 OS: Windows XP Submission from: (NULL) (129.125.139.114) The following code will crash Rgui in Windows XP. Of course, I know the code shouldn't work, but something more graceful than a Windows application error would be better. #Start R Code bar = winProgressBar(min = 0, max = 100, width = 300) setWinProgressBar(bar, 25) close(bar) setWinProgressBar(bar, 50) # End R code It crashes R with the following Windows error: RGui: Rgui.exe - Application Error The instruction at "0x6c715843" referenced memory at "0x00020". The memory could not be "read". __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stringsAsFactors .... in expand.grid() etc
On 20/05/2009, at 1:49 AM, Martin Maechler wrote:
"RT" == Rolf Turner
on Tue, 19 May 2009 11:02:08 +1200 writes:
RT> While we're at it --- would it not make sense to have the
RT> stringsAsFactors
RT> argument (once it's working) of expand.grid() default to
options()
RT> $stringsAsFactors,
RT> rather than to FALSE?
NNNOOO !
Oh, alright! :-)
cheers,
Rolf
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using a "third party" DLL in my package
Hello again, thank you for the comments, especially this one: Prof Brian Ripley wrote: > My concern would be that there are different cases that fail under > Fortran compiler X and you are just sweeping the problem under the > carpet. It inspired us to go back to search the cause, and we've made some progress: it's not the compiler, it's the compiler options. Simple, but it took a while to figure that out since my experience in these things is limited. When I build the package with default options using INSTALL --build the dll is built with option -O3 as per R's Makeconfig file. If I build the dll by hand, using gfortran with no additional options and dyn.load it, everything works, and also with -O and -Os. (No, I don't fully understand what the differences between all these are, but that's another question). I'm looking at chapter 5.5 in Writing R Extensions and also 6.3.3 in R Installation and Administration but I can't figure out how to tell "inside" my package that it is not to be built -O3 but with, say, -O. I can see how to add flags in the package (and as far as I can tell, if there are several optimization level flags the last in line is used and that's the wrong one from my point of view), and also how to override flags but only on my computer. Am I blind or am I again attempting something I shouldn't? Best regards, Seija S. Prof Brian Ripley wrote: On Thu, 14 May 2009, Seija Sirkiä wrote: Hello all, it seems my efforts in reading the manuals and help files aren't enough so here I am. The question is, how would I go about linking a pre-compiled DLL in to my package? I have previously successfully built packages with Fortran and C source code, but now I'd like to take this ready made DLL and call its routines from R. My collegue was brave enough to simply try and put the DLL in src folder of the package and proceed with building and installing the same way as if it had been source code. And it works, on my computer and his. Clearly this isn't exactly portable, and while that's ok for the use we have in mind (we both work on Windows XP) I have a nagging feeling this is somehow criminal or unwise at least. Unwise, since it is unsupported and might stop working at any time. Actually, you don't mention the version of R you used and (without checking) I think this may not work in all recent versions of R. What you can so is to have an 'inst/libs' directory in your package sources, and put the DLL you want to use there. Another approach (used in a few CRAN packages) is to use 'configure.win' to copy the DLL to a 'libs' directory in the installed package. A third approach is to have a 'src/Makefile.win' that creates the DLL you want (possibly by just checking it is present in 'src', but also possiby by calling the mysterious Fortran compiler X you obliquely mention below). Why I want to do this might explain it a bit further but in fact the background contains another problem and I welcome anyone to give hints about that too. So, we have some Fortran code from way back which deals with fitting taper curves for tree boles, and some other functions related to that. We wanted to make these available for use in R and I made a package with simple wrapper functions for the .Fortran calls, and built it with the help of the compiler in Rtools. All was fine until my collegue managed to bump in to a combination of parameters (tree species, height and breast height diameter) with which the computation freezes. We traced it to a certain very simple iteration in the Fortran code that finds the height at which the tree has a given diameter. I could give more details on that, but the point is that the very same computation goes through just fine when executed "fully" in Fortran, with the routines and an interface compiled with another Fortran compiler. And also when that compiler is used to make a DLL and that DLL is used within the R package in the way I described above. In summary, what we seem to have here is a compiler dependent convergence problem. Possible solutions are to figure out what's wrong with the computation - and I've pretty much exhausted my skills on that - or to figure out how to use a working DLL, as was my first question. My concern would be that there are different cases that fail under Fortran compiler X and you are just sweeping the problem under the carpet. Great big thanks in advance to anyone with advice! Seija Sirkiä, senior researcher (statistics), Finnish forestry research institute __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] qbinom (PR#13711)
Full_Name: Wolfgang Resch Version: R 2.8.1 GUI 1.27 OS: OS X 10.4.11 Submission from: (NULL) (137.187.89.14) Strange behavior of qbinom: > qbinom(0.01, 5016279, 1e-07) [1] 0 > qbinom(0.01, 5016279, 2e-07) [1] 16 > qbinom(0.01, 5016279, 3e-07) [1] 16 > qbinom(0.01, 5016279, 4e-07) [1] 16 > qbinom(0.01, 5016279, 5e-07) [1] 0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Auto-upgrading a package under Windows ?
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install.packages now intentionally references .Rprofile?
On Wed, 20 May 2009, Martin Morgan wrote:
A post on the Bioconductor mailing list
https://stat.ethz.ch/pipermail/bioconductor/2009-May/027700.html
suggests that install.packages now references .Rprofile (?), whereas
in R-2-8 it did not. Is this intentional?
Yes. And in fact it did in earlier versions, to find the default
library into which to install.
The example is, in .Rprofile
library(utils)
install.packages("Biobase",
repos="http://bioconductor.org/packages/2.4/bioc";)
then starting R from the command line results in repeated downloads
of Biobase
mtmor...@mm:~/tmp> R --quiet
trying URL
'http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz'
Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
opened URL
==
downloaded 1.9 Mb
trying URL
'http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz'
Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
opened URL
==
downloaded 1.9 Mb
^C
Execution halted
sessionInfo()
R version 2.9.0 Patched (2009-05-20 r48588)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Martin
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
