[Rd] install.packages problem
Hello,
R 3.4.1 on Windows 7, sessionInfo at the end.
Is there a problem with install.packages? Since last friday every time I
try to install a package in RGui, I start by choosing the CRAN mirror
Cloud-0 and RGui hangs. So I restart RGui and choose Portugal (Lisbon)
and get the following warning after a long while (minutes).
install.packages("igraph")
--- Please select a CRAN mirror for use in this session ---
Warning: unable to access index for repository
http://www.stats.ox.ac.uk/pub/RWin/src/contrib:
cannot open URL 'http://www.stats.ox.ac.uk/pub/RWin/src/contrib/PACKAGES'
Warning: unable to access index for repository
http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4:
cannot open URL
'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4/PACKAGES'
There is a binary version available but the source version is later:
binary source needs_compilation
igraph 1.0.1 1.1.1 TRUE
Do you want to install from sources the package which needs compilation?
y/n: y
installing the source package ‘igraph’
trying URL 'http://cran.radicaldevelop.com/src/contrib/igraph_1.1.1.tar.gz'
Content type 'application/x-gzip' length 3376077 bytes (3.2 MB)
downloaded 3.2 MB
[...]
The rest of the process goes on with success.
The problem seems to be with http://www.stats.ox.ac.uk/pub/RWin/src/contrib
When I check
> options("repos")
$repos
CRANCRANextra
"http://cran.radicaldevelop.com"; "http://www.stats.ox.ac.uk/pub/RWin";
I'm lead to think that install.packages should try
"http://cran.radicaldevelop.com"; first, only in case of failure CRANextra.
What is going on?
> sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=Portuguese_Portugal.1252
LC_CTYPE=Portuguese_Portugal.1252
[3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Portugal.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] igraph_1.0.1
loaded via a namespace (and not attached):
[1] compiler_3.4.1 magrittr_1.5 tools_3.4.1
Thanks in advance,
Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install.packages problem on Windows: CRANextras timeout
> Rui Barradas
> on Mon, 17 Jul 2017 09:03:33 +0100 writes:
> Hello,
> R 3.4.1 on Windows 7, sessionInfo at the end.
> Is there a problem with install.packages? Since last friday every time I
> try to install a package in RGui, I start by choosing the CRAN mirror
> Cloud-0 and RGui hangs. So I restart RGui and choose Portugal (Lisbon)
> and get the following warning after a long while (minutes).
As (I think) you notice below yourself, the problem is not with
the regular CRAN repos but with the 'CRANextra' repos that
R users of Windows use sometimes.
We had heard offline of a potential timeout/downtime for a short
period at Oxford for that, so this may be the simple explanation.
On the other hand everything ends up working fine,
so all this is just a warning, right?
If I do the same thing I don't have to wait and get the same
warning as you (and when I then decide to use the older *binary*
for igraph that is installed fine).
Martin
> install.packages("igraph")
> --- Please select a CRAN mirror for use in this session ---
> Warning: unable to access index for repository
> http://www.stats.ox.ac.uk/pub/RWin/src/contrib:
> cannot open URL 'http://www.stats.ox.ac.uk/pub/RWin/src/contrib/PACKAGES'
> Warning: unable to access index for repository
> http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4:
> cannot open URL
> 'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4/PACKAGES'
> There is a binary version available but the source version is later:
> binary source needs_compilation
> igraph 1.0.1 1.1.1 TRUE
> Do you want to install from sources the package which needs compilation?
> y/n: y
> installing the source package ‘igraph’
> trying URL
'http://cran.radicaldevelop.com/src/contrib/igraph_1.1.1.tar.gz'
> Content type 'application/x-gzip' length 3376077 bytes (3.2 MB)
> downloaded 3.2 MB
> [...]
> The rest of the process goes on with success.
> The problem seems to be with
http://www.stats.ox.ac.uk/pub/RWin/src/contrib
> When I check
>> options("repos")
> $repos
> CRANCRANextra
> "http://cran.radicaldevelop.com"; "http://www.stats.ox.ac.uk/pub/RWin";
> I'm lead to think that install.packages should try
> "http://cran.radicaldevelop.com"; first, only in case of failure CRANextra.
> What is going on?
>> sessionInfo()
> R version 3.4.1 (2017-06-30)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1
> Matrix products: default
> locale:
> [1] LC_COLLATE=Portuguese_Portugal.1252
> LC_CTYPE=Portuguese_Portugal.1252
> [3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
> [5] LC_TIME=Portuguese_Portugal.1252
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> other attached packages:
> [1] igraph_1.0.1
> loaded via a namespace (and not attached):
> [1] compiler_3.4.1 magrittr_1.5 tools_3.4.1
> Thanks in advance,
> Rui Barradas
> __
> 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] install.packages problem on Windows: CRANextras timeout
Hello,
Thanks for the answer.
No, in the end there's no problem, just a warning.
Rui Barradas
Em 17-07-2017 09:29, Martin Maechler escreveu:
Rui Barradas
on Mon, 17 Jul 2017 09:03:33 +0100 writes:
> Hello,
> R 3.4.1 on Windows 7, sessionInfo at the end.
> Is there a problem with install.packages? Since last friday every time I
> try to install a package in RGui, I start by choosing the CRAN mirror
> Cloud-0 and RGui hangs. So I restart RGui and choose Portugal (Lisbon)
> and get the following warning after a long while (minutes).
As (I think) you notice below yourself, the problem is not with
the regular CRAN repos but with the 'CRANextra' repos that
R users of Windows use sometimes.
We had heard offline of a potential timeout/downtime for a short
period at Oxford for that, so this may be the simple explanation.
On the other hand everything ends up working fine,
so all this is just a warning, right?
If I do the same thing I don't have to wait and get the same
warning as you (and when I then decide to use the older *binary*
for igraph that is installed fine).
Martin
> install.packages("igraph")
> --- Please select a CRAN mirror for use in this session ---
> Warning: unable to access index for repository
> http://www.stats.ox.ac.uk/pub/RWin/src/contrib:
> cannot open URL 'http://www.stats.ox.ac.uk/pub/RWin/src/contrib/PACKAGES'
> Warning: unable to access index for repository
> http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4:
> cannot open URL
> 'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.4/PACKAGES'
> There is a binary version available but the source version is later:
> binary source needs_compilation
> igraph 1.0.1 1.1.1 TRUE
> Do you want to install from sources the package which needs compilation?
> y/n: y
> installing the source package ‘igraph’
> trying URL
'http://cran.radicaldevelop.com/src/contrib/igraph_1.1.1.tar.gz'
> Content type 'application/x-gzip' length 3376077 bytes (3.2 MB)
> downloaded 3.2 MB
> [...]
> The rest of the process goes on with success.
> The problem seems to be with
http://www.stats.ox.ac.uk/pub/RWin/src/contrib
> When I check
>> options("repos")
> $repos
> CRANCRANextra
> "http://cran.radicaldevelop.com"; "http://www.stats.ox.ac.uk/pub/RWin";
> I'm lead to think that install.packages should try
> "http://cran.radicaldevelop.com"; first, only in case of failure
CRANextra.
> What is going on?
>> sessionInfo()
> R version 3.4.1 (2017-06-30)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1
> Matrix products: default
> locale:
> [1] LC_COLLATE=Portuguese_Portugal.1252
> LC_CTYPE=Portuguese_Portugal.1252
> [3] LC_MONETARY=Portuguese_Portugal.1252 LC_NUMERIC=C
> [5] LC_TIME=Portuguese_Portugal.1252
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> other attached packages:
> [1] igraph_1.0.1
> loaded via a namespace (and not attached):
> [1] compiler_3.4.1 magrittr_1.5 tools_3.4.1
> Thanks in advance,
> Rui Barradas
> __
> 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] Proposed Patch for poly.Rd
On 17/07/2017 2:57 AM, Martin Maechler wrote:
Duncan Murdoch
on Sat, 15 Jul 2017 19:27:57 -0400 writes:
> On 15/07/2017 11:37 AM, Martin Maechler wrote:
>>> Marc Schwartz
>>> on Fri, 14 Jul 2017 11:01:03 -0500 writes:
>>
>> >> On Jul 14, 2017, at 9:50 AM, Martin Maechler
>> >> wrote:
>> >>
>> >>> Martin Maechler on Fri,
>> >>> 14 Jul 2017 16:30:50 +0200 writes:
>> >>
>> >>> Marc Schwartz on Fri, 14 Jul
>> >>> 2017 06:57:26 -0500 writes:
>> >>
>> > On Jul 13, 2017, at 5:07 PM, Marc Schwartz
>> > wrote:
>> >
>> >
>>> On Jul 13, 2017, at 3:37 PM, Marc Schwartz
>> > wrote:
>>>
>>>
>> >>> On Jul 13, 2017, at 3:22 PM, Duncan Murdoch
>> >>> wrote:
>> >>>
>> >>> On 13/07/2017 4:08 PM, Marc Schwartz wrote:
>> Hi All,
>>
>> As per the discussion today on R-Help:
>>
>> https://stat.ethz.ch/pipermail/r-help/2017-July/448132.html
>>
>> I am attaching a proposed patch for poly.Rd to
>> provide clarifying wording relative to naming the
>> 'degree' argument explicitly, in the case where the
>> 'x' argument is a matrix, rather than a vector.
>>
>> This is based upon the svn trunk version of
>> poly.Rd.
>> >>>
>> >>> I don't think this is the right fix. The use of the
>> >>> unnamed 2nd arg as degree happens whether the first
>> >>> arg is a matrix or not.
>> >>>
>> >>> I didn't read the whole thread in detail, but it
>> >>> appears there's a bug somewhere, in the report or in
>> >>> the poly() code or in the plsr() code. That bug
>> >>> should be reported on the bug list if it turns out
>> >>> to be in base R, and to the package maintainer if it
>> >>> is in plsr().
>> >>>
>> >>> Duncan Murdoch
>>>
>>>
>>> Duncan,
>>>
>>> Thanks for your reply. You only really need to read that
>> >>> last post in the thread linked to above.
>>>
>>> I won't deny the possibility of a bug in poly(), relative
>> >>> to the handling of 'x' as a matrix. The behavior
>> >>> occurs in the poly() function in a pure stand alone
>> >>> fashion, without the need for plsr():
>>>
>>> x1 <- runif(20)
>>> x2 <- runif(20)
>>> mx <- cbind(x1, x2)
>>>
>> >
>> >
>> >
>> > Duncan,
>> >
>> > Tracing through the code for poly() using debug once
>> > with:
>> >
>> > poly(mx, 2)
>> >
>> > and then with:
>> >
>> > poly(mx, degree = 2)
>> >
>> > there is a difference in the transformation of 'mx'
>> > internally by the use of:
>> >
>> > if (is.matrix(x)) { m <-
>> > unclass(as.data.frame(cbind(x, ...)))
>> > return(do.call(polym, c(m, degree = degree, raw = raw,
>> > list(coefs = coefs }
>> >
>> >
>> > In the first case, 'mx' ends up being transformed to:
>> >
>> > Browse[2]> m $x1 [1] 0.99056941 0.13953093 0.38965567
>> > 0.35353514 0.90838486 0.97552474 [7] 0.01135743
>> > 0.06537047 0.56207834 0.50554056 0.96653391 0.69533973
>> > [13] 0.31333549 0.97488211 0.54952630 0.71747157
>> > 0.31164777 0.81694822 [19] 0.58641410 0.08858699
>> >
>> > $x2 [1] 0.6628658 0.9221436 0.3162418 0.8494452
>> > 0.4665010 0.3403719 [7] 0.4040692 0.4916650 0.9091161
>> > 0.2956006 0.3454689 0.3331070 [13] 0.8788974 0.5614636
>> > 0.7794396 0.2304009 0.6566537 0.6875646 [19] 0.5110733
>> > 0.4122336
>> >
>> > $V3 [1] 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
>> >
>> > attr(,"row.names") [1] 1 2 3 4 5 6 7 8 9 10 11 12 13
>> > 14 15 16 17 18 19 20
>> >
>> > Thus, when do.call() is used, m$V3 is passed as the
>> > 'x' argument on the third iteration, essentially
>> > resulting in:
>> >
>>> polym(rep(2, 20), degree = 2) Error in poly(dots[[1L]],
>> > degree, raw = raw, simple = raw && nd > 1) : 'degree'
>> > must be less than number of unique points
>> >
>> >
>> > Note also that in this case, 'dots', which is the
>> > result of using list(...) on the initial call, is:
>> >
>> > Browse[2]> dots [[1]] [1] 2
>> >
>> >
>> > In the second case:
>> >
>> > Browse[2]> m $x1 [1] 0.99056941 0.13953093 0.38965567
>> > 0.35353514 0.90838486 0.97552474 [7] 0.01135743
>> > 0.06537047 0.56207834 0.50554056 0.96653391 0.69533973
>
