When I run the simple profiling test case given in the Julia docs, my Julia kernel invariably dies regardless of environment. I've tried julia.exe, JuliaStudio, and Sublime Text with IJulia. I'm running a fresh install (via the standard 64-bit Windows installer) of version 0.3.0 on Windows 8.
Other components of Julia appear to be working without a hitch. What might be the issue?
This is a known bug in Julia 0.3.0, and will be fixed in the upcoming Julia 0.3.1
Related
As in R documentation:
The last version known to run on Windows 2000 was 2.12.2. Windows XP is no longer supported.
I tried to install R 3.4.3 on windows xp , but i faced problems when installing packages that i didn't face when installing them on Windows 7 system. I think it is safe to assume that R 2.12.2 runs on Windows xp as windows 2000, but does a version later than R 2.12.2 runs on windows xp also? what is the highest version ?
The latest version officially supported on XP was one version below, 3.4.2. Nevertheless, R as high as 3.6.0 installs and runs well on XP (though is not officially QA tested).
Starting from v.3.6.1, R is packed with InnoSetup v.6.0.0 (that means, installing on WinXP will not succeed and end up with an error "not valid Win32 application"). However, one may try to unpack the installer and deploy the files manually (still may help to launch R itself). Another option which may be useful is One Core API.
But... All this stuff is relevant if one is going to use plain R or integrated R environment in some old application. Many 3rd-party R packages require the most up-to-date versions of R, what will cause inconveniences on WinXP.
I have a problem with parallel estimation of random survival forest from randomForestSRC package. I have followed the this guide and tried installing it on Mac (Sierra). However, the rfsrc() function still runs on a single thread. Could you please advice what to do in order to achieve parallel execution, as the function takes ages to compute on a larger dataset. I have directly followed the steps described in the tutorial and no success.
Thanks in advance!
The guide noted in your question is from 2013 and the process for successful OpenMP parallel execution has been significantly streamlined since then. In fact, the binaries available on CRAN for the current build (2.5.1) should run in parallel on Sierra. The source code includes a ready-made configure file that is the result of the autoconf command. Thus, parallel execution is the default behaviour now. If you haven't yet upgraded to the latest build, I would recommend doing so. If the binary build provided by CRAN still does not switch on parallel execution, I would recommend upgrading your compiler to GCC using Homebrew or another package manager, and then appropriately create and massage a Makevars file as given in the instructions on our GitHub page so as to allow the CRAN package installation process to pick up the GCC compiler instead of the default Clang compiler:
https://kogalur.github.io/randomForestSRC/building.html
I have been using RcppArmadillo to build a package, but I've run into a small problem. I have a perfectly working package for 32-bit R, but I would like for it to run on 64-bit. When I started working on the package I was using 32-bit R (without realizing it), but when I shifted to 64-bit R I stopped being able to build my package. I get the error saying "LoadLibrary failure: %1 is not a valid Win32 application."
I realize that the issue is that the .dll file is 32-bit so 64-bit R can't work with it. What I don't understand is how to recreate the .dll so that it is 64-bit. In 64-bit R when I run devtools::find_rtools() I get TRUE, so I suspect that I have to add something to the makevars files to make this work.
So my question in one sentence is: how do you get a working 32bit package with RcppArmadillo to work with 64bit on Windows? Any guidance would be greatly appreciated.
All CRAN packages build on 32 and 64 bit Windows.
All CRAN submissions, including my different Rcpp* packages do (apart from those requiring Unix, or C++11, or ...).
So if I were you, and had (temporary) troubles setting up my main box, I would still use the excellent win-builder which will generate 32 and 64 bit binaries for you.
Aha, it was the makevars files.
I had to add $(shell "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" -e "Rcpp:::LdFlags()")
I have been having some weird issues with R (3.1.1) and RStudio (0.98.1079) and I suspect that it is due to the fact that these programs are not longer referencing the right places after I upgraded to Mac OSX 10.10.
In particular, I cannot seem to find packages that I know I have installed on my computer to run using the system command in the R console. That is, running man pdflatex in a Terminal window yields the help manual for PDFLATEX. However running system('man pdflatex') from the R console yields the error message No manual entry for pdflatex.
The issue persists even though I reinstalled R, RStudio and MacTex since I upgraded to Mac OSX 10.10. Any help would be appreciated!
Yosemite has a bug wherein some environment variables, including PATH, appear twice in a program's environment with different values. For instance, you might notice that Sys.getenv("PATH") will show you one PATH, and system("echo $PATH") will show you an entirely different one.
I expect that most of your problems are due to this bug.
There are a few workarounds you can try immediately:
You can manually forward PATH yourself. Try this:
> system2("man", "pdflatex", env=paste0("PATH=", Sys.getenv("PATH")))
Or, you can start RStudio from Terminal:
$ open /Applications/RStudio.app
Both the R and RStudio engineers have implemented workarounds in the last few days. R (as of 3.1.2) and RStudio (as of 0.98.1087) should behave as you'd expect.
There are a host of questions about similar problems. All of them appear to come up when you update OS X to either Yosemite or Sierra with an older version of R already installed.
The easiest solution is to completely uninstall R (note the comments about using which R !), and then to install it again.
This also solves problems such as R showing different version numbers in terminal and the GUI.
I'm planning a new build system for our project running on Centos 5.4. I intend to use SCons. I noticed the latest stable SCons version is 2.0.1 while Centos 5.4 comes with 1.2.
I'm new to SCons so I'd like to understand more about the features/stability ratio between the versions.
Would you recommend installing and using the latest version or sticking to what comes from my OS repository?
Since 1.2 the changes have been bug fixes and documentation improvements. There haven't been any new features.
The 2.x version of SCons drops support for Python versions older than 2.4, updating some of the internal code to use newer idioms but without affecting any user visible APIs. That's the reason for the major version number change. If CentOS comes with a recent version of python then this won't affect you either way.
There have been a lot of fixes for newer versions of the various Microsoft compiler versions, but this won't affect a CentOS install.
The bug fixes since SCons 1.2.0 also solve problems in the Fortran, TeX and LaTeX builders. If you make use of Fortran or LaTeX then it would probably be worth upgrading. Otherwise I think you would be hard pushed to spot any day-to-day difference between 1.2.0 and 2.0.1.