You can check whether you are running OS X using Sys.info()["sysname"] == "Darwin".
On Windows, finer control is possible by checking for specific versions of the OS using utils::win.version().
How do you check the version of OS X? (I can't find a mac.version or osx.version function. There are some low-level OS commands for finding the version, but I'm not aware of any R wrapper.)
Do Sys.info()["release"] or system("uname --kernel-release", intern = TRUE) return anything useful? (I don't have a machine to check.)
Depending on what you actually want, I would use:
system("uname -r")
14.5.0
or
system("uname -s")
Darwin
or
system("uname -v")
Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64
Sys.info()["sysname"] returns "Darwin" on Mac OS X.
Sys.info()["release"] tells you what version of Mac OS X. For example, "13.4.0" is Mac OS X 10.9.5.
There probably is no need to do a system() call: Sys.info()["version"] seems to return exactly the same as system("uname -v"). And this version really combines different pieces of information and is not convenient for just checking whether or not you're running on Mac. For example
> Sys.info()["version"]
version
"Darwin Kernel Version 13.4.0: Wed Mar 16 09:03:04 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64"
Use Sys.info() to get most of the information about the current platform:
Example:
osname_version<-c(paste(" System: ",Sys.info()[['sysname']],
"\nVersion: ",Sys.info()[['version']],
"\nRelease: ",Sys.info()[['release']],
"\nMachine: ",Sys.info()[['machine']]))
cat(osname_version,"\n")
Result:
System: Linux
Version: #1 SMP Fri Sep 2 15:45:09 CEST 2011
Release: 2.6.32.46
Machine: i686
More Information: https://stat.ethz.ch/R-manual/R-devel/library/base/html/Sys.info.html
Since Sys.info() gives the kernel version rather than the product version, I've opted for using sw_vers instead.
as.numeric_version(system("sw_vers -productVersion", intern = TRUE))
Related
We have installed R 4.1 on one server and it produces gibberish when running external script through SSMS (SQL Server Management Studio). We used this guide when installing: Install an R custom runtime for SQL Server
EXEC sp_execute_external_script
#language =N'myR',
#script=N'
print(R.version);'
STDOUT message(s) from external script:
��_��
��platform�� ��x86_64-w64-mingw32��
��arch�� ��x86_64��
��os�� ��mingw32��
��system�� ��x86_64, mingw32��
��status�� ����
��major�� ��4��
��minor�� ��1.0��
��year�� ��2021��
��month�� ��05��
��day�� ��18��
��svn rev�� ��80317��
��language�� ��R��
��version.string�� ��R version 4.1.0 (2021-05-18)��
��nickname�� ��Camp Pontanezen��
If I run something returning a resultset in a grid, everything seem to be fine.
EXEC sp_execute_external_script #language = N'myR'
, #script = N'
OutputDataSet <- data.frame(installed.packages()[,c("Package", "Version", "Depends", "License", "LibPath")]);'
WITH result sets((
Package NVARCHAR(255)
, Version NVARCHAR(100)
, Depends NVARCHAR(4000)
, License NVARCHAR(1000)
, LibPath NVARCHAR(2000)
));
If I run same script in RGui.exe, it's also fine
print(R.version);
_
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status
major 4
minor 1.0
year 2021
month 05
day 18
svn rev 80317
language R
version.string R version 4.1.0 (2021-05-18)
nickname Camp Pontanezen
An easier sample:
EXEC sp_execute_external_script
#language =N'myR',
#script=N'
print("ÅÄÖ");'
Gives:
"��ÅÄÖ��"
We're using the same SSMS towards another R Server, with bundled version of R (2.x or something) then it displays correctly.
Encoding on the server seem to be correct, but not the resulting output when it's run in SSMS and result as a "string". How can one correct this?
Sys.getenv() (related to R) on the machine not working:
R_ARCH /x64 R_ARCH_BIN /x64 R_BROWSER
R_BZIPCMD bzip2 R_CMD R CMD
R_COMPILED_BY gcc 8.3.0 R_DEFAULT_PACKAGES
datasets,utils,grDevices,graphics,stats R_DOC_DIR
D:/RCompile/recent/R-4.0.3/doc R_GAMS_SYSDIR
d:/RCompile/CRANpkg/extralibs215/GAMS/win64 R_GC_GROWINCRFRAC
0.2 R_GSCMD C:/Progra~2/gs/gs9.21/bin/gswin32c.exe R_GZIPCMD gzip R_HOME C:/Program
Files/R/R-4.1.0 R_INCLUDE_DIR
D:/RCompile/recent/R-4.0.3/include R_INSTALL_PKG RInside
R_INSTALL_TAR tar.exe R_LIBS_USER
C:/Users/CRAN/Documents/R/win-library/4.0 R_MAX_NUM_DLLS 153
R_OSTYPE windows R_PACKAGE_NAME RInside
R_PAPERSIZE a4 R_PAPERSIZE_USER a4 R_PARALLEL_PORT
random R_RD4PDF times,inconsolata,hyper R_SCRIPT_LEGACY
yes R_SESSION_TMPDIR
C:/WINDOWS/ServiceProfiles/MSSQLLaunchpad$MABI_SQLSERVER/AppData/Local/Packages/38af79a5ed4e7cad1e6ad6e9e57a562d-appcontainer1/AC/Temp
R_SHARE_DIR D:/RCompile/recent/R-4.0.3/share R_UNZIPCMD
unzip R_USER C:/Users/CRAN/Documents R_VERSION
4.0.3 R_ZIPCMD zip
Sys.getenv() (related to R) on the machine working:
R_ARCH /x64 R_COMPILED_BY gcc 4.9.3 R_HOME
D:/ProgramData/INSTANS01/R R_LIBS_USER
D:\ProgramData\INSTANS01\Temp-R\Appcontainer1\FF5697C0-8563-40AE-85B0-3DDE0B6C59C4/R/win-library/3.5
R_USER
D:\ProgramData\INSTANS01\Temp-R\Appcontainer1\FF5697C0-8563-40AE-85B0-3DDE0B6C59C4
R_ZIPCMD
D:/ProgramData/INSTANS01/R/library/RevoScaleR/utils/infoZip/zip.exe
After searching a lot, and not finding any solution, we downgraded to 3.6.3 and it worked as expected. It seems to be a bug/difference in R 4.1 regarding encoding.
SMSS has a default encoding of UTF-16. You should be able to change the default encoding in R to that or this article details how to change it within SSMS. I'm not sure if this will work but at this point, it can't hurt to try.
Best of luck
when I type ompi_info on my terminal, I get a huge output on my terminal buffer, a part of which looks like :
Package: Open MPI buildd#lgw01-57 Distribution
Open MPI: 1.10.2
Open MPI repo revision: v1.10.1-145-g799148f
Open MPI release date: Jan 21, 2016
Open RTE: 1.10.2
Open RTE repo revision: v1.10.1-145-g799148f
Open RTE release date: Jan 21, 2016
OPAL: 1.10.2
OPAL repo revision: v1.10.1-145-g799148f
OPAL release date: Jan 21, 2016
MPI API: 3.0.0
Ident string: 1.10.2
Prefix: /usr
Configured architecture: x86_64-pc-linux-gnu
Configure host: lgw01-57
Configured by: buildd
Ignoring the info on release dates, I am curious specifically about the meaning of second line: Open MPI : 1.10.2 and line number twelve: MPI API : 3.0.0 . Does it mean the new functions from Open MPI version 3.0.0 available on the MPI version 1.10.2 ?
Open MPI is an implementation (e.g. code) of the MPI Standard (e.g. pdf document).
These are two distinct things that have their own and independent versions.
Answering my own question, it seems yes, the stable version of OpenMPI 1.10 supports most of the new features introduced in MPI 3 . This page of OpenMPI-1.10.1 shows the list of all MPI API's available which includes the API for one sided communication, which was introduced in MPI version 2.0, and features of MPI 3.0 like non-blocking collective operations like MPI_Ibcast and matching probes like MPI_Mprobe and MPI_Mrecv.
Although this list also doesn't contain the MPI_T tool interface and many other features which is available in the current stable release of openMPI-3.0 .
I'm trying to download a gpx file from the YOURS routing API (http://wiki.openstreetmap.org/wiki/YOURS#Routing_API) and upload the file to R using the readGPS function contained in the maptools package.
Here is the code:
require(utils)
require(maptools)
URL <- 'http://www.yournavigation.org/api/1.0/saveas.php?type=gpx&data=5.62373%2053.01,5.62359%2053.01014,5.62336%2053.01024,5.62314%2053.010303'
download.file(URL, 'tmpTrip.gpx')
gpx.raw <- readGPS(i='gpx', f='tmpTrip.gpx', type='t')
And the error I receive:
Error in readGPS(i = "gpx", f = "tmpTrip.gpx", type = "t") :
gpsbabel not found
I do have installed gpsbabel and I can see the gpx file correctly downloaded in my working directory.
My system and R version are:
Windows 7 Enterprise Service Pack 1, running on Intel Core i5-3320M CPU # 2.60GHz, 4GB RAM, 32 bit OS.
R version 3.1.0 (2014-04-10) -- "Spring Dance"
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: i386-w64-mingw32/i386 (32-bit)
Any help is much appreciated, thank you!!
Figuring it out the hard way, I found that readGPS() calls Sys.which which is a function that tries to find where a file is located on the system. ?Sys.which doesn't say it that clearly but (at least on Windows) for it to work, you need to add the install path of gpsbabel to your path.
If you have GPSBabel installed in your working directory as well, this should work.
For me, I changed the WD:
setwd("C:/Program Files (x86)/GPSBabel")
And then my code
gpx.raw <- readGPS(i = "gpx", f = "C:/Users/Desktop/waypoints.gpx", type="w")
worked after that.
For Mac users:
setwd("/Applications/GPSBabelFE.app")
I just checked out the newest JOGL from git://jogamp.org/srv/scm/jogl.git and installed it.
The installation seems ok. I did run "ant junit.run" and saw 3d graphics.
However, when I tried to compile some example code, I kept getting errors about GLAutoDrawable. It says:
symbol: method getHeight()
location: variable glautodrawable of type GLAutoDrawable
I'm running RHDL 6.5:
$ lsb_release
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
$ uname -a
Linux oc5088881832.ibm.com 2.6.32-431.21.1.el6.x86_64 #1 SMP Tue Jun 3 19:11:40 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
This is my java version:java -version
java version "1.7.0_55"
OpenJDK Runtime Environment (rhel-2.4.7.1.el6_5-x86_64 u55-b13)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
And this is my classpath:
# For JOGL
export CLASSPATH=/usr/local/JOGL/gluegen/build/gluegen-rt.jar:$CLASSPATH
export CLASSPATH=/usr/local/JOGL/jogl/build/jar/jogl-all.jar:$CLASSPATH
export LD_LIBRARY_PATH=/usr/local/JOGL/jogl/build/lib:$LD_LIBRARY_PATH
For your reference, I am compiling this example:
http://jogamp.org/wiki/index.php/Using_JOGL_in_Java_Web_Start
It seems like either I missed something in my classpath or this version of JOGL didn't implement getWidth in GLAutoDrawable...
Please can someone let me know what I did wrong?
GLDrawable.getWidth() and GLDrawable.getHeight() have been renamed GLDrawable.getSurfaceWidth() and GLDrawable.getSurfaceHeight() when adding the support of HiDPI: GLDrawable.java
GLAutoDrawable extends GLDrawable. Please rather post your questions about JOGL on our official forum. Best regards.
We have an OpenCL program that works fine on my OS X machine. We just set up a machine with a Xeon Phi and Intel MPSS. However, even when not using the Phi but the Xeon CPU, the CL_PROGRAM_BUILD_STATUS we get is CL_BUILD_NONE.
Unfortunately, we cannot find any documentation on what might cause CL_BUILD_NONE. Do you have any suggestion on how to debug this?
Thank you in advance!
Versions:
[#memphis:~] $ cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
[#memphis:~] $ uname -a
Linux memphis 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) x86_64 x86_64 x86_64 GNU/Linux
[#memphis:~] 1 $ rpm -qa |grep intel
intel-mic-2.1.6720-15.suse
intel-mic-mpm-2.1.6720-15.suse
opencl-1.2-intel-mic-3.0.67279-1
intel-mic-sysmgmt-2.1.6720-15.suse
intel-mic-kmod-2.1.6720-15.3.0.13.0.suse
intel-mic-gdb-2.1.6720-15.suse
intel-mic-flash-2.1.386-3.suse
intel-mic-cdt-2.1.6720-15.suse
opencl-1.2-intel-devel-3.0.67279-1
intel-mic-micmgmt-2.1.6720-15.3.0.13.0.suse
opencl-1.2-intel-cpu-3.0.67279-1
intel-mic-gpl-2.1.6720-15.suse
intel-mic-crashmgr-2.1.6720-15.suse
The documentation for clGetProgramBuildInfo seems pretty straightforward:
CL_BUILD_NONE. The build status returned if no clBuildProgram, clCompileProgram or clLinkProgram has been performed on the specified program object for device.
You mention that your program worked on other platforms, but maybe you ended up with a slightly different flow between platforms which led to those methods not being properly invoked in the new flow? I'd suggest carefully verifying the return value from the earlier invoked functions to see you get what you expect to get.
Found it. I am not sure why I had &ret (cl_int return value) as the last parameter instead of having it as the return value of clBuildProgram. Moving it and setting the last parameter to NULL fixes the problem:
wrong:
clBuildProgram(*program, 1, &device_id, opts.str().c_str(), NULL, &ret);
correct:
ret = clBuildProgram(*program, 1, &device_id, opts.str().c_str(), NULL, NULL);
I do understand why this problem occured - apparently the compiler / the OpenCL libraries understood that I wanted to use pfn_notify and asynchronously build my kernel. I am, however, not sure if this behavior is fully conformant to the OpenCL documentation:
If pfn_notify is NULL, clBuildProgram does not return until the build has completed.
In my code, the pfn_notify argument was actually NULL, however user_data was (erroneously) not. While my code didn't make any sense, I believe that user_data should be ignored when pfn_notify is NULL.
I posted this on the Intel forums to see if they agree with my interpretation of the documentation.