Currently, Xamarin studio runs as 32 bit process and R runs only as 64 bit
process, so to make this work, you have to compile 64 bit version of mono.
However, once that's done, this should work. There are two tricks:
You need to create ~/.rprovider.conf pointing to your 64 bit mono
(the file should contain e.g. MONO64=/usr/local/mono64/bin/mono)
You need to have R in PATH so that we can run R --print-home to
get R location.
The main changes are:
In RProvider.Server.exe - this exposes the access to R via remoting.
On Mono, this did not work giving the evil "C stack size exceeded" error.
This is usually related to threading, so I changed this to access the R
engine through a simple event loop running on the main thread (this is
the only thing that worked on Mac) - this is for IntelliSense only and
I think it is safer choice for Windows too.
In RInteropClient.fs, we need to find location of 64bit mono
and if that fails, we report a nice error (through IntelliSense).
In RInit.fs, I added a new approach to resolving R location, which
is only used on Mac and calls R --print-home.
Also, RTypeBuilder.fs returned a lazy enumerable from a function that
was wrapped in a lock, which is obviously unintended, so I fixed that
(afaik, it didn't cause any deadlocks, so this should be fine)
Make R provider work on Mac
Currently, Xamarin studio runs as 32 bit process and R runs only as 64 bit process, so to make this work, you have to compile 64 bit version of mono. However, once that's done, this should work. There are two tricks:
~/.rprovider.confpointing to your 64 bit mono (the file should contain e.g.MONO64=/usr/local/mono64/bin/mono)R --print-hometo get R location.The main changes are:
RProvider.Server.exe- this exposes the access to R via remoting. On Mono, this did not work giving the evil "C stack size exceeded" error. This is usually related to threading, so I changed this to access the R engine through a simple event loop running on the main thread (this is the only thing that worked on Mac) - this is for IntelliSense only and I think it is safer choice for Windows too.RInteropClient.fs, we need to find location of 64bit mono and if that fails, we report a nice error (through IntelliSense).RInit.fs, I added a new approach to resolving R location, which is only used on Mac and callsR --print-home.RTypeBuilder.fsreturned a lazy enumerable from a function that was wrapped in a lock, which is obviously unintended, so I fixed that (afaik, it didn't cause any deadlocks, so this should be fine)