Re: [R-SIG-Mac] Totally frozen Gui and Forced Quit ... resolved.

[Joseph Kunkel]

Bryan,   aha!  … Exactly what I was fishing for in my turmoil … "an R.app 
plist”.  I look forward to that option since the “Open Recent” button is nice 
when it works but cursed when it does not.  Such a plist, I can see, has many 
ramifications to get right.  Thanks again for reviving my productivity.  I love 
the terminal mode for its independence and capacity but the GUI is essential 
for script development and fast turnaround.

Joe

> On Dec 30, 2016, at 7:41 AM, Bryan Hanson <han...@depauw.edu> wrote:
> 
> Excellent Joe.  If you have further problems, there have also been 
> discussions here in the past two months about the recent files list and an 
> R.app plist which can be removed manually, forcing the app to write a fresh 
> copy.  Bryan
> 
>> On Dec 29, 2016, at 11:10 PM, Joseph Kunkel <jkunk...@une.edu> wrote:
>> 
>> Bryan,  Following the directions in section 10.11 I removed every .RData and 
>> .Rhistory in my entire tree with no satisfaction.
>> 
>> Finally, after removing every .Rapp.history ... R failed again but I was 
>> able to exit R ungracefully using option 1. 
>> 
>> On rebooting, R-gui reopened with all the 3 prior R-scripts also opened but 
>> the R-console was not frozen and after closing the R-scripts I q() R and on 
>> reopening I had a normal R-gui and no R-scripts opened.
>> 
>> I had known about the .Rhistory and .Rdata files but they were not the 
>> problem.  The .Rapp.history was the culprit but trying to be logical and 
>> just removing it from the most obvious directories did not work.  I had to 
>> remove every single one.  
>> 
>> Perhaps a clue?  I was unable to remove two of the  ‘.Rapp.history' files 
>> using their file paths in a rm statement.  Looking closely at the path there 
>> was a gramatically-poor directory in both failed removes.
>> One failure had ‘/text file/‘ which had an illegal space in the directory 
>> name and the other failure had another illegal character in a path component 
>> /1&2/.   After I removed those two  ‘.Rapp.history’ files I was able to 
>> break the loop.
>> 
>> Thanks for the URL with directions that included the solution!
>> 
>> In addition I will redouble my conscious use of good unix path names!  OS X 
>> allows navigating through paths that may be easier to read but are traps for 
>> unix command syntax.
>> 
>> Joe
>> 
>> 
>>> On Dec 29, 2016, at 7:56 PM, Bryan Hanson <han...@depauw.edu> wrote:
>>> 
>>> Take a look at section 10.3 and 10.11 in 
>>> https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Miscellaneous-questions
>>> 
>>> I also remove .Rhistory routinely (in addition to the files listed in 
>>> 10.11) when having trouble.
>>> 
>>> If you need assistance finding these files throughout your system using 
>>> terminal, let us know.
>>> 
>>> Another alternative is to get R devel at http://r.research.att.com/ That 
>>> version of the GUI appears to have some fixes.
>>> 
>>> Bryan
>>> 
>>>> On Dec 29, 2016, at 7:46 PM, Joseph Kunkel <jkunk...@une.edu> wrote:
>>>> 
>>>> Dear R-Sig-Mac,
>>>> 
>>>> I have not received any response to my request for help in unlocking my 
>>>> R-gui from its infinite loop.
>>>> 
>>>> To restate it simply.
>>>> 
>>>> 1) I was running the newest version of R as of Dec 19th including the 
>>>> latest R-gui.
>>>> 2) I needed to force-quit R with three R-scripts open.
>>>> 3) On rebooting the R-gui the three scripts are reopened and the R-console 
>>>> is in its active mode without me being able to get its attention or close 
>>>> it without another force quit.
>>>> This is an infinite loop that I have not been able to break.
>>>> 
>>>> I can run R from a terminal window without the conveniences of the gui but 
>>>> as I have proceded from Dec 19 I have discovered that some of the 
>>>> conveniences of the R-gui are truly valuable and I would like to get back 
>>>> to a state where I can use the R-gui.
>>>> 
>>>> Is there anyone back from the Holidays yet who can tell me the minimum I 
>>>> need to do to break the infinite loop?
>>>> 
>>>> Re installing R from CRAN did not work.  There is some log that I need to 
>>>> erase to stop the system from recreating the problem each time I reboot R.
>>>> 
>>>> Joe
>>>> 
>>>>> On Dec 

Re: [R-SIG-Mac] Totally frozen Gui and Forced Quit does not resolve.

[Joseph Kunkel]

Bryan,  Following the directions in section 10.11 I removed every .RData and 
.Rhistory in my entire tree with no satisfaction.

Finally, after removing every .Rapp.history ... R failed again but I was able 
to exit R ungracefully using option 1. 

 On rebooting, R-gui reopened with all the 3 prior R-scripts also opened but 
the R-console was not frozen and after closing the R-scripts I q() R and on 
reopening I had a normal R-gui and no R-scripts opened.

I had known about the .Rhistory and .Rdata files but they were not the problem. 
 The .Rapp.history was the culprit but trying to be logical and just removing 
it from the most obvious directories did not work.  I had to remove every 
single one.  

Perhaps a clue?  I was unable to remove two of the  ‘.Rapp.history' files using 
their file paths in a rm statement.  Looking closely at the path there was a 
gramatically-poor directory in both failed removes.
One failure had ‘/text file/‘ which had an illegal space in the directory name 
and the other failure had another illegal character in a path component /1&2/.  
 After I removed those two  ‘.Rapp.history’ files I was able to break the loop.

Thanks for the URL with directions that included the solution!

In addition I will redouble my conscious use of good unix path names!  OS X 
allows navigating through paths that may be easier to read but are traps for 
unix command syntax.

Joe


> On Dec 29, 2016, at 7:56 PM, Bryan Hanson <han...@depauw.edu> wrote:
> 
> Take a look at section 10.3 and 10.11 in 
> https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Miscellaneous-questions
> 
> I also remove .Rhistory routinely (in addition to the files listed in 10.11) 
> when having trouble.
> 
> If you need assistance finding these files throughout your system using 
> terminal, let us know.
> 
> Another alternative is to get R devel at http://r.research.att.com/ That 
> version of the GUI appears to have some fixes.
> 
> Bryan
> 
>> On Dec 29, 2016, at 7:46 PM, Joseph Kunkel <jkunk...@une.edu> wrote:
>> 
>> Dear R-Sig-Mac,
>> 
>> I have not received any response to my request for help in unlocking my 
>> R-gui from its infinite loop.
>> 
>> To restate it simply.
>> 
>> 1) I was running the newest version of R as of Dec 19th including the latest 
>> R-gui.
>> 2) I needed to force-quit R with three R-scripts open.
>> 3) On rebooting the R-gui the three scripts are reopened and the R-console 
>> is in its active mode without me being able to get its attention or close it 
>> without another force quit.
>> This is an infinite loop that I have not been able to break.
>> 
>> I can run R from a terminal window without the conveniences of the gui but 
>> as I have proceded from Dec 19 I have discovered that some of the 
>> conveniences of the R-gui are truly valuable and I would like to get back to 
>> a state where I can use the R-gui.
>> 
>> Is there anyone back from the Holidays yet who can tell me the minimum I 
>> need to do to break the infinite loop?
>> 
>> Re installing R from CRAN did not work.  There is some log that I need to 
>> erase to stop the system from recreating the problem each time I reboot R.
>> 
>> Joe
>> 
>>> On Dec 19, 2016, at 9:29 AM, Joseph Kunkel <jkunk...@une.edu> wrote:
>>> 
>>> Using the R Gui a ’new' unsolvable situation has arisen.  I have been using 
>>> R almost daily since 2002 acording to my records.  This is the first time I 
>>> have not been able to rectify an R crash. 
>>> 
>>> I am running R version 3.3.2 (2016-10-31) — “Sincere Pumpkin Patch”  on Mac 
>>> Os Sierra Ver 10.12.1 MacBook Pro early 2013 2.7 GHh Intel Core i7, 16 GB 
>>> 1600 MHz DDR3
>>> 
>>> With three R-scripts in their editor windows and one R-script actually 
>>> invoked I needed to force a quit using the Activity Monitor.
>>> 
>>> Then, when the R Gui was re-invoked all the previous Gui windows opened (as 
>>> with previous experiences),  but this time R was still in process with 
>>> activity monitor showing R as non-responsive and rainbow wheel spinning 
>>> whenever a Gui window is hovered.
>>> 
>>> 'Activity monitor' or ‘Dock' force quit does not resolve the above issue.  
>>> Each time R Gui is reinvoked all windows are restored to the R (Non 
>>> Responding) state.  Activity monitor shows 2/3 of a core CPU devoted to R 
>>> with ~125 Mb of memory devoted to R.
>>> 
>>> Previously the R Gui R-script windows could be closed and when R was closed 
>>> and reopened ‘normal’ R-Gui opening could be invoked.
>>> 
>>>

Re: [R-SIG-Mac] Totally frozen Gui and Forced Quit does not resolve.

[Joseph Kunkel]

Dear R-Sig-Mac,

I have not received any response to my request for help in unlocking my R-gui 
from its infinite loop.

To restate it simply.

1) I was running the newest version of R as of Dec 19th including the latest 
R-gui.
2) I needed to force-quit R with three R-scripts open.
3) On rebooting the R-gui the three scripts are reopened and the R-console is 
in its active mode without me being able to get its attention or close it 
without another force quit.
This is an infinite loop that I have not been able to break.

I can run R from a terminal window without the conveniences of the gui but as I 
have proceded from Dec 19 I have discovered that some of the conveniences of 
the R-gui are truly valuable and I would like to get back to a state where I 
can use the R-gui.

Is there anyone back from the Holidays yet who can tell me the minimum I need 
to do to break the infinite loop?

Re installing R from CRAN did not work.  There is some log that I need to erase 
to stop the system from recreating the problem each time I reboot R.

Joe

> On Dec 19, 2016, at 9:29 AM, Joseph Kunkel <jkunk...@une.edu> wrote:
> 
> Using the R Gui a ’new' unsolvable situation has arisen.  I have been using R 
> almost daily since 2002 acording to my records.  This is the first time I 
> have not been able to rectify an R crash. 
> 
> I am running R version 3.3.2 (2016-10-31) — “Sincere Pumpkin Patch”  on Mac 
> Os Sierra Ver 10.12.1 MacBook Pro early 2013 2.7 GHh Intel Core i7, 16 GB 
> 1600 MHz DDR3
> 
> With three R-scripts in their editor windows and one R-script actually 
> invoked I needed to force a quit using the Activity Monitor.
> 
> Then, when the R Gui was re-invoked all the previous Gui windows opened (as 
> with previous experiences),  but this time R was still in process with 
> activity monitor showing R as non-responsive and rainbow wheel spinning 
> whenever a Gui window is hovered.
> 
> 'Activity monitor' or ‘Dock' force quit does not resolve the above issue.  
> Each time R Gui is reinvoked all windows are restored to the R (Non 
> Responding) state.  Activity monitor shows 2/3 of a core CPU devoted to R 
> with ~125 Mb of memory devoted to R.
> 
> Previously the R Gui R-script windows could be closed and when R was closed 
> and reopened ‘normal’ R-Gui opening could be invoked.
> 
> *** I have deleted R.app from the Applications Folder and reinstalled R 
> version 3.3.2 (2016-10-31) — “Sincere Pumpkin Patch” but seemingly the 
> residual logs extant at the last ‘force quit’ still exist and invoking the 
> R-gui re-establishes the R (Non Responding) state.
> 
> Terminal R and RStudio still work but I would rather use the R Gui, which had 
> been working well for me in the latest versions.
> 
> Can I identify 'the residual logs’ of the R-gui and erase or reset them to a 
> 'fresh start’ state?
> 
> I do not know where to go from this impasse other than using one of my other 
> lower grade computers or wiping my computer and reinstalling the Mac Os.
> 
> Is there a link to directions for a more serious cleaning of R files and logs 
> before I reinstall R?  I would guess that the R link in the R.app Contents 
> directory might invoke more deeply embedded R files that need to be 
> scrubbed/reset?
> 
> Joe Kunkel
> 
> -·.  .· ·.  .><º>·.  .· ·.  .><º>·.  .· ·.  .><º> .··.· >=-   
> =º}><
> Joseph G. Kunkel, Research Professor
> 112A Marine Science Center
> University of New England
> Biddeford ME 04005
> http://www.bio.umass.edu/biology/kunkel/
> 

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Problem using the R.app GUI Package Installer

[Joseph Kunkel]

I got this error message working under R version 3.3.0  trying to use the Mac 
[R.app GUI 1.68 (7238) x86_64-apple-darwin13.4.0]  Packages & Data/ Package 
Installer

R error message:
Warning: unable to access index for repository 
http://cran.at.r-project.org/bin/macosx/mavericks/contrib/3.3:  cannot open URL 
'http://cran.at.r-project.org/bin/macosx/mavericks/contrib/3.3/PACKAGES'

I checked for upgrades and installed R version 3.3.1

I got the same error message once again.

Luckily I remembered that I could install libraries from within R and thus used:

> install.packages('RCurl', dependencies=TRUE, repos='http://cran.rstudio.com/')

But I am wondering if the malfunction of the GUI approach is something I can 
fix or is temporary?

Joe

-·.  .· ·.  .><º>·.  .· ·.  .><º>·.  .· ·.  .><º> .··.· >=-   
=º}><
Joseph G. Kunkel, Research Professor
112A Marine Science Center
University of New England
Biddeford ME 04005
http://www.bio.umass.edu/biology/kunkel/

This e-mail may contain information that is privileged and confidential. If you 
suspect that you were not the intended recipient, please delete it and notify 
the sender as soon as possible.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Save History Not Implemented?

[Joseph Kunkel]

I report new clues to lock-up of Mac R-GUI:

  Model Name:MacBook Pro
  Model Identifier:MacBookPro10,1
  Processor Name:Intel Core i7
  Processor Speed:2.7 GHz
  Number of Processors:1
  Total Number of Cores:4
  L2 Cache (per Core):256 KB
  L3 Cache:6 MB
  Memory:16 GB
  Boot ROM Version:MBP101.00EE.B0A
  SMC Version (system):2.3f36
  Serial Number (system):C02KP40GFFT1
  Hardware UUID:1C991826-2C15-5AF1-8C81-1F69F51034A1

R for Mac OS X GUI 1.67-devel Mavericks build

R for Mac OS X GUI written by:
Simon Urbanek
Hans-Jörg Bibiko
Stefano M. Iacus

I installed R in my MacBook Pro (Retina, 15-inch, Early 2013).  I have been 
using R since mid 2000s and started using the OS X GUI fairly early in my R 
experience and value its organization of my R use.

About a year ago I started having interuptions in my R-GUI use where it locks 
up.  All of several past interactions on the R-SIG-MAC so far have not 
eliminated this locking up.  In the latest go-around it was terminated with the 
idea that it was related to my use of large data sets and long calculations 
particularly ones that also used the rgl library.

As part of the drama of R Mac OS X GUI locking up, which has not been resolved 
for me yet, I now discovered new clues in the past month during which I have 
not used rgl.

1) When I boot R-GUI anew  the File/Open Recent has no entries.
… if I do a carriage-return at the R prompt the File/Open Recent list is 
populated.
2) The history for the active workspace has not been working for me.  It only 
loads the history that was collected in some earlier work directory. It does 
not save the current history in either an older directory or the (currently set 
in R/Preferences/General/Startup/Directory[x]Always_apply) current work 
directory .
3) When I try to save the current history using the > savehistory(file = 
".Rhistory”) or simply  > savehistory() … I get the following message:

##

 > savehistory(file = ".Rhistory”)
Error in .External2(C_savehistory, file) :
  'savehistory' is not currently implemented

#

I have only made changes to R operation through R-GUI Preferences.  Is there 
something going wrong with the history functions in the GUI?

Work is slowed by lack of a useful history and continued need to reboot R in a 
complicated way each time the GUI locks up.

When I run R in a terminal at my home directory,  history works as advertised 
after I have done some work and q() with a save … then reboot R in terminal and 
use up-arrow to retrieve old R statements.

4) I reiterate the tedious procedure for rebooting after a lock-up of GUI 
typically with a few R-scripts open in editors:
 a) kill the R process ID
 b) reboot the R-GUI, which by default loads the previously open R-scripts.
 c) close those R-scripts and do not do any R-work.
 d) quit()
 e) reboot the R-GUI and close it immediately with another q() {otherwise go 
back to step ‘a’.}
 f) reboot the R-GUI and resume R-work {with no history … as usual} e.g. load a 
script into the editor, edit and run it.  But, avoid trying to load another 
R-script into the ediitor after having run the one script.
 … The scripts used are what I would call regular scripts accessing 
relatively small data sets and plotting results and _not_ using the difficult 
rgl library.

I am not sure how many other users are experiencing the same symptoms.

Joe

-·.  .· ·.  .><º>·.  .· ·.  .><º>·.  .· ·.  .><º> .··.· >=-   
=º}><
Joseph G. Kunkel, Research Professor
112A Marine Science Center
University of New England
Biddeford ME 04005
http://www.bio.umass.edu/biology/kunkel/

This e-mail may contain information that is privileged and confidential. If you 
suspect that you were not the intended recipient, please delete it and notify 
the sender as soon as possible.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Cut and paste from Email issues

[Joseph Kunkel]

The major issue I have found with using cut-and-paste of R-scripts  or lines 
from Email is the quotes which often use symetrical quotes rather than the 
appropriate identical quote symbol.

You can cut and paste but edit the quotes to be the appropriate R-quote symbol 
and most of the time that works.

I am not sure that simply using plain-text helps the issue … it is the symetry 
of the quote symbol that creates the problem.

Joe

-·.  .· ·.  .><º>·.  .· ·.  .><º>·.  .· ·.  .><º> .··.· >=-   
=º}><
Joseph G. Kunkel, Emeritus Professor
Biology Department
UMass Amherst 
Amherst MA 01003
j...@bio.umass.edu

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] R GUI is freezing

[Joseph Kunkel]

Sorry, but the freezing of the R-gui still persists:

Previously I had downloaded the latest version of R from the CRAN directory for 
my Os X  MacBook Pro (Retina, 15-inch, Early 2013). The R-gui check on R 
upgrades suggested my R was up-to-date with no upgrades available.

In that situation I experienced the R-gui freeze-up that I and others have 
alluded to before.

On Duncans advice (Feb 11, 2 days ago) I tried the suggested nightly build and 
then ran one of my R scripts from the initial directory I had set in the R-gui 
preferences menu R-startup menu which was still the default det from the 
previous build.   R opened with the appropriately set working directory:

R version 3.2.3 (2015-12-10) -- "Wooden Christmas-Tree”
…
[R.app GUI 1.67 (7128) x86_64-apple-darwin13.4.0]

I then ran a R-script to completion. … {I read somewhere that garbage 
collection is automatic and forcing it is only informational and does not 
improve a situation}. Despite that I have tried garbage collection.  ...  And I 
then tried to load another R-script into the editor from the same working 
directory.

The R-gui froze with a rotating rainbow icon.

I use my Terminal window to find and kill the R-process:

Josephs-MacBook-Pro:~ josephgkunkel$ ps -x
...
6533 ?? 9:44.90 /Applications/R.app/Contents/MacOS/R

Josephs-MacBook-Pro:~ josephgkunkel$ kill 6533

I then rebooted R:

R version 3.2.3 (2015-12-10) -- "Wooden Christmas-Tree”
…
[R.app GUI 1.67 (7128) x86_64-apple-darwin13.4.0]

[Workspace restored from 
/Users/josephgkunkel/Documents/Analysis/AVI_M2C_0.5/spiral/spiral1a/.RData]
[History restored from 
/Users/josephgkunkel/Documents/Analysis/AVI_M2C_0.5/spiral/spiral1a/.Rapp.history]

In addition the R-script that had been loaded into the editor at the freeze was 
auto-loaded.

At this point I try to load the new R-script that I had wanted to load when the 
R-gui froze. ...

The R-gui freezes again (because I did not close the opened R-script and close 
R and reopen it before trying to load the new R-script.

{Something is wrong with the gui at this point!  Something, such as a log, 
saved prior to the R-gui freezing is now directing things.  Why else would a 
new reboot result in a freezup with a ordinary operation. }

To run R successfully I must (1) re-kill the R process. (2) Boot the R-gui.  
(3) Close any R-scripts that are brought up in the default editor. (4) Close 
the R-gui using the gui red-dot icon or q(). (5) Reboot the R-gui.  

When opened in this manner I can load several R-scripts into the editor but 
after running any substantial R-script I should not try to load another into 
the editor -or- change the working directory.

I can run another R-script.

QUESTION to Duncan:  Is the above reported R version and GUI version not yet 
the correct R-gui build?

One clue?   After a freeze and reboot of R, the Rgui pulldown menu 
"File/Recent" initially shows "Clear Menu” rather than a list.   Retry still 
gives "Clear Menu”.
   After looking there repeatedly and getting "Clear Menu” and one 'goes 
somewhere else and does something else' and then comes back  to "File/Recent”, 
a list of appropriate old loads now appears ‘automagically’.  Then the loading 
of a new R-script works from this list ... but not via the “Open in Editor” 
icon. 

Another clue:  The R-scripts I run are often pretty heavy rgl library 3d 
function plotting programs that load v. large data sets and then in some cases 
create rotating movies that generate frames that are saved … the whole process 
taking up to an hour+.  Could this lead to 'memory leaks' that stomp on 
critical log files or parameters/variables that save critical info for process 
survival?  Occasinally the R process complains that I need to shut down 
non-essential processes that are using valuable memory.

Shorter uses of rgl do not cause gui freezes however the protocol to recover 
from a gui freeze is still disconcertingly laborious.  
 
Joe

-·.  .· ·.  .><º>·.  .· ·.  .><º>·.  .· ·.  .><º> .··.· >=-   
=º}><
Joseph G. Kunkel, Research Professor
112A Marine Science Center
University of New England
Biddeford ME 04005
http://www.bio.umass.edu/biology/kunkel/

> On Feb 11, 2016, at 11:17 AM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:
> 
> On 11/02/2016 10:50 AM, Joseph Kunkel wrote:
>> I have the same problem over many updates of R for my Mac.   After I load 
>> one R-script into the editor and run it, trying to open another script or 
>> trying to change my working directory results in R-gui freeze up.  In 
>> rebooting R I end up with the old R-script coming up in the editor and I 
>> must close it and close R once again before I can reboot R yet once again 
>> and start working bing aware that I must not try to open anothe R-scrip in 
>> the editor after a script has run or R-gui will lock up again.
&

Re: [R-SIG-Mac] R GUI is freezing

[Joseph Kunkel]

I have the same problem over many updates of R for my Mac.   After I load one 
R-script into the editor and run it, trying to open another script or trying to 
change my working directory results in R-gui freeze up.  In rebooting R I end 
up with the old R-script coming up in the editor and I must close it and close 
R once again before I can reboot R yet once again and start working bing aware 
that I must not try to open anothe R-scrip in the editor after a script has run 
or R-gui will lock up again.

With respect to the suggestion to 'tr(Y) recent nightly builds from 
http://r.research.att.com/', it is the developer’s page and the link to the 
R-gui nightly build loops back to the same page with no clear option of how to 
load a new build of the R-gui.

There seems to be a hell-hole of problems with the recent updates of R.  But my 
ver R 3.2.3 GUI 1.66 Mavericks build (7060) query  says that I am up to date 
with nothing to upgrade.  I would choose not to upgrade entire R if it is 
having problems with its ‘nightly build’.

??? what to do with this problem which was ignored the last time I posted it, 
similar to Dr. Swan’s experience.

Joe

-·.  .· ·.  .><º>·.  .· ·.  .><º>·.  .· ·.  .><º> .··.· >=-   
=º}><
Joseph G. Kunkel, Research Professor
112A Marine Science Center
University of New England
Biddeford ME 04005
http://www.bio.umass.edu/biology/kunkel/

> On Feb 11, 2016, at 10:22 AM, Duncan Murdoch  wrote:
> 
> Have you tried recent nightly builds from http://r.research.att.com/?  Some 
> bugs with the data editor were recently fixed; I think those were specific to 
> it, but maybe more got fixed at the same time.
> 
> Duncan Murdoch
> 
> On 11/02/2016 10:07 AM, Chris Swan wrote:
>> No - never got a solution -
>> 
>> ---
>> Christopher M. Swan, Ph.D.
>> Professor
>> Dept. of Geography & Environmental Systems
>> University of Maryland, Baltimore County
>> 211 Sondheim Hall
>> 1000 Hilltop Circle
>> Baltimore, MD 21250 USA
>> http://biodiversity.umbc.edu
>> http://orcid.org/-0002-9763-9630
>> http://scholar.google.com/citations?user=NNfHt5YJ
>> 1.410.455.3957
>> 
>> > On Aug 6, 2015, at 8:23 PM, Moriarty,Vincent W  
>> > wrote:
>> >
>> > Hi Christopher,
>> >
>> > I just came across your post online concerning R freezing. I’ve been 
>> > having this same problem for many months now over multiple machines. Did 
>> > you ever find a satisfactory answer for this issue?
>> >
>> >
>> > Cheers,
>> >
>> > Vincent
>> >
>> >
>> > ___
>> > 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 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] Multiple cores on a Mac

[Joseph Kunkel]

Wow, thanks guys.  I am back to original speed with matrix operations as 
documented here.  As noted previously, this includes the 4 fold basic slowing 
of matrix operations on a single processor that occurred at the time of the 
change ~2012(?).  So I have approx 80/5 = 16 fold improvement!!!   I can do 
experiments and do a new experiment tomorrow based on the calculation!!!

Tests applied today II_5_2016:

*Test without vecLib option
 > source("http://www.bio.umass.edu/biology/kunkel/pub/R/CuriousResult.R;)
 matrix multiplication  80.516   1.338   81.22 
 tcrossprod 79.999   1.366  80.734 
 transposition and reuse14.303   2.323   16.52 
 elementwise after reshape  11.088   1.776  12.774 
 columnwise sapply22.781   9.631  32.137 
 for loop over columns  23.976   7.811  31.507 
 >q()
*apply unix adjustment # for vecLib use
> source("http://www.bio.umass.edu/biology/kunkel/pub/R/CuriousResult.R;)
 matrix multiplication  19.595   1.188   5.389 
 tcrossprod 19   1.175   4.702 
 transposition and reuse14.113   2.416  16.432 
 elementwise after reshape  11.102   1.764  12.798 
 columnwise sapply21.747   9.125  30.683 
 for loop over columns  23.243   6.458  29.515 

I have renewed faith!
Joe

> On Feb 5, 2016, at 10:20 AM, Bryan Hanson <han...@depauw.edu> wrote:
> 
> On El Cap you can still pull off the symlink approach, as described here, 
> without building R fresh:
> 
> http://blog.quadrivio.com/2015/06/improved-r-performance-with-openblas.html
> 
> The next time you launch R you will have the library you specified.
> 
> Bryan
> 
>> On Feb 5, 2016, at 10:03 AM, peter dalgaard <pda...@gmail.com> wrote:
>> 
>> Why me..?
>> 
>> Probably Simon and maybe Brian has the full recollection of the story, but 
>> as I understood it, once upon a time you could switch out the BLAS on CRAN R 
>> just by editing a symlink in the R installation. For some reason, that 
>> cannot work anymore (Apple considered symlinked libraries a security risk?). 
>> I think the current situation is that you can still do it, but you have to 
>> physically overwrite the default BLAS(? Simon will know.). 
>> 
>> At any rate, you can certainly still do a local compile with the Accelerate 
>> framework, once you get all the tools in place:
>> 
>>> M <- matrix(rnorm(1e8),1)
>>> system.time(M %*% t(M))
>>  user  system elapsed 
>> 219.566   0.806  21.752 
>>> M <- crossprod(M)
>>> system.time(solve(M))
>>  user  system elapsed 
>> 310.874   1.477  29.998 
>> 
>> (To tell the truth, I actually don't have all the tools in place on that 
>> machine, so this was from a build of 3.2.1 patched)
>> 
>> -pd
>> 
>> On 05 Feb 2016, at 14:52 , Joseph Kunkel <j...@bio.umass.edu> wrote:
>> 
>>> To me there are big gorillas in the room and I need to know why I can not 
>>> use them all.
>>> 
>>> • Testing for physical and logical cpus on Joe's MacBook Pro.
>>> Josephs-MacBook-Pro:~ josephgkunkel$ /usr/sbin/sysctl -n hw.physicalcpu
>>> 4
>>> Josephs-MacBook-Pro:~ josephgkunkel$ /usr/sbin/sysctl -n hw.logicalcpu
>>> 8
>>> 
>>> Prior to about 2012 my multicore Macs would use all (physical) cores 
>>> automagically in R.  %*% was multicore automatically.
>>> 
>>> A 24 hour heavy matrix calculation would take a little over 6 hours on a 4 
>>> core Mac.
>>> 
>>> Then some problem with the BLAS library changed everything and colleague 
>>> stats people and I got really mad that we could not do our calculations as 
>>> fast in R.
>>> 
>>> Many work-around libraries were devised which did not seem to be that 
>>> useful for freewielding matrix operations.
>>> 
>>> Then Revolution R seemed to solve the problem and patented(?) it.  … but 
>>> not for Macs.
>>> 
>>> Recently they provided a free Mac version but using their R ‘open' version 
>>> messes up my computer for updating the libraries I am addicted to using.
>>> 
>>> My question after this appologeticlay long narrative is:
>>> 
>>> Why has no satisfactory and transparent method for multicore use been 
>>> available to CRAN R?
>>> 
>>> Secondarily,  how could our R open software system be hijacked by 
>>> Revolution and now Microsoft?
>>> 
>>> I would be pleased to know that there are colleagues out there who are 
>>> similarly hoping for an R core solution within CRAN.
>>> 
>>> I can do primitive matrix things faster wit

[R-SIG-Mac] Multiple cores on a Mac

[Joseph Kunkel]

To me there are big gorillas in the room and I need to know why I can not use 
them all.

• Testing for physical and logical cpus on Joe's MacBook Pro.
Josephs-MacBook-Pro:~ josephgkunkel$ /usr/sbin/sysctl -n hw.physicalcpu
4
Josephs-MacBook-Pro:~ josephgkunkel$ /usr/sbin/sysctl -n hw.logicalcpu
8

Prior to about 2012 my multicore Macs would use all (physical) cores 
automagically in R.  %*% was multicore automatically.

A 24 hour heavy matrix calculation would take a little over 6 hours on a 4 core 
Mac.

Then some problem with the BLAS library changed everything and colleague stats 
people and I got really mad that we could not do our calculations as fast in R.

Many work-around libraries were devised which did not seem to be that useful 
for freewielding matrix operations.

Then Revolution R seemed to solve the problem and patented(?) it.  … but not 
for Macs.

Recently they provided a free Mac version but using their R ‘open' version 
messes up my computer for updating the libraries I am addicted to using.

My question after this appologeticlay long narrative is:

Why has no satisfactory and transparent method for multicore use been available 
to CRAN R?

Secondarily,  how could our R open software system be hijacked by Revolution 
and now Microsoft?

I would be pleased to know that there are colleagues out there who are 
similarly hoping for an R core solution within CRAN.

I can do primitive matrix things faster with Julia, which is encouraging, but 
the libraries and flexability for me are not there yet.

Joe

-·.  .· ·.  .><º>·.  .· ·.  .><º>·.  .· ·.  .><º> .··.· >=-   
=º}><
Joseph G. Kunkel, Research Professor
112A Marine Science Center
University of New England
Biddeford ME 04005
http://www.bio.umass.edu/biology/kunkel/

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

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

[Joseph Kunkel]

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.

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.

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  0x7fff92e77ae2 
__exceptionPreprocess + 178
1   libobjc.A.dylib 0x7fff91c7d73c 
objc_exception_throw + 48
2   CoreFoundation  0x7fff92e7ab9d 
-[NSObject(NSObject) doesNotRecognizeSelector:] + 205
3   CoreFoundation  0x7fff92db3601 
___forwarding___ + 1009
4   CoreFoundation  0x7fff92db3188 
_CF_forwarding_prep_0 + 120
5   R   0x00010f78f1aa 
-[RController validateMenuItem:] + 1002
6   AppKit  0x7fff8c9a66f6 -[NSMenu 
_enableItem:] + 706
7   AppKit  0x7fff8c9b8152 
-[NSCarbonMenuImpl _carbonUpdateStatusEvent:handlerCallRef:] + 517
8   AppKit  0x7fff8c9aaea1 
NSSLMMenuEventHandler + 708
9   HIToolbox   0x7fff9456b7be 
_ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec 
+ 1231
10  HIToolbox   0x7fff9456ac48 
_ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec
 + 404
11  HIToolbox   0x7fff945809e6 
SendEventToEventTarget + 40
12  HIToolbox   0x7fff945ca99a 
_ZL18SendHICommandEventjPK9HICommandjjhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef
 + 411
13  HIToolbox   0x7fff945dcc2f 
UpdateHICommandStatusWithCachedEvent + 47
14  HIToolbox   0x7fff94566deb 
_ZN13HIApplication12EventHandlerEP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv
 + 2787
15  HIToolbox   0x7fff9456b7be 
_ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec 
+ 1231
16  HIToolbox   0x7fff9456ac48 
_ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec
 + 404
17  HIToolbox   0x7fff945809e6 
SendEventToEventTarget + 40
18  HIToolbox   0x7fff945dc852 
_ZL15SendMenuOpeningP14MenuSelectDataP8MenuDatadjjP14__CFDictionaryhPh + 716
19  HIToolbox   0x7fff945f6d24 
_ZL11DrawTheMenuP14MenuSelectDataPP9__CFArrayhPh + 280
20  HIToolbox   0x7fff945f6a21 
_ZL11MenuChangedP14MenuSelectDatahh + 316
21  HIToolbox   0x7fff94711207 
_ZL15TrackMenuCommonR14MenuSelectDataPhP13SelectionDataP10MenuResultS5_ + 1175
22  HIToolbox   0x7fff945f64fa 
_ZL14MenuSelectCoreP8MenuData5PointdjPP13OpaqueMenuRefPt + 555
23  HIToolbox   0x7fff945f6230 
_HandleMenuSelection2 + 460
24  AppKit  0x7fff8c8d575e 
_NSHandleCarbonMenuEvent + 277
25  AppKit  0x7fff8c815435 
_DPSNextEvent + 1906
26  AppKit  0x7fff8cbe1943 
-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454
27  R   0x00010f79031c 
-[RController doProcessEvents:] + 204
28  R   0x00010f78a72a 
-[RController handleReadConsole:] + 186
29  R   0x00010f793f99 
Re_ReadConsole + 185
30  libR.dylib  0x00010f9c071f R_ReplDLLdo1 
+ 143
31  R   0x00010f7a2367 
run_REngineRmainloop + 295
32  R   0x00010f79673a -[REngine 
runREPL] + 138
33  R   0x00010f78574f main + 815
34  libdyld.dylib   0x7fff8e5e65ad start + 1
35  ??? 0x0001 0x0 + 1
)

The 

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

[Joseph Kunkel]

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. 

Thanks for the quick view of the error codes.

Joe Kunkel

> On Jan 2, 2016, at 11:47 AM, Duncan Murdoch <murdoch.dun...@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  0x7fff92e77ae2 
>> __exceptionPreprocess + 178
>>  1   libobjc.A.dylib 0x7fff91c7d73c 
>> objc_exception_throw + 48
>>  2   CoreFoundation  0x7fff92e7ab9d 
>> -[NSObject(NSObject) doesNotRecognizeSelector:] + 205
>>  3   CoreFoundation  0x7fff92db3601 
>> ___forwarding___ + 1009
>>  4   CoreFoundation  0x7fff92db3188 
>> _CF_forwarding_prep_0 + 120
>>  5   R   0x00010f78f1aa 
>> -[RController validateMenuItem:] + 1002
>>  6   AppKit  0x7fff8c9a66f6 -[NSMenu 
>> _enableItem:] + 706
>>  7   AppKit  0x7fff8c9b8152 
>> -[NSCarbonMenuImpl _carbonUpdateStatusEvent:handlerCallRef:] + 517
>>  8   AppKit  0x7fff8c9aaea1 
>> NSSLMMenuEventHandler + 708
>>  9   HIToolbox   0x7fff9456b7be 
>> _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec
>>  + 1231
>>  10  HIToolbox   0x7fff9456ac48 
>> _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec
>>  + 404
>>  11  HIToolbox   0x7fff945809e6 
>> SendEventToEventTarget + 40
>>  12  HIToolbox   0x7fff945ca99a 
>> _ZL18SendHICommandEventjPK9HICommandjjhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef
>>  + 411
>>  13  HIToolbox   0x7fff945dcc2f 
>> UpdateHICommandStatusWithCachedEvent + 47
>>  14  HIToolbox   0x7fff94566deb 
>> _ZN13HIApplication12EventHandlerEP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv
>>  + 2787
>>  15  HIToolbox   0x7fff9456b7be 
>> _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec
>>  + 1231
>>  16  HIToolbox   0x7fff9456ac48 
>> _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec
>>  + 404
>>  17  HIToolbox   0x7fff945809e6 
>> SendEventToEventTarget + 40
>>  18  HIToolbox   0x7fff945dc852 
>> _ZL15SendMenuOpeningP14MenuSelectDataP8MenuDatadjjP14__CFDictionaryhPh + 716
>>  19  HIToolbox   0x7fff945f6d24 
>> _ZL11DrawTheMenuP14MenuSelectDataPP9__CFArrayhPh + 280
>>  20  HIToolbox   0x7fff945f6a21 
>> _ZL11MenuChangedP14MenuSelectDatahh + 316
>>  21  HIToolbox   0x7fff94711207 
>> _ZL15TrackMenuCommonR14MenuSelectDataPhP13SelectionDataP10MenuResultS5_ + 
>> 1175
>>  22  HIToolbox   0x7fff945f64fa 
>> _ZL14MenuSelectCoreP8MenuData5Poin

[R-SIG-Mac] R FAQ 10.5 fails for R ver 3.3.3 on Yosemite

[Joseph Kunkel]

 On Nov 22, 2014, at 6:00 AM, r-sig-mac-requ...@r-project.org wrote:
 
 There is FAQ 10.5 Which BLAS is used and how can it be changed? for the 
 first part.
 iomp is a bit involved, since you have to build it in the first place, but 
 I'm working on making it part of the CRAN binaries in the near future.
 
 Cheers,
 Simon
 
FAQ “10.5 recommends using a dylib file that was not included in my binary 
installation.

I have installed R version 3.1.1 (2014-07-10) -- Sock it to Me”

I followed the FAQ 10.5 instruction:
cd /Library/Frameworks/R.framework/Resources/lib
ln -sf libRblas.vecLib.dylib libRblas.dylib
R
  dyld: Library not loaded: 
/Library/Frameworks/R.framework/Versions/3.1/Resources/lib/libRblas.dylib
  Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R
 Reason: image not found
 Trace/BPT trap: 5

When I replace the R BLAS  R promptly works.

locate libRblas.vecLib.dylib   finds nothing.

Does this aspect of the FAQ apply to R ver 3.1.1 on Yosemite?

Joe

-·.  .· ·.  .º·.  .· ·.  .º·.  .· ·.  .º .··.· =-   
=º}
Joseph G. Kunkel, Emeritus Professor
Biology Department
UMass Amherst 
Amherst MA 01003
j...@bio.umass.edu




[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Problem with understanding red high lit meta-communication from the R Mac GUI

[Joseph Kunkel]

I am using R 3.1.1 GUI 1.65 Snow Leopard build (6784)

on a MacBook Pro, Retina, 15-inch, Early 2013, 
Processor  2.7 GHz Intel Core i7
Graphics  NVIDIA GeForce GT 650M 1024 MB
Software  OS X 10.9.4 (13E28)

The following response appears periodically in the R console window after I 
have completed an R-script source(“example.R) call of no particular sort 


2014-08-03 21:53:39.916 R[16844:707] -deltaZ is deprecated for 
NSEventTypeMagnify.  Please use -magnification.”

I am not sure how to respond


-·.  .· ·.  .º·.  .· ·.  .º·.  .· ·.  .º .··.· =-   
=º}
Joseph G. Kunkel, Research Professor
112A Marine Science Center
University of New England
Biddeford ME 04005
http://www.bio.umass.edu/biology/kunkel/


[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Difference between Terminal output and GUI output.

[Joseph Kunkel]

Dear R-sig-Mac,

Sorry, this was sent via another email(non-SIG-member instance) and I am 
resending this in order to get consideration perhaps more quickly.

I have a problem with output from the R.app GUI which is at odds in part with 
the Terminal console output which I prefer.  The GUI does debug requests 
interspersed with the desired output.

My system is:

 Model Name:   MacBook Pro
 Model Identifier: MacBookPro10,1
 Processor Name:   Intel Core i7
 Processor Speed:  2.7 GHz
 Number of Processors: 1
 Total Number of Cores:4
 L2 Cache (per Core):  256 KB
 L3 Cache: 6 MB
 Memory:   16 GB
System Software Overview:
System Version:OS X 10.9.4 (13E28)
Kernel Version:Darwin 13.3.0

R version 3.1.1 (2014-07-10) -- Sock it to Me
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin10.8.0 (64-bit)

R.app GUI 1.65 (6784 Snow Leopard build), S.

An R-script accesses an array XX which has ...

 attributes(XX)
$dim
[1] 12  3  8

The R-script that gives me the problem:
# GetCL.R
for (i in 1:4) { out- round(((sum((XX[3,,i]-XX[10,,i])^2))^0.5 + 
(sum((XX[2,,i]-XX[10,,i])^2))^0.5)/2,3)
   cat(out,'\n')
   }

The correct output obtained in Terminal mode is:

 source(GetCL.R)
35.791
35.811
44.625
43.316

In the GUI I get:

 source(GetCL.R)
debug at GetCL.R#3: out - round(((sum((XX[3, , i] - XX[10, , i])^2))^0.5 + 
(sum((XX[2,
   , i] - XX[10, , i])^2))^0.5)/2, 3)
Browse[2]
debug at GetCL.R#4: cat(out, \n)
Browse[2]
35.791
debug at GetCL.R#3: out - round(((sum((XX[3, , i] - XX[10, , i])^2))^0.5 + 
(sum((XX[2,
   , i] - XX[10, , i])^2))^0.5)/2, 3)
Browse[2]
debug at GetCL.R#4: cat(out, \n)
Browse[2]
35.811
debug at GetCL.R#3: out - round(((sum((XX[3, , i] - XX[10, , i])^2))^0.5 + 
(sum((XX[2,
   , i] - XX[10, , i])^2))^0.5)/2, 3)
Browse[2]
debug at GetCL.R#4: cat(out, \n)
Browse[2]
44.625
debug at GetCL.R#3: out - round(((sum((XX[3, , i] - XX[10, , i])^2))^0.5 + 
(sum((XX[2,
   , i] - XX[10, , i])^2))^0.5)/2, 3)
Browse[2]
debug at GetCL.R#4: cat(out, \n)
Browse[2]
43.316

Of course this output gets more tedious if I try to process the entire array by 
running for i in 1:larger-n.
Is there any way to get rid of these debug and browse messages messages in GUI 
mode?
I have never experienced this debug output in my ca. 12+ years of using R 
intensely.

I just recently upgraded to R version 3.1.1 (2014-07-10) and renewed all my 
libraries.

-·.  .· ·.  .º·.  .· ·.  .º·.  .· ·.  .º .··.· =-   
=º}
Joseph G. Kunkel, Emeritus Professor
Biology Department
UMass Amherst 
Amherst MA 01003
j...@bio.umass.edu

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Difference between Terminal output and GUI output.

[Joseph Kunkel]

Dear R-sig-Mac, 

I have a problem with output from the R.app GUI which is at odds in part with 
the Terminal console output which I prefer.  The GUI does debug requests 
interspersed with the desired output. 

My system is:

  Model Name:   MacBook Pro
  Model Identifier: MacBookPro10,1
  Processor Name:   Intel Core i7
  Processor Speed:  2.7 GHz
  Number of Processors: 1
  Total Number of Cores:4
  L2 Cache (per Core):  256 KB
  L3 Cache: 6 MB
  Memory:   16 GB
System Software Overview:
 System Version:OS X 10.9.4 (13E28)
 Kernel Version:Darwin 13.3.0

R version 3.1.1 (2014-07-10) -- Sock it to Me
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin10.8.0 (64-bit)

R.app GUI 1.65 (6784 Snow Leopard build), S. 

An R-script accesses an array XX which has ...

 attributes(XX)
$dim
[1] 12  3  8

The R-script that gives me the problem:
# GetCL.R
for (i in 1:4) { out- round(((sum((XX[3,,i]-XX[10,,i])^2))^0.5 + 
(sum((XX[2,,i]-XX[10,,i])^2))^0.5)/2,3)
cat(out,'\n')
}

The correct output obtained in Terminal mode is:

 source(GetCL.R)
35.791 
35.811 
44.625 
43.316 

In the GUI I get:

 source(GetCL.R)
debug at GetCL.R#3: out - round(((sum((XX[3, , i] - XX[10, , i])^2))^0.5 + 
(sum((XX[2, 
, i] - XX[10, , i])^2))^0.5)/2, 3)
Browse[2] 
debug at GetCL.R#4: cat(out, \n)
Browse[2] 
35.791 
debug at GetCL.R#3: out - round(((sum((XX[3, , i] - XX[10, , i])^2))^0.5 + 
(sum((XX[2, 
, i] - XX[10, , i])^2))^0.5)/2, 3)
Browse[2] 
debug at GetCL.R#4: cat(out, \n)
Browse[2] 
35.811 
debug at GetCL.R#3: out - round(((sum((XX[3, , i] - XX[10, , i])^2))^0.5 + 
(sum((XX[2, 
, i] - XX[10, , i])^2))^0.5)/2, 3)
Browse[2] 
debug at GetCL.R#4: cat(out, \n)
Browse[2] 
44.625 
debug at GetCL.R#3: out - round(((sum((XX[3, , i] - XX[10, , i])^2))^0.5 + 
(sum((XX[2, 
, i] - XX[10, , i])^2))^0.5)/2, 3)
Browse[2] 
debug at GetCL.R#4: cat(out, \n)
Browse[2] 
43.316

Of course this output gets more tedious if I try to process the entire array by 
running for i in 1:larger-n.
Is there any way to get rid of these debug and browse messages messages in GUI 
mode? 
I have never experienced this debug output in my ca. 12+ years of using R 
intensely.

I just recently upgraded to R version 3.1.1 (2014-07-10) and renewed all my 
libraries.


-·.  .· ·.  .º·.  .· ·.  .º·.  .· ·.  .º .··.· =-   
=º}
Joseph G. Kunkel, Research Professor
112A Marine Science Center
University of New England
Biddeford ME 04005
http://www.bio.umass.edu/biology/kunkel/

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] system('man R') works in Mac unix R but not in GUI R

[Joseph Kunkel]

On Why use 'man R'?   

Hooray, system('R --help') works in both a unix-terminal-R session and also in 
the GUI!   My problem solved.

Thanks!!

Joe
 
On Mar 25, 2011, at 10:56 AM, Prof Brian Ripley wrote:

 On Fri, 25 Mar 2011, Kasper Daniel Hansen wrote:
 
 On Fri, Mar 25, 2011 at 9:14 AM, Joseph Kunkel j...@bio.umass.edu wrote:
 Using  R 2.12.2 GUI 1.36 Leopard build 64-bit (5691)
 
 system('man R') gives error: 'No manual entry for R' ...  ??
 
 Running R in a unix window the system('man R') function provides the 
 expected manual entry.
 
 This complicates my teaching of R with the Gui if I want to use the 
 system('R ...') function.   Students need to know unix-window-use as a 
 prereq.
 
 system('man vi')  however does provide the correct unix vi manual in either 
 unix or GUI.
 
 Well, as you might know, setting PATH and other environment variables
 in the terminal using, say .profile or .bashrc, does not make them set
 inside of a GUI.  This has been discussed many times on this list (and
 really has nothing to do with R at all).
 
 Note though that this is slightly different: it is about what is set in the 
 shell which system() launches from R.app, not the usual question of what 
 variables are set for R.app itself.
 
 In this case it is because vi ships with the system and the man page
 for vi is in
 # man -w vi
 /usr/share/man/man1/vi.1.gz
 
 I do not have the GUI (CRAN) version of R installed, but I would guess
 that the man page is in /usr/local/share ..., and you can check the
 directories man searches by
 # man -d
 
 I do, and 'man R' does not find it (and it is not under /usr/local/share/man, 
 which is on my system searched from system() in R.app).  My reading of the 
 CRAN installation scripts is that it is only installed in 
 /Library/Frameworks/R.framework/Versions/2.13/Resources/man1
 (Try 'locate R.1': all the other instances are in my own development area.)
 
 So I think the question should rather be why 'man R' works in a 'unix window' 
 (whatever that really is).
 
 And also why you think 'man R' is useful for your students, rather than say 
 'R --help' (from which it is derived by a Perl script) or the 'Introduction 
 to R' manual.
 
 -- 
 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

-·.  .· ·.  .º·.  .· ·.  .º·.  .· ·.  .º .··.· =-   
=º}
Joseph G. Kunkel, Professor
Biology Department
University of Massachusetts Amherst
Amherst MA 01003
http://www.bio.umass.edu/biology/kunkel/

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac