I bought an M1 Silicon with Monterey back in January and --- after a three+ month pause -- am trying again to get Rcpp running so I can install RStan. Following these instructions in response to (I'd like to just comment on this other issue, but being new to posting on Stack Overflow it tells me that I cannot and what I am about to post is certainly NOT an answer):
Configuring compilers on Mac M1 (Big Sur, Monterey) for Rcpp and other tools
While step 3 (installing gfortran) looks to go well, when I ask about gfortran things seem less hopeful:
-bash: gfortran: command not found
Or maybe this is not how to ask if all went well with the installation?
No matter, I charge on to step 4 installing from openmp-13.0.0-darwin21-Release.tar.gz based on:
Apple clang version 13.1.6 (clang-1316.0.21.2.3)
Target: arm64-apple-darwin21.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I confirm that I have the files where expected, then create the .R directory and the Makevars file (in nano) then try to run the R and get ....
+ #endif
+ }
+ ')
/Users/lizzie/.R/Makevars:6: *** missing separator. Stop.
Error in Rcpp::sourceCpp(code = "\n#include <RcppArmadillo.h>\n#ifdef _OPENMP\n# include <omp.h>\n#endif\n\n// [[Rcpp::depends(RcppArmadillo)]]\n// [[Rcpp::export]]\nvoid omp_test()\n{\n#ifdef _OPENMP\n Rprintf(\"OpenMP threads available: %d\\n\", omp_get_max_threads());\n#else\n Rprintf(\"OpenMP not supported\\n\");\n#endif\n}\n") :
Error 1 occurred building shared library.
WARNING: The tools required to build C++ code for R were not found.
Please install Command Line Tools for XCode (or equivalent).
Any thoughts or ideas much appreciated. Again, I am new to posting to StackOverflow so apologize as I am sure I am doing this wrong.
Related
I'm having issues with Azure Machine Learning SDK for R: "module 'azureml' has no attribute 'core'"...
For reasons that aren't my own, I have to use azureml to apply machine learning (my own stuff, written in R) to data from our data warehouse that is put in the blob storage. The modelled output should be put back into the blob storage so it can be accessed from the data warehouse.
I've written the code in R on my local machine (stored in a git repo). Preferably, I'd find some method to pull my code from git into a pipeline in the azureml environment so that it can be directly run whenever new data is available in the blob storage.
I've embarked on a tutorial-spree and found this seemingly relevant walkthrough: Train and deploy your first model with Azure ML (and this one).
But... after trying all I could think of, I'm stuck on the first steps. After installing all (or at least.. that's what I think) packages, modules, apps etc, and running the following code in RStudio:
library(azuremlsdk)
existing_ws <- get_workspace(name = name,
subscription_id = subscription_id,
resource_group)
I run into an error that I haven't been able to fix:
AttributeError: module 'azureml' has no attribute 'core'
It seems that the azuerml is supposed to have an attribute "core", but when looking at it more closely, there is indeed no such attribute.
The function "get_workspace()" is trying to access: "azureml$core$Workspace$get".
I found that "azuerML$Workspace" does exist, but then I can't figure out how to make that work.
Can anyone explain to me why I'm encountering this error?
Does anyone know of a better tutorial on how to connect my R code the azureml's cloud service?
Any pointers in the right direction are much appreciated!
EDITS - still not solved:
After advice from others, I double, triple and quadruple checked the installation.
I updated R and I'm now running:
R.version
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status
major 3
minor 6.2
year 2019
month 12
day 12
svn rev 77560
language R
version.string R version 3.6.2 (2019-12-12)
nickname Dark and Stormy Night
I installed Conda with Python 3.6.10.
I installed the azuremlsdk R package (I tried both provided options).
I then realized that there are some inconsistencies with the versions of the azure-modules, so I also tried installing it with the keyword 'multi-arch':
remotes::install_cran('azuremlsdk', repos = 'http://cran.us.r-project.org', INSTALL_opts=c("--no-multiarch"))
Then, I installed the azureml python sdk.
I had a look at all the versions again (using python -m pip freeze):
azure-common==1.1.24
azure-graphrbac==0.61.1
azure-mgmt-authorization==0.60.0
azure-mgmt-containerregistry==2.8.0
azure-mgmt-keyvault==2.0.0
azure-mgmt-resource==7.0.0
azure-mgmt-storage==7.1.0
azureml==0.2.7
azureml-automl-core==1.0.83.1
azureml-core==1.0.69
azureml-dataprep==1.1.36
azureml-dataprep-native==13.2.0
azureml-pipeline==1.0.69
azureml-pipeline-core==1.0.69
azureml-pipeline-steps==1.0.69
azureml-sdk==1.0.69
azureml-telemetry==1.0.69
azureml-train==1.0.69
azureml-train-automl-client==1.0.83
azureml-train-core==1.0.69
azureml-train-restclients-hyperdrive==1.0.69
As I was surprised to see all the 1.0.69 versions, instead of the 1.0.83 versions, I re-installed the azureml python sdk using:
azuremlsdk::install_azureml(version = "1.0.83")
This worked, in the sense that indeed all versions are now 1.0.83:
azure-common==1.1.24
azure-graphrbac==0.61.1
azure-mgmt-authorization==0.60.0
azure-mgmt-containerregistry==2.8.0
azure-mgmt-keyvault==2.0.0
azure-mgmt-resource==7.0.0
azure-mgmt-storage==7.1.0
azureml==0.2.7
azureml-automl-core==1.0.83.1
azureml-core==1.0.83
azureml-dataprep==1.1.36
azureml-dataprep-native==13.2.0
azureml-pipeline==1.0.83
azureml-pipeline-core==1.0.83
azureml-pipeline-steps==1.0.83
azureml-sdk==1.0.83
azureml-telemetry==1.0.83
azureml-train==1.0.83
azureml-train-automl-client==1.0.83
azureml-train-core==1.0.83
azureml-train-restclients-hyperdrive==1.0.83
But still... I get the error with the missing core. I get it both when running:
library(azuremlsdk)
get_current_run()
and also when running:
library(azuremlsdk)
existing_ws <- get_workspace(name = name,
subscription_id = subscription_id,
resource_group)
Note that the first time running this code after starting up RStudio, I get the error:
Error in py_get_attr_impl(x, name, silent) :
AttributeError: module 'azureml' has no attribute '_base_sdk_common'
And every time after that I get this error:
Error in py_get_attr_impl(x, name, silent) :
AttributeError: module 'azureml' has no attribute 'core'
Any help would be much appreciated!
This issue was introduced by the latest reticulate 1.14 release, in which reticulate would create a default r-reticulate conda environment. Since Azure ML was installing the python SDK in an environment named r-azureml, the r-reticulate environment used by reticulate was missing the python SDK. A fix for this issue was addressed in a PR and has been merged into master. Please install from GitHub for now if you have reticulate version 1.14 and are running into this issue. We will be releasing an update to CRAN shortly.
I seemed to have fixed the issue by specifically installing the python package azureml AND azureml.core:
python -m pip install azureml
and then...
python -m pip install azureml.core
I did this for the Conda version that was called by R (r-reticulate). It's a bit odd to not be able to use the Conda environment 'r-azureml' without R switching back to 'r-reticulate', but ah well... at least I don't get my 'azureml' has no attribute 'core' anymore.
Reaching out to the wider group as I am totally stumped trying to install Intel MPSS 4.x for my Xeon Phi 7220P.
I followed the precise steps in this link: Intel MPSS Linux User Guide Rev 4.4.1, and did it 3 times to make sure I wasn't missing any steps or making mistakes, but keep getting the following error readout:
modprobe: WARNING: Module mic_x200_dma not found.
modprobe: WARNING: Module scif_bus not found.
modprobe: WARNING: Module vop_bus not found.
modprobe: WARNING: Module cosm_bus not found.
modprobe: WARNING: Module scif not found.
modprobe: WARNING: Module vop not found.
modprobe: WARNING: Module mic_cosm not found.
modprobe: WARNING: Module mic_x200 not found.
As a result of this, I cant do the basic MPSS commands such as micctrl -s etc nor use the Xeon Phi whatsoever.
I am running Centos 7 (862 kernel), and know its not listed in the Intel pdf, but did not think this should be causing an issue as it seems that the above kernel modules are simply not being installed seemingly from Intel MPSS - but not sure if this diagnosis is correct.
Would appreciate your help - many thanks in advance!
It is complaining about that because at one point your kernel got updated from 3.10.0-514.el7 to a later version, (it happens automatically when you do a yum update, annoying I know)
Check your kernel version by running
uname -r
When you installed/compiled all the modules they were placed into /lib/modules/3.10.0-514.el7.x86_64 which is where the source code you have exported to.
You have 2 options:
Recompile the source code to work for your current kernel version (which is a pain and has it's own problems)
Revert your host kernel back to 3.10.0-514.el7 via grub config (example here) and everything will work nicely
I too struggled with this very much in the beginning and I had to read pretty much every line of source code and spend countless hours debugging until I found out. At this point there is nothing I do not know about the Xeon Phi x100/x200.
The documentation is not bad, but it didn't cover this bare essential, which is frustrating.
I am trying to install OpenCL on a machine with the following specs:
CentOS 6.8
Kernel version 2.6.32-642.el6.x86_64
4G of RAM
FPGA board "Nallatech 395 – with Stratix V D8"
aocl version
aocl 16.0.0.211 (Altera SDK for OpenCL, Version 16.0.0 Build 211, Copyright (C) 2016 Altera Corporation)
However, I receive error [Q 2-3] described in the following page:
http://www.alteraforum.com/forum/showthread.php?t=46355
/#aocl install aocl install: Running install from
/root/altera/16.0/hld/board/nalla_pcie/linux64/libexec Using kernel
source files from /usr/src/kernels/2.6.32-642.el6.x86_64 make: ***
/usr/src/kernels/2.6.32-642.el6.x86_64: No such file or directory.
Stop. cp: cannot stat `./aclpci_drv.ko': No such file or directory
FATAL: Module aclpci_drv not found.
The page above suggests to execute the following command:
yum install kernel-devel
However I still receive the same error.
Please advise!
I found a thread with a similar error, the following solution could work for you. However, this solution is based on version 14.
First navigate to the linux/driver of the BSP folder which for you should be located at root/altera/16.0/hld/board/nalla_pcie/linux64/driver
Find and edit the file aclpci.c: At the top of the file add the following lines:
#define __devinit
#define __devexit
Secondly edit aclpci_cmd.c: On line 83 remove the assignment
Change:
result = pci_restore_state(aclpci->pci_dev);
to:
pci_restore_state(aclpci->pci_dev);
On lines 438-440 comment out the following statements:
if (dev->aer_firmware_first) {
return -EIO;
}
You should now be able to run "aocl install" successfully.
I ran into an odd issue that I cannot fix in any way and I was hoping someone here may have a better understanding of whats wrong;
I am unable to use RWebLogo package - even run the simplest examples due to the same missing Ghostscript error.
e.g. running:
library(RWebLogo)
aln <- c('CCAACCCAA', 'CCAACCCTA', 'AAAGCCTGA', 'TGAACCGGA')
weblogo(seqs=aln, file.out='mylogo.pdf')
Throws this error:
Traceback (most recent call last):
File "/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogo", line 71, in <module>
weblogolib._cli.main()
File "/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogolib/_cli.py", line 82, in main
formatter(data, format, opts.fout)
File "/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogolib/__init__.py", line 757, in pdf_formatter
gs = GhostscriptAPI()
File "/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogolib/__init__.py", line 196, in __init__
raise EnvironmentError("Could not find Ghostscript on path."
EnvironmentError: Could not find Ghostscript on path. There should be either a gs executable or a gswin32c.exe on your system's path
I have installed ghostscript ver 9.15 with configure/make/install in the terminal and then added the PATH to bash profile and executed it. When I run gs in the terminal it works, confirming it is set to the system path, yet the same error still occurs. Even after rebooting.
I tried adding the gs to the environment in R directly:
Sys.setenv(R_GSCMD = "/Applications/ghostscript-9.15/bin/gs")
which also hasn't helped... Gives exactly the same error. When I search the R environment it shows that gs is there.
Important version information:
MAC: OS Yosemite 10.10.1;
R version 3.1.1 (2014-07-10);
Platform: x86_64-apple-darwin10.8.0 (64-bit);
RWebLogo_1.0.3
Do you know of any issue that may have cause this problem? I'm new to programming, so I am worried I may be missing something basic. I would be grateful for any advice. Thank you!
I have gotten in touch with Omar, the author of RWebLogo, and he has been really helpful in pinpointing my problems and resolving the issue.
First, he advised to run the RWebLogo on a test sequence on the terminal:
/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RWebLogo/extdata/weblogo-3.3/weblogo -f test_seqs.txt -o ~/Desktop/out.pdf -F pdf
Change the base directory (everything before extdata/weblogo …) of the script above to be whatever the command below gives you in R:
system.file(package = 'RWebLogo')
I ran it and got a new error: the lack of numpy. I actually had the numpy installed but without full user privileges. After reinstalling numpy, the RWebLogo was successfully running from the terminal.
Still, the RStudio was throwing a GhostScript error. Omar suggested that there is a problem with an older version of RStudio running on Yosemite (I currently have 10.10.1), and sent me a link to an updated RStudio version where the problem was fixed.
http://www.r-bloggers.com/r-and-rstudio-incompatibility-with-yosemite-mac-os-x-10-10/
I got the updated RStudio and everything works great there right now. Hope this helps someone with a similar issue!
Is there a simple way to trigger a crash in R? This is for testing purposes only, to see how a certain program that uses R in the background reacts to a crash and help determine if some rare problems are due to crashes or not.
The easiest way is to call C-code. C provides a standard function abort()[1] that does what you want. You need to call: .Call("abort").
As #Phillip pointed out you may need to load libc via:
on Linux, dyn.load("/lib/x86_64-linux-gnu/libc.so.6") before issuing .Call("abort"). The path may of course vary depending on your system.
on OS X, dyn.load("/usr/lib/libc.dylib")
on Windows (I just tested it on XP as I could not get hold of a newer version.) you will need to install Rtools[2]. After that you should load dyn.load("C:/.../Rtools/bin/cygwin1.dll").
There is an entire package on GitHub dedicated to this:
crash
R package that purposely crash an R session. WARNING: intended
for test.
How to install a package from github is covered in other questions.
I'm going to steal an idea from #Spacedman, but I'm giving him full conceptual credit by copying from his Twitter feed:
Segfault #rstats in one easy step:
options(device=function(){});plot(1)
reported Danger, will crash your R session.
— Barry Rowlingson (#geospacedman) July 16, 2014
As mentioned in a comment to your question, the minimal approach is a simple call to the system function abort(). One way to do this in one line is to
R> Rcpp::cppFunction('int crashMe(int ignored) { ::abort(); }');
R> crashMe(123)
Aborted (core dumped)
$
or you can use the inline package:
R> library(inline)
R> crashMe <- cfunction(body="::abort();")
R> crashMe()
Aborted (core dumped)
$
You can of course also do this outside of Rcpp or inline, but then you need to deal with the system-dependent ways of compiling, linking and loading.
I'll do this in plain C because my C++-foo isn't Dirkian:
Create a C file, segv.c:
#include <signal.h>
void crashme(){raise(SIGSEGV);}
Compile it at the command line (windows users will have to work this out for themselves):
R CMD SHLIB segv.c
In R, load and run:
dyn.load("segv.so") # or possibly .dll for Windows users
.C("crashme")
Producing a segfault:
> .C("crashme")
*** caught segfault ***
address 0x1d9e, cause 'unknown'
Traceback:
1: .C("crashme")
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
aborting ...
Segmentation fault
This is the same behaviour as the one Thomas references in the graphics system bug report which I have filed and might get fixed one day. However this two-liner will always raise a segfault...
Maybe Dirk can one-line-Rcpp-ise it?
If you want to crash your R, try this
lapply("", function(x) eval(sys.call(1)))
(Save everything before running because this immediately results in "R Session Aborted")
Edit: This works for me on Windows 10.