Comments (11)
I can't replicate this; it works fine for me. Are you sure you have the
most recent rocker/r-base? (I'm on image 84bd0646c215)
On Fri, Oct 24, 2014 at 10:45 AM, Karl Forner [email protected]
wrote:
docker run -t rocker/r-base Rscript -e 'install.packages("seqinr")'
...
** R
Warning in parse(outFile) :
invalid input found on input connection '/usr/local/lib/R/site-library/seqinr/R/seqinr'
Error in parse(outFile) :
/tmp/RtmpCwXuIp/R.INSTALL1a409031a/seqinr/R/synonymous.R:69:0: unexpected end of input
67: })
68: usage = uco(sequence)[allcodons] #r
^
ERROR: unable to collate and parse R files for package ‘seqinr’
- removing ‘/usr/local/lib/R/site-library/seqinr’
The downloaded source packages are in
‘/tmp/RtmpitkBKh/downloaded_packages’
Warning message:
In install.packages("seqinr") :
installation of package ‘seqinr’ had non-zero exit statusThis seems to be an encoding issue, there's a french accent at
seqinr/R/synonymous.R:69:0.
But I wonder: could we not just set the same setting than the CRAN check
process ?Thanks.
—
Reply to this email directly or view it on GitHub
#58.
Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/
from rocker.
Works for me also. Maybe you need to do a docker pull rocker/r-base
?
from rocker.
Same here. Makes you 0 for 3. I'm closing this.
from rocker.
Sorry, I did Not pull. Thought docker run did.
from rocker.
FYI, today I received a very similar issue HenrikBengtsson/R.utils#3 related to installing R.utils on CRAN from source. Interestingly, this is also from a user using docker ("ubuntu:14.04 inside boot2docker VM"). Myself, I fail to reproduce the installation errors on Linux and Windows under various locale settings.
My working hypothesis is that this has to do with non-ASCII ("7 bit") characters in source-code comment. Note that non-ASCII is allowed in source-code comments, but not in code (http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-subdirectories);
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 normally10 fail when the package is installed. Any byte will be allowed in a quoted character string but \uxxxx 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.
What "readable" means is not clear, but I assume it means "human readable". This is why I conclude non-ASCII characters are allowed in comments.
In the R.utils case, I found one source file containing é
(0xE9) in comments. Removing this "offending" comment, the package installs correctly, cf. HenrikBengtsson/R.utils#3.
Finding this thread, I checked seqinr 3.1.2. Sure enough, in R/synonymous.R, there is a comment containing non-ASCII characters:
usage = uco(sequence)[allcodons] #ré-ordonner selon NCBI
In this case, it's also a é
(0xE9) character. In case you wonder, these two source codes are not using UTF-8 or UTF-16 and there is no BOM sequence or similar. They are plain 8-bit ASCII files.
Keep searching, I found rocker issue #40, which reports on a similar issue with the bit package, and that package also contains comments with non-ASCII character, e.g.
"# (c) 2010 Jens Oehlschl\xe4gel"
Now look at this:
# Create a small foo.R file with a non-ASCII comment
> bfr <- as.raw(c(0x23, 0x20, 0x61, 0xe9, 0x65, 0x62, 0x0a))
> writeBin(bfr, con="foo.R")
> readLines("foo.R")
[1] "# a\xe9eb"
> Sys.setlocale("LC_CTYPE", "C")
[1] "C"
> parse("foo.R")
expression()
> Sys.setlocale("LC_CTYPE", "en_US.UTF-8")
[1] "en_US.UTF-8"
> parse("foo.R")
expression()
Warning message:
In grepl("\n", lines, fixed = TRUE) :
input string 1 is invalid in this locale
I don't know if using the "C"
locale is a solution or just a coincidence, because even with "en_US.UTF-8"
I cannot reproduce the original installation issues. Related, in tools:::.install_package_code_files()
, there is an effort of using the "C"
locale for collating the source files.
I see that @eddelbuettel maybe onto something in Issue #40:
I'd look at what the base R tools package does. By allowing for old-world encodings, you may need to set some explicit overrides.
To conclude, a workaround for package developers seems to use only (7-bit) ASCII characters throughout all source code files - also in comments.
I leave it at this for now; maybe someone else will find this comment and further narrow the installation problem(s).
- And another day passed troubleshooting.
from rocker.
Nice work.
It sort of rings bell from when we did cran2deb (ie automated .deb creation of all CRAN packages; we stopped a few years but the idea lives on in eg http://debian-r.debian.net by Don) and I think I had to once or twice override exotic chars. I am pretty sure one package by Jens was among them.
I generally think it is not worth putzing with this. I think I have also seen R itself use "C" as a local prior to some other system()
calls.
Quick check confirms:
edd@max:~/svn/r-devel/src/library/tools$ grep "\"C\"" R/* | wc -l
28
edd@max:~/svn/r-devel/src/library/tools$
Not worth arguing with, is it?
from rocker.
It's getting late and brain is shutting down so I'm not sure what you mean with you're last comment; are you saying there is an inherent problem with how encoding in handled in R and all those (28) cases indicates there are lots of ad hoc workarounds in R? Or maybe you mean something else.
In tools:::.install.packages()
, I found the following comment interesting:
## This cannot be done in a C locale
res <- try(.install_package_code_files(".", instdir))
if (inherits(res, "try-error"))
pkgerrmsg("unable to collate and parse R files", pkg_name)
Someone already thought about this and decided against using the C
locale! It would be nice if one could conclude if this is something that should/could be fixed in R or not.
from rocker.
So, after finding e260a42, I can reproduce the installation issues reported here (#40 and #58) and elsewhere (HenrikBengtsson/R.utils#3) myself. Is it your understanding that it is all due to setting the encoding at startup (which is always used by install.packages()
unless you do some tricks)?
from rocker.
I don't know. I usually found ways to avoid the issue.
If you think it is an R issue, you should take it up on r-devel. To me, the "R installation is the spec" so if a package breaks, I change the package.
from rocker.
I ended up posting 'SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?' to R-devel.
from rocker.
Saw it, good move. Like the follow-up as well ("hell yeah, in principle other charsets ought to work") but maybe that needs more work.
from rocker.
Related Issues (20)
- Migrating from Dockerhub? HOT 3
- Container for RStudio (not server) HOT 1
- MRAN repository snapshots were deleted - Failing jobs because packages can't be found anymore HOT 5
- docker v18 & packages repositories & rocker's images HOT 5
- unable to load shared object
- Update results in deletion of all install package...
- installation testing fails HOT 1
- r: error while loading shared libraries: libR.so: cannot open shared object file: No such file or directory
- Docker image r-base:4.2.1 not reproducible HOT 4
- Installing unstable apt packages? HOT 4
- Local Zotero Integration? HOT 3
- R session terminated HOT 1
- latest r-base breaks install of `curl` package HOT 8
- xz-utils backdoor HOT 4
- Potential high vulnerability in r-base:4.3.1 HOT 3
- Installing packages fails due to broken openssl package in debian testing HOT 2
- Alternative Methods of Extending Images? HOT 5
- update 'latest' version to 4.4.0 RDS security flaw HOT 2
- New `usrmerge` issues. HOT 5
- 502 Returned by Rstudio Server when executing 'client_init' HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rocker.