unable to run Mac GUI with helpers enabled

[randy3k]

The official Mac R GUI can be complied successfully for both the helper-enabled and disabled versions.
However only the helper-disabled R GUI can be run without errors.

For the helper-enabled R GUI, I got the following runtime error

I tracked down the problem, I found that the GUI crashes when running the function setup_Rmainloop().
The problem should be also related to libR.dylib and function helpers_avail1 as indicated in the top-right corner of the above figure.

I am not good in objective C and the structure of R.
Hope this piece of information will help somebody to fix the problem.

[radfordneal]

Thanks for the report. I've just started playing myself with pqR on a Mac, but haven't tried the GUI yet. As others have reported, helper threads don't work at all with the version of gcc 4.2 distributed with Xcode (at least in the old Xcode 3.2.6 on Snow Leopard that I'm using at the moment), since it doesn't support the "threadprivate" feature of OpenMP. I found that helper threads do work with gcc 4.7.3 (but don't try it with -O3). Could you say what compiler you are using? Does pqR with helper threads work when you compile it without the R GUI?

The error above seems to result from the threadprivate pointer variable this_task_info being null, when it should point to a suitable structure. So this could have something to do with support (or lack of it) for the threadprivate feature. Is it possible that you compiled the shared library for pqR with a compiler supporting "threadprivate", but this library was then called from a GUI that was compiled with a compiler that doesn't support this feature, and hence didn't initialize properly for use of threadprivate variables? (This is speculation. I haven't investigated the GUI and OpenMP on Macs enough yet to know whether this scenario actually makes sense...)

[radfordneal]

Or, continuing my speculation, could it be that the GUI was compiled with a suitable compiler, but without the -fopenmp option to gcc?

[randy3k]

Is it possible that you compiled the shared library for pqR with a compiler supporting "threadprivate", but this library was then called from a GUI that was compiled with a compiler that doesn't support this feature, and hence didn't initialize properly for use of threadprivate variables?

Yes, you are right. I am now trying to use GNU gcc to compile the GUI, but it seems to be not obvious..

[randy3k]

When I complied the guy with GNU gcc... I got the followings..

    /usr/local/Cellar/gcc47/4.7.3/bin/gcc-4.7 -x objective-c-header -fmessage-length=0 -pipe -std=gnu99 -Wno-trigraphs -O0 -DUSE_POOLS -gdwarf-2 -fvisibility=hidden -I/Users/Randy/Desktop/pqR/Mac-GUI-1.53 -I/Users/Randy/Desktop/pqR/Mac-GUI-1.53/build/Debug/include -I/opt/Frameworks/R.framework/Headers -I/opt/Frameworks/R.framework/PrivateHeaders -I/Users/Randy/Desktop/pqR/Mac-GUI-1.53/build/R.build/Debug/R.build/DerivedSources/x86_64 -I/Users/Randy/Desktop/pqR/Mac-GUI-1.53/build/R.build/Debug/R.build/DerivedSources -Wall -F/Users/Randy/Desktop/pqR/Mac-GUI-1.53/build/Debug -F/opt/Frameworks -DPLAIN_STDERR -DDEBUG_RGUI -DUSE_POOLS -c /Users/Randy/Desktop/pqR/Mac-GUI-1.53/R_Prefix.pch -o /var/folders/w9/7w10svxj5093z4831n7m27w00000gp/C/com.apple.Xcode.502/SharedPrecompiledHeaders/R_Prefix-hakfwqlftgjqhleiynzlpicfjuuw/R_Prefix.pch.gch
In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:123:0,
                 from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
                 from /Users/Randy/Desktop/pqR/Mac-GUI-1.53/R_Prefix.pch:6:
/System/Library/Frameworks/Foundation.framework/Headers/NSTask.h:69:24: error: expected identifier or '(' before '^' token
/System/Library/Frameworks/Foundation.framework/Headers/NSTask.h:72:1: error: expected identifier before 'end'

It seems that the GNU gcc won't compile some system header files.
However, the working complier (by Apple) doesn't support openmp....
I don't have any clue at this moment.

[radfordneal]

I'm planning to try this out myself soon. I'll see whether I can figure out a solution. Thanks for trying it, and getting as far as identifying the problem here.

[radfordneal]

From a quick look at the R GUI code, it seems that it doesn't call the usual R mainloop procedure (in src/main.c), which is where helpers_startup is called to set up the whole helpers scheme. So I think the R GUI needs to be modified to call helpers_startup itself at some appropriate point. I can't guess whether the R GUI also needs to be compiled with a compiler that support OpenMP threadprivate variables, but I think just using such a compiler would not be sufficient.

[randy3k]

I think that setup_Rmainloop() is called in REngine/Rinit.m and it is the source of error.

[radfordneal]

Calling setup_Rmainloop isn't sufficient. The actual Rf_mainloop procedure needs to be called. It's not possible for the full setup to be done in a separate "setup" function because OpenMP creates threads as a result of a "parallel" construct, with the threads being destroyed when that construct is left. So the whole main part of the R interpreter needs to be called from within that parallel construct, which exists inside the mainloop procedure.