Skip to content

Embedded R, event loops, GUI events, and OS X

4 messages · Miëtek Bak, Simon Urbanek

#
Hello,

I?m helping with the development of an R-to-Haskell interoperability solution, called H.  The project allows Haskell functions to seamlessly call R functions and vice versa, making use of an embedded R interpreter.  H is developed in-house by Tweag I/O, and is soon to be open-sourced.

The project is stable on Linux and Windows, and I?m focussing on an OS X port.  Basic functionality is ready, but I?m having trouble with the GUI parts.  Specifically, any graph window, e.g. the one expected for `plot(cars)`, appears blank and unresponsive when triggered from H.

I think the issue lies between the H loop, the R event loop, and the Cocoa event loop.  So far, I?ve pored over ?Writing R Extensions? (chapter 8, ?Linking GUIs and other front-ends to R?), the R 3.1.0 sources, (`./src/library/grDevices/src/qdCocoa.m`), and the R.app 1.6.4 sources (`./RController.m`, `./REngine/RCallbacks.m`, `./REngine/RInit.m`, and `./REngine/REngine.m`).  I?ve also found interesting notes in the R.app `./ReadMe.txt`, but unfortunately, they no longer seem to be in sync with the code.

As I?ve seemingly hit a wall, I?m looking for advice.  Are any of the developers of the OS X port of R subscribed to this list?

Thanks, and kind regards,
#
Mi?tek,
On Jul 2, 2014, at 1:43 PM, Mi?tek Bak <mietek at bak.io> wrote:

            
Yes.

In general, the trick is to make sure that you setup the R event loop. That is an extra step after initializing the embedded R. There is nothing special about the OS X port in that regard - as long as you run the R event loop all is well. It becomes more tricky if the app you use wants to use its own event loop - that can cause issues as you have to make sure the two loops mesh properly.

For more specific help you'll need to ask more specific questions - possibly with link to reproducible code.

Cheers,
Simon
#
Hi Simon,

Thanks for the reply.  I?m looking into giving you access to the H repository.  Meanwhile, this is how we initialise embedded R, disabling stack limit checks:

    // NOTE: It is crucial to set the two R stack globals after calling
    // Rf_initialize_R() and before calling setup_Rmainloop().
    // H_initUnlimitedEmbeddedR() is based on Rf_initEmbeddedR(), found in
    // R 3.1.0 source code at src/gnuwin32/embeddedR.c:127.
    int H_initUnlimitedEmbeddedR(int argc, char **argv)
    {
        Rf_initialize_R(argc, argv);
        R_CStackLimit = -1;
        R_CStackStart = -1;
        setup_Rmainloop();
        return(1);
    }

We do use our own event loop.  In order to mesh the H loop and the R loop, we do two things every 0.03 seconds, depending on the platform, neither of which fixes the issue on OS X:

1. On Linux, we call the following:

    void processGUIEventsUnix(InputHandler** inputHandlers) {
      if (*inputHandlers == NULL)
          initStdinHandler();
      R_runHandlers(*inputHandlers, R_checkActivityEx(1000, 0, NULL));
    }

2. On Windows, we call `R_ProcessEvents`.

Can you say what exactly you have in mind when you say ?run the R event loop??

Best,
#
On Jul 2, 2014, at 9:10 PM, Mi?tek Bak <mietek at bak.io> wrote:

            
Why do you disable stack checks? That should never be necessary unless there is a serious problem with threads or stack management in your application.
The official way to check events is to use R_CheckUserInterrupt() - that works on all platforms.

But if you want to run the event loop for another loop, that's typically done using the combination of R_ReplDLLinit() setup and R_ReplDLLdo1() loop (see the Mac GUI).

Cheers,
Simon