Re: [Bioc-devel] error from biocLite on OSX with R-devel / Bioc-devel

2017-02-01 Thread Martin Morgan 

On 02/01/2017 01:11 PM, Kevin Ushey wrote:

Although installation succeeds for me (macOS Sierra with recent R-devel), I
see the following output in an interactive session when I try to install
the lazyeval package:


install.packages('lazyeval', repos = BiocInstaller:::biocinstallRepos())

Installing package into '/Users/kevin/r/r-devel-sanitizers/library'
(as 'lib' is unspecified)
curl: (22) The requested URL returned error: 404 Not Found
Warning in gzfile(file, "rb") :
  cannot open compressed file
'/var/folders/tm/5dt8p5s50x58br1k6wpqnwx0gn/T//RtmpyHUICQ/repos_https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.5%2Fbioc%2Fsrc%2Fcontrib.rds',
probable reason 'No such file or directory'
curl: (22) The requested URL returned error: 404 Not Found
Warning in gzfile(file, "rb") :
  cannot open compressed file
'/var/folders/tm/5dt8p5s50x58br1k6wpqnwx0gn/T//RtmpyHUICQ/repos_https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.5%2Fdata%2Fannotation%2Fsrc%2Fcontrib.rds',
probable reason 'No such file or directory'
curl: (22) The requested URL returned error: 404 Not Found
Warning in gzfile(file, "rb") :
  cannot open compressed file
'/var/folders/tm/5dt8p5s50x58br1k6wpqnwx0gn/T//RtmpyHUICQ/repos_https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.5%2Fdata%2Fexperiment%2Fsrc%2Fcontrib.rds',
probable reason 'No such file or directory'
curl: (22) The requested URL returned error: 404 Not Found
Warning in gzfile(file, "rb") :
  cannot open compressed file
'/var/folders/tm/5dt8p5s50x58br1k6wpqnwx0gn/T//RtmpyHUICQ/repos_https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.5%2Fextra%2Fsrc%2Fcontrib.rds',
probable reason 'No such file or directory'


Bizarrely, I don't see this in a non-interactive session; that is, this
works fine:

R -e "install.packages('lazyeval', repos =
BiocInstaller:::biocinstallRepos())"


In Levi's case, what happens is in a call to available.packages(), for this

repos <- 
"https://cran.rstudio.com/bin/macosx/mavericks/contrib/3.4.rds;

dest <- file.path(tempdir(), paste0("repos_", URLencode(repos,
TRUE), ".rds"))

'dest' is meant to be a local cache of 'repos'. R checks to see if dest 
exists. If it does, then R says


readRDS(dest)

but if it doesn't it tries

z <- tryCatch(download.file(repos, dest=dest), error=identity)

The first time through, dest doesn't exist, so R tries to download the 
file. This fails (because the 'repos' url doesn't exist) and subsequent 
R code recovers from the failure.


Unfortunately, the failed download.file() creates a 0-length file, so 
the next time through 'dest' exists as a file on disk, so R tries to 
readRDS(dest), and fails.


A workaround is actually to take Kevin's approach, and use a method 
different from the default 'libcurl' for the download.


I believe, a little ironically, that this is actually at least partly my 
fault in base R, and will fix this upstream.


Martin




For reference, I'm using 'curl' for downloads:


options("download.file.method", "download.file.extra")

$download.file.method
[1] "curl"

$download.file.extra
[1] "-L -f --stderr -"


And the version of R I'm using:

R Under development (unstable) (2017-01-24 r72026)
Platform: x86_64-apple-darwin16.3.0 (64-bit)
Running under: macOS Sierra 10.12.3


I don't see the aforementioned warnings with R 3.3.2.

Best,
Kevin

On Wed, Feb 1, 2017 at 4:26 AM, Vincent Carey 
wrote:


i did not mean to implicate biocLite ... i am being too terse.  i mention
it because, after so many
years of biocLite being spectacularly reliable ... persistence of a problem
with its performance
implies a serious upstream problem that would be very nice to eradicate ...

On Wed, Feb 1, 2017 at 1:15 AM, Levi Waldron 
wrote:



On Wed, Feb 1, 2017 at 12:51 AM, Martin Morgan <
martin.mor...@roswellpark.org> wrote:


Levi triggered the problem with install.packages("lazyeval",
repos=biocinstallRepos(), which is an R-only command. Also, there have

not

been any changes to the logic of biocLite() in this regard, so the

problem

is likely to be in R (devel) per se. I'll try to get access to a Mac and
investigate.



Yes, in fact, now I notice that it also happens with just
install.packages("lazyeval"), on the second invocation with the same repo
argument (although exiting and starting R again creates a new tmp

directory

so gives another free invocation. Sorry for blaming it on biocLite().

--
Levi Waldron
http://www.waldronlab.org
Assistant Professor of Biostatistics CUNY School of Public Health
US: +1 646-364-9616 <(646)%20364-9616>
   Skype: levi.waldron



[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] R CMD Check: Tests running infinite

2017-02-01 Thread Uwe Ligges 
Check whether the parallel cluster is closed. Can it be that the cluster 
is still open and the check process waits for them to complete?


Best,
Uwe Ligges



On 31.01.2017 13:45, Patrick Schratz wrote:

Hello,

when running R CMD check / devtools::check, section "running tests..." is
not finishing (40 min+).

*Checking tests only works:*

*==> Sourcing R files in 'tests' directory*

*testthat results
*
*OK: 7 SKIPPED: 0 FAILED: 0*

*Tests complete*


As well as running tests line-by-line.

How can I debug my tests to discover the problem during R CMD check?

*Tests are using parallelization (foreach + doParallel)*

Best, Patrick

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] R CMD Check: Tests running infinite

2017-02-01 Thread Patrick Schratz 
Hello,

when running R CMD check / devtools::check, section "running tests..." is
not finishing (40 min+).

*Checking tests only works:*

*==> Sourcing R files in 'tests' directory*

*testthat results
*
*OK: 7 SKIPPED: 0 FAILED: 0*

*Tests complete*


As well as running tests line-by-line.

How can I debug my tests to discover the problem during R CMD check?

*Tests are using parallelization (foreach + doParallel)*

Best, Patrick

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

2017-02-01 Thread Avraham Adler 
On Wed, Feb 1, 2017 at 3:14 AM, Martin Maechler 
wrote:

> Or the file was corrupted during download?
>
> Here are the md5sum s  from the server itself for the last three snapshots:
>
> 388b607afe732c92442dbb49845fe377  /ftp/R/R-patched_2017-01-31.tar.gz
> 7daea59067454311818df1c75971a485  /ftp/R/R-patched_2017-01-30.tar.gz
> 9ddad833a455973631920c70b6da5d6e  /ftp/R/R-patched_2017-01-29.tar.gz
>

That is probably the case as the 01-30 version gives me an MD5 of
49fcb4ad0874b136a4499b8d3d39cc03.

Thank you,

Avi

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] GenomeInfoDb::Seqinfo() failing with 404 error

2017-02-01 Thread Hervé Pagès 

Hi Raymond,

On 02/01/2017 04:39 AM, Raymond Cavalcante wrote:

Hello,

I was wondering if any progress has been made on fixing this? I looked through 
recent commits for GenomeInfoDb, but there didn't seem to be anything related 
to this problem.


Not yet. Please expect a couple more days before this is resolved.

Thanks for your patience,
H.



Thanks,
Raymond


On Jan 25, 2017, at 23:01, Obenchain, Valerie 
 wrote:

Thanks for the report. It looks like the directory structure has
changed. I'll work on this tomorrow and will post back when it's fixed.

Valerie



On 01/25/2017 06:29 PM, Raymond Cavalcante wrote:
Hello,

I'm suddenly encountering errors with GenomeInfoDb::Seqinfo():


GenomeInfoDb::Seqinfo(genome='hg19')

Error in file(file, "rt") : cannot open connection
In addition: Warning message:
In file(file, "rt") :
 URL 
'https://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_01405.13.assembly.txt':
 status was '404 Not Found'

I'm not sure how to fix this issue, as it seems to be more of an NCBI problem. 
Any help would be greatly appreciated.

Thanks,
Raymond Cavalcante
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel





This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.


___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
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...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] error from biocLite on OSX with R-devel / Bioc-devel

2017-02-01 Thread Kevin Ushey 
Although installation succeeds for me (macOS Sierra with recent R-devel), I
see the following output in an interactive session when I try to install
the lazyeval package:

> install.packages('lazyeval', repos = BiocInstaller:::biocinstallRepos())
Installing package into '/Users/kevin/r/r-devel-sanitizers/library'
(as 'lib' is unspecified)
curl: (22) The requested URL returned error: 404 Not Found
Warning in gzfile(file, "rb") :
  cannot open compressed file
'/var/folders/tm/5dt8p5s50x58br1k6wpqnwx0gn/T//RtmpyHUICQ/repos_https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.5%2Fbioc%2Fsrc%2Fcontrib.rds',
probable reason 'No such file or directory'
curl: (22) The requested URL returned error: 404 Not Found
Warning in gzfile(file, "rb") :
  cannot open compressed file
'/var/folders/tm/5dt8p5s50x58br1k6wpqnwx0gn/T//RtmpyHUICQ/repos_https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.5%2Fdata%2Fannotation%2Fsrc%2Fcontrib.rds',
probable reason 'No such file or directory'
curl: (22) The requested URL returned error: 404 Not Found
Warning in gzfile(file, "rb") :
  cannot open compressed file
'/var/folders/tm/5dt8p5s50x58br1k6wpqnwx0gn/T//RtmpyHUICQ/repos_https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.5%2Fdata%2Fexperiment%2Fsrc%2Fcontrib.rds',
probable reason 'No such file or directory'
curl: (22) The requested URL returned error: 404 Not Found
Warning in gzfile(file, "rb") :
  cannot open compressed file
'/var/folders/tm/5dt8p5s50x58br1k6wpqnwx0gn/T//RtmpyHUICQ/repos_https%3A%2F%2Fbioconductor.org%2Fpackages%2F3.5%2Fextra%2Fsrc%2Fcontrib.rds',
probable reason 'No such file or directory'


Bizarrely, I don't see this in a non-interactive session; that is, this
works fine:

R -e "install.packages('lazyeval', repos =
BiocInstaller:::biocinstallRepos())"


For reference, I'm using 'curl' for downloads:

> options("download.file.method", "download.file.extra")
$download.file.method
[1] "curl"

$download.file.extra
[1] "-L -f --stderr -"


And the version of R I'm using:

R Under development (unstable) (2017-01-24 r72026)
Platform: x86_64-apple-darwin16.3.0 (64-bit)
Running under: macOS Sierra 10.12.3


I don't see the aforementioned warnings with R 3.3.2.

Best,
Kevin

On Wed, Feb 1, 2017 at 4:26 AM, Vincent Carey 
wrote:

> i did not mean to implicate biocLite ... i am being too terse.  i mention
> it because, after so many
> years of biocLite being spectacularly reliable ... persistence of a problem
> with its performance
> implies a serious upstream problem that would be very nice to eradicate ...
>
> On Wed, Feb 1, 2017 at 1:15 AM, Levi Waldron 
> wrote:
>
> >
> > On Wed, Feb 1, 2017 at 12:51 AM, Martin Morgan <
> > martin.mor...@roswellpark.org> wrote:
> >
> >> Levi triggered the problem with install.packages("lazyeval",
> >> repos=biocinstallRepos(), which is an R-only command. Also, there have
> not
> >> been any changes to the logic of biocLite() in this regard, so the
> problem
> >> is likely to be in R (devel) per se. I'll try to get access to a Mac and
> >> investigate.
> >
> >
> > Yes, in fact, now I notice that it also happens with just
> > install.packages("lazyeval"), on the second invocation with the same repo
> > argument (although exiting and starting R again creates a new tmp
> directory
> > so gives another free invocation. Sorry for blaming it on biocLite().
> >
> > --
> > Levi Waldron
> > http://www.waldronlab.org
> > Assistant Professor of Biostatistics CUNY School of Public Health
> > US: +1 646-364-9616 <(646)%20364-9616>
> >Skype: levi.waldron
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] tokay2 outage

2017-02-01 Thread Obenchain, Valerie 
Hi,

We've been having problems with our Windows devel builder, tokay2
(https://stat.ethz.ch/pipermail/bioc-devel/2017-January/010424.html).
It's been determined the battery for the storage array is bad and needs
to be replaced. The work is scheduled for tomorrow, Thursday Feb 2 at at
10am EST.

It is possible that the swap will be complete before the next build
cycle but let's not count on it. tokay2 build results should post on Feb
2, may be missing from Feb 3 and should be back again Feb 4.

Valerie



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] RFC: tapply(*, ..., init.value = NA)

2017-02-01 Thread Suharto Anggono Suharto Anggono via R-devel 
On 'aggregate data.frame', the URL should be 
https://stat.ethz.ch/pipermail/r-help/2016-May/438631.html .

vector(typeof(ans))
(or  vector(storage.mode(ans)))
has length zero and can be used to initialize array.

Instead of
if(missing(default)) ,
if(identical(default, NA))
could be used. The documentation could then say, for example: "If default = NA 
(the default), NA of appropriate storage mode (0 for raw) is automatically 
used."

On Wed, 1/2/17, Martin Maechler  wrote:

 Subject: Re: [Rd] RFC: tapply(*, ..., init.value = NA)

 Cc: R-devel@r-project.org
 Date: Wednesday, 1 February, 2017, 12:14 AM
 
> Suharto Anggono Suharto Anggono via R-devel 
> on Tue, 31 Jan 2017 15:43:53 + writes:

> Function 'aggregate.data.frame' in R has taken a different route. With 
drop=FALSE, the function is also applied to subset corresponding to combination 
of grouping variables that doesn't appear in the data (example 2 in 
https://stat.ethz.ch/pipermail/r-devel/2017-January/073678.html).

Interesting point (I couldn't easily find 'the example 2' though).
However, aggregate.data.frame() is a considerably more
sophisticated function and one goal was to change tapply() as
little as possible for compatibility (and maintenance!) reasons .

[snip]

> With the code using
>if(missing(default)) ,
> I consider the stated default value of 'default',
>default = NA ,
> misleading because the code doesn't use it. 

I know and I also had thought about it and decided to keep it 
in the spirit of "self documentation" because  "in spirit", the
default still *is* NA.

> Also,
>  tapply(1:3, 1:3, as.raw)
> is not the same as
>  tapply(1:3, 1:3, as.raw, default = NA) .
> The accurate statement is the code in
> if(missing(default)) ,
> but it involves the local variable 'ans'.

exactly.  But putting that whole expression in there would look
confusing to those using  str(tapply), args(tapply) or similar
inspection to quickly get a glimpse of the function user "interface".
That's why we typically don't do that and rather slightly cheat
with the formal default, for the above "didactical" purposes.

If you are puristic about this, then missing() should almost never
be used when the function argument has a formal default.

I don't have a too strong opinion here, and we do have quite a
few other cases, where the formal default argument is not always
used because of   if(missing(.))  clauses.

I think I could be convinced to drop the '= NA' from the formal
argument list..


> As far as I know, the result of function 'array' in is not a classed 
object and the default method of  `[<-` will be used in the 'tapply' code 
portion.

> As far as I know, the result of 'lapply' is a list without class. So, 
'unlist' applied to it uses the default method and the 'unlist' result is a 
vector or a factor.

You may be right here
  ((or not:  If a package author makes array() into an S3 generic and defines
S3method(array, *) and she or another make tapply() into a
generic with methods,  are we really sure that this code
would not be used ??))

still, the as.raw example did not easily work without a warning
when using as.vector() .. or similar.

> With the change, the result of

> tapply(1:3, 1:3, factor, levels=3:1)

> is of mode "character". The value is from the internal code, not from the 
factor levels. It is worse than before the change, where it is really the 
internal code, integer.

I agree that this change is not desirable.
One could argue that it was quite a "lucky coincidence" that the previous
code returned the internal integer codes though..


[snip]


> To initialize array, a zero-length vector can also be used.

yes, of course; but my  ans[0L][1L]  had the purpose to get the
correct mode specific version of NA .. which works for raw (by
getting '00' because "raw" has *no* NA!).

So it seems I need an additional   !is.factor(ans)  there ...
a bit ugly.


-

[snip]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] GenomeInfoDb::Seqinfo() failing with 404 error

2017-02-01 Thread Raymond Cavalcante 
Hello,

I was wondering if any progress has been made on fixing this? I looked through 
recent commits for GenomeInfoDb, but there didn't seem to be anything related 
to this problem.

Thanks,
Raymond

> On Jan 25, 2017, at 23:01, Obenchain, Valerie 
>  wrote:
> 
> Thanks for the report. It looks like the directory structure has
> changed. I'll work on this tomorrow and will post back when it's fixed.
> 
> Valerie
> 
> 
>> On 01/25/2017 06:29 PM, Raymond Cavalcante wrote:
>> Hello,
>> 
>> I'm suddenly encountering errors with GenomeInfoDb::Seqinfo():
>> 
 GenomeInfoDb::Seqinfo(genome='hg19')
>>> Error in file(file, "rt") : cannot open connection
>>> In addition: Warning message:
>>> In file(file, "rt") :
>>>  URL 
>>> 'https://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_01405.13.assembly.txt':
>>>  status was '404 Not Found'
>> I'm not sure how to fix this issue, as it seems to be more of an NCBI 
>> problem. Any help would be greatly appreciated.
>> 
>> Thanks,
>> Raymond Cavalcante
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> 
> 
> 
> 
> This email message may contain legally privileged and/or confidential 
> information.  If you are not the intended recipient(s), or the employee or 
> agent responsible for the delivery of this message to the intended 
> recipient(s), you are hereby notified that any disclosure, copying, 
> distribution, or use of this email message is prohibited.  If you have 
> received this message in error, please notify the sender immediately by 
> e-mail and delete this email message from your computer. Thank you.

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] error from biocLite on OSX with R-devel / Bioc-devel

2017-02-01 Thread Vincent Carey 
i did not mean to implicate biocLite ... i am being too terse.  i mention
it because, after so many
years of biocLite being spectacularly reliable ... persistence of a problem
with its performance
implies a serious upstream problem that would be very nice to eradicate ...

On Wed, Feb 1, 2017 at 1:15 AM, Levi Waldron 
wrote:

>
> On Wed, Feb 1, 2017 at 12:51 AM, Martin Morgan <
> martin.mor...@roswellpark.org> wrote:
>
>> Levi triggered the problem with install.packages("lazyeval",
>> repos=biocinstallRepos(), which is an R-only command. Also, there have not
>> been any changes to the logic of biocLite() in this regard, so the problem
>> is likely to be in R (devel) per se. I'll try to get access to a Mac and
>> investigate.
>
>
> Yes, in fact, now I notice that it also happens with just
> install.packages("lazyeval"), on the second invocation with the same repo
> argument (although exiting and starting R again creates a new tmp directory
> so gives another free invocation. Sorry for blaming it on biocLite().
>
> --
> Levi Waldron
> http://www.waldronlab.org
> Assistant Professor of Biostatistics CUNY School of Public Health
> US: +1 646-364-9616 <(646)%20364-9616>
>Skype: levi.waldron
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] Typos in manuals

2017-02-01 Thread Mikko Korpela 
I found some trivial typos, mostly unmatched parentheses, in the R 
manuals. More information and suggested fixes are in the attached diff file.



--
Mikko Korpela
Department of Geosciences and Geography
University of Helsinki
Index: doc/manual/R-admin.texi
===
--- doc/manual/R-admin.texi	(revision 72066)
+++ doc/manual/R-admin.texi	(working copy)
@@ -571,7 +571,7 @@
 @noindent
 This requires @command{ebook-convert} from @command{Calibre}
 (@uref{http://calibre-ebook.com/download}), or from most Linux
-distributions).  If necessary the path to @command{ebook-convert} can be
+distributions.  If necessary the path to @command{ebook-convert} can be
 set as make macro @env{EBOOK} to by editing @file{doc/manual/Makefile}
 (which contains a commented value suitable for macOS).
 
@@ -2973,7 +2973,7 @@
 distributions.)
 
 Even on 64-bit builds of @R{} there are limits on the size of @R{}
-objects (see @code{help("Memory-limits")}, some of which stem from the
+objects (see @code{help("Memory-limits")}), some of which stem from the
 use of 32-bit integers (especially in FORTRAN code).  For example, the
 dimensions of an array are limited to @math{2^{31} - 1}.
 
@@ -4566,7 +4566,7 @@
 designed for use in terminals).  In such locales @emph{fontsets} are
 used, made up of fonts encoded in other encodings.  If the locale you
 are using has an entry in the @samp{XLC_LOCALE} directory (typically
-@file{/usr/share/X11/locale}, it is likely that all you need to do is to
+@file{/usr/share/X11/locale}), it is likely that all you need to do is to
 pick a suitable font specification that has fonts in the encodings
 specified there.  If not, you may have to get hold of a suitable locale
 entry for X11.  This may mean that, for example, Japanese text can be
Index: doc/manual/R-data.texi
===
--- doc/manual/R-data.texi	(revision 72066)
+++ doc/manual/R-data.texi	(working copy)
@@ -345,7 +345,7 @@
 By default strings are quoted (including the row and column names).
 Argument @code{quote} controls if character and factor variables are
 quoted: some programs, for example @pkg{Mondrian}
-(@uref{https://en.wikipedia.org/wiki/Mondrian_(software)}, do not accept
+(@uref{https://en.wikipedia.org/wiki/Mondrian_(software)}), do not accept
 quoted strings.
 
 Some care is needed if the strings contain embedded quotes.  Three
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi	(revision 72066)
+++ doc/manual/R-exts.texi	(working copy)
@@ -463,9 +463,9 @@
 suitable @samp{Authors@@R} field is given.  This field can be used to
 provide a refined and machine-readable description of the package
 ``authors'' (in particular specifying their precise @emph{roles}), via
-suitable @R{} code. It should create an object of class @code{"person'},
+suitable @R{} code. It should create an object of class @code{"person"},
 by either a call to @code{person} or a series of calls (one per
-``author'') concatenated by @code{c()}): see the example
+``author'') concatenated by @code{c()}: see the example
 @file{DESCRIPTION} file above.  The roles can include @samp{"aut"}
 (author) for full authors, @samp{"cre"} (creator) for the package
 maintainer, and @samp{"ctb"} (contributor) for other contributors,
@@ -1553,7 +1553,7 @@
 @group
 foo <- function(x) @{
 if(!@@HAVE_FOO@@)
-  stop("Sorry, library 'foo' is not available"))
+  stop("Sorry, library 'foo' is not available")
 ...
 @end group
 @end example
@@ -1566,7 +1566,7 @@
 @group
 foo <- function(x) @{
 if(!FALSE)
-  stop("Sorry, library 'foo' is not available"))
+  stop("Sorry, library 'foo' is not available")
 ...
 @end group
 @end example
@@ -3351,7 +3351,7 @@
 to the encoding of the current @R{} session.
 
 @code{Stangle()} will produce an @R{} code file in the current locale's
-encoding: for a non-@acronym{ASCII} vignette what that is recorded in a
+encoding: for a non-@acronym{ASCII} vignette what that is is recorded in a
 comment at the top of the file.
 
 @code{Sweave()} will produce a @file{.tex} file in the current
@@ -4214,7 +4214,7 @@
 @R{} has tested that @code{DOUBLE COMPLEX} works (although an extension
 to the Fortran standards) and so is preferred to @code{COMPLEX*16}.
 (Fortran 9x code can use something like
-@code{COMPLEX(KIND=KIND(0.0D0)}@footnote{See
+@code{COMPLEX(KIND=KIND(0.0D0))}@footnote{See
 @uref{http://people.ds.cam.ac.uk/nmm1/fortran/paper_07.pdf}.}.)
 
 
@@ -5179,7 +5179,7 @@
 and mark strings by
 
 @example
-dngettext(("@var{pkg}", @var{}, @var{}, n)
+dngettext("@var{pkg}", @var{}, @var{}, n)
 @end example
 
 @item
@@ -6484,8 +6484,8 @@
 The ``comment'' character @samp{%} and unpaired braces@footnote{See the
 examples section in the file @file{Paren.Rd} for an example.}
 @emph{almost always} need to be escaped by @samp{\}, and @samp{\\} can
-be used for

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

2017-02-01 Thread Avraham Adler 
It worked for me at home but not at work. I will email my work the copy I
have at home. It could have been something with our connectivity or
firewall. My home copy of 1-31 is also 388b607afe732c92442dbb49845fe377.
I'll check the work ones tomorrow, or should I say later today.

Thank you,

Avi

On Wed, Feb 1, 2017 at 3:14 AM, Martin Maechler 
wrote:

> > Avraham Adler 
> > on Tue, 31 Jan 2017 16:07:20 -0500 writes:
>
> > On Tue, Jan 31, 2017 at 3:30 PM, peter dalgaard 
> wrote:
> >>
> >>> On 31 Jan 2017, at 18:56 , Avraham Adler 
> wrote:
> >>>
> >>> Hello.
> >>>
> >>> When trying to unpack today's version of R-patched,
> >>
> >> From which source? The files from cran.r-project.org seems OK,
> both those in src/base-prerelease and those from ETHZ.
>
> >> Also, is it not "tar -xfz" when reading a compressed file?
>
> Recent (for several years) versions of tar (on Linux at least)
> do not need the compression extension anymore: They guess it
> correctly from the file.
>
> >>
> >> -pd
>
> >> From 
>
> The last two of the daily R-patched*.tar.gz
> unpack flawlessly for me as well.
>
> Could it be that your Windows(?) version of tar (or the file
> system or ???) is the problem?
>
> Or the file was corrupted during download?
>
> Here are the md5sum s  from the server itself for the last three snapshots:
>
> 388b607afe732c92442dbb49845fe377  /ftp/R/R-patched_2017-01-31.tar.gz
> 7daea59067454311818df1c75971a485  /ftp/R/R-patched_2017-01-30.tar.gz
> 9ddad833a455973631920c70b6da5d6e  /ftp/R/R-patched_2017-01-29.tar.gz
>
>
>
> > Also, while passing z is not in the instructions given in
> Installation
> > and Administration [1], I tried passing -xzf and it did not work. I
> > believe f has to be last if the file name follows immediately.
>
> > [1]   html#Getting-the-source-files>
>
> > Thanks,
>
> > Avi
>
> >>> I get the following error:
> >>>
> >>> C:\R>tar -xf R-patched_2017-01-30.tar.gz
> >>>
> >>> gzip: stdin: unexpected end of file
> >>> tar: Unexpected EOF in archive
> >>> tar: Unexpected EOF in archive
> >>> tar: Error is not recoverable: exiting now
> >>>
> >>> I got the same error for R-patched_2017-01-30.tar.gz but not for
> R-3.3.2.tar.gz.
> >>>
> >>> Thank you,
> >>>
> >>> Avi
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >> --
> >> Peter Dalgaard, Professor,
> >> Center for Statistics, Copenhagen Business School
> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> >> Phone: (+45)38153501
> >> Office: A 4.23
> >> Email: pd@cbs.dk  Priv: pda...@gmail.com
> >>
>
> > __
> > 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] Unexpected EOF in R-patched_2017-01-30

2017-02-01 Thread Martin Maechler 
> Avraham Adler 
> on Tue, 31 Jan 2017 16:07:20 -0500 writes:

> On Tue, Jan 31, 2017 at 3:30 PM, peter dalgaard  wrote:
>> 
>>> On 31 Jan 2017, at 18:56 , Avraham Adler  
wrote:
>>> 
>>> Hello.
>>> 
>>> When trying to unpack today's version of R-patched,
>> 
>> From which source? The files from cran.r-project.org seems OK, both 
those in src/base-prerelease and those from ETHZ. 

>> Also, is it not "tar -xfz" when reading a compressed file?

Recent (for several years) versions of tar (on Linux at least)
do not need the compression extension anymore: They guess it
correctly from the file.

>> 
>> -pd

>> From 

The last two of the daily R-patched*.tar.gz
unpack flawlessly for me as well.

Could it be that your Windows(?) version of tar (or the file
system or ???) is the problem?

Or the file was corrupted during download?

Here are the md5sum s  from the server itself for the last three snapshots:

388b607afe732c92442dbb49845fe377  /ftp/R/R-patched_2017-01-31.tar.gz
7daea59067454311818df1c75971a485  /ftp/R/R-patched_2017-01-30.tar.gz
9ddad833a455973631920c70b6da5d6e  /ftp/R/R-patched_2017-01-29.tar.gz



> Also, while passing z is not in the instructions given in Installation
> and Administration [1], I tried passing -xzf and it did not work. I
> believe f has to be last if the file name follows immediately.

> [1]  


> Thanks,

> Avi

>>> I get the following error:
>>> 
>>> C:\R>tar -xf R-patched_2017-01-30.tar.gz
>>> 
>>> gzip: stdin: unexpected end of file
>>> tar: Unexpected EOF in archive
>>> tar: Unexpected EOF in archive
>>> tar: Error is not recoverable: exiting now
>>> 
>>> I got the same error for R-patched_2017-01-30.tar.gz but not for 
R-3.3.2.tar.gz.
>>> 
>>> Thank you,
>>> 
>>> Avi
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> --
>> Peter Dalgaard, Professor,
>> Center for Statistics, Copenhagen Business School
>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>> Phone: (+45)38153501
>> Office: A 4.23
>> Email: pd@cbs.dk  Priv: pda...@gmail.com
>> 

> __
> 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