Is Mac OSX Stable yet?

Aug 14, 2013 at 6:18 PM
If unknown I could give it a go.
Coordinator
Aug 15, 2013 at 12:09 AM
Hi,

I do not have access to a Mac, so if you can give feedback on where things are up to on that platform this would be very useful and appreciated
Aug 16, 2013 at 7:35 AM
Hi jp,

Okay, gave it a quick go on the work computer and some preliminary test results. First, the installation doesn't work right off the bat. The library is a .zip file and I gather (though am not certain) that apple/linux systems require a tar/gzipped file and will not accept a .zip file. As a result, the install doesn't work.

I just downloaded the code quickly and tried to run the ./Build.sh command which I suspected/hoped would just remake the correct compressed installation file on my mac. This bash script failed with some unsupported archictecture message. I quickly changed the script from a "==Linux" statement to a "==Darwin" statement and then it seemed to work okay.

The rClr library was clearly installed, but then upon calling "library(rClr)" in R I received this message.
Error: package ‘rClr’ was built for x86_64-w64-mingw32 
I suspected you wrote this, very nice and robust sounding, error message so I thought I would just ping back for a response on it.

Anyway, my sense is that no terribly difficult compilation issues has shown up, but there is a veneer of windows v. linux v. mac in the current release that is probably problematic but disappear at the C#/R level.

Do you develop on a linux system? I gathered from the code that you do, so thought I would ask for whatever package file you crate rather than make it myself. Am still very much looking forward to being able to run code that is as fast and easy to code as C# in R.

All the best,
Nigel
Coordinator
Aug 16, 2013 at 11:30 AM
Thanks for this; very appreciated feedback.

I have some old scripts to archive/discard. The build folder has some leftovers from quite a few months, which were not the gold standard way to build packages. I have moved on since then. Not yet gold, but bronze I hope. rClr being a rather complicated beast, it needs to have "configure" and "configure.win" scripts, which generate Makevars and Makefile files. Seems to be in line with R package build practices, but documentation becomes sparse off the usual beaten trail.

I log in this post the steps I go through to build/install on a Linux machine (Debian, 'sid' i.e. most recent packages but possibly unstable). I'll polish that to a proper documentation later.

A bit of context about the Linux box I use for this post:
$ uname -a
Linux somemachinename 3.10-1-amd64 #1 SMP Debian 3.10.1-1 (2013-07-16) x86_64 GNU/Linux
$ R --version
R version 3.0.1 (2013-05-16) -- "Good Sport"
$ which mono
/usr/local/bin/mono
$ which xbuild
/usr/local/bin/xbuild
$ mono --version
Mono JIT compiler version 3.0.6 (Debian 3.0.6+dfsg2-4)
side note - if mono is build from a very recent checkout; as it happens this 3.3 mono causes runtime trouble I just found out, but rClr build builds otherwise fine. You should be a able to build against any 3.x or even 2.10.x release of Mono.
$ mono --version
Mono JIT compiler version 3.3.0 (master/76890ae Sunday 28 July  13:30:22 EST 2013)
What I'd now do to build the package:
cd src/codeplex/r2clr/packages/
R CMD check rClr
As of writing, with the most recent checkout of rClr, it should all compile. With the bleeding edge Mono, you may have a loading 'libmonoboehm-2.0.so.1' issue. With the Debian distro Mono 3.0.6, I get the results from the check with a few failed unit tests. Expected, and the issue is in Mono not rClr. So seeing the following is a good sign.
* checking for unstated dependencies in tests ... OK
* checking tests ...
  Running ‘test-all.R’
 ERROR
Running the tests in ‘tests/test-all.R’ failed.
Last 13 lines of output:
  6/04/2013 2:59:00 PM
  2013-04-07 01:59
  g.DateEqualsFails
  6/04/2013 3:33:00 PM
  2013-04-07 02:33
  h.............DateEqualsFails
  31/12/2999 1:00:00 PM
  3000-01-01
  i...........
Assuming I am happy with the check:
R CMD REMOVE rClr # in case I have in installed already. May be unnecessary.
At this point, in passing, I should mention I prefer to customize the location of my downloaded packages; I have a ~/.Renviron file containing the line:
R_LIBS=~/R
I prefer this to easily upgrade R version. Probably not relevant to the build process; need to check what R does without a user .Renviron.

Then:
R CMD INSTALL --no-test-load rClr
the -no-test-load option installs despite the unit tests still failing.

Then, from R, running the unit tests: all basics should pass
> library(rClr)
Loading the dynamic library for Mono runtime...
Assembly '/home/per202/R/rClr/libs/ClrFacade.dll' doesn't have an entry point.
Loaded Common Language Runtime version 4.0.30319.17020
> library(testthat)
> test_package(
package=   filter=    reporter=  
> test_package('rClr', filter='basic')
rClr essentials : .......................................................................................................................................
date and time handling, some known issues remaining.
> test_package('rClr', filter='date')
Lengthy post, but I hope it provides clarifications. Tanks again for your contribution. Hope I can catch up if I make it to the U.S. in a year or so...

Cheers,
J-M
Aug 17, 2013 at 8:15 PM
Excellent, thanks for all of the information. So I gave it a go, and on a vanilla Mac ran in to the problems that the build tools were simply not available, missing such as:

pkg-config
sh
gcc
etc. etc.

Will take a look at it a bit later to see if I can work around this and try to figure out the best way to do a mac build. Definitely let me know if you are near Boston!

Best,
Nigel
Aug 20, 2013 at 10:57 PM
Okay, given the limited number of macs and the overhead in having people install GCC, I think one solution might be to distribute a precompiled file, and set the LD_LIBRARY_PATH to reference the mono library at runtime. Does this seem reasonable?

Also, out of curiosity, how does garbage collection work across the interface?
Coordinator
Aug 21, 2013 at 12:36 AM
Very reasonable; after this is what MacOS users get from CRAN, I believe. Only Linux plaforms recompile the package from sources.

The reason there is no package for Linux (source tarball) or Mac (aside from my not being (yet?) a Mac user) is that it is not tested to a level where I am confident the first impression would be positive enough for new users giving it a spin.

Some runtime issues with Mono have puzzled me, though they may have gone now. I think I'll have the latitude to test on Linux ore over the coming months concurrently to my day job.

If you can summarize your notes on the build process on MacOS (either via a fork/pull request or via mail as you wish), this would be good.

As to the garbage collection accross R/.NET, during the creation of an R 'object' (SEXP), a finalizer function can be registered via the R API function R_RegisterCFinalizerEx. Finding this out was not a linear process, and information can be very patchy for every runtime (R/MS.NET/Mono), but this seems to work as desired.
SEXP clr_object_to_SEXP(CLR_OBJ * objptr) {
    SEXP result;
    // snip code
    R_RegisterCFinalizerEx(result, clr_object_finalizer, (Rboolean) 1/*TRUE*/);
    // snip code
}

static void clr_object_finalizer(SEXP clrSexp) {
    ClrObjectHandle * clroh_ptr;
    if (TYPEOF(clrSexp)==EXTPTRSXP) {
#ifdef MONO_CLR
        clroh_ptr = (ClrObjectHandle*)R_ExternalPtrAddr(clrSexp);
        mono_gchandle_free(clroh_ptr->handle);
        free(clroh_ptr);
#elif MS_CLR
        CLR_OBJ * objptr;
        clroh_ptr = static_cast<ClrObjectHandle*> (R_ExternalPtrAddr(clrSexp));
        objptr = clroh_ptr->objptr;
        delete objptr; // TOCHECK
#endif
    }
}
Aug 31, 2013 at 6:51 AM
Just an FYI, gave it a go tonight, learned lots about the R building process but still a no go, got to the point where I realized I had 32 bit mono on 64 bit R, will work on it some more later