[Rd] contrib.url in non-interactive mode
Hi,
is it intended that one cannot install packages in non-interactive mode,
without explicitly setting a CRAN mirror (see below)?
Couldn't a default mirror be used in that case?
Thank you.
Bests,
Renaud
$ Rscript --vanilla -e "install.packages('whatever')"
Installing package into '/home/renaud/R/x86_64-pc-linux-gnu-library/3.0'
(as 'lib' is unspecified)
Error in contrib.url(repos, type) :
trying to use CRAN without setting a mirror
Calls: install.packages -> grep -> contrib.url
Execution halted
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] contrib.url in non-interactive mode
On 14/02/2014 10:03, Renaud Gaujoux wrote:
Hi,
is it intended that one cannot install packages in non-interactive mode,
without explicitly setting a CRAN mirror (see below)?
Couldn't a default mirror be used in that case?
Thank you.
You seem to be talking about installing from CRAN. The intention is
indeed that in non-interactive use you have to select the repositories
you want to use. See ?setRepositories and its links.
It is up to you to set a default mirror: we have little idea where you
live (and it may not be where your email address suggests). Geolocation
of mirrors had been mooted but not implemented (and in a corporate
setting is not 100% reliable). The whole point of mirrors is to spread
the load: without them there would be no CRAN as the main host would not
allow the traffic.
This would have been appropriate for R-help, if it would not have been
answered by doing the homework required by the posting guide (which also
requires no HTML ...).
Bests,
Renaud
$ Rscript --vanilla -e "install.packages('whatever')"
Installing package into '/home/renaud/R/x86_64-pc-linux-gnu-library/3.0'
(as 'lib' is unspecified)
Error in contrib.url(repos, type) :
trying to use CRAN without setting a mirror
Calls: install.packages -> grep -> contrib.url
Execution halted
[[alternative HTML version deleted]]
__
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
Re: [Rd] getting environment from "top" promise
On Tue, 11 Feb 2014, Romain Francois wrote:
Hello,
We have something very similar to your while loop in dplyr.
https://github.com/hadley/dplyr/blob/02a609310184d003c2ae9e0c013bfa69fa4d257a/inst/include/tools/DataDots.h#L15
because we need to know exactly in which environment a promise is supposed to
be evaluated, even though we might combine standard R evaluation with an
alternative faster engine. this is the basis of what we called hybrid
evaluation.
For future work, I also have the while loop in the Promise class in Rcpp11, so
that when you create a Promise in Rcpp11, its .environment() method gives you
what you expect.
https://github.com/romainfrancois/Rcpp11/blob/master/inst/include/Rcpp/Promise.h#L14
So, this is something I find useful, although I’m not sure we are supposed to
mess with promises.
No you are not :-)
Promises are an internal mechanism for implementing lazy
evaluation. They are convenient but also very inefficient, so they may
very well go away when a better approach becomes available. What will
not go away is the functionality they provide -- bindings with
deferred evaluations, an expression/code for the evaluation, and an
environment (until the evaluation happens). If you build on those
concepts you will be more future proof than if you assume there will
be an internal promise object.
Best,
luke
Romain
Le 11 févr. 2014 à 19:02, Michael Lawrence a écrit :
Hi all,
It seems that there is a use case for obtaining the environment for the
"top" promise. By "top", I mean following the promise chain up the call
stack until hitting a non-promise.
S4 data containers often mimic the API of base R data structures. This
means writing S4 methods for functions that quote their arguments, like
with() and subset(). The methods package directly forwards any arguments
not used for dispatch, so substitute(subset) is able to resolve the
original quoted argument (this is not the case for naively written
wrappers). The problem then becomes figuring out the environment in which
to evaluate the expression.
Consider:
setClass("A", representation(df = "data.frame"))
setMethod("subset", "A", function(x, subset) {
env <- parent.frame(2)
x@df <- x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
x
})
dropLowMpg <- function(x, cutoff=20) {
invisible(subset(x, mpg > cutoff))
}
a <- new("A", df=mtcars)
dropLowMpg(a)
The above works just fine, because we figured out that we need to evaluate
in the grand-parent frame to avoid the frame of the generic call. But now
let's assume A has a subclass B, and subset,B delegates to subset,A via
callNextMethod(). The call stack is different, and our assumption is
invalid.
setClass("B", representation(nrow="integer"), contains="A")
setMethod("subset", "B", function(x, ...) {
ans <- callNextMethod()
ans@nrow <- nrow(ans@df)
ans
})
b <- new("B", df=mtcars)
dropLowMpg(b)
Error in eval(expr, envir, enclos) (from #3) : object 'cutoff' not found
We can fix this with a simple C function:
SEXP top_prenv(SEXP nm, SEXP env)
{
SEXP promise = findVar(nm, env);
while(TYPEOF(promise) == PROMSXP) {
env = PRENV(promise);
promise = PREXPR(promise);
}
return env;
}
With R wrapper:
top_prenv <- function(x) {
.Call2("top_prenv", substitute(x), parent.frame())
}
Then this works (need to set subset,B again to reset cache):
setMethod("subset", "A", function(x, subset) {
env <- top_prenv(subset)
x@df <- x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
x
})
setMethod("subset", "B", function(x, ...) {
ans <- callNextMethod()
ans@nrow <- nrow(ans@df)
ans
})
b <- new("B", df=mtcars)
dropLowMpg(b)
Would this be a useful addition to R? Is there a better way to solve this
issue? We're using this successfully in the IRanges package now, but we'd
like to avoid dealing with the internal details of R, and this is something
that could be of general benefit.
Thanks,
Michael
[[alternative HTML version deleted]]
__
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
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] contrib.url in non-interactive mode
On Fri, Feb 14, 2014 at 10:54 AM, Prof Brian Ripley wrote: > > It is up to you to set a default mirror: we have little idea where you > live (and it may not be where your email address suggests). Geolocation > of mirrors had been mooted but not implemented (and in a corporate > setting is not 100% reliable). The whole point of mirrors is to spread > the load: without them there would be no CRAN as the main host would not > allow the traffic. > > The RStudio CRAN mirror uses Amazon's CDN to achieve a degree of geographic convenience: http://blog.rstudio.org/2013/06/10/rstudio-cran-mirror/ As far as I know all the other CRAN mirrors are geographically nailed down and your data will come out of that server in that data centre wherever you and it may be. Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getting environment from "top" promise
Le 14 févr. 2014 à 16:40, luke-tier...@uiowa.edu a écrit :
> On Tue, 11 Feb 2014, Romain Francois wrote:
>
>> Hello,
>>
>> We have something very similar to your while loop in dplyr.
>> https://github.com/hadley/dplyr/blob/02a609310184d003c2ae9e0c013bfa69fa4d257a/inst/include/tools/DataDots.h#L15
>>
>> because we need to know exactly in which environment a promise is supposed
>> to be evaluated, even though we might combine standard R evaluation with an
>> alternative faster engine. this is the basis of what we called hybrid
>> evaluation.
>>
>>
>> For future work, I also have the while loop in the Promise class in Rcpp11,
>> so that when you create a Promise in Rcpp11, its .environment() method gives
>> you what you expect.
>> https://github.com/romainfrancois/Rcpp11/blob/master/inst/include/Rcpp/Promise.h#L14
>>
>> So, this is something I find useful, although I’m not sure we are supposed
>> to mess with promises.
>
> No you are not :-)
Most of what we do with them is consult them. So whenever the better approach
you mention becomes available in R, we can update the Promise class and change
how to get access to the expression and the environment in which it will be
eventually evaluated.
Not the first time I get « you are not supposed to use that because we might
change it ». Experience is that that sort of changes are relatively slow to
happen, so are easy to adapt to.
Romain
> Promises are an internal mechanism for implementing lazy
> evaluation. They are convenient but also very inefficient, so they may
> very well go away when a better approach becomes available. What will
> not go away is the functionality they provide -- bindings with
> deferred evaluations, an expression/code for the evaluation, and an
> environment (until the evaluation happens). If you build on those
> concepts you will be more future proof than if you assume there will
> be an internal promise object.
>
> Best,
>
> luke
>
>>
>> Romain
>>
>> Le 11 févr. 2014 à 19:02, Michael Lawrence a
>> écrit :
>>
>>> Hi all,
>>>
>>> It seems that there is a use case for obtaining the environment for the
>>> "top" promise. By "top", I mean following the promise chain up the call
>>> stack until hitting a non-promise.
>>>
>>> S4 data containers often mimic the API of base R data structures. This
>>> means writing S4 methods for functions that quote their arguments, like
>>> with() and subset(). The methods package directly forwards any arguments
>>> not used for dispatch, so substitute(subset) is able to resolve the
>>> original quoted argument (this is not the case for naively written
>>> wrappers). The problem then becomes figuring out the environment in which
>>> to evaluate the expression.
>>>
>>> Consider:
>>>
>>> setClass("A", representation(df = "data.frame"))
>>>
>>> setMethod("subset", "A", function(x, subset) {
>>> env <- parent.frame(2)
>>> x@df <- x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
>>> x
>>> })
>>>
>>> dropLowMpg <- function(x, cutoff=20) {
>>> invisible(subset(x, mpg > cutoff))
>>> }
>>>
>>> a <- new("A", df=mtcars)
>>> dropLowMpg(a)
>>>
>>> The above works just fine, because we figured out that we need to evaluate
>>> in the grand-parent frame to avoid the frame of the generic call. But now
>>> let's assume A has a subclass B, and subset,B delegates to subset,A via
>>> callNextMethod(). The call stack is different, and our assumption is
>>> invalid.
>>>
>>> setClass("B", representation(nrow="integer"), contains="A")
>>> setMethod("subset", "B", function(x, ...) {
>>> ans <- callNextMethod()
>>> ans@nrow <- nrow(ans@df)
>>> ans
>>> })
>>> b <- new("B", df=mtcars)
>>> dropLowMpg(b)
>>> Error in eval(expr, envir, enclos) (from #3) : object 'cutoff' not found
>>>
>>> We can fix this with a simple C function:
>>> SEXP top_prenv(SEXP nm, SEXP env)
>>> {
>>> SEXP promise = findVar(nm, env);
>>> while(TYPEOF(promise) == PROMSXP) {
>>> env = PRENV(promise);
>>> promise = PREXPR(promise);
>>> }
>>> return env;
>>> }
>>>
>>> With R wrapper:
>>> top_prenv <- function(x) {
>>> .Call2("top_prenv", substitute(x), parent.frame())
>>> }
>>>
>>> Then this works (need to set subset,B again to reset cache):
>>>
>>> setMethod("subset", "A", function(x, subset) {
>>> env <- top_prenv(subset)
>>> x@df <- x@df[eval(substitute(subset), x@df, env),,drop=FALSE]
>>> x
>>> })
>>> setMethod("subset", "B", function(x, ...) {
>>> ans <- callNextMethod()
>>> ans@nrow <- nrow(ans@df)
>>> ans
>>> })
>>>
>>> b <- new("B", df=mtcars)
>>> dropLowMpg(b)
>>>
>>> Would this be a useful addition to R? Is there a better way to solve this
>>> issue? We're using this successfully in the IRanges package now, but we'd
>>> like to avoid dealing with the internal details of R, and this is something
>>> that could be of general benefit.
>>>
>>> Thanks,
>>> Michael
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
Re: [Rd] contrib.url in non-interactive mode
Renaud,
The script below has been in use for about as long as littler existed, and
also ships with it. I use it, and its sibbling 'update.r' all the time. Doing
this at the command-line frees the R prompt during compilations too...
As Barry suggests, the RStudio-provided CDN is not a bad choice either as a
repo.
Dirk
edd@max:~$ cat bin/install.r
#!/usr/bin/env r
#
# a simple example to install one or more packages
if (is.null(argv) | length(argv)<1) {
cat("Usage: installr.r pkg1 [pkg2 pkg3 ...]\n")
q()
}
## adjust as necessary, see help('download.packages')
#repos <- "http://cran.us.r-project.org";
repos <- "http://cran.r-project.org";
## this makes sense on Debian where no packages touch /usr/local
lib.loc <- "/usr/local/lib/R/site-library"
install.packages(argv, lib.loc, repos)
edd@max:~$
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] contrib.url in non-interactive mode
>> It is up to you to set a default mirror: we have little idea where you >> live (and it may not be where your email address suggests). Geolocation >> of mirrors had been mooted but not implemented (and in a corporate >> setting is not 100% reliable). The whole point of mirrors is to spread >> the load: without them there would be no CRAN as the main host would not >> allow the traffic. >> >> > The RStudio CRAN mirror uses Amazon's CDN to achieve a degree of geographic > convenience: > > http://blog.rstudio.org/2013/06/10/rstudio-cran-mirror/ Cloudfront, the service we use, currently has 36 locations around the world: http://aws.amazon.com/cloudfront/details/. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
