[R-SIG-Mac] Updating to Mavericks
This is an attempt to collect together various pieces of advice. If you update to Mavericks and want to compile packages (or run some) with the CRAN binary R, you will need to - Update R to 3.0.2 or later if you use R.app. - Re-install XQuartz. The Mavericks update re-populates /usr/X11 with links which tell you to install XQuartz (even if it is currently installed). - Re-install the Apple Java 6 runtime if you use rJava. Try any of the rJava examples and you will be prompted for an install. - Install Xcode 5.0.1 if you had not previously done so. - Re-install the Xcode command-line tools. Xcode for Mavericks has moved most things inside Xcode (specifically under /Applications/Xcode.app/Contents/Developer) and the command-line tools previously installed seemed almost to work, but not entirely. xcode-select --install seems to be the recommended way to do so under Mavericks. If you previously had them installed, the Xcode 4.6.3 compilers (such as llvm-g++-4.2) should still work. Otherwise you could select clang as your compiler: see http://cran.r-project.org/doc/manuals/r-release/R-admin.html#OS-X-packages . There are also compilers called 'gcc' and 'g++' in Xcode 5.0.1: these are clang-based but are not quite the same as clang/clang++. Although g++ reports % g++ --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 it looks at the libcxx headers at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ . And the packages which do not compile under clang++ do not compile under g++ . Packages using a C++ interface may need re-compiling if you use clang++ (or g++) as your C++ compiler. The external software at http://r.research.att.com/libs/ which I know does is gdal and zeromq. It would be prudent to compile Rcpp with the same compiler as a Rcpp-using package, although not always necessary. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] RODBC not connecting from my Mac
On 25/10/2013 13:54, Marc Schwartz wrote: On Oct 13, 2013, at 11:41 AM, Mikkel Grum mi2kelg...@yahoo.com wrote: iODBC appears no longer to come standard with OSX, so I installed unixodbc and set it up following instructions here: http://www.boriel.com/en/2013/01/16/postgresql-odbc-connection-from-mac-os-x/ I connected to my remote database with isql -v mydsn. No problem. Then I tried from R: library(RODBC) pg - odbcConnect(mydsn) # waited for a couple of minutes before pressing Ctrl-C ^C There were 50 or more warnings (use warnings() to see the first 50) warnings()[1:2] Warning messages: 1: In odbcDriverConnect(DSN=mydsn) : [RODBC] ERROR: state IM002, code 1606406032, message [iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded 2: In odbcDriverConnect(DSN=mydsn) : [RODBC] ERROR: state IM002, code 1606406032, message [iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded It looks like RODBC might only work with iODBC on the Mac. Is that the case? I haven't been able to configure iODBC correctly, and therefore haven't been able to test whether that would work with RODBC. Any chance that I can get RODBC to work with unixodbc? Any other information that would be useful in resolving it? sessionInfo() R version 3.0.2 (2013-09-25) Platform: x86_64-apple-darwin10.8.0 (64-bit) locale: [1] C/UTF-8/C/C/C/C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] RODBC_1.3-8 Regards Mikkel First, no need to cross-post to three groups. I am replying to R-SIG-Mac only here. iODBC is still available on OSX. Apple removed the ODBC Administrator application back on Snow Leopard. A newer ODBC Manager application is freely available for download here: http://www.odbcmanager.net/index.php It is supported by Actual Technologies, which offers for purchase, ODBC drivers on OSX for various data sources. I use their driver for Oracle. If you want to use the older Apple ODBC Administrator application, it is still available here: http://support.apple.com/kb/DL895 If you want to stay with unixODBC, you may want to read through the vignette for RODBC that Prof. Ripley has written and pay attention to the Installation section on page 22: http://cran.r-project.org/web/packages/RODBC/vignettes/RODBC.pdf which has some hints that should be helpful, such as using: --with-odbc-manager=odbc when installing RODBC from source. Yes, RODBC will, by default, use iODBC on OSX, since that is the default ODBC installation on OSX. Thus, the precompiled binary for RODBC will not work for what you are attempting to do. Regards, Marc Schwartz Hi All, I wanted to follow up on this thread, as the information that I provided above was not complete, as I now know from conversations with Prof. Ripley, information found online by searching in the Apple Developer Forums and an e-mail exchange with Actual Technologies' (AT) tech support. Beginning with OS X 10.6 (Snow Leopard), Apple removed the ODBC Administrator GUI application from the default OS installation, as I noted above. The Apple version was and is still available as a separate download from Apple.com and the AT folks began to support and release and updated version called ODBC Manager, as I also noted. However, that was only part of the story as it turns out. Beginning with OS X 10.8 (Mountain Lion), Apple began the process of deprecating direct support for iODBC. The header files for iODBC that were included with XCode on 10.8 in the SDK tree apparently had indications of this, but it was not overtly documented anywhere else, including the XCode release notes. The binary dylib files for iODBC were still present in /usr/lib on 10.8, so if you wanted to use, for example, the RODBC binary for OS X on 10.8, there was not an issue. You still need the ODBC Administrator/Manager GUI to set up the DSN configuration of course, unless you manually set up the configuration files. There is not a specific indication as to why, but an entry from August of *2012* in the Apple Dev Forums by an Apple rep indicated that a decision had been made by Apple to engage in the deprecation of the default installation of iODBC on OS X. This reply was to another user who had noted the header file content indicating this and posted a query. The Apple rep suggested that users begin to consider going to iODBC.org for OS X binaries where available or the source code moving forward. Alternatively, users should consider moving to other ODBC tools such as unixODBC or the use of native (non-ODBC) drivers for the data sources of interest. With 10.9 (Mavericks), Apple has now completely removed iODBC from the default OS X installation. In the latest version of XCode, the binary dylib files
Re: [R-SIG-Mac] Forking issues in Mavericks
On Oct 29, 2013, at 3:53 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote: On Tue, Oct 29, 2013 at 12:35 PM, Steve Lianoglou lianoglou.st...@gene.com wrote: Is this happening when you are running R from w/in R.app (which, I think, is not new), or are you running R from the terminal and still seeing this)? It happens when a forked child process tries to use some fork unsafe opratation, after the parent has already done so as well, see [1]. It is related to R.app in the sense that the GUI uses the CF event loop which is considered fork unsafe, and therefore a forked child process can't do any fork unsafe operations anymore. However it also happens in other contexts such as prefork in RApache [2]. But my actual question is: what is it about using httr::GET that is considered fork unsafe, which was not considered unsafe in 10.8? I didn't have time to look (will do later today), but a wild guess is that Apple was moving away from some common libraries like OpenSSL and replacing them with their own which could be CF-based and thus unsafe. Again, that's wild guess, I'll have to look at the trace to confirm that. Cheers, Simon [1] http://objectivistc.tumblr.com/post/16187948939/you-must-exec-a-core-foundation-fork-safety-tale [2] http://stackoverflow.com/questions/2344368/problem-configuring-rapache-on-os-x-10-5-8/2358834#2358834 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] no title bar on mavericks X11 windows
Hi, Since upgrading to Mavericks, all X11 windows created by R are without title bar (no maximize/minimize/close buttons, no title)...just a blank white canvas placed in the upper-left corner of my primary display. R draws into this just fine, but I can't move, close, or otherwise manipulate the window. This occurs with X11() called from remote machines (an older R-2.14.1), and from R-3.0.0 and R-3.0.2 locally. Other X applications, both locally- and remotely-executed, do not suffer from this issue. I also upgraded Xquartz to the 2.7.5-rc3 recommended for Mavericks users by the Xquartz team, but it had no effect on this issue. I don't know if this is an R issue or an Xquartz issue...any ideas? Thanks, Andy -- Andy Jacobson andy.jacob...@noaa.gov NOAA Earth System Research Lab Global Monitoring Division 325 Broadway Boulder, Colorado 80305 303/578-2237 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Forking issues in Mavericks
On Wed, Oct 30, 2013 at 10:08 AM, Simon Urbanek simon.urba...@r-project.org wrote: I didn't have time to look (will do later today), but a wild guess is that Apple was moving away from some common libraries like OpenSSL and replacing them with their own which could be CF-based and thus unsafe. Again, that's wild guess, I'll have to look at the trace to confirm that. Thanks. It's unfortunate though, these developments are limiting the usefulness of the parallel package on the mac, because a lot of basic functionality is now considered unsafe to use in a forked process, even though on Linux there is no problem at all. I also don't get why osx decides to kill both the parent and child process when the child attempt to do something unsafe. That doesn't seem the most graceful way of dealing with things. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] no title bar on mavericks X11 windows
On Oct 30, 2013, at 12:11 PM, Andy Jacobson (NOAA Affiliate) andy.jacob...@noaa.gov wrote:Hi,Since upgrading to Mavericks, all X11 windows created by R are without title bar (no maximize/minimize/close buttons, no title)...just a blankwhite canvas placed in the upper-left corner of my primary display. R draws into this just fine, but I can't move, close, or otherwise manipulatethe window. This occurs with X11() called from remote machines (an older R-2.14.1), and from R-3.0.0 and R-3.0.2 locally. Other X applications,both locally- and remotely-executed, do not suffer from this issue. I also upgraded Xquartz to the 2.7.5-rc3 recommended for Mavericks users bythe Xquartz team, but it had no effect on this issue. I don't know if this is an R issue or an Xquartz issue...any ideas?Thanks,AndyHi,I am running 3.0.2 on Mavericks (CRAN binary install) and when I use X11() running R in a terminal session, I get a full window with title bar on my MacBook Pro. I re-installed XQuartz (2.7.4) after upgrading from 10.8 to 10.9.See the attached screen capture PNG.I tested it via R.app as well, with the same result.Regards,Marc Schwartz___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Forking issues in Mavericks
Still, I do not get any error with package parallel in my Mavericks. I compiled though R with a gcc 4.8.2. On 30 Oct 2013, at 18:26, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote: On Wed, Oct 30, 2013 at 10:08 AM, Simon Urbanek simon.urba...@r-project.org wrote: I didn't have time to look (will do later today), but a wild guess is that Apple was moving away from some common libraries like OpenSSL and replacing them with their own which could be CF-based and thus unsafe. Again, that's wild guess, I'll have to look at the trace to confirm that. Thanks. It's unfortunate though, these developments are limiting the usefulness of the parallel package on the mac, because a lot of basic functionality is now considered unsafe to use in a forked process, even though on Linux there is no problem at all. I also don't get why osx decides to kill both the parent and child process when the child attempt to do something unsafe. That doesn't seem the most graceful way of dealing with things. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] no title bar on mavericks X11 windows
For me the same … Have you installed the Command Line Tools for Mavericks? The Tcl framework location has changed and following http://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html the X11 implementation of Tcl/Tk is used. On 30 Oct 2013, at 19:08, Marc Schwartz marc_schwa...@me.com wrote: On Oct 30, 2013, at 12:11 PM, Andy Jacobson (NOAA Affiliate) andy.jacob...@noaa.gov wrote: Hi, Since upgrading to Mavericks, all X11 windows created by R are without title bar (no maximize/minimize/close buttons, no title)...just a blank white canvas placed in the upper-left corner of my primary display. R draws into this just fine, but I can't move, close, or otherwise manipulate the window. This occurs with X11() called from remote machines (an older R-2.14.1), and from R-3.0.0 and R-3.0.2 locally. Other X applications, both locally- and remotely-executed, do not suffer from this issue. I also upgraded Xquartz to the 2.7.5-rc3 recommended for Mavericks users by the Xquartz team, but it had no effect on this issue. I don't know if this is an R issue or an Xquartz issue...any ideas? Thanks, Andy Hi, I am running 3.0.2 on Mavericks (CRAN binary install) and when I use X11() running R in a terminal session, I get a full window with title bar on my MacBook Pro. I re-installed XQuartz (2.7.4) after upgrading from 10.8 to 10.9. See the attached screen capture PNG. I tested it via R.app as well, with the same result. Regards, Marc Schwartz Screen Shot 2013-10-30 at 1.03.09 PM.png ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] no title bar on mavericks X11 windows
Hi Marc, all: More digging on the Xquartz mailing lists led me to discover the source of this issue. It's a preferences setting in Mission Control: displays have separate spaces. If that is clicked on, then a range of X apps will exhibit the behavior that the title bar is hidden behind the menu bar. (You can see the title bar by entering Mission Control with F3). Once that setting is turned off, the problem goes away. Changing this setting does require a logout/login cycle. -Andy On Wed 30 Oct 2013, at 12:08 , Marc Schwartz marc_schwa...@me.com wrote: On Oct 30, 2013, at 12:11 PM, Andy Jacobson (NOAA Affiliate) andy.jacob...@noaa.gov wrote: Hi, Since upgrading to Mavericks, all X11 windows created by R are without title bar (no maximize/minimize/close buttons, no title)...just a blank white canvas placed in the upper-left corner of my primary display. R draws into this just fine, but I can't move, close, or otherwise manipulate the window. This occurs with X11() called from remote machines (an older R-2.14.1), and from R-3.0.0 and R-3.0.2 locally. Other X applications, both locally- and remotely-executed, do not suffer from this issue. I also upgraded Xquartz to the 2.7.5-rc3 recommended for Mavericks users by the Xquartz team, but it had no effect on this issue. I don't know if this is an R issue or an Xquartz issue...any ideas? Thanks, Andy Hi, I am running 3.0.2 on Mavericks (CRAN binary install) and when I use X11() running R in a terminal session, I get a full window with title bar on my MacBook Pro. I re-installed XQuartz (2.7.4) after upgrading from 10.8 to 10.9. See the attached screen capture PNG. I tested it via R.app as well, with the same result. Regards, Marc Schwartz Screen Shot 2013-10-30 at 1.03.09 PM.png -- Andy Jacobson andy.jacob...@noaa.gov NOAA Earth System Research Lab Global Monitoring Division 325 Broadway Boulder, Colorado 80305 303/578-2237 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Forking issues in Mavericks
Jeroen,
actually, it works just fine for me on 10.9 (with CRAN build of R):
library(parallel)
library(httr)
myfork - mcparallel(GET(https://api.github.com/users/hadley/repos;))
out - mccollect(myfork)
out
$`53129`
Response [https://api.github.com/users/hadley/repos]
Status: 200
Content-type: application/json; charset=utf-8
[{id:12241750,name:adv-r,full_name:hadley/adv-r,owner:{login:hadley,id:4196,avatar_url:https://2.gravatar.com/avatar/7ba164f40a50bc23dbb2aa825fb7bc16?d=https%3A%2F%2Fidenticons.gi
[...]
sessionInfo()
R version 3.0.2 Patched (2013-10-23 r64103)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] parallel stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] httr_0.2
loaded via a namespace (and not attached):
[1] digest_0.6.3 RCurl_1.95-4.1 stringr_0.6.2 tools_3.0.2
system(uname -a)
Darwin ginaz.client.research.att.com 13.0.0 Darwin Kernel Version 13.0.0: Thu
Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
BTW: if you really want to trace the crash, start the parent R and run this in
lldb:
pro at -n R -w
that will attach to the forked child process.
Cheers,
Simon
On Oct 29, 2013, at 3:08 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:
The following works in Linux and OSX 10.8 but in OSX 10.9 it results
in a
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__():
library(parallel)
library(httr)
myfork - mcparallel(GET(https://api.github.com/users/hadley/repos;))
out - mccollect(myfork)
I've seen this error before when trying to access X11 from inside a
forked process. In this case it seems to be related to SSL, but I'm
not quite sure how to further debug this in 10.9 (lldb anyone?). What
exactly might be triggering this error?
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Forking issues in Mavericks
On Wed, Oct 30, 2013 at 1:41 PM, Simon Urbanek simon.urba...@r-project.org wrote: Jeroen, actually, it works just fine for me on 10.9 (with CRAN build of R): Hmm interesting. Here is a clip of what happens on my machine: http://youtu.be/GAtKa6P75Qs. Note that it shows the error messages from the child proc, but afterwards the parent process is also broken. I think it is no longer allowed to use fork() or exec(). This mac is an almost completely blank installation of Mavericks. I formatted and did a recovery of 10.8 before updating to 10.9. Afterwards installed R.app and xquarts. Other than that almost everything on the machine is factory settings. ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Forking issues in Mavericks
On Oct 30, 2013, at 5:45 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote: On Wed, Oct 30, 2013 at 1:41 PM, Simon Urbanek simon.urba...@r-project.org wrote: Jeroen, actually, it works just fine for me on 10.9 (with CRAN build of R): Hmm interesting. Here is a clip of what happens on my machine: http://youtu.be/GAtKa6P75Qs. Note that it shows the error messages from the child proc, but afterwards the parent process is also broken. I think it is no longer allowed to use fork() or exec(). This mac is an almost completely blank installation of Mavericks. I formatted and did a recovery of 10.8 before updating to 10.9. Afterwards installed R.app and xquarts. Other than that almost everything on the machine is factory settings. Ah, you're running it in R.app? That less likely to work, because R.app is fully in CF by being an app, so anything that touches the event loop will die. R itself is trying to avoid that by disabling the EL calls in children, but libraries may not know. Anyway, my hunch was correct - it's libcurl crashing in SSL trying to use CF. There must be some code that is conditional in running in an app, so it thinks it's ok to use CF which fails (see below). A way around could be compiling static libcurl against openssl so it doesn't uses the system one. * thread #1: tid = 0x11e139, 0x7fff83381206 libdispatch.dylib`_dispatch_wakeup + 100, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x110) frame #0: 0x7fff83381206 libdispatch.dylib`_dispatch_wakeup + 100 frame #1: 0x7fff833817a8 libdispatch.dylib`_dispatch_queue_push_list_slow2 + 30 frame #2: 0x7fff83384145 libdispatch.dylib`_dispatch_mach_msg_send + 608 frame #3: 0x7fff83383e99 libdispatch.dylib`dispatch_mach_send + 136 frame #4: 0x7fff8198a864 libxpc.dylib`_xpc_connection_send_message_with_reply_f + 125 frame #5: 0x7fff8198a724 libxpc.dylib`xpc_connection_send_message_with_reply_sync + 180 frame #6: 0x7fff8c8cc193 CoreFoundation`-[CFPrefsPlistSource copyReplyForDaemonMessage:toConnection:error:] + 243 frame #7: 0x7fff8ca26820 CoreFoundation`__47-[CFPrefsPlistSource alreadylocked_synchronize]_block_invoke_2 + 352 frame #8: 0x7fff8c8cba9b CoreFoundation`withDaemonConnection + 299 frame #9: 0x7fff8c8cb4fb CoreFoundation`-[CFPrefsPlistSource alreadylocked_synchronize] + 587 frame #10: 0x7fff8c8cb1f3 CoreFoundation`_copyValueForKey + 131 frame #11: 0x7fff8c8cb147 CoreFoundation`-[CFPrefsPlistSource copyValueForKey:] + 71 frame #12: 0x7fff8c8f3730 CoreFoundation`___CFPreferencesCopyValueWithContainer_block_invoke + 32 frame #13: 0x7fff8c8ca097 CoreFoundation`+[CFPrefsSource withSourceForIdentifier:user:byHost:container:perform:] + 839 frame #14: 0x7fff8c8f36c7 CoreFoundation`_CFPreferencesCopyValueWithContainer + 231 frame #15: 0x7fff85c7e3de Security`_SSLContextReadDefault + 46 frame #16: 0x7fff8d52d8d6 libsystem_pthread.dylib`__pthread_once_handler + 65 frame #17: 0x7fff884b5156 libsystem_platform.dylib`_os_once + 73 frame #18: 0x7fff8d52d875 libsystem_pthread.dylib`pthread_once + 57 frame #19: 0x7fff85c7cec5 Security`SSLCreateContextWithRecordFuncs + 329 frame #20: 0x7fff85c7cd3f Security`SSLCreateContext + 25 frame #21: 0x7fff867a8fe4 libcurl.4.dylib`darwinssl_connect_common + 443 frame #22: 0x7fff8679a18c libcurl.4.dylib`Curl_ssl_connect_nonblocking + 36 frame #23: 0x7fff86778134 libcurl.4.dylib`Curl_http_connect + 77 frame #24: 0x7fff867847da libcurl.4.dylib`Curl_protocol_connect + 129 frame #25: 0x7fff867953cb libcurl.4.dylib`multi_runsingle + 840 frame #26: 0x7fff86794fd1 libcurl.4.dylib`curl_multi_perform + 166 frame #27: 0x7fff8678e944 libcurl.4.dylib`curl_easy_perform + 244 frame #28: 0x00010069a18a RCurl.so`R_curl_easy_perform(handle=0x000102ce6000, opts=0x000104026ca0, isProtected=0x00010090a848, encoding=0x00010087f000) + 106 at curl.c:93 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Forking issues in Mavericks
On Wed, Oct 30, 2013 at 2:57 PM, Simon Urbanek simon.urba...@r-project.org wrote: Ah, you're running it in R.app? Well this was the easiest way to show it; the same problem appears when forking form inside httpuv or so. Anyway, my hunch was correct - it's libcurl crashing in SSL trying to use CF. I wish there was at least way to make situations like these fail more gracefully... it's fine if the misbehaved child proc is killed, but it's a bit painful that it also takes down its parent(s). There's nothing we can do to catch these situations before it is too late? ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
