[Rd] Warning when sourcing file after require
Hi
I have recently upgraded to R 2.15.1. Since the upgrade, I am getting
some odd behaviour that I don't understand. If I source a file which
has a function with a require (or library) statement in it, then the
first time I source it behaves as expected. If I then call the
function (so that the require statement is evaluated) the function
also runs ok. However, if I then subsequently try to source the file
again I get an .Internal(eval.with.vis) warning.
At first I obviously thought it must be an error of mine in the file
containing the functions I had written. However, subsequent tests show
that even if the following code
foo<-function(){
require(XML)
cat("This is a test fn\n")
}
is put in the file foo.R, then running the following code gives the warning.
> source('foo.R')
> foo()
Loading required package: XML
This is a test fn
> source('foo.R')
Warning message:
In eval.with.vis(ei, envir) :
.Internal(eval.with.vis) should not be used and will be removed soon
The key part to this is the inclusion of the require statement. If the
require statement was not in the function, then there are no warnings.
I experience this behaviour on my desktop running Ubuntu 12.04 and on
my Mac running OSX. From looking at the change log of 2.15.1 I notice
that the way files are sourced has changed (and seems to relate to
this warning), but it is not clear to me what if anything this means I
should change.
I would be grateful for any tips.
Kind regards
Dave
--
David Hastie, Ph.D.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning when sourcing file after require
I don't see this in R-patched; I don't have 2.15.1 installed on this
machine. But the problem appears to be that XML exports a function
called source() (a generic), and you're using it -- but not the current
version, which doesn't give the warning.
Duncan Murdoch
On 12-07-18 1:36 PM, David Hastie wrote:
Hi
I have recently upgraded to R 2.15.1. Since the upgrade, I am getting
some odd behaviour that I don't understand. If I source a file which
has a function with a require (or library) statement in it, then the
first time I source it behaves as expected. If I then call the
function (so that the require statement is evaluated) the function
also runs ok. However, if I then subsequently try to source the file
again I get an .Internal(eval.with.vis) warning.
At first I obviously thought it must be an error of mine in the file
containing the functions I had written. However, subsequent tests show
that even if the following code
foo<-function(){
require(XML)
cat("This is a test fn\n")
}
is put in the file foo.R, then running the following code gives the warning.
source('foo.R')
foo()
Loading required package: XML
This is a test fn
source('foo.R')
Warning message:
In eval.with.vis(ei, envir) :
.Internal(eval.with.vis) should not be used and will be removed soon
The key part to this is the inclusion of the require statement. If the
require statement was not in the function, then there are no warnings.
I experience this behaviour on my desktop running Ubuntu 12.04 and on
my Mac running OSX. From looking at the change log of 2.15.1 I notice
that the way files are sourced has changed (and seems to relate to
this warning), but it is not clear to me what if anything this means I
should change.
I would be grateful for any tips.
Kind regards
Dave
--
David Hastie, Ph.D.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning when sourcing file after require
On 19/07/2012 12:46, Duncan Murdoch wrote:
I don't see this in R-patched; I don't have 2.15.1 installed on this
machine. But the problem appears to be that XML exports a function
called source() (a generic), and you're using it -- but not the current
version, which doesn't give the warning.
Whenever you upgrade your R you need to re-install your packages. And
this is particularly true of noisome packages (mainly using the
'methods' package) which make copies of code from R itself. XML is a
known example.
conflicts()
update.packages(checkBuilt=TRUE)
are your friends. E.g.
> library(XML)
> conflicts(, TRUE)
$`package:XML`
[1] "coerce" "show" "source"
$`package:methods`
[1] "coerce""show" "body<-""kronecker"
$`package:base`
[1] "body<-""kronecker" "source"
Duncan Murdoch
On 12-07-18 1:36 PM, David Hastie wrote:
Hi
I have recently upgraded to R 2.15.1. Since the upgrade, I am getting
some odd behaviour that I don't understand. If I source a file which
has a function with a require (or library) statement in it, then the
first time I source it behaves as expected. If I then call the
function (so that the require statement is evaluated) the function
also runs ok. However, if I then subsequently try to source the file
again I get an .Internal(eval.with.vis) warning.
At first I obviously thought it must be an error of mine in the file
containing the functions I had written. However, subsequent tests show
that even if the following code
foo<-function(){
require(XML)
cat("This is a test fn\n")
}
is put in the file foo.R, then running the following code gives the
warning.
source('foo.R')
foo()
Loading required package: XML
This is a test fn
source('foo.R')
Warning message:
In eval.with.vis(ei, envir) :
.Internal(eval.with.vis) should not be used and will be removed soon
The key part to this is the inclusion of the require statement. If the
require statement was not in the function, then there are no warnings.
I experience this behaviour on my desktop running Ubuntu 12.04 and on
my Mac running OSX. From looking at the change log of 2.15.1 I notice
that the way files are sourced has changed (and seems to relate to
this warning), but it is not clear to me what if anything this means I
should change.
I would be grateful for any tips.
Kind regards
Dave
--
David Hastie, Ph.D.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
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
[Rd] Are R packages supposed to be "relocatable"? (avoiding BioConductor scripts...)
I've asked a question in the BioConductor list about package
management. My solution depends on your answer to the following
question.
Are installed R packages "relocatable"?
I mean relocatable in the same sense that files in a RedHat RPM file
might be "relocatable" after compiling
(http://www.rpm.org/max-rpm/ch-rpm-reloc.html). This allows one to
build a package as the ordinary user and then the root user can take
the result and put it wherever it fits well in the path (say,
/usr/local/lib/R/library).
Here is why I asked. I manage packages in our cluster and some users
have asked me to install some BioConductor packages. BioConductor
install documents expect me to run a script as root that does a bunch
of changes, and I'm just unwilling to do that. If I have to do
something as root, it has to be something more focused like running a
particular R command (install.packages(), for example). It seems
insane to me that they expect (http://www.bioconductor.org/install) a
root user to run
source("http://bioconductor.org/biocLite.R";)
biocLite("limma")
If I could do the installs as me with their script, and then copy the
install folder into the system, then it would be OK, if the packages
would work.
Or perhaps post-processing is required to fiddle some paths inside
package files?
pj
--
Paul E. Johnson
Professor, Political ScienceAssoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.orghttp://quant.ku.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] installing spam package is failing (spam_0.29-1)
> Dirk Eddelbuettel > on Wed, 18 Jul 2012 20:16:25 -0500 writes: > For Pete's sake, could you please stop spamming the > r-devel list? Indeed! R-devel is reserved for people who do their homework! I've added "moderation" for Mr. Clone. Martin Maechler, ETH Zurich > We have a dedicated list r-sig-debian for questions > related to R on Debian/Ubuntu. Please use it. > And as as far as I can tell, Peter already told you what's > up: >deb > http://http://cran.cnr.Berkeley.edu/bin/linux/ubuntu > oneiric/ > [] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] On RObjectTables
I was wondering if anyone knows more about the state of RObjectTables. This largely undocumented functionality was introduced by Duncan around 2002 somewhere and enables you create an environment where the contents are dynamically queried by R through a hook function. It is mentioned in R Internals and ?attach. This functionality is quite powerful and allows you to e.g. offload a big database of R objects to disk, yet use them as if they were in your workspace. The recent RProtoBuf package also uses some of this functionality to dynamically lookup proto definitions. I would like to do something similar, but I am not sure if support for this functionality will be or has been discontinued. The RObjectTables package is no longer available on OmegaHat and nothing has not been mentioned on the mailing lists for about 5 years. I found an old version of the package no github which seems to work, but as far as I understand, the package still needs the hooks from within R to work. So if this functionality is actually unsupported and might be removed at some point, I should probably not invest in it. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] On RObjectTables
You might be able to take advantage of the ObjectTable support in C, which is part of R, see R_ext/Callbacks.h. Michael On Thu, Jul 19, 2012 at 10:30 AM, Jeroen Ooms wrote: > I was wondering if anyone knows more about the state of RObjectTables. This > largely undocumented functionality was introduced by Duncan around 2002 > somewhere and enables you create an environment where the contents are > dynamically queried by R through a hook function. It is mentioned in R > Internals and ?attach. This functionality is quite powerful and allows you > to e.g. offload a big database of R objects to disk, yet use them as if > they were in your workspace. The recent RProtoBuf package also uses some of > this functionality to dynamically lookup proto definitions. > > I would like to do something similar, but I am not sure if support for this > functionality will be or has been discontinued. The RObjectTables package > is no longer available on OmegaHat and nothing has not been mentioned on > the mailing lists for about 5 years. I found an old version of the package > no github which seems to work, but as far as I understand, the package > still needs the hooks from within R to work. So if this functionality is > actually unsupported and might be removed at some point, I should probably > not invest in it. > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Are R packages supposed to be "relocatable"? (avoiding BioConductor scripts...)
On Jul 19, 2012, at 12:13 PM, Paul Johnson wrote:
> I've asked a question in the BioConductor list about package
> management. My solution depends on your answer to the following
> question.
>
> Are installed R packages "relocatable"?
>
It depends on the platform and what you want to relocate (R or just the
packages) and on the package itself. For example on OS X absolute paths are
included in dylibs, so you can move packages that allow it and don't link to
other packages but you can't relocate R or packages that link to other packages
directly or libraries within the package (that should be rare, though). Whether
a package allows relocation depends whether it hard-codes any paths it uses -
typical packages use facilities like system.file to locate files so those are
relocatable, but if a package determines paths at configure time it may not be
relocatable.
Since you didn't even specify the platform you're interested in, this is only a
generic answer ...
> I mean relocatable in the same sense that files in a RedHat RPM file
> might be "relocatable" after compiling
> (http://www.rpm.org/max-rpm/ch-rpm-reloc.html). This allows one to
> build a package as the ordinary user and then the root user can take
> the result and put it wherever it fits well in the path (say,
> /usr/local/lib/R/library).
>
> Here is why I asked. I manage packages in our cluster and some users
> have asked me to install some BioConductor packages. BioConductor
> install documents expect me to run a script as root that does a bunch
> of changes, and I'm just unwilling to do that. If I have to do
> something as root, it has to be something more focused like running a
> particular R command (install.packages(), for example). It seems
> insane to me that they expect (http://www.bioconductor.org/install) a
> root user to run
>
You can install BioC packages simply with install.packages() - there is no
black magic involved, it's a regular repository just like CRAN ...
Cheers,
Simon
> source("http://bioconductor.org/biocLite.R";)
> biocLite("limma")
>
> If I could do the installs as me with their script, and then copy the
> install folder into the system, then it would be OK, if the packages
> would work.
>
> Or perhaps post-processing is required to fiddle some paths inside
> package files?
>
> pj
> --
> Paul E. Johnson
> Professor, Political ScienceAssoc. Director
> 1541 Lilac Lane, Room 504 Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.orghttp://quant.ku.edu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Are R packages supposed to be "relocatable"? (avoiding BioConductor scripts...)
Short answer:
setRepositories() # chose what you want from BioC
install.packages()
works and always has. 'Smoke and mirrors' are not actually needed.
As for relocatability:
I am guessing you are talking about a Linux cluster ... but the details
do matter.
The distribution of Windows binaries relies on installed packages being
relocatable, so most packages are written to be. There are a very few
exceptions: the one most frequently encountered is packages linked to
Rcpp, which on Linux put the path to Rcpp in their DSOs. So you can
relocate the package, but not the Rcpp installation it is linked to.
(Not a problem on other OSes as it statically links elsewhere.)
A question you did not ask is if you can use differently located R: in
most cases yes (I regularly run different versions of R with the same
library trees).
We've relocated complete CRAN/BioC installations on Linux several times.
On 19/07/2012 17:13, Paul Johnson wrote:
I've asked a question in the BioConductor list about package
management. My solution depends on your answer to the following
question.
Are installed R packages "relocatable"?
I mean relocatable in the same sense that files in a RedHat RPM file
might be "relocatable" after compiling
(http://www.rpm.org/max-rpm/ch-rpm-reloc.html). This allows one to
build a package as the ordinary user and then the root user can take
the result and put it wherever it fits well in the path (say,
/usr/local/lib/R/library).
Here is why I asked. I manage packages in our cluster and some users
have asked me to install some BioConductor packages. BioConductor
install documents expect me to run a script as root that does a bunch
of changes, and I'm just unwilling to do that. If I have to do
something as root, it has to be something more focused like running a
particular R command (install.packages(), for example). It seems
insane to me that they expect (http://www.bioconductor.org/install) a
root user to run
source("http://bioconductor.org/biocLite.R";)
biocLite("limma")
If I could do the installs as me with their script, and then copy the
install folder into the system, then it would be OK, if the packages
would work.
Or perhaps post-processing is required to fiddle some paths inside
package files?
pj
--
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] Changes to parser in R-devel
I'm not sure if there is a bug somewhere; see this example:
getParseData(parse(text='function(x){}'))
line1 col1 line2 col2 id parent token terminal text
1 11 18 1 11 FUNCTION TRUE function
2 19 19 2 11'(' TRUE(
3 1 10 1 10 3 5 SYMBOL_FORMALS TRUEx
4 1 11 1 11 4 11')' TRUE)
5 1 12 1 12 6 8'{' TRUE{
6 1 13 1 13 7 8'}' TRUE}
7 1 12 1 12 5 11'}' TRUE{
8 1 12 1 13 8 11 exprFALSE
9 11 1 13 11 0 exprFALSE
I get an additional { in the 7th row of the 'text' column.
Another problem is that for this empty function below, there will be
an obvious pause if you run it more than once:
getParseData(parse(text='function(){}'))
and you may get wild line/col numbers like this:
line1 col1 line2 col2 id parenttoken terminal text
1 11 18 1 9 FUNCTION TRUE function
2 19 19 2 9 '(' TRUE(
3 1 10 1 10 3 9 ')' TRUE)
4 1 11 1 11 4 6 '{' TRUE{
5 1 12 1 12 5 6 '}' TRUE}
6 320024 11 140106360 11 11 9 '}' TRUE
7 1 11 1 12 6 9 exprFALSE
8 11 1 12 9 11 exprFALSE
What is worse is it can crash R:
*** caught segfault ***
address 0x9488c20, cause 'memory not mapped'
Traceback:
1: parse(text = "function(){}")
2: getSrcref(x)
3: getSrcfile(x)
4: getParseData(parse(text = "function(){}"))
> sessionInfo()
R Under development (unstable) (2012-07-18 r59904)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Wed, Jul 18, 2012 at 2:31 PM, Duncan Murdoch
wrote:
> I have just committed (in r59883) some changes to the R parser based on
> Romain Francois' parser package. Packages that made use of parser will
> hopefully find that the information in base R gives them what they need to
> work with, but the data is not identical to
> what parser recorded (since it was not consistent with some things already
> in R). One reason for the change was that the parser in the parser package
> was slightly different than the one in R; the hope is that by providing the
> services in R, it will make maintenance easier for things like code
> analysis, pretty printing, etc.
>
> See ?getParseData for details, and if you are maintaining a package that
> depends on parser, feel free to ask me for help in the transition, or make
> suggestions for changes if I've done something that causes you too much
> trouble.
>
> Duncan Murdoch
>
> P.S. to Qiang Li: as mentioned privately, the goal for this change was to
> reproduce output equivalent to what parser did, so I have not incorporated
> your suggested change to outlaw expressions like "x[[1] ]" (with an
> embedded space where it shouldn't be). After things settle down we can
> consider that change and others.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changes to parser in R-devel
On 12-07-19 4:41 PM, Yihui Xie wrote:
I'm not sure if there is a bug somewhere; see this example:
There's definitely a bug in the handling of empty lists, such as the
empty list of commands in your first example and the empty list of
arguments in your second. There's a partial workaround currently in
R-devel, but not a perfect fix. (This is due to me missing a conversion
from Romain's 0-based column counting to the usual 1-based counting.)
I expect it will be fixed tomorrow, or sooner.
Duncan Murdoch
getParseData(parse(text='function(x){}'))
line1 col1 line2 col2 id parent token terminal text
1 11 18 1 11 FUNCTION TRUE function
2 19 19 2 11'(' TRUE(
3 1 10 1 10 3 5 SYMBOL_FORMALS TRUEx
4 1 11 1 11 4 11')' TRUE)
5 1 12 1 12 6 8'{' TRUE{
6 1 13 1 13 7 8'}' TRUE}
7 1 12 1 12 5 11'}' TRUE{
8 1 12 1 13 8 11 exprFALSE
9 11 1 13 11 0 exprFALSE
I get an additional { in the 7th row of the 'text' column.
Another problem is that for this empty function below, there will be
an obvious pause if you run it more than once:
getParseData(parse(text='function(){}'))
and you may get wild line/col numbers like this:
line1 col1 line2 col2 id parenttoken terminal text
1 11 18 1 9 FUNCTION TRUE function
2 19 19 2 9 '(' TRUE(
3 1 10 1 10 3 9 ')' TRUE)
4 1 11 1 11 4 6 '{' TRUE{
5 1 12 1 12 5 6 '}' TRUE}
6 320024 11 140106360 11 11 9 '}' TRUE
7 1 11 1 12 6 9 exprFALSE
8 11 1 12 9 11 exprFALSE
What is worse is it can crash R:
*** caught segfault ***
address 0x9488c20, cause 'memory not mapped'
Traceback:
1: parse(text = "function(){}")
2: getSrcref(x)
3: getSrcfile(x)
4: getParseData(parse(text = "function(){}"))
sessionInfo()
R Under development (unstable) (2012-07-18 r59904)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Wed, Jul 18, 2012 at 2:31 PM, Duncan Murdoch
wrote:
I have just committed (in r59883) some changes to the R parser based on
Romain Francois' parser package. Packages that made use of parser will
hopefully find that the information in base R gives them what they need to
work with, but the data is not identical to
what parser recorded (since it was not consistent with some things already
in R). One reason for the change was that the parser in the parser package
was slightly different than the one in R; the hope is that by providing the
services in R, it will make maintenance easier for things like code
analysis, pretty printing, etc.
See ?getParseData for details, and if you are maintaining a package that
depends on parser, feel free to ask me for help in the transition, or make
suggestions for changes if I've done something that causes you too much
trouble.
Duncan Murdoch
P.S. to Qiang Li: as mentioned privately, the goal for this change was to
reproduce output equivalent to what parser did, so I have not incorporated
your suggested change to outlaw expressions like "x[[1] ]" (with an
embedded space where it shouldn't be). After things settle down we can
consider that change and others.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Are R packages supposed to be "relocatable"? (avoiding BioConductor scripts...)
On 07/19/2012 09:13 AM, Paul Johnson wrote:
I've asked a question in the BioConductor list about package
management. My solution depends on your answer to the following
question.
Are installed R packages "relocatable"?
I mean relocatable in the same sense that files in a RedHat RPM file
might be "relocatable" after compiling
(http://www.rpm.org/max-rpm/ch-rpm-reloc.html). This allows one to
build a package as the ordinary user and then the root user can take
the result and put it wherever it fits well in the path (say,
/usr/local/lib/R/library).
Here is why I asked. I manage packages in our cluster and some users
have asked me to install some BioConductor packages. BioConductor
install documents expect me to run a script as root that does a bunch
of changes, and I'm just unwilling to do that. If I have to do
something as root, it has to be something more focused like running a
particular R command (install.packages(), for example). It seems
insane to me that they expect (http://www.bioconductor.org/install) a
root user to run
source("http://bioconductor.org/biocLite.R";)
biocLite("limma")
For the record, this does four things.
(1) The 'source' command installs the BiocInstaller package appropriate
for your (recent) version of R or, if this package is already installed,
attaches it.
All remaining steps are executed by scripts in the BiocInstaller
package, so after an initial invocation the 'source()' statement can be
replaced by library(BiocInstaller).
(2) biocLite() invokes BiocInstaller::biocLite, which checks whether
BiocInstaller is current and, if not, updates it. Disable this behaviour
with the option suppressAutoUpdate=TRUE.
(3) The limma package and needed dependencies are installed, using
install.packages() and the repositories appropriate for your version of
R (paying attention to utils::setRepositories() and
utils::chooseBioCmirror()). The 'lib' argument to biocLite is passed to
install.packages() so the user has control over the directory in which
packages will be installed.
(4) biocLite checks whether any packages are out-of-date relative to the
version in the repository, and offers to update those that are out of
date. Packages that are in directories that cannot be written are
reported, via a warning and hence when biocLite finishes, as "installed
directory not writeable, cannot update packages '...'" (this message
apparently confused you; we will try for a better wording). Use
suppressUpdates=TRUE to suppress this step, ask=FALSE to have old
packages (in writeable directories) updated without being prompted; a
lib.loc argument can be used to restrict the locations where
old.packages() searches.
The arguments to biocLite are documented on its help page in the
BiocInstaller package, ?biocLite.
For step (3), Prof Ripley & Dr Urbanek (and me in my response to your
Bioconductor post,
https://stat.ethz.ch/pipermail/bioconductor/2012-July/046999.html) are
correct in stating that this can be done with a direct call to
install.packages().
Step (4) arises because Bioconductor packages (a) follow a semi-annual
release cycle, with a 'release' and 'devel' branch, and (b) generally
have greater dependencies amongst one another. In the past, two very
common scenarios leading to problems were that user installations mix
packages from different releases of Bioconductor, and users report bugs
that have already been addressed via bug fixes to the current release.
So step (4) is trying to be pro-active, and based on traffic to the
mailing list this has generally been successful. This synchronization is
more important, and difficult for the user to manage directly, now that
R has moved to an annual release cycle.
Steps (1) and (2) are needed to bootstrap the process. The relatively
recent introduction of the BiocInstaller package allows us to document
biocLite in a standard way, as well as provide the code in a more
familiar fashion. Step (1) is partly a legacy (BiocInstaller is not in
all releases of Bioconductor), and partly a simplification to avoid
confusion (avoiding 'first time users should do A, return users should
do B').
As a 'normal' user it is safe and appropriate to use biocLite to manage
Bioconductor (and CRAN) packages. One takes a more cautious approach as
'root', but I personally would be comfortable administering a widely
used R / Bioconductor installation with biocLite.
Martin Morgan
Bioconductor
If I could do the installs as me with their script, and then copy the
install folder into the system, then it would be OK, if the packages
would work.
Or perhaps post-processing is required to fiddle some paths inside
package files?
pj
--
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/mailm
[Rd] subRaw?
Hello, All:
Do you know of any capability to substitute more then one byte in
an object of class Raw?
Consider the following:
> let4 <- paste(letters[1:4], collapse='')
> (let4Raw <- charToRaw(let4))
[1] 61 62 63 64
> (let. <- sub('bc', '--', let4Raw))
[1] "61" "62" "63" "64"
> # no substitution
> (bc <- charToRaw('bc'))
[1] 62 63
> (ef <- charToRaw('ef'))
[1] 65 66
> (let. <- sub(bc, ef, let4Raw))
[1] "61" "65" "63" "64"
Warning messages:
1: In sub(bc, ef, let4Raw) :
argument 'pattern' has length > 1 and only the first element will be used
2: In sub(bc, ef, let4Raw) :
argument 'replacement' has length > 1 and only the first element will
be used
In this example, "b" was replaced by "e", but "bc" was not
replaced by "ef"? Do you know of any function to do this?
I ask, because I need it. I've written such a function, subRaw
for my own use. If I don't hear that another exists, I plan to add the
one I've written to the oro.dicom package.
Thanks,
Spencer
> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Spencer Graves, PE, PhD
President and Chief Technology Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph: 408-655-4567
web: www.structuremonitoring.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] subRaw?
Hi Spencer,
On 07/19/2012 08:29 PM, Spencer Graves wrote:
Hello, All:
Do you know of any capability to substitute more then one byte in
an object of class Raw?
Consider the following:
> let4 <- paste(letters[1:4], collapse='')
> (let4Raw <- charToRaw(let4))
[1] 61 62 63 64
> (let. <- sub('bc', '--', let4Raw))
[1] "61" "62" "63" "64"
> # no substitution
> (bc <- charToRaw('bc'))
[1] 62 63
> (ef <- charToRaw('ef'))
[1] 65 66
> (let. <- sub(bc, ef, let4Raw))
[1] "61" "65" "63" "64"
Warning messages:
1: In sub(bc, ef, let4Raw) :
argument 'pattern' has length > 1 and only the first element will be
used
2: In sub(bc, ef, let4Raw) :
argument 'replacement' has length > 1 and only the first element will
be used
It makes no sense to use sub(), grep(), and family (i.e. all the stuff
based on the regex code) *directly* on a raw vector because all these
functions will start by coercing their 'x', 'text', 'pattern',
'replacement' args to character with as.character (if they are not
already character).
But the way as.character() operates on a raw vector won't give good
results in that context. You'd rather do the coercion yourself first
with rawToChar(), and coerce back the result with charToRaw():
> charToRaw(sub("bc", "--", rawToChar(let4Raw)))
[1] 61 2d 2d 64
IMO it would make much more sense that sub(), grep(), and family()
raise an error than blindly try to coerce to character but these
functions (like many functions in R) are too polite to tell the
user s/he's doing something wrong.
Cheers,
H.
In this example, "b" was replaced by "e", but "bc" was not
replaced by "ef"? Do you know of any function to do this?
I ask, because I need it. I've written such a function, subRaw
for my own use. If I don't hear that another exists, I plan to add the
one I've written to the oro.dicom package.
Thanks,
Spencer
> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
