Re: [Rd] R CMD check --as-cran and (a)spell checking
> Henrik Bengtsson > on Fri, 5 Dec 2014 18:17:57 -0800 writes: > Does anyone know if it is possible to add a dictionary > file of known words that becomes part of the *built* > package to tell 'R CMD check --as-cran' not to report > these words as misspelled. I want this dictionary to come > with the *.tar.gz such that it will be available > regardless where the package is checked. For instance, > currently I get: > * using log directory > 'T:/R/_R-3.1.2patched/matrixStats.Rcheck' * using R > version 3.1.2 Patched (2014-12-03 r67101) * using > platform: x86_64-w64-mingw32 (64-bit) * using session > charset: ISO8859-1 * checking for file > 'matrixStats/DESCRIPTION' ... OK * this is package > 'matrixStats' version '0.12.0' * checking CRAN incoming > feasibility ... NOTE Maintainer: 'Henrik Bengtsson > ' Possibly mis-spelled words in > DESCRIPTION: rowMedians (18:74) rowRanks (18:92) rowSds > (18:111) * checking package namespace information ... OK > ... I agree that some customization possibility would be great here. Maybe it'll be sufficient to allow a short list of about a dozen words in the DESCRIPTION itself, e.g., with an item Extrawords: rowMedians, rowRanks Would you feel like providing a patch to the R (devel) sources for this? Best, Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package.skeleton leads to R CMD check aborting
The package.skeleton() base function is useful for creating empty packages.
The fact that the help files generated by the function cause errors was long
an annoyance, but I noticed last month (while preparing for a workshop on R
and packages) that it creates packages which cause 'R CMD check ...' to die
in error. Which is always a bug.
I just verified that it still dies in error under R-devel, and filed bug
report 16105 at the bugzilla instance. See below for a session log.
As a bug reporter, I should offer help. I do, though somewhat hesitantly as
package.skeleton() has gotten a bit complicated over the years. But if a
patch simplifying the output of a simple default package is of interest I
will work on it.
Dirk
edd@max:/tmp$ rm -rf demo/
edd@max:/tmp$ mkdir demo && cd demo
edd@max:/tmp/demo$ R-devel.sh
R Under development (unstable) (2014-12-09 r67142) -- "Unsuffered Consequences"
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
John Kane: I have 120 columns in a data.frame. I have one value in a column
named "blaw" that I want to change. How do I find the coordinates?
Roger Koenker: It is the well-known wicked which problem: If you had
(grammatically incorrectly) thought "... which I want to change" then you might
have
been led to type (in another window):
?which
and you would have seen the light. Maybe that() should be an alias for which()?
-- John Kane and Roger Koenker
R-help (August 2006)
R> package.skeleton("quickDemo")
Creating directories ...
Creating DESCRIPTION ...
Creating NAMESPACE ...
Creating Read-and-delete-me ...
Saving functions and data ...
Making help files ...
Done.
Further steps are described in './quickDemo/Read-and-delete-me'.
R> q()
edd@max:/tmp/demo$ R-devel.sh CMD build quickDemo
* checking for file ‘quickDemo/DESCRIPTION’ ... OK
* preparing ‘quickDemo’:
* checking DESCRIPTION meta-information ... OK
* installing the package to process help pages
* saving partial Rd database
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building ‘quickDemo_1.0.tar.gz’
edd@max:/tmp/demo$ R-devel.sh CMD check quickDemo_1.0.tar.gz
* using log directory ‘/tmp/demo/quickDemo.Rcheck’
* using R Under development (unstable) (2014-12-09 r67142)
* using platform: x86_64-unknown-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ‘quickDemo/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘quickDemo’ version ‘1.0’
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘quickDemo’ can be installed ... WARNING
Found the following significant warnings:
Warning:
/tmp/Rtmp3vskac/Rbuild4e1945bdc52a/quickDemo/man/quickDemo-package.Rd:26: All
text must be in a section
See ‘/tmp/demo/quickDemo.Rcheck/00install.out’ for details.
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... WARNING
Non-standard license specification:
What license is it under?
Standardizable: FALSE
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... WARNING
prepare_Rd: quickDemo-package.Rd:26: All text must be in a section
* checking Rd metadata ... OK
* checking Rd cross-references ... WARNING
Unknown
[Rd] Fwd: No source view when using gdb
Dear R contributors, Say I want to debug some C code invoked through .Call() - say "varbayes" in the VBmix package. following the instructions in "Writing R Extensions", I perform the following actions : R -d gdb run library(VBmix) CTRL+C break varbayes signal 0 mod <- varbayes(as.matrix(iris)[,1:4], 2) The breakpoint is indeed activated, seemingly at the correct position in the source file, but instead of the actual text at the respective line, I get the following : 69varbayes.c: No such file or directory. Issuing "next" afterwards seems to attain the expected purpose (step by step progression), but source code lines are replaced by, e.g. : 72in varbayes.c There should be some way of "installing" the source code files, but I did not find R-specific info there. Does someone have a clue for my problem? Thanks by advance, Pierrick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: No source view when using gdb
On Thu, 2014-12-11 at 14:00 +0100, Pierrick Bruneau wrote:
> Dear R contributors,
>
> Say I want to debug some C code invoked through .Call() - say
> "varbayes" in the VBmix package. following the instructions in
> "Writing R Extensions", I perform the following actions :
>
> R -d gdb
> run
> library(VBmix)
> CTRL+C
> break varbayes
> signal 0
> mod <- varbayes(as.matrix(iris)[,1:4], 2)
>
> The breakpoint is indeed activated, seemingly at the correct position
> in the source file, but instead of the actual text at the respective
> line, I get the following :
>
> 69varbayes.c: No such file or directory.
>
> Issuing "next" afterwards seems to attain the expected purpose (step
> by step progression), but source code lines are replaced by, e.g. :
>
> 72in varbayes.c
>
> There should be some way of "installing" the source code files, but I
> did not find R-specific info there. Does someone have a clue for my
> problem?
This happens when you install a package from the tarball. The source is
unpacked into a temporary directory which is then deleted. Try unpacking
the source tarball yourself, and then installing from the unpacked
directory, e.g.
tar xfvz VBMix_0.2.17.tar.gz
R CMD INSTALL VBMix
Martyn
> Thanks by advance,
> Pierrick
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
---
This message and its attachments are strictly confidenti...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: No source view when using gdb
Works like a charm, thanks!
On Thu, Dec 11, 2014 at 3:00 PM, Martyn Plummer wrote:
> On Thu, 2014-12-11 at 14:00 +0100, Pierrick Bruneau wrote:
>> Dear R contributors,
>>
>> Say I want to debug some C code invoked through .Call() - say
>> "varbayes" in the VBmix package. following the instructions in
>> "Writing R Extensions", I perform the following actions :
>>
>> R -d gdb
>> run
>> library(VBmix)
>> CTRL+C
>> break varbayes
>> signal 0
>> mod <- varbayes(as.matrix(iris)[,1:4], 2)
>>
>> The breakpoint is indeed activated, seemingly at the correct position
>> in the source file, but instead of the actual text at the respective
>> line, I get the following :
>>
>> 69varbayes.c: No such file or directory.
>>
>> Issuing "next" afterwards seems to attain the expected purpose (step
>> by step progression), but source code lines are replaced by, e.g. :
>>
>> 72in varbayes.c
>>
>> There should be some way of "installing" the source code files, but I
>> did not find R-specific info there. Does someone have a clue for my
>> problem?
>
> This happens when you install a package from the tarball. The source is
> unpacked into a temporary directory which is then deleted. Try unpacking
> the source tarball yourself, and then installing from the unpacked
> directory, e.g.
>
> tar xfvz VBMix_0.2.17.tar.gz
> R CMD INSTALL VBMix
>
> Martyn
>
>> Thanks by advance,
>> Pierrick
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ---
> This message and its attachments are strictly confiden...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?
SUGGESTION:
Would it make sense if install.packages() and friends always use an
"ascii"(*) encoding when parse():ing R package source code files?
I believe this should be safe, because R code files should be in ASCII
[http://en.wikipedia.org/wiki/ASCII] and only in source-code comments
you may use other characters. This is from Section 'Package
subdirectories' in 'Writing R Extensions':
"Only ASCII characters (and the control characters tab, formfeed, LF
and CR) should be used in code files. Other characters are accepted in
comments, but then the comments may not be readable in e.g. a UTF-8
locale. Non-ASCII characters in object names will normally fail when
the package is installed. Any byte will be allowed in a quoted
character string but \u escapes should be used for non-ASCII
characters. However, non-ASCII character strings may not be usable in
some locales and may display incorrectly in others."
Since comments are dropped by parse(), their actual content does not
matter, and the rest of the code should be in ASCII.
(*) It could be that the specific encoding "ascii" is not cross
platforms. If so, is there another way to specify a pure ASCII
encoding?
BACKGROUND:
If a user/system sets the 'encoding' option at startup, it may break
package installations from source if the package has source code
comments with non-ASCII characters. For example,
$ mkdir foo; cd foo
$ echo "options(encoding='UTF-8')" > .Rprofile
$ R --vanilla
> install.packages("R.oo", type="source")
> install.packages("R.oo", type="source")
Installing package into 'C:/Users/hb/R/win-library/3.2'
(as 'lib' is unspecified)
--- Please select a CRAN mirror for use in this session ---
trying URL 'http://cran.at.r-project.org/src/contrib/R.oo_1.18.0.tar.gz'
Content type 'application/x-gzip' length 394545 bytes (385 KB)
opened URL
downloaded 385 KB
* installing *source* package 'R.oo' ...
** package 'R.oo' successfully unpacked and MD5 sums checked
** R
Warning in parse(outFile) :
invalid input found on input connection 'C:/Users/hb/R/win-library/3.2/R.oo/R/
R.oo'
** inst
** preparing package for lazy loading
Warning in parse(n = -1, file = file, srcfile = NULL, keep.source = FALSE) :
invalid input found on input connection 'C:/Users/hb/R/win-library/3.2/R.oo/R/
R.oo'
** help
[...]
(This can be an extremely time consuming task to troubleshoot,
particularly if reported to a package maintainer not having access to
the original system).
FYI, setting it only in the session is alright:
> options(encoding="UTF-8")
> install.packages("R.oo", type="source")
because install.packages() launches a separated R process for the
installation and it's only then the startup code becomes an issue.
TROUBLESHOOTING:
My understanding for the
Warning in parse(n = -1, file = file, srcfile = NULL, keep.source = FALSE) :
invalid input found on input connection 'C:/Users/hb/R/win-library/3.2/R.oo/R/
is that this happens when there is a non-ASCII character in one of the
source-code comments (*) with a bit pattern matching a multi-byte
UTF-8 sequence [http://en.wikipedia.org/wiki/UTF-8#Description]. For
instance, consider a source code comment with an acute accent:
> raw <- as.raw(c(0x23, 0x20, 0xe9, 0x74, 0x75, 0x64, 0x69, 0x61, 0x6e, 0x74,
> 0x0a))
> writeBin(raw, con="foo.R")
> code <- readLines("foo.R")
> code
[1] "# étudiant"
> options(encoding="UTF-8")
> parse("foo.R")
Warning message:
In readLines(file, warn = FALSE) :
invalid input found on input connection 'foo.R'
> options(encoding="ascii")
> parse("foo.R")
expression()
Reason for the "invalid input": The bit pattern for raw[3:5], is:
> R.utils::intToBin(raw[3:5])
[1] "11101001" "01110100" "01110101"
The first byte (raw[3]) matched special UTF-8 byte pattern "1110",
which according to UTF-8 should be followed by two more bytes with bit
patterns "10xx" and "10x"
[http://en.wikipedia.org/wiki/UTF-8#Description]. Since raw[4:5] does
not match those, it's an invalid UTF-8 byte sequence. So, technically
this does not happen for all comments using acute accents, but it's
very likely. More generally, a multi-byte UTF-8 sequence is expected
when byte pattern "11x" (>= 192 in decimal values) is encountered.
Looking http://en.wikipedia.org/wiki/ISO/IEC_8859, there are several
characters with this bit pattern for many "Latin-N" encodings, which
I'd assume is still in dominant use by many developers.
So, since options(encoding="UTF-8") was set at startup, that is also
the encoding that R tries to follow. My suggestion is that it seems
that R should be able to always use a pure-ASCII encoding when parsing
R code in packages, because that is what 'Writing R Extensions' says
we should use in the first place.
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?
On 11/12/2014 12:59 PM, Henrik Bengtsson wrote:
SUGGESTION:
Would it make sense if install.packages() and friends always use an
"ascii"(*) encoding when parse():ing R package source code files?
I think that would be a step backwards. It would be better to accept
other encodings. As an English speaker this isn't a big deal to me, but
users of other languages may want to have messages and variable names in
their native language, and ASCII might not be enough for that.
On the other hand, I think it's quite reasonable to require a declared
encoding if anything other than ASCII is used, and possibly to fail for
some encodings. It is probably also reasonable to at least warn when
non-ASCII characters are used in strings in packages on CRAN, as many
users can't display all characters.
Duncan Murdoch
I believe this should be safe, because R code files should be in ASCII
[http://en.wikipedia.org/wiki/ASCII] and only in source-code comments
you may use other characters. This is from Section 'Package
subdirectories' in 'Writing R Extensions':
"Only ASCII characters (and the control characters tab, formfeed, LF
and CR) should be used in code files. Other characters are accepted in
comments, but then the comments may not be readable in e.g. a UTF-8
locale. Non-ASCII characters in object names will normally fail when
the package is installed. Any byte will be allowed in a quoted
character string but \u escapes should be used for non-ASCII
characters. However, non-ASCII character strings may not be usable in
some locales and may display incorrectly in others."
Since comments are dropped by parse(), their actual content does not
matter, and the rest of the code should be in ASCII.
(*) It could be that the specific encoding "ascii" is not cross
platforms. If so, is there another way to specify a pure ASCII
encoding?
BACKGROUND:
If a user/system sets the 'encoding' option at startup, it may break
package installations from source if the package has source code
comments with non-ASCII characters. For example,
$ mkdir foo; cd foo
$ echo "options(encoding='UTF-8')" > .Rprofile
$ R --vanilla
> install.packages("R.oo", type="source")
> install.packages("R.oo", type="source")
Installing package into 'C:/Users/hb/R/win-library/3.2'
(as 'lib' is unspecified)
--- Please select a CRAN mirror for use in this session ---
trying URL 'http://cran.at.r-project.org/src/contrib/R.oo_1.18.0.tar.gz'
Content type 'application/x-gzip' length 394545 bytes (385 KB)
opened URL
downloaded 385 KB
* installing *source* package 'R.oo' ...
** package 'R.oo' successfully unpacked and MD5 sums checked
** R
Warning in parse(outFile) :
invalid input found on input connection
'C:/Users/hb/R/win-library/3.2/R.oo/R/
R.oo'
** inst
** preparing package for lazy loading
Warning in parse(n = -1, file = file, srcfile = NULL, keep.source = FALSE) :
invalid input found on input connection
'C:/Users/hb/R/win-library/3.2/R.oo/R/
R.oo'
** help
[...]
(This can be an extremely time consuming task to troubleshoot,
particularly if reported to a package maintainer not having access to
the original system).
FYI, setting it only in the session is alright:
> options(encoding="UTF-8")
> install.packages("R.oo", type="source")
because install.packages() launches a separated R process for the
installation and it's only then the startup code becomes an issue.
TROUBLESHOOTING:
My understanding for the
Warning in parse(n = -1, file = file, srcfile = NULL, keep.source = FALSE) :
invalid input found on input connection
'C:/Users/hb/R/win-library/3.2/R.oo/R/
is that this happens when there is a non-ASCII character in one of the
source-code comments (*) with a bit pattern matching a multi-byte
UTF-8 sequence [http://en.wikipedia.org/wiki/UTF-8#Description]. For
instance, consider a source code comment with an acute accent:
> raw <- as.raw(c(0x23, 0x20, 0xe9, 0x74, 0x75, 0x64, 0x69, 0x61, 0x6e, 0x74,
0x0a))
> writeBin(raw, con="foo.R")
> code <- readLines("foo.R")
> code
[1] "# étudiant"
> options(encoding="UTF-8")
> parse("foo.R")
Warning message:
In readLines(file, warn = FALSE) :
invalid input found on input connection 'foo.R'
> options(encoding="ascii")
> parse("foo.R")
expression()
Reason for the "invalid input": The bit pattern for raw[3:5], is:
> R.utils::intToBin(raw[3:5])
[1] "11101001" "01110100" "01110101"
The first byte (raw[3]) matched special UTF-8 byte pattern "1110",
which according to UTF-8 should be followed by two more bytes with bit
patterns "10xx" and "10x"
[http://en.wikipedia.org/wiki/UTF-8#Description]. Since raw[4:5] does
not match those, it's an invalid UTF-8 byte sequence. So, technically
this does not happen for all comments using acute accents, but it's
very likely. More generally, a multi-byte UTF-8 sequence is expected
when byte pattern "11x" (>= 192 in decimal values) is encountered.
Looking http://en.wikipedia.org/wiki/ISO/IEC_8859, there are several
characters with this
[Rd] Significant memory leak when using XML on Windows
Dear list, I'm sorry to keep coming back with this time and time again, but this bug is still not fixed even though the root cause of the issue has been around for 2-3 years now. And as the number of packages that depend on XML grows, I thought maybe this deserves some wider attention. I did my best to make reproduction of the issue as easy as possible: https://github.com/omegahat/XML/issues/4 http://goo.gl/aV17Lv But as I'm not familiar with C I'm kind of out of clues of what else do to. Duncan has been really dedicated and helpful so far, but unfortunately he seems to have too little time to really dig into this himself. So I thought I'd try and raise the attention of other developers that have the skills to fix this. Apparently, the issue is caused by the way the memory consumed by the underlying C-objects/pointers is released (or not released, for that matter). I'd so much appreciate if someone could have a look at this. If I can be of any help whatsoever, please let me know! Thanks and best regards, Janko [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?
On Thu, Dec 11, 2014 at 10:47 AM, Duncan Murdoch
wrote:
> On 11/12/2014 12:59 PM, Henrik Bengtsson wrote:
>>
>> SUGGESTION:
>> Would it make sense if install.packages() and friends always use an
>> "ascii"(*) encoding when parse():ing R package source code files?
>
>
> I think that would be a step backwards. It would be better to accept other
> encodings. As an English speaker this isn't a big deal to me, but users of
> other languages may want to have messages and variable names in their native
> language, and ASCII might not be enough for that.
Thanks for the feedback. While I'll probably agree with you that R
packages should support other source code encodings than ASCII, that
would require a change in the specifications and design. What I'm
proposing is (just) an adjustment to the implementation to meet the
current specs and design.
>
> On the other hand, I think it's quite reasonable to require a declared
> encoding if anything other than ASCII is used, and possibly to fail for some
> encodings. It is probably also reasonable to at least warn when non-ASCII
> characters are used in strings in packages on CRAN, as many users can't
> display all characters.
That would be a reasonable extension of the design, which would be
backward compatible with the current design, i.e. if encoding for the
source code is not declared, then it is assumed to be ASCII.
Source code comments are special, because by the current design
('Writing R Extensions'), it somehow leaves it open to use any type of
encoding. If I read it freely, it could even be that you can use
different encoding for different comments in the same file (which is
not unlikely to occur considered cut'n'paste and open-source
licenses). If other encodings are to be supported, then I see two
ways forward:
1. Have R completely ignore what's in the comments (what follows #
until the newline) such that encoding does not matter, or
2. require the same encoding for the source code comments as the rest
of the code.
As I see it, today's design falls (could fall?) under 1, but the
implementation does not go all the way to support it.
/Henrik
PS. It should be emphasized that this is about R packages. AFAIK, you
can already now source() code written in any encoding, e.g.
> raw <- as.raw(c(
+ 0xcf, 0x80, 0x20, 0x3c, 0x2d, 0x20, 0x70, 0x69, 0x0a,
+ 0x70, 0x72, 0x69, 0x6e, 0x74, 0x28, 0xcf, 0x80, 0x29, 0x0a
+ ))
> writeBin(raw, con="pi.R")
> source("pi.R", encoding="UTF-8")
[1] 3.141593
>
> Duncan Murdoch
>>
>>
>> I believe this should be safe, because R code files should be in ASCII
>> [http://en.wikipedia.org/wiki/ASCII] and only in source-code comments
>> you may use other characters. This is from Section 'Package
>> subdirectories' in 'Writing R Extensions':
>>
>> "Only ASCII characters (and the control characters tab, formfeed, LF
>> and CR) should be used in code files. Other characters are accepted in
>> comments, but then the comments may not be readable in e.g. a UTF-8
>> locale. Non-ASCII characters in object names will normally fail when
>> the package is installed. Any byte will be allowed in a quoted
>> character string but \u escapes should be used for non-ASCII
>> characters. However, non-ASCII character strings may not be usable in
>> some locales and may display incorrectly in others."
>>
>> Since comments are dropped by parse(), their actual content does not
>> matter, and the rest of the code should be in ASCII.
>>
>> (*) It could be that the specific encoding "ascii" is not cross
>> platforms. If so, is there another way to specify a pure ASCII
>> encoding?
>>
>>
>>
>> BACKGROUND:
>> If a user/system sets the 'encoding' option at startup, it may break
>> package installations from source if the package has source code
>> comments with non-ASCII characters. For example,
>>
>> $ mkdir foo; cd foo
>> $ echo "options(encoding='UTF-8')" > .Rprofile
>> $ R --vanilla
>> > install.packages("R.oo", type="source")
>>
>> > install.packages("R.oo", type="source")
>> Installing package into 'C:/Users/hb/R/win-library/3.2'
>> (as 'lib' is unspecified)
>> --- Please select a CRAN mirror for use in this session ---
>> trying URL 'http://cran.at.r-project.org/src/contrib/R.oo_1.18.0.tar.gz'
>> Content type 'application/x-gzip' length 394545 bytes (385 KB)
>> opened URL
>> downloaded 385 KB
>>
>> * installing *source* package 'R.oo' ...
>> ** package 'R.oo' successfully unpacked and MD5 sums checked
>> ** R
>> Warning in parse(outFile) :
>>invalid input found on input connection
>> 'C:/Users/hb/R/win-library/3.2/R.oo/R/
>> R.oo'
>> ** inst
>> ** preparing package for lazy loading
>> Warning in parse(n = -1, file = file, srcfile = NULL, keep.source = FALSE)
>> :
>>invalid input found on input connection
>> 'C:/Users/hb/R/win-library/3.2/R.oo/R/
>> R.oo'
>> ** help
>> [...]
>>
>> (This can be an extremely time consuming task to troubleshoot,
>> particularly if reported to a package maintainer not having access to
>> the original system
