Call RDotNet and R on 64-bit Mac OS X from 32-bit W7 over network

May 29, 2014 at 3:26 AM
Edited May 29, 2014 at 2:47 PM
I am following the console example (https://rdotnet.codeplex.com/), which works fine on 32-bit Windows 7. However, the work that I have for R to do needs to load vectors bigger than 2 MB, which I can't do in 32-bit R on Windows - (even tried bcdedit to increase VA to 3072 MB on a normally 2 GB RAM system, and checked defragging to see if I could open a larger contiguous block of address space). The R application (v.3.0.3) handles this just fine on Mac OS X 10.7.5 (64-bit). So I am attempting to call RDotNet (v.1.5.12) and R (v.3.0.3 or v.3.1.0, both 64-bit) from my VS 2012 console application on 32-bit W7 over a network connection to the Mac. I built Mono (v.3.4.0) in 64-bit mode on the Mac. Here are the changes that I made to the console application code on W7:
REngine.SetEnvironmentVariables("\\\\MACBOOKPRO-443C\\Macintosh HD\\Library\\Frameworks\\R.framework\\Versions\\3.0\\Resources\\bin", "\\\\MACBOOKPRO-443C\\Macintosh HD\\Library\\Frameworks\\R.framework\\Versions\\3.0\\Resources\\bin");

Console.WriteLine(RDotNet.NativeLibrary.NativeUtility.FindRHome());
        
Console.WriteLine(RDotNet.NativeLibrary.NativeUtility.GetPlatform());

REngine engine = REngine.GetInstance("R");
``` I have also tried slightly changing the paths from /bin to /lib and calling REngine engine = REngine.GetInstance("libR.dylib"); . The console output is essentially the same:
c:\Program Files\R\R-3.0.3
Win32NT
Unhandled Exception:  System.Exception  This 32 bit process failed to load the library \MACBOOKPRO-443C\Macintosh HD\Library\Frameworks\R.framework\Versions\3.0\Resources\bin\R (or lib\libR.dylib)  Native error message is 'The system cannot find the file specified'
at RDotNet.NativeLibrary.UnmanagedDll.ReportLoadLibrary<String dllName>
at RDotNet.NativeLibrary.UnmanagedDll.ctor<String dllName>
at RDotNet.REngine.ctor<String id, String dllName>
at RDotNet.REngine.CreateInstance<String id, String dllName>
at RDotNet.REngine.GetInstance<String id, Boolean initialize, StartupParameter parameter, ICharacterDevice device>
at RConsoleAppTest.Program.Main<String[] args> in C:\Users\Me\Documnets\Visual Studio 2012\Projects\RConsoleAppTest\Program.cs: line 38
The error is a result of the ThrowFailedLibraryLoad method in RDotNet.NativeLibrary.UnmanagedDll.cs. I believe this method was called from the ReportLoadLibError method from libraryLoader method "if (handle == IntPtr.Zero)" section. Line 38 is the REngine.GetInstance(). I had loaded the RDotNet and RDotNet.NativeLibrary assemblies into my VS project through the network path (i.e. Add Reference>Browse to network path files), and they are in the same directories as R....
I see the problem that FindRHome() and GetPlatform() return W7 settings (c:\Program Files\R\R-3.0.3 and
Win32NT, respectively), from the registry, since that path no longer exists (this error persists across reboots). Can anyone help to get FindRHome() and GetPlatform() to return the values from Mac, where I thought that I was actually running RDotNet and RDotNet.NativeLibrary? It looks as if I am not running the RDotNet dll's on the Mac OS X environment as intended. Do I need to specify explicitly somehow in this dual-OS networked dynamic that Mono be used to open the RDotNet dll's on Mac OS X? I think if I can resolve this, then there wouldn't be the 32-bit vs. 64-bit conflict that I'm getting, as I would be running RDotNet in a 64-bit environment to call R 64-bit, but I'm not sure. Any advice is appreciated.
Developer
May 30, 2014 at 12:43 AM
Unless I am missing something here, you are trying to execute Mac binary libraries on a Windows system; there is no way this could work as far as I know. The fact that the mac is 32 or 64 bits is not relevant; it is just a file server in this instance.

You'll need to access a Windows 64 bits, or use MonoDevelop on Mac or Linux to develop/debug your programs.
May 30, 2014 at 2:11 AM
Well, I am trying to issue a command from Windows to have them execute on Mac, then return an image back to Windows...