[R-SIG-Mac] (old) rgl package crashes MacGUI using R 3.2.3 in El Cap, new compiled one does not. (Duncan Murdoch)

David Winsemius dwinsemius at comcast.net
Sun Jan 3 02:26:28 CET 2016


> On Jan 2, 2016, at 5:00 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
> 
> On 02/01/2016 5:47 PM, David Winsemius wrote:
>> 
>>> On Jan 2, 2016, at 10:34 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
>>> 
>>> On 02/01/2016 12:47 PM, Joseph Kunkel wrote:
>>>> Duncan, The rgl (binary) download says it, ver 0.95.1201, is as up to date as binaries are for my MacBook Pro retina early 2013 with OS X El Capitan w. 16 GB ram.
>>> 
>>> That version is just over a year old.  We are getting closer to tracking down the problem with newer ones that has prevented them from being distributed as binaries on OSX, so you will likely find at some point that an "update.packages()" call causes you to jump ahead a lot of versions.  You can read the change list here:
>>> 
>>> https://r-forge.r-project.org/scm/viewvc.php/pkg/rgl/inst/NEWS?view=markup&root=rgl
>>> 
>>> (This goes a little newer than the CRAN version.)
>>> 
>>> Duncan Murdoch
>>> 
>> 
>> Dear Joseph;
>> 
>> Since I started this thread and am a *NIX noob and not an experienced package developer, I thought I would recount my stumbling efforts (at least the successful portions of them) toward moving to the development version of `rgl` as opposed to the current CRAN version, 1435. I had earlier reported success in compiling from source and loading the version 1435 source, so I will assume that you are able to do that. If you don't have XCode and XQuartz, you should start there.. I think this is an effective test of having the needed XCode (mine is Version 7.2 (7C68) ) and XQuartz 2.7.8 (xorg-server 1.16.4) packages, since I'm pretty sure something would fail if either of them are not paired to the El Cap OS. I first tried the recommended checkout of the source from R-Forge. I was at at a Terminal prompt and at the "user-root" which is `~/` in Unix-speak:
> 
> The way you describe below works, but there are easier ways:  install Xcode and Xquartz, then from within the R.app GUI, use the package installer menu to install it from "CRAN (sources)" (for the latest CRAN version), or "Other Repository", "http://r-forge.r-project.org", with "Binary format packages" unchecked.  This will get the latest build from R-forge.
> 
> The main reason you'd want to use svn is if you (think you) find a bug, and want to play around with the source in order to isolate it.  Or if you just want to play around with the source for fun.
> 
> Duncan Murdoch

Thanks, Duncan. 

I do know why I "forgot" that method. I've used source installs with the Mac GUI Package Installer many times but had lost confidence in using the "other" repositories with that interface because it failed  many times. But in this instance it does succeed (using the r-forge repo), and I also updated a couple of other packages that had the letters "rgl".

 I wasn't not sure what Rglpk is supposed to do, tried to install it, but it failed installation using this method. After looking at its DESCRIPTION file I now know it has nothing to do with rgl and requires an external package: GLPK library.

-- 
David


> 
> 
> 
>> svn checkout svn://svn.r-forge.r-project.org/svnroot/rgl/
>> 
>> #----
>> # ... a really large number of files were downloaded ...
>> # That created a directory at the "user-root" named rgl which had in it a sub directory named ~/rgl/pkg/ with a further subdirectory named ~/rgl/pkg/rgl/ , which was where all the good stuff was sitting.
>> #  So after some flailing around and reading some manuals, I got this to succeed (at a Terminal prompt):
>> 
>> R CMD build -l ~/rgl/pkg/rgl rgl > rgl.log 2>&1
>> 
>> #-----------
>> # contents of log file
>> #-------------
>> Warning: unknown option ‘-l’
>> * checking for file ‘/Users/davidwinsemius/rgl/pkg/rgl/DESCRIPTION’ ... OK
>> * preparing ‘rgl’:
>> * checking DESCRIPTION meta-information ... OK
>> * cleaning src
>> * running ‘cleanup’
>> * installing the package to build vignettes
>> * creating vignettes ... OK
>> * cleaning src
>> * running ‘cleanup’
>> * checking for LF line-endings in source and make files
>> * checking for empty or unneeded directories
>> Removed empty directory ‘rgl/src/ext/GLsdk/GL/codegen’
>> * building ‘rgl_0.95.1438.tar.gz’
>> 
>> * checking for file ‘rgl/DESCRIPTION’ ... NO
>> 
>> 
>> #end contents------
>> # So I would drop that "-l" from that "CMD build"-call
>> # It was a hangover from a failed call to INSTALL
>> # However, since there were no errors
>> # ... and I could see rgl_0.95.1438.tar.gz in ~/
>> # I then tried this for an R console session:
>> 
>> install.packages("/Users/davidwinsemius/rgl_0.95.1438.tar.gz", repo=NULL, dependencies=TRUE, type="source")
>> 
>> # Success.
>> 
>> Duncan is exhibiting an abundance of caution in not recommending that people use the current version if it fails the automatic compilation checks. The alternative for me was not having any version of 'rgl' that would work. The version on CRAN will compile and load, but it does so with a warnign about some difficulty with initialization and then fails to display any graphs  ... at all.
>> 
>> --
>> David.
>>> 
>>> 
>>> 
>>>> Thanks for the quick view of the error codes.
>>>> 
>>>> Joe Kunkel
>>>> 
>>>>> On Jan 2, 2016, at 11:47 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
>>>>> 
>>>>> On 02/01/2016 10:23 AM, Joseph Kunkel wrote:
>>>>>> What is the recomendation about upgrading to R 3.2.3 for someone who is now working on a project that is highly invested in using rgl?   I am a bit reluctant to fall far behind in upgrades but using the MacGUI  and R 3.2.2 is working reasonably well for me.
>>>>> 
>>>>> You didn't say what version of rgl you're using.
>>>>> 
>>>>>> I have gotten some error complaints during/after rgl use which might be an indication that I should upgrade?
>>>>>> 
>>>>>> Error 1 in MacGUI window:
>>>>>> 
>>>>>> 2016-01-01 21:52:05.063 R[2942:183303] -deltaZ is deprecated for NSEventTypeMagnify.  Please use -magnification.
>>>>> 
>>>>> I don't think this is present in the current rgl.  I don't remember if it was there in earlier versions, but your verbose error message doesn't show any rgl activity as far as I can see.
>>>>> 
>>>>> Duncan Murdoch
>>>>> 
>>>>>> 
>>>>>> Verbose error 2 in MacGUI window:
>>>>>> 
>>>>>> 2016-01-01 21:33:36.342 R[2942:183303] -[GLView delegate]: unrecognized selector sent to instance 0x7f9690b73a70
>>>>>> 2016-01-01 21:33:36.342 R[2942:183303] An uncaught exception was raised
>>>>>> 2016-01-01 21:33:36.343 R[2942:183303] -[GLView delegate]: unrecognized selector sent to instance 0x7f9690b73a70
>>>>>> 2016-01-01 21:33:36.349 R[2942:183303] (
>>>>>> 	0   CoreFoundation                      0x00007fff92e77ae2 __exceptionPreprocess + 178
>>>>>> 	1   libobjc.A.dylib                     0x00007fff91c7d73c objc_exception_throw + 48
>>>>>> 	2   CoreFoundation                      0x00007fff92e7ab9d -[NSObject(NSObject) doesNotRecognizeSelector:] + 205
>>>>>> 	3   CoreFoundation                      0x00007fff92db3601 ___forwarding___ + 1009
>>>>>> 	4   CoreFoundation                      0x00007fff92db3188 _CF_forwarding_prep_0 + 120
>>>>>> 	5   R                                   0x000000010f78f1aa -[RController validateMenuItem:] + 1002
>>>>>> 	6   AppKit                              0x00007fff8c9a66f6 -[NSMenu _enableItem:] + 706
>>>>>> 	7   AppKit                              0x00007fff8c9b8152 -[NSCarbonMenuImpl _carbonUpdateStatusEvent:handlerCallRef:] + 517
>>>>>> 	8   AppKit                              0x00007fff8c9aaea1 NSSLMMenuEventHandler + 708
>>>>>> 	9   HIToolbox                           0x00007fff9456b7be _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1231
>>>>>> 	10  HIToolbox                           0x00007fff9456ac48 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 404
>>>>>> 	11  HIToolbox                           0x00007fff945809e6 SendEventToEventTarget + 40
>>>>>> 	12  HIToolbox                           0x00007fff945ca99a _ZL18SendHICommandEventjPK9HICommandjjhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef + 411
>>>>>> 	13  HIToolbox                           0x00007fff945dcc2f UpdateHICommandStatusWithCachedEvent + 47
>>>>>> 	14  HIToolbox                           0x00007fff94566deb _ZN13HIApplication12EventHandlerEP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv + 2787
>>>>>> 	15  HIToolbox                           0x00007fff9456b7be _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1231
>>>>>> 	16  HIToolbox                           0x00007fff9456ac48 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 404
>>>>>> 	17  HIToolbox                           0x00007fff945809e6 SendEventToEventTarget + 40
>>>>>> 	18  HIToolbox                           0x00007fff945dc852 _ZL15SendMenuOpeningP14MenuSelectDataP8MenuDatadjjP14__CFDictionaryhPh + 716
>>>>>> 	19  HIToolbox                           0x00007fff945f6d24 _ZL11DrawTheMenuP14MenuSelectDataPP9__CFArrayhPh + 280
>>>>>> 	20  HIToolbox                           0x00007fff945f6a21 _ZL11MenuChangedP14MenuSelectDatahh + 316
>>>>>> 	21  HIToolbox                           0x00007fff94711207 _ZL15TrackMenuCommonR14MenuSelectDataPhP13SelectionDataP10MenuResultS5_ + 1175
>>>>>> 	22  HIToolbox                           0x00007fff945f64fa _ZL14MenuSelectCoreP8MenuData5PointdjPP13OpaqueMenuRefPt + 555
>>>>>> 	23  HIToolbox                           0x00007fff945f6230 _HandleMenuSelection2 + 460
>>>>>> 	24  AppKit                              0x00007fff8c8d575e _NSHandleCarbonMenuEvent + 277
>>>>>> 	25  AppKit                              0x00007fff8c815435 _DPSNextEvent + 1906
>>>>>> 	26  AppKit                              0x00007fff8cbe1943 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454
>>>>>> 	27  R                                   0x000000010f79031c -[RController doProcessEvents:] + 204
>>>>>> 	28  R                                   0x000000010f78a72a -[RController handleReadConsole:] + 186
>>>>>> 	29  R                                   0x000000010f793f99 Re_ReadConsole + 185
>>>>>> 	30  libR.dylib                          0x000000010f9c071f R_ReplDLLdo1 + 143
>>>>>> 	31  R                                   0x000000010f7a2367 run_REngineRmainloop + 295
>>>>>> 	32  R                                   0x000000010f79673a -[REngine runREPL] + 138
>>>>>> 	33  R                                   0x000000010f78574f main + 815
>>>>>> 	34  libdyld.dylib                       0x00007fff8e5e65ad start + 1
>>>>>> 	35  ???                                 0x0000000000000001 0x0 + 1
>>>>>> )
>>>>>> 
>>>>>> The prior error did not seem to affect the visual output of rgl but is troublesome.
>>>>>> 
>>>>>> Joe Kunkel
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -·.  .· ·.  .><((((º>·.  .· ·.  .><((((º>·.  .· ·.  .><((((º> .··.· >=-       =º}}}}}><
>>>>>> Joseph G. Kunkel, Emeritus Professor
>>>>>> Biology Department
>>>>>> UMass Amherst
>>>>>> Amherst MA 01003
>>>>>> joe at bio.umass.edu
>>>>>> 
>>>>>> _______________________________________________
>>>>>> R-SIG-Mac mailing list
>>>>>> R-SIG-Mac at r-project.org
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> R-SIG-Mac mailing list
>>>>> R-SIG-Mac at r-project.org
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>> 
>>> 
>>> _______________________________________________
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac at r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
>> David Winsemius
>> Alameda, CA, USA
>> 
> 

David Winsemius
Alameda, CA, USA



More information about the R-SIG-Mac mailing list