I am trying to call an exe file created with Fortran and the gfortran compiler in R. However, R does not show the same output on my two computers.
Let's say I have a very simple Fortran code :
program Main
write(*,*) 'Hello World !'
end
I created an exe file using gfortran, giving : hello.exe
Then, when i call the exe in R using :
shell('hello.exe')
on my first computer, i get the 'Hello World !' printed in the R console, while on the other one, the code works, but nothing is printed, and I don't understand why. I guess something must be different between the two computers by I don't know what (both use the same R and gfortran versions).
Finally, I found the solution. I thought that both computers shared the same version of R but it was not the case. The one that prints the message runs with R 3.5.0 while the other runs with a previous version.
Surprisingly, it is apparently not possible to display the messages with previous versions of R.
Related
When trying to execute any commands from MATLAB.jl in julia, the matlab command window opens, and Julia immediately exits with no errors, warnings, or messages. Has anyone else encountered this before? I'm working on translating some MATLAB code to julia and using MATLAB.jl to check that the sparse matrices are the same for both pieces of code.
I'm on a Windows computer and have tried following the instructions on the MATLAB.jl github repo. I've also tried adding Matlab to path and executing the code from the Julia REPL, but keep encountering the same problem.
I can get mxarray executes, however, trying it seems like anything which requires a matlab session causes julia to quit, e.g. mxcall, md"", and MSession.
Was able to solve the problem by opening julia through the command prompt as an administrator and running ] build MATLAB and ] test MATLAB. If the terminal was not opened as administrator, it would build, however, during the testing it would return exit error: 3765269347, which seems to be a windows-specific internal process error.
After this has been done, MATLAB.jl seems to work even when it is not opened directly with admin rights.
I tried to run a Python script from R with:
system('python script.py arg1 arg2')
And got an error:
ImportError: No module named pandas
This was a bit of a surprise since the script was working from the terminal as expected. Having encountered this type of issue before (with knitr, whence the engine.path chunk option), I know to check:
Sys.which('python')
# python
# "/usr/bin/python"
And compare it to the command line:
$ which python
# /Users/michael.chirico/anaconda2/bin/python
(i.e., the error arises because I have pandas installed for the anaconda distribution, though TBH I don't know why I have a different distribution)
Hence I can fix my issue by running:
system('/Users/michael.chirico/anaconda2/bin/python script.py arg1 arg2')
My question is two-fold:
How does R's system/Sys.which find a different python than my terminal?
How can I fix this besides writing out the full binary path each time?
I read ?Sys.which for some hints, but to no avail. In particular, ?Sys.which suggests Sys.which is using which:
This is an interface to the system command which
This is clearly (?) untrue; to be sure, I checked Sys.which('which') and which which to confirm both are pointing to /usr/bin/which (goaded on by this tidbit):
On a Unix-alike the full path to which (usually /usr/bin/which) is found when R is installed.
To the latter, on a whim I tried Sys.setenv(python = '/Users/michael.chirico/anaconda2/bin/python') to no avail.
As some of the comments hint, this is a problem that arises because the PATH environment variable is different for programs launched by Finder (or the Dock) than it is in the Terminal. There are ways to set the PATH for Dock-launched applications, but they aren't pretty. Here's a place to start looking if you want to go that route:
https://apple.stackexchange.com/questions/51677/how-to-set-path-for-finder-launched-applications
The other thing you can do, which is probably more straightforward, is tell R to set the PATH variable when it starts up, using Sys.setenv to add the path to your desired Python instance. You can do that for just one project, for your whole user account, or for the whole system, by placing the command in a .Rprofile file in the corresponding location. More information on how to do this here:
https://stat.ethz.ch/R-manual/R-devel/library/base/html/Startup.html
When I run a Julia Script that prints "Hello World" on HTCondor, I get the following error
fatal: error thrown and no exception handler available.
Base.InitError(mod=:Pkg, error=Base.KeyError(key="HOME"))
The code runs without a problem on my local Ubuntu machine. I can run
eval julia --version
in a bash script on condor and the output is
julia version 0.5.0
This problem has been discussed in two places on github: one, two.
ENV["HOME"] is used in a single file and the common recommendation is to modify that. However, I cannot change the julia installation on condor.
Is there a way to fix this on the fly before running a script without sudo?
As #sujeet suggested, it is possible to set environmental parameters in condor. The issue is resolved by adding the following line in the condor submit script
Environment = "HOME=""/tmp"""
, which sets the home directory to the tmp. Julia code runs fine then (as long one is careful not to write to home before resetting it in the script itself).
I am trying to use gdb to debug compiled code in an R package in the same way as specified in the video: https://vimeo.com/11937905 and Writing R Extensions section 4.4.
These sources say to use the command
R -d gdb when starting R. However, whenever I try to do this I get a message saying WARNING: unknown option '-d' and R is started under normal conditions.
Why isn't R recognizing the -d flag? I am using Windows 10.
As #MatthewLueder has found out himself finally debugging on Windows does not work as on Linux.
A how-to is described in the R for Windows FAQ
The main reason for the missing -d argument in R seems to be that Windows cannot send a signal to a process to interrupt the execution and pass the control to the (gdb) debugger:
Without interrupting R you cannot set a breakpoint.
Without starting R into the R console you cannot load libraries to be debugged (without making your hands dirty).
Therefore R on Windows offers a work-around using RGui instead of R:
gdb /path/to/R-3.x.x/bin/x64/Rgui.exe
(gdb) run
After starting the RGui you are in an R shell and can load your packages
that contain the DLLs to be debugged.
To set breakpoints for debugging you can interrupt R to break into the debugger via a menu item that is only visible if RGui was started with gdb:
Now you can set breakpoints in your code via b a_function_name, enter c to continue R, call the function in R and voilà: gdb shows the breakpoint hit and
you can debug (stepping through the code and printing variable values).
PS: I am currently developing an R package to improve the debugging of C++ code in R packages since it is quite difficult to view the current values of R variables or Rcpp data types in gdb: https://github.com/aryoda/R_CppDebugHelper
If someone could walk me through a particular problem, I'd really appreciate it... I think I know what's causing it, but I don't know how to fix it.
Problem-- Emacs ESS won't start up R.
Cause-- I've installed OpenFOAM, an open source fluids modeling kit that has it's own function called R, and executes with the letter "R". (I.e. type "R" in the command line and it tries to run an OpenFOAM function, not R). I think by installing OpenFoam, I have overwritten the previous "R" calling the language R, and so that messes with ESS trying to call R.
Environment-- I'm ssh'ing into a remote client running scientific linux where I don't have root access. I don't exactly understand what ESS is calling that is local to my account and what is not local.
Calling /usr/bin/./R from the command line starts an instance of R. How do I modify ESS such that it calls '/usr/bin/./R'?
This was the closest I could find, ESS to call different installations of R, but as far as I can tell, my system doesn't have R-1 or R-2 at all on its exec path, so I don't know how similar it is.
I had run into the same problem. Following the links and tips of Josh O'Brien, I put
;; Set default R version, (i.e. the one launched by typing M-x R <RET>)
(setq inferior-R-program-name "/usr/bin/R")
in my .emacs file. Now it works perfectly.