[Rd] R in the browser ...

[Jony Hudson]

Hi all,

 I hope you'll forgive me - I don't plan to start using this list as my blog - but given the discussion following my last post I thought people on here might be interested to see some progress. This is a minimal build of R, cross-compiled from C/Fortran to javascript with emscripten - to be clear, nothing is running server-side, this is all running in the browser's JS engine. The user experience is rather lacking at the minute, much is missing (see below), and there are no compiler optimisations applied (also below) but still, it kind of works. Have a play here:

http://r-in-the-browser.herokuapp.com/

(WARNING: 20MB HTML file, 3.5MB gzipped  + 7MB data file). It goes without saying that you'll want to use a modern web browser to look at it! It works in the latest chrome, firefox, and safari (although I can't see the session output until after I q() in my safari :-() It also seems to run on my iPad, after a very long start-up wait, but it shares the problem of desktop safari that you have to work blind. It also runs on my Android phone, although it takes a _very_ long time to start up - something like 15 minutes!
Picture of a session running on an iPad: http://imgur.com/jzYL5wf
Picture of a session running on a Nexus 4 phone: http://imgur.com/bjDA95j

So far, it's only the core of R - the only package it is loading is "base". The other default packages build mostly, I think, but I haven't yet figured out how to patch the dynamic loading to pull the "native" code in at the right time. Also, nothing using LAPACK works as R is trying to dynamically load that too.

Getting it to build was fiddly, but that probably has a lot to do with my lack of experience building anything unix-y, and this being the first time I've used autotools (I read in the manual that their aim was not to make it user-friendly for maintainers, but rather for users. Well, chapeau to them as they've certainly achieved their aims). In rough outline (and from memory):
- I used f2c to convert the Fortran sources in appl, main and extra/blas to c, and modified the Makefile.in's accordingly - also adding instruction to link in a version of libf2c that I'd pre-compiled to LLVM bitcode.
- I had to manually hack on the configure.h file to remove references to some functions that don't seem to exist in emscripten: ccosh, cexp etc.
- I also added code to set SSIZE_MAX and R_XLEN_T_MAX to sensible values (thanks Peter).
- I hacked connections.c as there were some duplicate case statements. I think this was because the ./configure was getting confused over the size of some basic types. I suspect all of above hacks could be avoided if I understood autotools better.
- I tweaked configure.h again by hand to disable ARPA_INET. I think there's a problem in emscripten's inet header files, but am not sure yet.
- I had to hack xdr_mem.c to force it to use an appropriate ntohl and htonl. Again, probably an autotools problem that I'm not understanding.
- This was enough to run make and have it build LLVM-bitcode for the main source tree (except, bizarrely mkdtemp.c which I had to compile by hand). The make errors out before the end, but it gets far enough. I could then link all of the generated bitcode together and convert to JS. The "virtual filesystem" for the JS code was populated with the contents of /usr/local/lib/R which I trimmed down a bit to get rid of stuff that wasn't going to work.
- The emscripten libc implementation is incomplete so I had to stub out some functions that are probably quite important - glob() and globfree(). That really needs to be fixed! I also stubbed out __locale_mb_cur_max to return some value or other, as I wasn't sure where it was supposed to come from, and I was getting tired.

At the moment all compiler optimisations are turned off, which makes a big difference to code size and performance. The problem is that it appears that some of the R code uses unsafe function pointer casting, which causes trouble with the way that emscripten optimises code (I think it's that it depends on each function having a well-defined type that the JS interpreter can be sure of). I haven't looked into where these casts are, and how difficult it would be to make them safe, but hopefully they're not too pervasive. 

Anyway, it's just a start, but I'm pretty pleased with it :-)


Jony

--
Centre for Cold Matter, The Blackett Laboratory,
Imperial College London, London SW7 2BW
T: +44 (0)207 5947741
http://www.imperial.ac.uk/people/jony.hudson
http://www.imperial.ac.uk/ccm/research/edm
http://www.monkeycruncher.org
http://j-star.org/
--