Re: [Rd] R CMD config for R = 3.0.1
G'day Brian,
On Sat, 18 May 2013 10:28:43 +0100
Prof Brian Ripley rip...@stats.ox.ac.uk wrote:
[...]
Is it necessary for R = 3.0.1 to have one build as
main-architecture and the other one as sub-architecture? I could
not find anything in the NEWS file or the Admin manual that
indicated that this would now be necessary.
Not exclusively, but as the Mac build no longer uses this, we do need
people who do to test pre-releases. One of us needs to build such a
setup and test it
Either that, or amend the administration and installation manual to
state that one installation should not be a sub-architecture
installation. :)
But the latter solution also seems to have some problems. My usual
install script did the following:
1) Run ./configure with 'r_arch=32' (and a few other options) using a
config.site, configured for a 32bit build; followed by make
2) make check ; make install
3) `make distclean'; run ./configure with 'r_arch=64' (and a few other
options using a config.site configured for a 64 bit build; followed
by make
4) make check ; make install
5) make pdf info; make install-pdf install-info
When trying to install Rgraphviz afterwards (mmh, this is a
BioConductor package and not a CRAN package, so perhaps I should ask on
their lists?), Rgrahviz couldn't find the correct compiler settings as
R CMD config ... did not work (as reported originally).
So I changed my install script to remove the 'r_arch=64' in step 3.
(The modified script is attached.) But now, trying to install
Rgraphviz falls over earlier when a dependencies of Rgraphviz,
BiocGenerics, is installed. Trying to install BiocGenerics fails with:
[...]
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
*** arch - 32
*** arch - R
ERROR: sub-architecture 'R' is not installed
ERROR: loading failed for 'R'
* removing '/opt/R/R-3.0.1/lib/R/library/BiocGenerics'
I have no idea why the process tries to check for an 'arch - R'. But
this seems to be happening for packages that do not contain code that
needs to be compiled, another example is 'car' which is needed by 'AER'.
So I am bit puzzled how I should change my scripts. Does step 3 needs
something stronger than 'make distclean'? Or should the 'r_arch=32' be
dropped in step 1 but step 3 should use 'r_arch=64'?
Essentially, I would like to install 32bit and 64bit builds on my
machines, with one or both as sub-architectures (to save space) and
with the 64bit the 'default', i.e. the one that is run by
${R_HOME}/bin/R.
Cheers,
Berwin
#!/bin/bash -e
VERSION=3.0.1
part1a ()
{
cd /opt/src/R-$VERSION
echo **
echo *** configure (32bit)
echo **
cp ../R-config.site-32 config.site
./configure --prefix=/opt/R/R-$VERSION --with-blas --with-lapack
--enable-R-shlib r_arch=32 | tee CONFIGURE_32
echo *
echo *** make (32 bit)
echo *
make -j6
}
part2()
{
echo *
echo *** make check
echo *
make check
make install
}
part1b ()
{
echo **
echo *** configure (64bit)
echo **
make distclean
cp ../R-config.site-64 config.site
./configure --prefix=/opt/R/R-$VERSION --with-blas --with-lapack
--enable-R-shlib | tee CONFIGURE_64
echo *
echo *** make (64 bit)
echo *
make -j6
}
part3 ()
{
echo **
echo *** make documentation
echo **
make pdf info
make install-pdf install-info
}
export http_proxy=http://proxy.uwa.edu.au:
export LANG=en_AU.UTF-8
echo Installing R-$VERSION
part1a /opt/src/R-$VERSION-LOG 21
part2/opt/src/R-$VERSION-CheckLOG 21
part1b /opt/src/R-$VERSION-LOG 21
part2 /opt/src/R-$VERSION-CheckLOG 21
part3 /opt/src/R-$VERSION-LOG 21
echo Done
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD config for R = 3.0.1
Could you try current R-patched or R-devel? Works in my tests at least.
On 19/05/2013 08:25, Berwin A Turlach wrote:
G'day Brian,
On Sat, 18 May 2013 10:28:43 +0100
Prof Brian Ripley rip...@stats.ox.ac.uk wrote:
[...]
Is it necessary for R = 3.0.1 to have one build as
main-architecture and the other one as sub-architecture? I could
not find anything in the NEWS file or the Admin manual that
indicated that this would now be necessary.
Not exclusively, but as the Mac build no longer uses this, we do need
people who do to test pre-releases. One of us needs to build such a
setup and test it
Either that, or amend the administration and installation manual to
state that one installation should not be a sub-architecture
installation. :)
That is not sufficient. AFAICS the issue only occurs after installation
(which is probably why no one else saw it), and the Renviron files for
the different sub-architectures will be different (in R_PLATFORM).
But the latter solution also seems to have some problems. My usual
install script did the following:
1) Run ./configure with 'r_arch=32' (and a few other options) using a
config.site, configured for a 32bit build; followed by make
2) make check ; make install
3) `make distclean'; run ./configure with 'r_arch=64' (and a few other
options using a config.site configured for a 64 bit build; followed
by make
4) make check ; make install
5) make pdf info; make install-pdf install-info
When trying to install Rgraphviz afterwards (mmh, this is a
BioConductor package and not a CRAN package, so perhaps I should ask on
their lists?), Rgrahviz couldn't find the correct compiler settings as
R CMD config ... did not work (as reported originally).
So I changed my install script to remove the 'r_arch=64' in step 3.
(The modified script is attached.) But now, trying to install
Rgraphviz falls over earlier when a dependencies of Rgraphviz,
BiocGenerics, is installed. Trying to install BiocGenerics fails with:
[...]
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
*** arch - 32
*** arch - R
ERROR: sub-architecture 'R' is not installed
ERROR: loading failed for 'R'
* removing '/opt/R/R-3.0.1/lib/R/library/BiocGenerics'
I have no idea why the process tries to check for an 'arch - R'. But
this seems to be happening for packages that do not contain code that
needs to be compiled, another example is 'car' which is needed by 'AER'.
So I am bit puzzled how I should change my scripts. Does step 3 needs
something stronger than 'make distclean'? Or should the 'r_arch=32' be
dropped in step 1 but step 3 should use 'r_arch=64'?
Essentially, I would like to install 32bit and 64bit builds on my
machines, with one or both as sub-architectures (to save space) and
with the 64bit the 'default', i.e. the one that is run by
${R_HOME}/bin/R.
Cheers,
Berwin
--
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] R CMD config for R = 3.0.1
G'day Brian, On Sun, 19 May 2013 08:40:04 +0100 Prof Brian Ripley rip...@stats.ox.ac.uk wrote: Could you try current R-patched or R-devel? Works in my tests at least. Tried R-patched (2013-05-18 r62762) and R-devel (2013-05-18 r62762), installed with my original script. Things seem fine when I try to install my usual selection of packages in either of those versions. Loading under correct (and existing) architectures is tested and packages that query the configuration get the correct answers from `R CMD config'. Thank you very much for the help. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0.1: wrong MD5 checksums for Windows?
On 13-05-18 5:37 PM, Duncan Murdoch wrote: On 13-05-17 2:01 PM, Tal Galili wrote: Hello dear R-devel, I am not sure if this issue is tracked or not, but in case it isn't: It appears that R 3.0.1 reproduces the error reported for R 3.0.0 here: http://r.789695.n4.nabble.com/R-3-0-0-wrong-MD5-checksums-for-Windows-td4663348.html That is, that when installing R 3.0.1 on Windows 7, and then running: require(tools) checkMD5sums(dir=R.home()) It produces the error: files ‘etc/Rconsole’, ‘etc/Rprofile.site’ have the wrong MD5 checksums [1] FALSE Technically speaking, that's just a message, not an error. Those files were changed by the installer, so the information is correct. From a user point of view, it does look like an error. We could avoid the message in several ways: don't bother checking those files, or compute the MD5 checksums on default installed versions of those files, or recompute the checksums after installation. I think the third choice is too hard, so it's not something I'd do. I don't know which of the other two is better. A malicious attacker could do a lot of damage by messing with the Rprofile.site file; maybe a user would want to know if that had happened. So that suggests the second choice. But then users who don't choose whatever default the installer picks will always get the message. I think the problem of a malicious attacker is pretty far-fetched, but an accidental change might be worth noting, so I've put the second choice in place in R-devel and R-patched. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Copy on assignment to large field of reference class
Dear all
I am trying to find the best way to handle large fields in reference
classes.
As the code below shows assignment via - causes many copies to be made if
the subsetting is extensive (in modb1). This can cause R to run out of
memory. Creating a local copy and using the optimisation in - is the best
solution I have found so far (in modb2) - but it is not really much better
than ordinary functions using call by value and then reassigning.
Is there a reason why optimisation does not occur for - ? Or is their a
better solution for reference classes?
Regards
Giles
A - setRefClass(A, fields=list(b=vector))
A$methods(
initialize=function() {
b - 1:1
},
modb1=function() {
# simple subsetting for illustration
for(i in 2:length(b)) b[i] - b[i-1] + 1
},
modb2=function() {
bb - b
for(i in 2:length(b)) bb[i] - bb[i-1] + 1
b - bb
}
)
a - new(A)
tracemem(a$b)
a$modb1()
a$modb2()
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] locking down R
Is anyone on this list aware of discussions about locking down/securing R? My colleagues and I are working with health statistics in an office that disallows many useful tools (e.g. emacs, vim, perl, make) on the grounds that they represent a security risk. We are considering pushing back, but we are worried that if we attract the attention of the Powers That Be to the reality that R allows execution of arbitrary shell commands, they will then disallow the use of R (SAS and Stata are our other optiona). It might be useful to be able to give them options for securing R. Possibly useful information: * the office allows use of SAS (and Stata, MLWiN, etc.) but uses the NOXCMD specification to prevent shell access from within SAS. They also disallow access to the Windows shell (in the current configuration, shell() works fine from within R, but we think this may have escaped their notice ...) The workstations have no access to external networks, nor to external media (thumb drives etc.) [information transfer to the outside world is via shared drives that can be accessed by administrators with network access]. * I stipulate that (1) the security policies don't make sense, (2) allowing users access to arbitrary shell commands should _not_ represent a security risk on a well-administered, modern operating system (they're running WinXP), (3) R probably offers many other avenues for system access to a malicious user, even in the absence of shell access, compilers, etc.. * I suspect the answer given here will be if you really want to secure R, run it within a standard restricted-access shell (e.g. chroot on a Linux system). If anyone has experience of 'locking down' R on Windows (XP) in a sensitive environment, I'd be curious about the details. thanks Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
