I had this piece of code that was working several months ago but not anymore now. I changed the directory but the data is the same.
My issue is that the cache is never saved. I tried different methods: either dep_prev(), dep_auto() + autodep or dependson and different debugging approaches but nothing seems to work. The computation is still performed at each run and there is nothing in the cache folder.
Another issue that appeared is that my figures don´t appear anymore into my pdf file. They pop out when the R code is executed but they are not saved (the problem is probably linked to the cache problem).
In my code I setup everything in the first chunk then I don´t add any options in the following chunks. Here is the code of my first chunk:
<<setupKnitr, include=FALSE, cache=FALSE>>=
library(knitr)
## set global chunk options
opts_chunk$set(fig.path='figures_knitR/', cache.path='cache/', fig.align='center', fig.show='asis', par=TRUE, tidy = TRUE, cache = TRUE, autodep=T, fig.keep='all', dev='tikz', echo = TRUE, eval = TRUE)
opts_knit$set(output.dir = getwd())
dep_auto()
options(formatR.arrow=TRUE, width=68, digits=4)
options(tikzDefaultEngine = 'pdftex')
#
Also I found something strange when looking at the dep_auto function: it uses the functions valid_path and parse_objects that are not known in my R session which might be the cause of the problem. And I cannot find the package from which they originates.
here is my sessionInfo
> sessionInfo()
R version 3.2.0 (2015-04-16)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu precise (12.04.5 LTS)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
other attached packages:
[1] jerdev_0.1 knitr_1.10.5
loaded via a namespace (and not attached):
[1] tools_3.2.0 tcltk_3.2.0
Thank you very much for your help!
Related
I have a problem when running R scripts on a Unix cluster as a batch job. The issue is when trying to load libraries in the environment, R cannot find the library. I'll give you an example. I'll use a basic R script names sess.R:
print(.libPaths())
library("gtools")
print(sessionInfo())
If I just run this script from the command line using the command:
$ Rscript sess.R
I get the following output:
[1] "/usr/lib64/R/library" "/usr/share/R/library"
R version 3.2.3 (2015-12-10)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: CentOS release 6.6 (Final)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets base
other attached packages:
[1] gtools_3.5.0
The library "gtools" is correctly loaded, script is working. however if I write a simple batch job (I will include in the job a couple of optional parameters including an error and output file) like:
#!/bin/bash
#SBATCH --output=sess.out
#SBATCH --error=sess.err
Rscript sess.R
The job fails after a second. The two output files I get are of course sess.out and sess.err.
Sess.out contains the library directory:
[1] "/usr/lib64/R/library" "/usr/share/R/library"
which seem to be the same as when running Rscript from the command line, so no error there. However there is no printing of the Info Session since the script has been terminated. The sess.err file contains the following error:
Error in library("gtools") : there is no package called ‘gtools’
Execution halted
There, it seems like R cannot find gtools in this situation, even if the library path is the same...
Am I missing something? Is there an error I don't see somewhere? Or is it a problems of cluster settings?
We have a problem using RMarkdown on multiple operating systems.
Initially, an .Rmd file is created on a Linux system (Ubuntu 12.04 LTS) and then pushed to a GitHub repo.
It can be compiled ("knitted") without problems on this system.
It is then pulled on a Windows 7 machine with RStudio installed.
There, when trying to compile, the following error shows up:
Error in yaml::yaml.load(front_matter) :
Reader error: invalid leading UTF-8 octet: #FC at 66
Calls: <Anonymous> -> parse_yaml_front_matter -> <Anonymous> -> .Call
Execution halted
When creating another .Rmd file on the Windows system, it works flawlessly.
When creating another .Rmd file on the Windows system, and copying everything but the first few lines of the "problematic" file to the other .Rmd file, and compiling this file, it works flawlessly.
I compared both files in HEX (in Sublime) on both operating systems: They are EXACTLY the same.
Has somebody else seen that error before?
Update: It seems as if a German Umlaut ("ü") is causing the problem, as its UTF-8 "Escaped Unicode" is \uFC, according to http://www.endmemo.com/unicode/unicodeconverter.php
In general, it seems that Unicode is not correctly recognized by either R, RStudio or knitr on Windows. When I type in some Umlauts in a new .Rmd file, and knit it, I get output such as "öää". In RStudio > Tools > Global options, I set the Default text encoding to "UTF-8". And I also did that for R, in the RProfile.site file (options(encoding="UTF-8")).
Update 2: library(rmarkdown); sessionInfo() gives
R version 3.1.2 (2014-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=German_Switzerland.1252 LC_CTYPE=German_Switzerland.1252 LC_MONETARY=German_Switzerland.1252
[4] LC_NUMERIC=C LC_TIME=German_Switzerland.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] rmarkdown_0.4.2
loaded via a namespace (and not attached):
[1] digest_0.6.8 htmltools_0.2.6 tools_3.1.2
on Windows 7, whereas, on Ubuntu, it is:
R version 3.1.2 (2014-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] rmarkdown_0.3.10
loaded via a namespace (and not attached):
[1] digest_0.6.8 htmltools_0.2.6 tools_3.1.2
I already suspect the problem to be the diverging locale... how do I fix this?
I am extremely late to this, but I solved the issue by changing the options encoding back to "native":
options(encoding="native")
And changing the default windows encoding to UTF-8 (which opened the pandora box of a non-negligible number of other issues related to the encoding of other programs; so, treat with caution).
I'm generating an html report from a knitr::spin marked up document
1) It works doing the following
> spin("document.R")
Process the resulting .md file in Rstudio by clicking the "Preview HTML" button, and then the "view the webpage with the system web browser" button.
2) However, the html file that is generated by spin('document.R') directly does not display LaTeX equations.
This is because (1) generates the MathJax scripts tags, but (2) does not.
Any ideas why not?
R 2.15.1> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] markdown_0.5.4 knitr_1.2
loaded via a namespace (and not attached):
[1] digest_0.6.3 evaluate_0.4.3 formatR_0.7 stringr_0.6.2 tools_2.15.1
knitr::spin() calls markdown::markdownToHTML(), which does include MathJax when math expressions are present. I cannot reproduce the problem with a minimal example:
#' A math expression $\alpha+\beta$. Below is a code chunk:
x <- 5
y <- 10
I can see the math expression after I save it as test.R and run spin('test.R').
I am updating a package qdap that had a single note on CRAN in its previous build, which was resolved.
In the qdap development version, under R 2.15.3, using --as-cran and --resave-data=best, I get the following note:
* checking R code for possible problems ... NOTE
Segmentation fault
Why is this segfault occurring (I'm somewhat new to Linux)? How can I find it? I googled this for sometime but I couldn't figure out what the problem is. I gather there's some sort of problem in my code but...
On Windows I get no notes.
I can provide more info if needed (though the GitHub repo is available).
Session Info:
R version 2.15.3 (2013-03-01)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8
[4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] pacman_0.2.0 XML_3.9-4
loaded via a namespace (and not attached):
[1] tools_2.15.3
Edit: Solved, the error dissapeared whe I updated the package.
I'm getting an error when working with just one summary statistic. Is there any reason why this is happening? Is there a way to get around this problem?
Thanks
library(abc)
data(human)
target<-(stat.voight["hausa",])[,1]
sumstat<-(stat.3pops.sim)[,1]
modsel.ha <- postpr(target, models, sumstat, tol=.05, method="mnlogistic")
#Error in eval(predvars, data, env) : numeric 'envir' arg not of length one
Aditional details: no other objects were loaded (to my knowledge) as the R session had just been started. When I use two summary statistics instead of just 1 postpr works fine.
Session details as per request from nograpes
sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8
[4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=de_DE.UTF-8
[7] LC_PAPER=C LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] abc_1.5 locfit_1.5-7 quantreg_4.79 SparseM_0.96 nnet_7.3-4 MASS_7.3- 21
loaded via a namespace (and not attached):
[1] grid_2.15.1 lattice_0.20-10 tools_2.15.1
The problem turned out to be solved when I upgraded abc. Surely it was a bug of an old version of the package.