(a) I have Julia Studio 0.4.3 and the settings for libraries in my installation (Windows) point to C:/Program Files (x86)/JuliaStudio-0.4.3/julia-studio/Julia. Within that directory, I found julia-basic.exe, julia-debug.exe, julia-debug-readline.exe and julia-readline.exe. I didn't find julia.exe in that folder.
If I write a Julia file within Julia studio, but later I want to run it in cmd line or a bat file, which exe should I use?
Do I need to install Julia separately if I want to run Julia from cmd line or a bat file (Windows)?
(b) Also the Julia documentation says that I can start Julia with -p n option (where n is the number of workers). Is it possible to do this within Julia Studio?
Julia Studio uses the julia-basic executable. There is no julia executable, per se. Rather there is julia-basic and julia-readline executables, the later of which has GNU Readline capabilities. The debug versions of the executables included debug symbols in the executable--it does not sound like you need those.
You can add processors in the REPL with addprocs (link to docs). There is no requirement to define the number of processors up front when starting the Julia process.
Related
I have compiled R 4.1.0 from source against the Intel MKL.
I have put:
source /opt/intel/oneapi/mkl/latest/env/vars.sh intel64
in ~/.bashrc.
If I open a .R file with RStudio, no problem.
But if I open RStudio directly, it is unable to start R correctly, giving me the error:
/usr/lib/rstudio/bin/rsession: error while loading shared libraries: libmkl_gf_lp64.so.1: cannot open shared object file: No such file or directory
Why is that? Doesn't RStudio run ~/.bashrc when started directly?
I am running Fedora 34 Workstation.
When shared libraries are stored in "non-standard locations" we have to tell the dynamic linker about it. That is sometimes done in the calling script (often the case with bundled software, e.g. when you download RStudio which ships with a fair number of local builds of shared libraries) but a more general solution is to tell ldconfig via its configuration.
Older systems used a line per directory in /etc/ld.so.conf. Newer systems generalize this (like many other configurations) with a directory containing small files with entries. So you can create a file named, say, /etc/ld.so.conf.d/local-mkl.conf, and place the directory path in there. If you then run sudo ldconfig all applications will know about it -- including R and RStudio calling R.
I am developing R packages for an internal use applications at work. Unfortunately, not everybody is on the same version of R. I want to build Windows binaries of my package to support multiple versions, for example, 3.6.x and 4.0.x R.
I can easily do this by building the package (I use devtools::build(binary = TRUE)), and then change the R version in RStudio, restart, and run again. But this gets very tedious.
Is there a way to streamline this (e.g., my own custom function to build both at once)? I imagine some CI/CD thing is probably best, but this solution would have to be limited to what I can run locally.
Don't do it in RStudio, write a script to do it. It would have commands like these:
/path/to/R3.6.3/R CMD INSTALL --build /path/to/yourpackage
mv yourpackage.*.zip /path/for/R3.6users
/path/to/R4.0.3/R CMD INSTALL --build /path/to/yourpackage
mv yourpackage.*.zip /path/for/R4.0users
You don't need a lot of builds; only the first two parts of the version number (e.g. 3.6 or 4.0) need to match the target system.
You could implement this script in R using system() calls, but it's probably simpler to do it using one of the Windows script languages (.bat or .cmd or whatever).
Per the Julia Docs:
The build step is executed the first time a package is installed or when explicitly invoked with build. A package is built by executing the file deps/build.jl.
Why would I want to make a build.jl file and how do I effectively utilize the benefits it allows for?
Typically (historically) the build step and the build.jl file is used for downloading/installing binary dependencies with e.g. BinaryProvider (or its predecessor BinDeps)1. The build step can also be used to install configuration files. For example, IJulia uses build.jl in order to install a Julia kernel for Jupyter.
If your package is pure Julia code you typically don't have a build.jl file since there is no need for it.
1 With Julia 1.3 we have Artifacts which is meant to replace the BinaryProvider workflow and make build.jl obsolete for the purpose of downloading and installing prebuilt binaries.
I have both python2 and python3 installed on my desktop. If I do
python -V in the terminal I get Python 3.6.0 :: Anaconda 4.3.0 (x86_64).
However if I use the system2 command from R
system2("python", args = "-V")
then it reports Python 2.7.10
If I specify the full path it I get the right version
system2("//anaconda/bin/python", args = "-V")
Python 3.6.0 :: Anaconda 4.3.0 (x86_64)
But I'd like system2 to just use python3 by default. Is there someway to change which version it uses? This is for Mac OSX
When running R from the R application or RStudio, system calls access a different environment than they do when you run R from terminal. Because of that, the PATH environment variable you have configured to run the correct version of a unix executable in a shell program is different than the one used in a system2()or system() call in an R session in either of these applications. To solve this, you need to set the path in your R environment.
In an interactive session, you can do this:
# Reproducing your problem (in the R application or RStudio)
system2("python", args="-V")
# Python 2.7.10
# set a new PATH in the environment accessed by R
# This is the line you can also add to your .Rprofile
Sys.setenv(PATH = paste(c("//anaconda/bin", Sys.getenv("PATH"),
collapse = .Platform$path.sep))
# For users other than the OP, you'll want to use the directory
# where your preferred installation of python is. For the OP that's
# //anaconda/bin
# Confirm
system2("python", args="-V")
# Python 3.6.0 :: Anaconda 4.3.0 (x86_64)
The system command python should now be found in the directory //anaconda/bin, rather than /usr/bin. This, of course, depends on where these unix executables are found in your system, so for readers other than the OP, you'll need to use the directory that holds your desired version of python.
This PATH will remain valid through the rest of your R session. To change your path in all R sessions, update (or create, if you haven't yet) your .Rprofile file. An .Rprofile file can be (or go) in your HOME directory or R_HOME. If you add the above line to .Rprofile, each time R is initialized, they will execute at the beginning of each R session.
When running the checks for my R-package (via devtools::check()) I face the warning ''qpdf' is needed for checks on size reduction of PDFs. I found this question were it was suggested (if I understood the answer correctly) to run Sys.which(Sys.getenv("R_QPDF", "qpdf")) and see whether qpdf is found or not. In my case this just returns
qpdf
""
so, I think I didn't install qpdf correctly. Unfortunately it seems to be quite complicated to install qpdf on Windows. My first side question is: does it really is so painful and complicated to install qpdf for Windows or is there an easy solution?
I've followed the instructions until it is said to add C:\MinGW-w64\bin and C:\MinGW-w64\lib\mingw to the PATH variable. But then I don't find further specific instructions to install qpdf, only about how to build qpdf with different other programs. The second side question is: is my assumption correct that after I've build qpdf it is installed? But the real question is: What is the best way to build qpdf? I tried the ./config-mingw32 and ./config-mingw64 commands from the section "Building with MinGW" in my C:\MinGW\msys\1.0\bin\bash.exe but got the error messages ./config-mingw32: No such file or directory and have no idea how to fix this issue.
I'm using Windows 10, R version 3.3.2 Patched (2017-01-07 r71934) -- "Sincere Pumpkin Patch" and RStudio 1.0.136.
You basically do not need to build the file on windows. Please follow three steps below:
Download qpdf for windows from https://sourceforge.net/projects/qpdf/?source=typ_redirect
Extract files in a temp folder
Copy the contents of the bin folder to %SystemRoot%\System32
job done!
Sys.which(Sys.getenv("R_QPDF", "qpdf"))
qpdf
"C:\\WINDOWS\\SYSTEM32\\qpdf.exe"
To flesh out an answer provided elsewhere:
If you are running the 32-bit version of R, it is important that you download the 32-bit version of qpdf, which is the version linked from the SourceForge homepage. If you are running a 64-bit installation of R, you will need to do a bit of digging to locate the 64-bit version of qpdf, which is buried a little more deeply (version 10.0.1 is listed here).
Rather than copying files to C:/Windows/System32, a potentially safer option is to extracted the zipped qpdf directory to C:\Program Files. If you do this, you'll need to add C:\Program Files\qpdf-version_number\bin to your system PATH under the environment variables.
To do this within R, run Sys.setenv('PATH' = paste0('C:\Program Files\qpdf-version_numer\bin;', Sys.getenv('PATH')))
To do this in Windows, open the start menu, type "edit the system environment variables" to open the System Properties, and at the bottom of the "Advanced" tab click "Environment variables". Find the "Path" entry under "System variables" and click "Edit". Then, re-start R so it picks up the modified PATH.
One further step may be required to convince Windows that pqdf is safe to run.
Navigate to C:\Program Files\qpdf-version_numer\bin and execute qpdf.exe (by double-clicking). Windows 10 throws up a security warning, as it's an unrecognized executable file. You'll need to use the more options link to find the button to run the program. This done, Windows will recognize the file as safe to run and allow other software, including R, to use it.