I am trying to use R-Bookdown for building joint .pdf and html site. According to the manual it should be possible to integrate Julia code. However R does not find the Julia sys.so. The problem is explained here: https://github.com/Non-Contradiction/JuliaCall/issues/99 without any solution provided.
The command:
Rscript -e "bookdown::render_book('index.Rmd', 'bookdown::gitbook')"
Gives this result:
Julia version 1.0.3 at location /usr/bin will be used.
ERROR: could not load library "/usr/lib/x86_64-linux-gnu/../bin/../lib/x86_64-linux-gnu/julia/sys.so"
/usr/lib/x86_64-linux-gnu/../bin/../lib/x86_64-linux-gnu/julia/sys.so: cannot open shared object file: No such file or directory
Something is obviously wrong in the construction of the search path for sys.so. Appreciating any assistance!
Related
I want to optimize my process for building a package. I have in pckgname/src some fortran code (f90):
pckgname/src/FortranFile1.f90
pckgname/src/FortranFile2.f90
I am under RStudio. When I build the package, it creates the src-i386 and src-x64 folders, inside which executable files in .o are produced
pckgname/src-i386/FortranFile1.o
pckgname/src-i386/FortranFile2.o
pckgname/src-x64/FortranFile1.o
pckgname/src-x64/FortranFile2.o
then dll files are produced into each of these folders from the .o files:
pckgname/src-i386/dllname.dll
pckgname/src-x64/dllname.dll
thereafter if I want to check the code successfully, I need to manually copy paste the dll into these two folders (in the previous version of the question i wrote code instead of dll which might have led to misunderstandings)
pckgname/inst/libs/x64/dllname.dll
pckgname/libs/X64/dllname.dll
My question is: is it normal that I have to do this or is there a shorter way without having to copy paste by hand dllname.dll
into these two folders? It could be indeed a source of error.
NB: If i don't copy the dlls into the said folders I get the following error messages (translated from the French):
Error in inDL(x, as.logical(local), as.logical(now), ...) :
impossible to load shared object 'C:/Users/username/Documents/pckgname/inst/libs/x64/dllname.dll':
LoadLibrary failure: The specified module can't be found
Error in inDL(x, as.logical(local), as.logical(now), ...) :
impossible to load shared object 'C:/Users/username/Documents/pckgname/libs/x64/dllname.dll':
LoadLibrary failure: The specified module can't be found.
[...]
`cleanup` is deprecated
The short answer
Is it normal that I have to do this?
No. If path/to/package is the directory you are developing your package in, and you have everything set up for your package to call your Fortran subroutines correctly (see "The long answer"), you can run
R CMD build path/to/package
at the command prompt, and a tarball will be constructed for you with everything in the right place (note you will need Rtools for this). Then you should be able to run
R CMD check packagename_versionnumber.tar.gz
from the command prompt to check your package, without any problems (stemming from the .dll files being in the wrong place -- you may have other problems, in which case I would suggest asking a new question with the ERROR, WARNING, or NOTE listed in the question).
If you prefer to work just from R, you can even
devtools::check("path/to/package")
without having to run devtools::build() or R CMD build ("devtools::check()... [b]undles the package before checking it" -- Hadley's chapter on checking; see also Karl Broman's chapter on checking).
The long answer
I think your question has to do with three issues potentially:
The difference between directory structure of packages before and after they're installed. (You may want to read the "What is a package?" section of Hadley's Package structure chapter -- luckily R CMD build at the command prompt or devtools::build() in R will take care of that for you)
Using INSTALL vs. BUILD (from the comments to the original version of this answer)
The proper way to set up a package to call Fortran subroutines.
You may need quite a bit of advice on the process of developing R packages itself. Some good guides include (in increasing order of detail):
Karl Broman's R package primer
Hadley Wickham's R packages
The Writing R Extensions manual
In particular, there are some details about having compiled code in an R package that you may want to be aware of. You may want to first read Hadley's chapter on compiled code (Broman doesn't have one), but then you honestly need to read most of the Writing R Extensions manual, in particular sections 1.1, 1.2, 1.5.4, and 1.6, and all of chapters 5 and 6.
In the mean time, I've setup a GitHub repository here that demonstrates a toy example R package FortranExample that shows how to correctly setup a package with Fortran code. The steps I took were:
Create the basic package structure using devtools::create("FortranExample").
Eliminate the "Depends" line in the DESCRIPTION, as it set a dependence on R >= 3.5.1, which will throw a warning in check (I have now also revised the "License" field to eliminate a warning about not specifying a proper license).
Make a src/ directory and add toy Fortran code there (it just doubles a double value).
Use tools::package_native_routine_registration_skeleton("FortranExample") to generate the symbol registration code that I placed in src/init.c (See Writing R Extensions, section 5.4).
Create a nice R wrapper for using .Fortran() to call the Fortran code (placed in R/example_function.R).
In that same file use the #' #useDynLib FortranExample Roxygen tag to add useDynLib(FortranExample) to the NAMESPACE file; if you don't use Roxygen, you can put it there manually (See Writing R Extensions 1.5.4 and 5.2).
Now we have a package that's properly set up to deal with the Fortran code. I have tested on a Windows machine (running Windows 8.1 and R 3.5.1) both the paths of running
R CMD build FortranExample
R CMD check FortranExample_0.0.0.9000.tar.gz
from the command prompt, and of running
devtools::check("FortranExample")
from R. There were no errors, and the only warning was the "License" issue mentioned above.
After cleaning up the after-effects of running devtools::check("FortranExample") (for some reason the cleanup option is now deprecated; see below for an R function to handle this for you inspired by devtools::clean_dll()), I used
devtools::install("FortranExample")
to successfully install the package and tested its function, getting:
FortranExample::example_function(2.0)
# [1] 4
The cleanup function I mentioned is
clean_source_dirs <- function(path) {
paths <- file.path(path, paste0("src", c("", "-i386", "-x64")))
file_pattern <- "\\.o|so|dll|a|sl|dyl"
unlink(list.files(path = paths, pattern = file_pattern, full.names = TRUE))
}
No, it is not normal and there is a solution to this problem. Make use of Makevars.win. The reason for your problem is that .dlls are looking for dependencies in places defined by environment variable PATH and relative paths defined during the linking. Linking is being done when running the command R CMD INSTALL as it is stated in Mingw preferences plus some custom parameters defined in the file Makevars.win (Windows platform dependent). As soon as the resulting library is copied, the binding to the places where dependent .dlls were situated may become broken, so if you put dlls in a place where typically dependent libraries reside, such as, for instance, $(R_HOME)/bin/$(ARCH)/,
cp -f <your library relative path>.dll $(R_HOME)/bin/$(ARCH)/<your library>.dll
during the check R will be looking for your dependencies specifically there too, so you will not miss the dependencies. Very crude solution, but it worked in my case.
I am interested in providing a command line interface to an R package called Slidify that I am authoring. It uses Rscript and I think that would make it cross-platform. The scripts are stored in the subdirectory inst/slidify. In order to use the script from any directory, I added its path to my .bash_profile as I am on a Mac.
My question is
How should I handle installation of the script in an automated cross-platform way?
How can I make sure that the file permissions are retained in this process?
What should the shebang line for the script be? I am currently using
#!/usr/bin/Rscript --vanilla --slave
I would appreciate pointers on how to handle this and any examples of R packages that already do it. Just to make sure, I am clear on how this would work, a user would be able to generate a slide deck from slides.Rmd by just running slidify generate slides.Rmd from the command line.
UPDATE:
Here is how I install it on a Mac from the command line. I use the excellent sub library by 37 signals to create the scripts.
echo "$(path/to/clidir/slidify init -)" >> ~/.bash_profile
exec bash
Two follow up questions
Can I package these commands into an R function install_slidify_cli?
How can I mirror these commands for Windows users?
Lovin' slidify so would be glad to help.
But in short, you can't.
R packages simply cannot install outside of $R_HOME or the chosen library folder. Ship the script in the package, and tell users to copy it. If there was a better way, out littler package with predecessor / alternative to Rscript would long have used it, and roxygen / roxygen2 would also have shipped something.
I made a small change to the source code of the igraph package because I want to implement the forest fire method based on the breadth first search method.
I used Rtools to build the package and followed the steps as this link. But, I got a error message:
foreign-graphml.c:38:29: fatal error: libxml/encoding.h: No such file or directory.
I tested using the source code, but still had the same error.
I also used the install.packages() method. It still showed the same error.
Update:
I downloaded the Libxml2 and set the bin location to the path. The libxml/encoding.h file is actually in the 'include' folder. Why does this error show?
You can build it at http://win-builder.r-project.org/upload.aspx, just don't forget to change the DESCRIPTION file to include your email address as maintainer.
It is actually quite tricky to build it because Rtools has some fixed (?) paths and it is looking for libraries at specific places, so you need to put them there. We build it with something like
...
if ! (subst | grep -qi ^d:); then
subst d: c:\\
fi
pkg=`ls igraph*.tar.gz`
zip=`echo $pkg | sed 's/.tar.gz/.zip/'`
rfile="r-win/${zip}"
OLDPATH=$PATH
PATH=/cygdrive/c/Program\ Files/R/R-default/bin:/cygdrive/c/Rtools/bin:/cygdrive/c/Rtools/gcc-4.6.3/bin:$PATH
LIB_XML=c:/RCompile/CRANpkg/extralibs64/local R CMD INSTALL -l . $pkg
zip -r ${zip} igraph
PATH=$OLDPATH
...
This uses a cygwin shell. You can get the extra libraries here:
http://www.stats.ox.ac.uk/pub/Rtools/libs.html
I am interested in providing a command line interface to an R package called Slidify that I am authoring. It uses Rscript and I think that would make it cross-platform. The scripts are stored in the subdirectory inst/slidify. In order to use the script from any directory, I added its path to my .bash_profile as I am on a Mac.
My question is
How should I handle installation of the script in an automated cross-platform way?
How can I make sure that the file permissions are retained in this process?
What should the shebang line for the script be? I am currently using
#!/usr/bin/Rscript --vanilla --slave
I would appreciate pointers on how to handle this and any examples of R packages that already do it. Just to make sure, I am clear on how this would work, a user would be able to generate a slide deck from slides.Rmd by just running slidify generate slides.Rmd from the command line.
UPDATE:
Here is how I install it on a Mac from the command line. I use the excellent sub library by 37 signals to create the scripts.
echo "$(path/to/clidir/slidify init -)" >> ~/.bash_profile
exec bash
Two follow up questions
Can I package these commands into an R function install_slidify_cli?
How can I mirror these commands for Windows users?
Lovin' slidify so would be glad to help.
But in short, you can't.
R packages simply cannot install outside of $R_HOME or the chosen library folder. Ship the script in the package, and tell users to copy it. If there was a better way, out littler package with predecessor / alternative to Rscript would long have used it, and roxygen / roxygen2 would also have shipped something.
I am writing a package in R and I would appreciate some example bash code to process the Rd files to latex and then to pdf.
It is in the directory ~/mypkg/dev/. I have generated the file structure and Rd templates.
from ~/mypkg/dev/man, I have tried
R CMD Rdconv -o mypkg-package.tex --type=latex mypkg-package.Rd
mypkg-package.tex file is generated, but
pdflatex mypkg-package.tex
generates tex without any preamble.
I have read the documentation in "Writing R extensions" and "R CMD Rdconv --help" on this subject, but no examples are provided.
Thank you
There are two issues here:
First, the Rdconv command only transforms one Rd file at a time; your question suggests that you want the full manual.
Second, the Rd2dvi command is your friend. I just ran the following on a local package:
R CMD Rd2dvi --pdf --title='Test of foo' -o /tmp/foo.pdf man/*.Rd
That should be what you asked for.
Try this. It worked for me.
found from Making an R package PDF manual using devtools
pack <- "name_of_your_package"
path <- find.package(pack)
system(paste(shQuote(file.path(R.home("bin"), "R")),"CMD", "Rd2pdf", shQuote(path)))
0. From question, it is assumed that you have .Rd files.
You may have obtained these .Rd files via roxygen package or some other ways. You need .pdf of your package. One way to do this is from Windows's command line.
1. Open Windows Command Prompt (in Administrator mode, if possible).
Start - type "cmd" - (optional: right click the appearing icon - Run as administrator)
2. Pass to the R's current working directory (it can be found via "getwd()" in R's console) in the command propmt. R's current working directory contains the folder with your package source.
cd C:\Users\erdogan\Documents\Revolution
3. For the sake of argument, say the package folder was called "causfinder". Run the following command in Windows command prompt:
(be sure that you have not got any causfinder.pdf in R's working directory (You may have obtained some R-development-incompatible causfinder.pdf with some other ways outside R). If there exists, delete causfinder.pdf first.
Otherwise, you get this error: "file 'causfinder.pdf' exists; please remove it first")
R CMD Rd2pdf causfinder/
This command performs .Rd --> LateX --> .pdf process automatically. You obtain causfinder.pdf in R's working directory.
This is further described in the manual on Writing R Extensions under the section on "Processing documentation files"
I have created a basic bash function, so I can just run rdoc from my command line. It generates the Rd files, creates the pdf, and opens it. I only use it for testing, not for creating the final documentation. You can add it by adding the following function to your .bashrc (or whichever you use) file
rdoc() {
echo -e "devtools::document()" | R --no-save
rm /tmp/rdoc.pdf
R CMD Rd2pdf -o /tmp/rdoc.pdf man/*.Rd
open /tmp/rdoc.pdf
}