I built my own R library mlib001, and did Build/Build source package, which produced tar file in that libs directory. Now I can reference that library from another main/test R script file with:
library(mlib001)
I also went to Tools in that main code screen, Install Packages, Install from Package archive, then brows to the tar file for that library mlib001, import - all gets loaded fine. I then run the main code with CTRL-ALT-R, it runs fine and invokes functions from mlib001 and all completes ok. But if I set breakpoint in the main code to step into the function from the library, once I do step in I get the message that source code is not available: "Debug location is approximate because the source code is not available". How do I resolve this so I can step into the functions with the debugger? Thanks
I'm not sure if this is applicable but I had similar problems because I copied some comments written elsewhere that included some scandinavian characters, like "ä".
Related
I'm trying to install wholebrain by Daniel Fürth, following the instructions on the macosX install page (available here). I am running MacOS Big Sur 11.5.2, R 4.1.2, and RStudio 2021.09.1.
Unfortunately, the program is not straight-forward to install and requires significant developer tools to work correctly. I'm not a programmer and have almost no experience with coding, so I've been mucking through the instructions for two days now trying to get the install to work correctly and I'm firmly stuck on the final step.
In RS, when I run, devtools::install_github("tractatus/wholebrain", INSTALL_opts=c("--no-multiarch")) I get the following error message:
/bin/sh: pkg-config: command not found filter.cpp:9:10: fatal error: 'fftw3.h' file not found #include "fftw3.h" ^~~~~~~~~ 1 error generated. make: *** [filter.o] Error 1 ERROR: compilation failed for package ‘wholebrain’
I have been trying to figure out what this means for quite awhile now and I think I've narrowed it down to R is not reading the location of the fftw header file from where it was installed by Homebrew. (I could be totally wrong, again- not a programmer)
From what I understand, Homebrew always installs under opt/homebrew/cellar. And, in fact, in there is the compiled fftw program with the needed "fftw3.h" file. But for some reason, RStudio is not able to find and read the file in that location.
From random googling and reading of other posted issues, I think that RStudio may expect the file to be under usr/local/include. Can I just copy and paste the header file into that folder? Or will I be screwing something up if I do that? I am totally intimidated by fftw's description of manual compilation so I don't really want to attempt that. Is there a way to change where R is looking for that header file? I already set my wd to "/" so shouldn't R be able to access any folder on my computer?
I want to post an answer here for anyone who comes after me with the same issue. It came down to RStudio not recognizing the programs Homebrew had installed because it wasn't reading the file location where Homebrew saves them. Homebrew always installs programs in /opt/homebrew/... Here is what I had to do:
In RStudio, open your Renviron file using this command: usethis::edit_r_environ()
In the file that opens (which for me was totally blank), type: PATH=/opt/homebrew/bin:${PATH}, or whatever your particular path you want prepended to the Renviron path is.
Quit RStudio and, when prompted, save. Re-open RStudio and run Sys.getenv("PATH") to check. Your new path (in the example above, '/opt/homebrew/bin') should now be prepended to the list of paths that RStudio will use when looking for programs/files. For me this now looks like /opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/Library/Apple/usr/bin:/Applications/RStudio.app/Contents/MacOS/postback
Finally, I want to say thank you very much to Mark Setchell who really helped point me in the correct direction!
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 used packrat (v 0.4.8.-1) to to create a snapshot and bundle of the R package dependencies that go along with the corresponding R code. I want to provide the R code and packrat bundle to others to make the work I am doing (including the R environment) fully reproducible.
I tested unbundling using a different computer from the one I used to write R code and create the bundle. I opened an R code file in R studio, and called library(packrat) to load packrat (also v 0.4.8-1). I then called packrat::unbundle(bundle = "directory", where = "directory"), which unbundled successfully. But subsequently calling packrat::restore() gave me the error "This project has not yet been packified. Run 'packrat::init()' to init packrat". It seems like init() should not be necessary because I am not trying to create a new snapshot, but rather utilize the one in the bundle. The packrat page (https://rstudio.github.io/packrat/) and CRAN provide very little documentation about unbundling to help troubleshoot this, or that I could point users of my code to for instructions (who likely will be familiar with R, but may not have used packrat).
So, can someone please provide clear step-by-step instructions for how users of a bundled snapshot should unbundle, and then use that saved snapshot to run a R code file?
After some experimenting, I found an approach that seems to have worked so far.
I have provided users with three files:
-tar.gz (packrat bundle file)
-unbundle.R (R code file that includes a library statement to load
the packrat library, and the unbundle command for the tar.gz file)
-unbundle_readme.txt
The readme file includes instructions similar to those below, and so far users have been able to run R code using the package dependencies. The readme file tells users about requirements (R, R studio, packrat, R package development prerequisites (Rtools for Windows, XCode for Mac)), and includes output of sessionInfo() to document R package versions that the R code should use after instructions are followed. In the example below 'code_folder' refers to a folder within the tar.gz file that contains R. code and associated input files.
Example unbundle instructions:
Step 1
Save, but do not expand/unzip, the tar file to a directory.
Problems with accessing the saved package dependencies
are more likely when a program other than R or R studio
is used to unbundle the tar file.
If the tar file has already been expanded, re-save the
tar file to a new directory, which should not be a the same
directory as the expanded tar file, or a subdirectory of
the expanded tar file.
Step 2
Save unbundle.R in the same directory as the tar file
Step 3
Open unbundle.R using R studio
Step 4
Execute unbundle.R
(This will create a subfolder ‘code_folder’.
Please note that this step may take 5-15 minutes to run.)
Step 5
Close R studio
Step 6
Navigate to the subfolder ‘cold_folder’
Step 7
Open a R script using R studio
(The package library should correspond to that listed below.
This will indicate R studio is accessing the saved package
dependencies.)
Step 8
Execute the R code, which will utilize the project package library.
After the package library has been loaded using the above
steps, it is not necessary to re-load the package library for each
script. R studio will continue to access the package dependencies
for each script you open within the R studio session. If you
subsequently close R-studio, and then open scripts from within
the unbundle directory, R studio should still access the
dependencies without requiring re-loading of the saved package
snapshot.
I'm trying to use the SemiMarkov package and I want to change one small line of code in there. I've done some digging via:
getAnywhere("semiMarkov")
& I've identified that I want to change this line:
hessian <- diag(ginv(hessian(V, solution)))
to try something like:
hessian <- diag(ginv(pracma::hessian(V, solution)))
How do I go about this? Do I need to rebuild the package from scratch, and if so do I need rTools etc for this, or is there a simple-ish workaround (I'm a relevant R novice)? I've done some searching online and can't find anything obvious. Any ideas/pointers gratefully appreciated.
If you'd like to simply test out the effect of that change in an interactive R session, you can do so using trace(). Here's how:
Type trace("semiMarkov", edit=TRUE)
In the text editor that that launches, edit the line of interest.
Save the modified file.
Close the text editor
Back in R, use the modified function.
Linux environment
Starting with downloading the package source from CRAN.
This is the landing page: https://cran.r-project.org/web/packages/SemiMarkov/index.html
This is the package source: https://cran.r-project.org/src/contrib/SemiMarkov_1.4.2.tar.gz
Download and extract the source:
wget https://cran.r-project.org/src/contrib/SemiMarkov_1.4.2.tar.gz
tar -xvzf SemiMarkov_1.4.2.tar.gz
This should result in a directory named SemiMarkov. Open up the source (cd SemiMarkov), and modify as necessary.
Next, build the changes:
cd ..
R CMD build SemiMarkov/
This will result in a new archive file named SemiMarkov_1.4.2.tar.gz.
Lastly, install your modified archive:
R CMD INSTALL SemiMarkov_1.4.2.tar.gz
Windows environment
I'm less familiar with the Windows platform. *nix tooling is available in Cygwin, but it's painful. Instead, as Josh O'Brien points out, you should follow the Windows-specific instructions in the R Installation and Administration manual.
I'm at a loss as to how to install the RBloomberg package. The only source for the files seems to be GitHub. The offered zip file is called blpwrapper-master.zip which embeds an rbloomberg folder. When I try to install the zip file (in RStudio), I get an error message that it cannot open a compressed file. I rezipped just the rbloomberg folder, but that led nowhere either. How does one go about this?
In general things can be installed from Github using the devtools package. For example:
library("devtools")
install_github("username/packagename")
I don't know who authors so Rbloomberg, but you can swap in the appropriate Github username in the above.
Note: Sometimes this won't work because a developer uses a non-traditional .git directory structure, but it should work in most cases. Indeed, that is the case here (as #rawr points out), where you need to use a slightly different path to point to package (which is in a subdirectory of the git repo):
install_github("johnlaing/blpwrapper/rbloomberg")