Re: [R-SIG-Mac] [Rd] My first package
On Mon, Jan 20, 2014 at 4:31 AM, Federico Calboli wrote: [...] > Is it? this is news to me. I have a grand total of 2 packages up and I > never ever used R-devel, and never ever had a problem, had a report of a > problem or had a note from CRAn about my packages not being ok because I > built them with R-relase (or whatever it might be called) and not R-devel. > >From the CRAN repository policy, that you also read and agreed to: "Please ensure that R CMD check --as-cran has been run on the tarball to be uploaded before submission. This should be done with the current version of R-devel (or if that is not possible, current R-patched or the current release of R.)" Gabor [...] [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] [Rd] My first package
On Mon, Jan 20, 2014 at 10:34 AM, Federico Calboli wrote: [...] > > That's as interesting as the English language makes it -- please note of > the expression 'should' as opposed to 'must', and the list of three options > of R versions. > Well, my interpretation is that package maintainers are expected to make an effort and check the package with R-devel. If they cannot for some reason, e.g. they cannot install R-devel, then R-patched or R-release. > Are you a CRAN maintainer? > > I maintain two packages on CRAN, if that's what you're asking. No, that's not what I am asking. > > > I guess you were just lucky so far. Most packages are small and not > affected by changes between R-release and R-devel. But some of them are. > > > > Also, R-devel typically has more rigorous package checks than R-release. > > Does it? > E.g. in current R-devel: * R CMD check reports namespaces imported _via_ ::: calls, including where this is unnecessary because :: would do or the code is in the namepace being imported from. (http://stat.ethz.ch/R-manual/R-devel/NEWS) > My package was delayed several times because it did not pass checks in > R-devel (it did in R-release). I guess this happened to other packages as > well, hence the sentence above was included in the policies. > > I presume that the issue is this: some packages are written solely in R, > hence, unless one uses a particular and outdated syntax, there are no > differences between R-devel and and R-current, whereas packages that call > C/C++/Fortran code are subject to the vagaries of compilers and operating > systems, and using R-devel should help future proofing the package, while > maintaing compatibility with R-current. > Partially, but not completely. You can have issues with R code (or even the manual!) as well, see above: if you have an unneeded ::: in your R code, then it will pass the check in R-release, but not in R-devel. Or, this one was new in R-3.0.2: * R CMD check --as-cran checks the line widths in usage and examples sections of the package Rd files. So again, back when this was only included in R-devel, your package with too long lines in the manual page examples passed the check on R-release, but not on R-devel. Gabor [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] [Rd] My first package
On Mon, Jan 20, 2014 at 9:58 AM, Federico Calboli wrote: [...] > I do that *with the current release of R* and I never had an issue > whatsoever. Incidentally the words 'This should be done with the current > version of R-devel (or if that is not possible, current R-patched or the > current release of R' translate in plainspeak 'run R CMD check --as-cran > with whatever version of R provided it's not outdated'. That's an interesting "translation". Are you a CRAN maintainer? I guess you were just lucky so far. Most packages are small and not affected by changes between R-release and R-devel. But some of them are. Also, R-devel typically has more rigorous package checks than R-release. My package was delayed several times because it did not pass checks in R-devel (it did in R-release). I guess this happened to other packages as well, hence the sentence above was included in the policies. Gabor [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Shortcut for launching command line R?
On Thu, Jan 23, 2014 at 11:40 PM, Tyler Ritchie wrote: > > > > Well, in Terminal you don't need any alias - just type R > > > > If you really want to save the shift though.. alias r='R' > No, OSX is case insensitive: ~$ which r /usr/bin/r ~$ which R /usr/bin/R ~$ ls -l /usr/bin/[rR] lrwxr-xr-x 1 root wheel 47 Jan 14 13:13 /usr/bin/R -> /Library/Frameworks/R.framework/Resources/bin/R Gabor [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Shortcut for launching command line R?
What is the "new version"? R-devel? I am running R-3.0.2, the latest released version. Gabor On Fri, Jan 24, 2014 at 12:31 AM, Dave Deriso wrote: > Hmm on my system the new osx version doesn't put the r binary in the usual > path folders so I had to create an alias...are you guys running the new > version? > On Jan 23, 2014 9:08 PM, "Gábor Csárdi" wrote: > >> On Thu, Jan 23, 2014 at 11:40 PM, Tyler Ritchie > >wrote: >> >> > > >> > > Well, in Terminal you don't need any alias - just type R >> >> > > >> > >> > If you really want to save the shift though.. alias r='R' >> > >> >> No, OSX is case insensitive: >> >> ~$ which r >> /usr/bin/r >> ~$ which R >> /usr/bin/R >> ~$ ls -l /usr/bin/[rR] >> lrwxr-xr-x 1 root wheel 47 Jan 14 13:13 /usr/bin/R -> >> /Library/Frameworks/R.framework/Resources/bin/R >> >> Gabor >> >> [[alternative HTML version deleted]] >> >> ___ >> R-SIG-Mac mailing list >> R-SIG-Mac@r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] making R.app and home-brew live happily together
On Wed, Mar 5, 2014 at 9:21 AM, Simon Urbanek wrote: > On Mar 5, 2014, at 8:04 AM, Federico Calboli > wrote: > > > On 4 Mar 2014, at 18:41, Davor Cubranic wrote: > > > >> If you don't care about Tcl/Tk, you could also install R without it. > Just choose "Customize" in the installer and unselect it. > > > > isn't there a different tcl/tk framework that one can use anyway? I'm > referring to the active state one ( > http://www.activestate.com/activetcl/downloads) > > > > No, because it doesn't work with R.app since that Tcl/Tk build assumes > it's controlling the application and system event loop. > Is this also true the other way? I mean, does the R Tcl/Tk work with other OSX apps that need Tcl/Tk? Gabor, another person annoyed by R and homebrew not playing well together. > > Cheers, > S > > > > > > > >> > >> Davor > >> > >> On Feb 28, 2014, at 9:51 AM, Federico Calboli > wrote: > >> > >>> Simon, > >>> > >>> > >>> > Unfortunately HB installs by default in /usr/local and requires full > control so you cannot have native libraries and HB in the same place at the > same time. So essentially you have to pick one or the other. There are two > options: > > a) install HB in another place. This allows you to keep native > libraries in /usr/local and parallel HB. HB is less tested that way, > though, so that's why HB is shy of recommending it. > > b) ignore HB's moaning. It should be ok as long as you don't install > tcl/tk via HB. It may get complicated if dependencies detect tcl/tk so for > safety you could rename the .pc files and the t*Config.sh files if you > don't expect to compile R packages that depend on tcl/tk. > >>> > >>> I am ignoring the moanings of brew doctor. I generally try and avoid > compiling R packages if at all possible, and I never used stuff that uses > tcl/tk (that I know of). My main concern is that I want to install SciPy > and Python 3 (assuming this can be done in a way that will not get > Mavericks throw a fit) and that might -- or not -- get some tcl/tk action in. > If not, R.app and HB can live together for all I care. > >>> > >>> Best > >>> > >>> F > >>> > >>> > >>> > >>> > > Cheers, > Simon > > > > BW > > > > F > > > > > > PS I also asked on apple stack, but I haven't go any reasonable > answer thus far and I'd rather get going. > > > > > > > > ___ > > 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 > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] making R.app and home-brew live happily together
On Wed, Mar 5, 2014 at 9:53 AM, Simon Urbanek wrote: [...] > > I just checked, and homebrew proper doesn't even provide Tcl/Tk so it > seems like this is not really an issue at all. Even the dupes version > installs in a hidden location so it doesn't clash. Homebrew typically tries > not to mess up the system so it was historically working along with R very > well. So do you have some evidence for them not playing well together? I > know MacPorts and Fink were disasters, but Homebrew has so far tried to > learn from their mistakes. > Hmmm. It seems that brew tcl-tk does not put anything in /usr/, so it all seems to be fine, actually. Quite possibly, my problems come up because I am compiling R from source, which is a much less serious case. Will try. Anyway, sorry for the noise. Gabor > > Cheers, > Simon > > > > > > > > > > Cheers, > > S > > > > > > > > > > > > >> > > >> Davor > > >> > > >> On Feb 28, 2014, at 9:51 AM, Federico Calboli < > f.calb...@imperial.ac.uk> wrote: > > >> > > >>> Simon, > > >>> > > >>> > > >>> > > Unfortunately HB installs by default in /usr/local and requires > full control so you cannot have native libraries and HB in the same place > at the same time. So essentially you have to pick one or the other. There > are two options: > > > > a) install HB in another place. This allows you to keep native > libraries in /usr/local and parallel HB. HB is less tested that way, > though, so that's why HB is shy of recommending it. > > > > b) ignore HB's moaning. It should be ok as long as you don't > install tcl/tk via HB. It may get complicated if dependencies detect tcl/tk > so for safety you could rename the .pc files and the t*Config.sh files if > you don't expect to compile R packages that depend on tcl/tk. > > >>> > > >>> I am ignoring the moanings of brew doctor. I generally try and > avoid compiling R packages if at all possible, and I never used stuff that > uses tcl/tk (that I know of). My main concern is that I want to install > SciPy and Python 3 (assuming this can be done in a way that will not get > Mavericks throw a fit) and that might -- or not -- get some tcl/tk action in. > If not, R.app and HB can live together for all I care. > > >>> > > >>> Best > > >>> > > >>> F > > >>> > > >>> > > >>> > > >>> > > > > Cheers, > > Simon > > > > > > > BW > > > > > > F > > > > > > > > > PS I also asked on apple stack, but I haven't go any reasonable > answer thus far and I'd rather get going. > > > > > > > > > > > > ___ > > > 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 > > > > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit
On Tue, Apr 15, 2014 at 7:14 AM, Duncan Murdoch wrote: > On 14/04/2014, 10:23 AM, Marc Schwartz wrote: > >> Hi Martin, >> >> Thanks for your confirmation on this. >> >> I normally do not use R CMD Sweave, as I too run under ESS in normal day >> to day operations. This finding was a quirk of having a particular Rnw >> document that I occasionally run using R CMD Sweave and I had done so over >> the weekend, realizing this behavior. >> > > This sounds like an argument for dropping R CMD Sweave, rather than fixing > it. The bug was introduced in July, 2013, and nobody noticed it because so > few people use that feature, and apparently nobody who does use it bothers > to test pre-release versions. > Or they just fix it for themselves, and do not report it. At least I know of one such case Gabor [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Fwd: The old versions of versions, and especially packages
Hi Ville, here is one way that *might* work. Go to http://cran.github.io/w/, click on "Older versions", and then click on the version you want (say 2.2.1). Here you can browse the packages that were available at CRAN at the time R 2.2.1 was released. I am still working on easy installation of old packages, so this is not very smooth currently, you'll need to download the packages one by one from github, or from Archive/, and install them by hand. The problem is that resolving the dependencies does not really work, so you'll also need to do it by hand. So I guess this is only viable if the package(s) you want to install do not have many dependencies. Good luck, best, Gabor On Sun, May 18, 2014 at 11:31 AM, Ville Hallikainen < ville.o.hallikai...@gmail.com> wrote: > > Dear R-users, > what is the most easiest way to download old versions of R and it's > packages. I have found some functions, but none of them have worked. How > to use the Archieve for this purpose. I would like to have detailed > instructions for Mac. I would need only some older version e.g. effects > 2.2-4. I know the address at http://cran.r-project.org/bin/macosx/old/. > > Ville > > ___ > R-SIG-Mac mailing list > R-SIG-Mac@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Mac OS X tcltk/X11 issues
What's wrong with capabilities("X11")?
I am not sure if teting for the OS, and especially for a particular X
server, installed in a particular directory, is a good idea, even if
it covers most of the _current_ installations.
Gabor
On Mon, Jul 14, 2014 at 6:13 PM, Marc Schwartz wrote:
>
> On Jul 14, 2014, at 4:53 PM, Marc Schwartz wrote:
>
>> On Jul 14, 2014, at 4:13 PM, John Fox wrote:
>>
>>> Dear Simon and list members,
>>>
>>> As many of you are aware, when X11 isn't installed on Mac OS X, loading the
>>> tcltk package produces an error, with a message that many users find
>>> cryptic. There was yet another instance of this problem reported to the list
>>> today.
>>>
>>> I'm interested in the issue because the Rcmdr package uses tcltk and thus
>>> fails to load when X11 is absent. Rcmdr users tend to be inexperienced and
>>> so, unless they find their way to the Rcmdr installation webpage, where
>>> detailed installation instructions are provided, they tend to be stymied by
>>> the problem.
>>>
>>> If I could, I'd intercept the problem by checking capabilities()["X11"] in
>>> the Rcmdr .onLoad() or .onAttach() function, but because the Rcmdr package
>>> imports the tcltk namespace, the error occurs before these startup functions
>>> are executed -- a chicken-and-egg problem.
>>>
>>> It occurs to me that tcltk could fail more gracefully on Mac OS X when X11
>>> is absent, perhaps popping up a webpage in a browser with instructions and a
>>> link for installing XQuartz. I'd do this myself in the Rcmdr package if I
>>> could. Or tcltk could check for the presence of X11 and not try to start it
>>> if it's absent, reporting a warning rather than throwing an error.
>>>
>>> Alternatively, I'd be grateful if someone could suggest how I might detect
>>> the problem in the Rcmdr package before loading fails. The only thing that I
>>> could think of was writing a separate RcmdrInstall package that bypasses
>>> tcltk, but that would be awkward and would only help users who discovered
>>> that RcmdrInstall exists.
>>>
>>> Thanks,
>>> John
>>
>>
>> John,
>>
>> Is there someplace in your startup process where you could run code along
>> the lines of:
>>
>> if (grepl("apple", R.version$platform) & length(list.files("/opt/X11/bin",
>> pattern = "Xquartz")) == 0) {
>> cat("X11 is required. Please visit http://xquartz.macosforge.org to
>> download and install Xquartz.")
>> stop()
>> }
>>
>>
>> The above code will check to see if the user is running R on OS X and also
>> if the Xquartz binary is present in the default location.
>>
>> Not sure if this is helpful.
>
>
> A possible correction in the above code relative to detecting OS X:
>
> if ((Sys.info()["sysname"] == "Darwin") & length(list.files("/opt/X11/bin",
> pattern = "Xquartz")) == 0) {
> cat("X11 is required. Please visit http://xquartz.macosforge.org to
> download and install Xquartz.")
> stop()
> }
>
>
> I believe that Sys.info()["sysname"] == "Darwin" is preferred for detecting
> the OS that R is running on versus the OS that it was built upon according to
> the help files, if I read correctly. This could be important if someone is
> building R from source versus installing Simon's CRAN binary, I presume.
>
> Regards,
>
> Marc
>
> ___
> 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] Mac OS X tcltk/X11 issues
Hi John,
On Mon, Jul 14, 2014 at 8:12 PM, John Fox wrote:
> Dear Gabor,
>
> As I just explained, the problem isn't testing for X11, which I know how to
> do -- though capabilities("X11") is a bit better than what I suggested. The
> issue is specific to Mac OS X because the Windows implementation of R
> includes a Tcl/Tk that doesn't use X11, and I've never seen the problem on
> Linux.
actually, what I am saying is, that it is not specific to OSX. Some
(older, before 2012) OSX versions do include an X11 server, and some
Linux or other Unix installations do not.
I am not saying tcltk should not test for an X11 server, all I am
saying is that the test suggested below (based on the os and the
existence of a certain file) is not the best one.
If it turns out that there is no X11 server, and the os is OSX, then
indeed a dialog box could be displayed, see e.g. the one at
http://www.macrumors.com/2012/02/17/apple-removes-x11-in-os-x-mountain-lion-shifts-support-to-open-source-xquartz/
Best,
Gabor
> Best,
> John
>
>> -Original Message-
>> From: Gábor Csárdi [mailto:csardi.ga...@gmail.com]
>> Sent: Monday, July 14, 2014 6:37 PM
>> To: Marc Schwartz
>> Cc: John Fox; urba...@research.att.com; R-SIG-Mac
>> Subject: Re: [R-SIG-Mac] Mac OS X tcltk/X11 issues
>>
>> What's wrong with capabilities("X11")?
>>
>> I am not sure if teting for the OS, and especially for a particular X
>> server, installed in a particular directory, is a good idea, even if
>> it covers most of the _current_ installations.
>>
>> Gabor
>>
>> On Mon, Jul 14, 2014 at 6:13 PM, Marc Schwartz
>> wrote:
>> >
>> > On Jul 14, 2014, at 4:53 PM, Marc Schwartz
>> wrote:
>> >
>> >> On Jul 14, 2014, at 4:13 PM, John Fox wrote:
>> >>
>> >>> Dear Simon and list members,
>> >>>
>> >>> As many of you are aware, when X11 isn't installed on Mac OS X,
>> loading the
>> >>> tcltk package produces an error, with a message that many users
>> find
>> >>> cryptic. There was yet another instance of this problem reported to
>> the list
>> >>> today.
>> >>>
>> >>> I'm interested in the issue because the Rcmdr package uses tcltk
>> and thus
>> >>> fails to load when X11 is absent. Rcmdr users tend to be
>> inexperienced and
>> >>> so, unless they find their way to the Rcmdr installation webpage,
>> where
>> >>> detailed installation instructions are provided, they tend to be
>> stymied by
>> >>> the problem.
>> >>>
>> >>> If I could, I'd intercept the problem by checking
>> capabilities()["X11"] in
>> >>> the Rcmdr .onLoad() or .onAttach() function, but because the Rcmdr
>> package
>> >>> imports the tcltk namespace, the error occurs before these startup
>> functions
>> >>> are executed -- a chicken-and-egg problem.
>> >>>
>> >>> It occurs to me that tcltk could fail more gracefully on Mac OS X
>> when X11
>> >>> is absent, perhaps popping up a webpage in a browser with
>> instructions and a
>> >>> link for installing XQuartz. I'd do this myself in the Rcmdr
>> package if I
>> >>> could. Or tcltk could check for the presence of X11 and not try to
>> start it
>> >>> if it's absent, reporting a warning rather than throwing an error.
>> >>>
>> >>> Alternatively, I'd be grateful if someone could suggest how I might
>> detect
>> >>> the problem in the Rcmdr package before loading fails. The only
>> thing that I
>> >>> could think of was writing a separate RcmdrInstall package that
>> bypasses
>> >>> tcltk, but that would be awkward and would only help users who
>> discovered
>> >>> that RcmdrInstall exists.
>> >>>
>> >>> Thanks,
>> >>> John
>> >>
>> >>
>> >> John,
>> >>
>> >> Is there someplace in your startup process where you could run code
>> along the lines of:
>> >>
>> >> if (grepl("apple", R.version$platform) &
>> length(list.files("/opt/X11/bin", pattern = "Xquartz")) == 0) {
>> >> cat("X11 is required. Please visit http://xquartz.macosforge.org
>> to download and install Xquartz.")
>> >> stop()
>> >> }
>> >>
&
[R-SIG-Mac] Unload CRAN package and locally built package
Hi all,
I have a little mystery here, and ideas would be welcome.
I would like to unload the package igraph. The following works fine
with the package downloaded from CRAN (Snow Leopard package):
install.packages("igraph")
library(igraph)
library(devtools)
unload(inst("igraph"))
However, if I build the package myself on my machine, then it does not
work any more and unloading hangs. I can press CTRL+C to get the R
prompt back, but every command hangs again. This is my machine:
~$ xcodebuild -version
Xcode 5.1.1
Build version 5B1008
~$ Rscript -e 'sessionInfo()'
R version 3.1.1 (2014-07-10)
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] stats graphics grDevices utils datasets base
It also hangs if I call dyn.unload() directly, instead of calling
devtools; if I remove
the igraph.so file from the package, then it works again, so it is
definitely something with the .so file.
I know this is not much work with, but if you have any guesses, please
let me know. Thanks,
Gabor
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Unload CRAN package and locally built package
Hi Simon,
thanks for the answer, sorry, I should have included this, it is
apparently not in sessionInfo().
So, this happens on 10.9.4 with R 3.1.1 and also on 10.8.5 with R
3.1.0. And the (10.8) CRAN binary version of igraph unloads cleanly on
both of them.
I am not sure how and why destructors would be called when unloading,
igraph does not use any external pointers to keep C++ objects alive.
They should be destroyed when returning the C/C++ call to R. It is
certainly possible that they are not, because of a bug or something,
but I cannot even unload if I do not call any igraph functions at all,
just load the package. (Loading the package calls an igraph_init, but
that only sets some global variables, it does not create any C or C++
objects.)
But I definitely think that you are right in general, and this is some
binary incompatibility between the R binary and my binary. It has been
a long standing issue, actually. It never worked for me in the last ~5
years.
I am also not really sure how to debug this, but will check with an R
version compiled on my mac in a minute.
Thank again, Best,
Gabor
On Thu, Sep 25, 2014 at 10:53 PM, Simon Urbanek
wrote:
> Gabor,
>
> what OS X version are you using? More recent OS X versions have slightly
> different C++ ABI so you can't really mix C++ code compiled on SL and let's
> say Mavericks - hence the two different sets of binaries. That would be my
> guess here since igraph uses C++ and it involves destructor code on
> unloading...
>
> Cheers,
> Simon
>
>
> On Sep 25, 2014, at 11:27 AM, Gábor Csárdi wrote:
>
>> Hi all,
>>
>> I have a little mystery here, and ideas would be welcome.
>>
>> I would like to unload the package igraph. The following works fine
>> with the package downloaded from CRAN (Snow Leopard package):
>>
>> install.packages("igraph")
>> library(igraph)
>> library(devtools)
>> unload(inst("igraph"))
>>
>> However, if I build the package myself on my machine, then it does not
>> work any more and unloading hangs. I can press CTRL+C to get the R
>> prompt back, but every command hangs again. This is my machine:
>>
>> ~$ xcodebuild -version
>> Xcode 5.1.1
>> Build version 5B1008
>>
>> ~$ Rscript -e 'sessionInfo()'
>> R version 3.1.1 (2014-07-10)
>> 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] stats graphics grDevices utils datasets base
>>
>> It also hangs if I call dyn.unload() directly, instead of calling
>> devtools; if I remove
>> the igraph.so file from the package, then it works again, so it is
>> definitely something with the .so file.
>>
>> I know this is not much work with, but if you have any guesses, please
>> let me know. Thanks,
>> Gabor
>>
>> ___
>> 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] Unload CRAN package and locally built package
I just tried on an R version that I compiled myself, and unloading
works fine. \o/
I also tried using the Mavericks build of R, and that works fine, too,
on my Mavericks laptop. \o/
I have no idea why the Snow Leopard R build did not work with my other
Snow Leopard machine, but honestly, I don't care much about it. :)
Thanks for the help, this is already a great day, and it is only 5:50am! :)
Best,
Gabor
On Fri, Sep 26, 2014 at 4:40 AM, Gábor Csárdi wrote:
> Hi Simon,
>
> thanks for the answer, sorry, I should have included this, it is
> apparently not in sessionInfo().
>
> So, this happens on 10.9.4 with R 3.1.1 and also on 10.8.5 with R
> 3.1.0. And the (10.8) CRAN binary version of igraph unloads cleanly on
> both of them.
>
> I am not sure how and why destructors would be called when unloading,
> igraph does not use any external pointers to keep C++ objects alive.
> They should be destroyed when returning the C/C++ call to R. It is
> certainly possible that they are not, because of a bug or something,
> but I cannot even unload if I do not call any igraph functions at all,
> just load the package. (Loading the package calls an igraph_init, but
> that only sets some global variables, it does not create any C or C++
> objects.)
>
> But I definitely think that you are right in general, and this is some
> binary incompatibility between the R binary and my binary. It has been
> a long standing issue, actually. It never worked for me in the last ~5
> years.
>
> I am also not really sure how to debug this, but will check with an R
> version compiled on my mac in a minute.
>
> Thank again, Best,
> Gabor
>
> On Thu, Sep 25, 2014 at 10:53 PM, Simon Urbanek
> wrote:
>> Gabor,
>>
>> what OS X version are you using? More recent OS X versions have slightly
>> different C++ ABI so you can't really mix C++ code compiled on SL and let's
>> say Mavericks - hence the two different sets of binaries. That would be my
>> guess here since igraph uses C++ and it involves destructor code on
>> unloading...
>>
>> Cheers,
>> Simon
>>
>>
>> On Sep 25, 2014, at 11:27 AM, Gábor Csárdi wrote:
>>
>>> Hi all,
>>>
>>> I have a little mystery here, and ideas would be welcome.
>>>
>>> I would like to unload the package igraph. The following works fine
>>> with the package downloaded from CRAN (Snow Leopard package):
>>>
>>> install.packages("igraph")
>>> library(igraph)
>>> library(devtools)
>>> unload(inst("igraph"))
>>>
>>> However, if I build the package myself on my machine, then it does not
>>> work any more and unloading hangs. I can press CTRL+C to get the R
>>> prompt back, but every command hangs again. This is my machine:
>>>
>>> ~$ xcodebuild -version
>>> Xcode 5.1.1
>>> Build version 5B1008
>>>
>>> ~$ Rscript -e 'sessionInfo()'
>>> R version 3.1.1 (2014-07-10)
>>> 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] stats graphics grDevices utils datasets base
>>>
>>> It also hangs if I call dyn.unload() directly, instead of calling
>>> devtools; if I remove
>>> the igraph.so file from the package, then it works again, so it is
>>> definitely something with the .so file.
>>>
>>> I know this is not much work with, but if you have any guesses, please
>>> let me know. Thanks,
>>> Gabor
>>>
>>> ___
>>> 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] Command Line Quartz Device in Yosemite
On Wed, Oct 29, 2014 at 9:57 AM, Grant Rettke wrote: > On Tue, Oct 28, 2014 at 5:33 PM, Colin A. Smith wrote: > >> First, it seems that under Yosemite, the default device is now x11 instead >> of quartz. > > Just curious, why do you prefer the quartz device over the x11 device on OSX? > > Starting out with quartz, I got a lot of crashes with R from homebrew > (15 times in a row using base plotting) and when I switched to x11 the > crashes stopped. That's probably just your system or homebrew R. I have been using quartz as a default device on various machines and OSX versions for many years now, and never had a single crash. As for the reason, the quartz device looks *much* nicer than the x11 device, probably because of the (better) anti-aliasing. Also, you do not need to run an X server to use it. Gabor > > ___ > 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] checking for pdflatex
John,
my guess is that on OSX, >95% of the users have https://tug.org/mactex/,
which seems to have pdflatex in /usr/texbin. If it is not there, then most
likely the user does not have pdflatex installed, and you can give a note
or warning about it.
If you want to be sure, you can check other tex distributions for OSX, to
be honest I don't know any other. Based on
http://mactex-wiki.tug.org/wiki/index.php/Distribution_Matrix pretty much
MacTeX is the only player. Maybe people also install TeX with brew, so it
might be worth checking that, too.
Gabor
On Mon, Mar 16, 2015 at 12:25 PM, John Fox wrote:
> Dear Simon,
>
> Thanks for this, and to the others who responded to my question. The FAQ
> and Matt Denwood's response jogged my memory, and reminded me that I
> encountered this problem before.
>
> In this case, I don't see a good solution, but I'll think about the
> problem some more.
>
> Without providing too many tedious details, the development version of the
> Rcmdr package checks at startup what resources are available to it,
> including pdflatex, and configures itself accordingly. Having inexperienced
> users edit, e.g., their .Renviron files is probably a non-starter. The
> Rcmdr could offer to do this at the user's option (it already provides
> dialogs that guide the user to locations of missing software like LaTeX and
> pandoc), but I'd still have to be able to figure out whether pdflatex is
> available and if so where it's located.
>
> Ian Gow suggested using locate, but I apparently can't rely on a locate
> database having been compiled -- it wasn't on my Mac -- and the overhead of
> compiling the locate db is excessive for a start-up check.
>
> Again, thanks for explaining the problem.
>
> John
>
> > -Original Message-
> > From: Simon Urbanek [mailto:simon.urba...@r-project.org]
> > Sent: March-16-15 10:39 AM
> > To: John Fox
> > Cc: Ian Gow; r-sig-mac@r-project.org
> > Subject: Re: [R-SIG-Mac] checking for pdflatex
> >
> > John,
> >
> > see R for Mac FAQ 10.13: I get “command not found” in the GUI yet it
> works
> > in the Terminal – why?
> >
> > Cheers,
> > Simon
> >
> >
> > > On Mar 15, 2015, at 6:21 PM, John Fox wrote:
> > >
> > > Dear Ian,
> > >
> > > Thanks for this. Please see below:
> > >
> > >> -Original Message-
> > >> From: Ian Gow [mailto:iand...@gmail.com]
> > >> Sent: March-15-15 5:07 PM
> > >> To: John Fox
> > >> Cc: r-sig-mac@r-project.org
> > >> Subject: Re: [R-SIG-Mac] checking for pdflatex
> > >>
> > >> I think it's driven by the PATH variable, which appears to differ for
> > >> me between RStudio and R from Terminal on the one hand and R.app on
> > >> the other.
> > >
> > > Yes, I understand that, though I don't understand why there's a
> > > difference in the path.
> > >
> > >>
> > >>> Sys.getenv("PATH")
> > >> [1] "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
> > >>> Sys.which("pdflatex")
> > >> pdflatex
> > >> ""
> > >>
> > >> If I add
> > >>
> > >> Sys.setenv(PATH=paste(Sys.getenv("PATH"),"/opt/local/bin", sep=":"))
> > >>
> > >> to ~/.Rprofile then R.app finds pdflatex (from MacPorts in my case).
> > >>
> > >>> Sys.which("pdflatex")
> > >> pdflatex
> > >> "/opt/local/bin/pdflatex"
> > >>> Sys.getenv("PATH")
> > >> [1] "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin"
> > >
> > > The problem for me is to determine whether pdflatex is installed
> > > *without* knowing in advance where it's installed. I haven't described
> > > the purpose of this, and, in the interest of brevity, won't for the
> > > time-being, but it may also prove necessary to determine where pdflatex
> > resides.
> > >
> > > Best,
> > > John
> > >
> > >>
> > >>
> > >> On 15 Mar 2015, at 16:46, John Fox wrote:
> > >>
> > >>> Dear list members,
> > >>>
> > >>> I need to determine whether pdflatex is installed and have been
> > >>> doing that via Sys.which("pdflatex"). This works when R is run in a
> > >>> terminal window (or in RStudio):
> > >>>
> > Sys.which("pdflatex")
> > >>> pdflatex
> > >>> "/usr/texbin/pdflatex"
> > >>>
> > >>> but not from R.app:
> > >>>
> > Sys.which("pdflatex")
> > >>> pdflatex
> > >>> ""
> > >>>
> > >>> The session info is the same in both cases:
> > >>>
> > >>> -- snip
> > >>>
> > sessionInfo()
> > >>> R version 3.1.3 (2015-03-09)
> > >>> Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X
> > >>> 10.10.2 (Yosemite)
> > >>>
> > >>> locale:
> > >>> [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-
> > 8/en_CA.UTF-
> > >> 8
> > >>>
> > >>> attached base packages:
> > >>> [1] stats graphics grDevices utils datasets methods base
> > >>>
> > >>> -- snip
> > >>>
> > >>> Why is the result different? Is there a better way to check for the
> > >>> presence of pdflatex?
> > >>>
> > >>> Any help would be appreciated.
> > >>>
> > >>> Thanks,
> > >>> John
> > >>>
> > >>>
> > >
Re: [R-SIG-Mac] using package xlsx
While I don't know the answer to your question, I would try https://github.com/hadley/readxl in this situation. Gabor On Wed, Apr 8, 2015 at 5:12 PM, Dennis Fisher wrote: > OS X Yosemite > R 3.1.3 > > Colleagues > > I have used the package xlsx successfully in the past. Today, I attempted > to use that package, the first time since I upgraded to Yosemite. R > responded to: > library(“xlsx”) > with > No Java runtime present, requesting install. > A popup then said “you need to install the legacy Java SE 6 runtime” > > I updated all my packages, then I tried: > library(“rJava”) > The outcome is the same. > > I installed Java (Java 8 Update 40), then tried again. Same problem. I > can confirm that Java is installed: > > PET633> java -version > > java version "1.8.0_40" > > Java(TM) SE Runtime Environment (build 1.8.0_40-b27) > > Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) > > It appears that the rJava wants an old version of java — however, I can’t > find that version at the Oracle website. For curiosity, I tried to install > Java SE 7 — the installer would not allow this once it found the newer > version (8). This suggests that installing version 6 will also not be > permitted. > > Any thoughts? > > Dennis > > Dennis Fisher MD > P < (The "P Less Than" Company) > Phone: 1-866-PLessThan (1-866-753-7784) > Fax: 1-866-PLessThan (1-866-753-7784) > www.PLessThan.com > > ___ > R-SIG-Mac mailing list > R-SIG-Mac@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] detecting cores
10.10.5: ❯ /usr/sbin/sysctl -n hw.physicalcpu 2 ❯ /usr/sbin/sysctl -n hw.logicalcpu 4 Which I believe is correct. Laptop has one processor with two cores according to "Hardware Overview" in "System Information" Gabor On Fri, Feb 5, 2016 at 12:07 PM, Prof Brian Ripley wrote: > sysctl on 10.11 has options which would enable us to differentiate between > logical and physical codes on parallel::detectCores --- however these are > not documented in Apple's online man pages, which are for 10.9. Could > someone running 10.9 and someone for 10.10 report if > > /usr/sbin/sysctl -n hw.physicalcpu > /usr/sbin/sysctl -n hw.logicalcpu > > run in a terminal work and gives the correct result? (Normally the second > will be twice the first taking account of hyperthreading.) > > Thanks in advance. > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Emeritus Professor of Applied Statistics, University of Oxford > > ___ > 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] Download data from Internet contained in a Zip file
Your R build does not support HTTPS.
I suggest that you use the curl package if you can. HTTP support in
base R is very limited currently.
Gabor
On Sun, Dec 25, 2016 at 10:37 PM, Christofer Bogaso
wrote:
> Hi again,
>
> I posted this in general R thread, however it is suggested this group
> since I am using MAC OS 10.7.5.
>
> I was following the instruction available in
> "http://stackoverflow.com/questions/3053833/using-r-to-download-zipped-data-file-extract-and-import-data";
> to download data from Internet contained in a zip file from the
> address :
>
> https://npscra.nsdl.co.in/download.php?path=download/&filename=NAV_File_23122016.zip
>
> However when I tried to follow the instruction I am facing below error :
>
>> temp <- tempfile()
>> download.file("https://npscra.nsdl.co.in/download.php?path=download/&filename=NAV_File_23122016.zip",temp)
> Error in
> download.file("https://npscra.nsdl.co.in/download.php?path=download/&filename=NAV_File_23122016.zip";,
> :
> unsupported URL scheme
>
> Can someone here please tell me what went wrong in above?
>
> Highly appreciate your feedback.
>
> Thanks for your time.
>
> ___
> 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] Feature request: install R in ~/Library/Frameworks
Hi all, I realize that this is not the typical use case on macOS, but for my work, it would be great to be able to install R into ~/Library/Frameworks. This would allow having different R versions for different users. I am not sure how difficult this would be to implement. I can see that some paths in scripts and makefiles are hardwired to /Library/Frameworks. Is there anything more, perhaps in the binaries as well? Best, Gabor [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Feature request: install R in ~/Library/Frameworks
Thanks, that's not an option for me, I need an R installation that is binary compatible with CRAN. I realized that I can maybe use ./configure --enable-R-framework=~/Library/Frameworks I am trying this right now. Gabor On Tue, Feb 7, 2017 at 9:02 AM, 美彦 馬場 wrote: > Hi, > > > On Feb 7, 2017, at 17:46, Gábor Csárdi wrote: > > > > Hi all, > > > > I realize that this is not the typical use case on macOS, but for my > work, > > it would be great to be able to install R into ~/Library/Frameworks. > > > > This would allow having different R versions for different users. > > > > I am not sure how difficult this would be to implement. I can see that > some > > paths in scripts and makefiles are hardwired to /Library/Frameworks. Is > > there anything more, perhaps in the binaries as well? > > > I install R with Fink, which allows you to install R-3.3, R-3.2 and > R-3.1. Each of them looks for files in > /sw/Library/Frameworks/R.framework/Versions/3.3, > 3.2 and 3.1 respectively. Also, CRAN packages for different R versions are > installed separately. > > -- > BABA > > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Feature request: install R in ~/Library/Frameworks
On Tue, Feb 7, 2017 at 9:52 AM, David Winsemius wrote: > > > On Feb 7, 2017, at 1:11 AM, Gábor Csárdi wrote: > > > > Thanks, that's not an option for me, I need an R installation that is > > binary compatible with CRAN. > > > > I realized that I can maybe use > > > > ./configure --enable-R-framework=~/Library/Frameworks > > > > I am trying this right now. > > > > I'm a bit confused. The bog-standard distribution of R has installed it > (as a sub-directory) of ~/Library/Frameworks for many versions. > I think the CRAN R build installs in /Library, not in ~/Library. > More specifically it is placed in this subdirectory: > > /Library/Frameworks/R.framework > These are not the same. I want it to be in the user's home directory, i.e. ~/Library, and not in the global /Library. Gabor > The Revolution R distribution for the Mac also uses this location (and > basically copies the installation script that is part of the CRAN version.) > > -- > David. > > > Gabor > > > > On Tue, Feb 7, 2017 at 9:02 AM, 美彦 馬場 wrote: > > > >> Hi, > >> > >>> On Feb 7, 2017, at 17:46, Gábor Csárdi wrote: > >>> > >>> Hi all, > >>> > >>> I realize that this is not the typical use case on macOS, but for my > >> work, > >>> it would be great to be able to install R into ~/Library/Frameworks. > >>> > >>> This would allow having different R versions for different users. > >>> > >>> I am not sure how difficult this would be to implement. I can see that > >> some > >>> paths in scripts and makefiles are hardwired to /Library/Frameworks. Is > >>> there anything more, perhaps in the binaries as well? > >> > >> > >> I install R with Fink, which allows you to install R-3.3, R-3.2 and > >> R-3.1. Each of them looks for files in /sw/Library/Frameworks/R. > framework/Versions/3.3, > >> 3.2 and 3.1 respectively. Also, CRAN packages for different R versions > are > >> installed separately. > >> > >> -- > >> BABA > >> > >> > > > > [[alternative HTML version deleted]] > > > > ___ > > R-SIG-Mac mailing list > > R-SIG-Mac@r-project.org > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > David Winsemius > Alameda, CA, USA > > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Feature request: install R in ~/Library/Frameworks
./configure --enable-R-framework=~/Library/Frameworks does not work, btw, not too surprisingly. G. On Tue, Feb 7, 2017 at 10:00 AM, Gábor Csárdi wrote: > On Tue, Feb 7, 2017 at 9:52 AM, David Winsemius > wrote: > >> >> > On Feb 7, 2017, at 1:11 AM, Gábor Csárdi >> wrote: >> > >> > Thanks, that's not an option for me, I need an R installation that is >> > binary compatible with CRAN. >> > >> > I realized that I can maybe use >> > >> > ./configure --enable-R-framework=~/Library/Frameworks >> > >> > I am trying this right now. >> > >> >> I'm a bit confused. The bog-standard distribution of R has installed it >> (as a sub-directory) of ~/Library/Frameworks for many versions. >> > > I think the CRAN R build installs in /Library, not in ~/Library. > > >> More specifically it is placed in this subdirectory: >> >> /Library/Frameworks/R.framework >> > > These are not the same. I want it to be in the user's home directory, i.e. > ~/Library, and not in the global /Library. > > Gabor > > > >> The Revolution R distribution for the Mac also uses this location (and >> basically copies the installation script that is part of the CRAN version.) >> >> -- >> David. >> >> > Gabor >> > >> > On Tue, Feb 7, 2017 at 9:02 AM, 美彦 馬場 wrote: >> > >> >> Hi, >> >> >> >>> On Feb 7, 2017, at 17:46, Gábor Csárdi >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> I realize that this is not the typical use case on macOS, but for my >> >> work, >> >>> it would be great to be able to install R into ~/Library/Frameworks. >> >>> >> >>> This would allow having different R versions for different users. >> >>> >> >>> I am not sure how difficult this would be to implement. I can see that >> >> some >> >>> paths in scripts and makefiles are hardwired to /Library/Frameworks. >> Is >> >>> there anything more, perhaps in the binaries as well? >> >> >> >> >> >> I install R with Fink, which allows you to install R-3.3, R-3.2 and >> >> R-3.1. Each of them looks for files in /sw/Library/Frameworks/R.frame >> work/Versions/3.3, >> >> 3.2 and 3.1 respectively. Also, CRAN packages for different R >> versions are >> >> installed separately. >> >> >> >> -- >> >> BABA >> >> >> >> >> > >> > [[alternative HTML version deleted]] >> > >> > ___ >> > R-SIG-Mac mailing list >> > R-SIG-Mac@r-project.org >> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> >> David Winsemius >> Alameda, CA, USA >> >> > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Feature request: install R in ~/Library/Frameworks
On Tue, Feb 7, 2017 at 10:22 AM, Prof Brian Ripley wrote: [...] > Well, you have missed the point. R itself allows you to do that: do read > 'R Installation and Administration'. > [...] For use as 'R' from a terminal, multiple CRAN distributions (of 3.x.y for > different 'x') can easily be installed and used together: that is §4.3 of > the manual. > Yes, I indeed missed this. Thanks much for the explanation! Gabor [...] [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Feature request: install R in ~/Library/Frameworks
On Tue, Feb 7, 2017 at 10:54 AM, Gábor Csárdi wrote: > On Tue, Feb 7, 2017 at 10:22 AM, Prof Brian Ripley > wrote: > [...] > >> Well, you have missed the point. R itself allows you to do that: do read >> 'R Installation and Administration'. >> > > [...] > > For use as 'R' from a terminal, multiple CRAN distributions (of 3.x.y for >> different 'x') can easily be installed and used together: that is §4.3 of >> the manual. >> > > Yes, I indeed missed this. Thanks much for the explanation! > One more question. I suppose if I install the various minor versions on different disks (e.g. I want 3.3.2 and 3.3.3 as well), that would work fine as well, and I don't even need pkgutil --forget? Or am I missing something? Gabor > > Gabor > > [...] > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Feature request: install R in ~/Library/Frameworks
On Tue, Feb 7, 2017 at 4:07 PM, Prof Brian Ripley wrote: > On 07/02/2017 15:26, Gábor Csárdi wrote: > >> On Tue, Feb 7, 2017 at 10:54 AM, Gábor Csárdi > <mailto:csardi.ga...@gmail.com>> wrote: >> >> On Tue, Feb 7, 2017 at 10:22 AM, Prof Brian Ripley >> mailto:rip...@stats.ox.ac.uk>> wrote: >> [...] >> >> Well, you have missed the point. R itself allows you to do >> that: do read 'R Installation and Administration'. >> >> >> [...] >> >> For use as 'R' from a terminal, multiple CRAN distributions (of >> 3.x.y for different 'x') can easily be installed and used >> together: that is §4.3 of the manual. >> >> >> Yes, I indeed missed this. Thanks much for the explanation! >> >> >> One more question. I suppose if I install the various minor versions on >> different disks (e.g. I want 3.3.2 and 3.3.3 as well), that would work >> fine as well, and I don't even need pkgutil --forget? Or am I missing >> something? >> > > You can install in different locations. I have never tried using > different 'volumes' (in Apple parlance), but AFAIK Apple treats them > separately (with separate records of packages installed). Maybe I am missing the point again, but just installing in different locations does not seem to work. E.g.: ❯ installer -pkg tmp/R-3.3.2.pkg -target CurrentUserHomeDirectory installer: Package name is R 3.3.2 for Mac OS X 10.9 or higher (Mavericks build) installer: Upgrading at base path /Users/gaborcsardi installer: The upgrade was successful. ❯ grep Library/Frameworks/R.framework Library/Frameworks/R.framework/Resources/bin/R R_HOME_DIR=/Library/Frameworks/R.framework/Resources R_SHARE_DIR=/Library/Frameworks/R.framework/Resources/share R_INCLUDE_DIR=/Library/Frameworks/R.framework/Resources/include R_DOC_DIR=/Library/Frameworks/R.framework/Resources/doc So the installed version still refers to /Library. If there is nothing there, then the version in ~/Library fails, of course: ❯ Library/Frameworks/R.framework/Resources/bin/R Library/Frameworks/R.framework/Resources/bin/R: line 238: /Library/Frameworks/R.framework/Resources/etc/ldpaths: No such file or directory Maybe you mean recompiling using a different framework location, or different --prefix? Yes, I guess that should work. Anyway, different volumes seem like a very good solution to me, because I can use the stock CRAN installers. I'll try it in a second. Gabor > > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Emeritus Professor of Applied Statistics, University of Oxford > [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Feature request: install R in ~/Library/Frameworks
On Tue, Feb 7, 2017 at 4:17 PM, Gábor Csárdi wrote: [...] > > Anyway, different volumes seem like a very good solution to me, because I > can use the stock CRAN installers. I'll try it in a second. > Actually, this will not work, because all R installations will just refer to /Library anyway. Never mind then, I'll need to recompile, there is no other way. Gabor [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] mirroring the cran build environment for R 3.4.x under El-capitan + (10.11+) MacOS
On Sat, Aug 5, 2017 at 6:40 PM, BATES Timothy wrote: > We thought https://builder.r-hub.io would be ideal for this but apparently > r.hub and the CRAN build are differenent? It would seem ideal to set-up > r-hub identically to the CRAN check machine… Is that possible? How are they different? Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/
https://cran.r-project.org/bin/macosx/tools/ suggests installing a special clang6 build. OTOH, the R binary links to a library that comes with CRAN's clang4 build: ❯ otool -L /Library/Frameworks/R.framework/Resources/bin/exec/R /Library/Frameworks/R.framework/Resources/bin/exec/R: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libR.dylib (compatibility version 3.5.0, current version 3.5.1) /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/clang4/lib/libomp.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) Notice '/usr/local/clang4/lib/libomp.dylib' above. R seems to run happily without this file, though, until you start it with lldb: ❯ R -d lldb (lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R" Current executable set to '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64). (lldb) run Process 74239 launched: '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64) dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R Reason: image not found Process 74239 stopped * thread #1, stop reason = signal SIGABRT frame #0: 0x00010002c9ee dyld`__abort_with_payload + 10 dyld`__abort_with_payload: -> 0x10002c9ee <+10>: jae0x10002c9f8 ; <+20> 0x10002c9f0 <+12>: movq %rax, %rdi 0x10002c9f3 <+15>: jmp0x10002c300 ; cerror_nocancel 0x10002c9f8 <+20>: retq After clang4 is installed from http://r.research.att.com/libs/ everything is fine. Is linking to this library intentional? If yes, then maybe the web could be updated to suggest installing clang6 and clang4? Thanks, Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/
Would it be possible to fix this for the builds of the upcoming release? Thanks, Gabor On Wed, Oct 10, 2018 at 11:12 PM Gábor Csárdi wrote: > > https://cran.r-project.org/bin/macosx/tools/ suggests installing a > special clang6 build. OTOH, the R binary links to a library that comes > with CRAN's clang4 build: > > ❯ otool -L /Library/Frameworks/R.framework/Resources/bin/exec/R > /Library/Frameworks/R.framework/Resources/bin/exec/R: > /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libR.dylib > (compatibility version 3.5.0, current version 3.5.1) > /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib > (compatibility version 0.0.0, current version 0.0.0) > /usr/local/clang4/lib/libomp.dylib (compatibility version 5.0.0, > current version 5.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1226.10.1) > > Notice '/usr/local/clang4/lib/libomp.dylib' above. R seems to run > happily without this file, though, until you start it with lldb: > > ❯ R -d lldb > (lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R" > Current executable set to > '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64). > (lldb) run > Process 74239 launched: > '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64) > dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib > Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R > Reason: image not found > Process 74239 stopped > * thread #1, stop reason = signal SIGABRT > frame #0: 0x00010002c9ee dyld`__abort_with_payload + 10 > dyld`__abort_with_payload: > -> 0x10002c9ee <+10>: jae0x10002c9f8 ; <+20> > 0x10002c9f0 <+12>: movq %rax, %rdi > 0x10002c9f3 <+15>: jmp0x10002c300 ; cerror_nocancel > 0x10002c9f8 <+20>: retq > > After clang4 is installed from http://r.research.att.com/libs/ > everything is fine. > > Is linking to this library intentional? If yes, then maybe the web > could be updated to suggest installing clang6 and clang4? > > Thanks, > Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/
On Sat, Dec 15, 2018 at 2:29 AM Simon Urbanek wrote: [...] > although the R binary itself was omitted. However it doesn’t actually matter, > because it is always executed through the R shell wrapper which correctly > prepends $R_HOME/lib which is why R works just fine. This does not seem to happen with ❯ R -d lldb (lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R" [...] (lldb) run [...] Process 52551 launched: '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64) dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R Reason: image not found Process 52551 stopped * thread #1, stop reason = signal SIGABRT frame #0: 0x00010002c9ee dyld`__abort_with_payload + 10 dyld`__abort_with_payload: -> 0x10002c9ee <+10>: jae0x10002c9f8 ; <+20> 0x10002c9f0 <+12>: movq %rax, %rdi 0x10002c9f3 <+15>: jmp0x10002c300 ; cerror_nocancel 0x10002c9f8 <+20>: retq (lldb) So maybe this is a bug in the R shell wrapper then? I am not sure, but it would be nice to make 'R -d lldb' work out of the box. Thanks, G. [...] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/
Great, thanks much!
Gabor
On Sat, Dec 15, 2018 at 9:47 PM Simon Urbanek
wrote:
>
> Gabor,
>
> this appears to be a known issue with lldb[1] - it doesn’t pass DYLD_*
> variables to the executable anymore. You have to explicitly set it in lldb:
>
> process launch -v
> DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
>
> or similar. Unfortunately, it means the wrapper can’t help here. You can get
> the full setting from R if the above is not sufficient:
>
> $ R --slave -e 'cat(Sys.getenv("DYLD_FALLBACK_LIBRARY_PATH"))'
> /Library/Frameworks/R.framework/Resources/lib:/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/lib/server
>
> Cheers,
> Simon
>
> PS: I have fixed the path for the nightly builds so it should be fixed in
> tonight’s build, but the lesson is that the debugger does indeed have an
> environment that is different from the actual executable.
>
> [1] http://lists.llvm.org/pipermail/lldb-dev/2015-October/008691.html
>
>
> > On Dec 15, 2018, at 4:41 AM, Gábor Csárdi wrote:
> >
> > On Sat, Dec 15, 2018 at 2:29 AM Simon Urbanek
> > wrote:
> > [...]
> >> although the R binary itself was omitted. However it doesn’t actually
> >> matter, because it is always executed through the R shell wrapper which
> >> correctly prepends $R_HOME/lib which is why R works just fine.
> >
> > This does not seem to happen with
> >
> > ❯ R -d lldb
> > (lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"
> > [...]
> > (lldb) run
> > [...]
> > Process 52551 launched:
> > '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64)
> > dyld: Library not loaded: /usr/local/clang4/lib/libomp.dylib
> > Referenced from: /Library/Frameworks/R.framework/Resources/bin/exec/R
> > Reason: image not found
> > Process 52551 stopped
> > * thread #1, stop reason = signal SIGABRT
> >frame #0: 0x00010002c9ee dyld`__abort_with_payload + 10
> > dyld`__abort_with_payload:
> > -> 0x10002c9ee <+10>: jae0x10002c9f8 ; <+20>
> >0x10002c9f0 <+12>: movq %rax, %rdi
> >0x10002c9f3 <+15>: jmp0x10002c300 ; cerror_nocancel
> >0x10002c9f8 <+20>: retq
> > (lldb)
> >
> > So maybe this is a bug in the R shell wrapper then? I am not sure, but
> > it would be nice to make 'R -d lldb' work out of the box.
> >
> > Thanks,
> > G.
> >
> > [...]
> >
>
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Error when fitting a brms model, maybe associated with Catalina MacOS
Setting the PATH in the shell does not apply to applications on macOS,
e.g. I customize the PATH in my .zshrc, and yet in R.app I have the
vanilla PATH:
> Sys.getenv("PATH")
[1] "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
RStudio is similar.
Gabor
On Mon, Dec 16, 2019 at 7:08 PM Simon Urbanek
wrote:
>
> JJB,
>
> to be honest, what surprises me is why people don't use the most
> straight-forward way documented very explicitly in the installer which is
> simply
>
> export PATH=/usr/local/clang7/bin:$PATH
>
> I never touch Makevars as that is very error-prone and makes it impossible to
> use multiple R versions. CRAN is already configured correctly for those
> compilers so you should not need to do any manual overrides.
>
> Cheers,
> Simon
>
>
>
> > On Dec 16, 2019, at 1:37 PM, Balamuta, James Joseph
> > wrote:
> >
> > Kasper,
> >
> > With all due respect, setting up the ~/.R/Makevars file is a key step that
> > trips up a majority of users. Sadly, the documentation for Makevars is not
> > beginner friendly and is scattered across multiple manuals [1][2] with the
> > most precise explanation being off-site [3]. Moreover, many do not know
> > about R's startup files [4], how to modify them, or where they exist as dot
> > files are hidden by default [5].
> >
> > I've toyed with many solutions over the years, including but not limited
> > to: providing an R script to write the lines to ~/.R/Makevars, emphasizing
> > that `file.edit()` can be used to open the configuration files, providing
> > step-by-step guides, and so on. The most successful approach taken was to
> > provide as much of an automated process as possible while emphasizing the
> > steps for those who wanted more depth.
> >
> > Having said this, my dream is for the macOS CRAN binary to come with
> > everything configured and setup correctly. Until that is the case or there
> > exists a better approach, I'm more inclined to stick with the current
> > approach I've taken especially as the macOS toolchain's stability changes
> > on minor point releases (MAJOR.MINOR.PATCH). Again, these are made freely
> > available to address an ever clearer need that is arising in the community.
> >
> > Best,
> >
> > JJB
> >
> > [1]: R Installation and Administration, Section 6.3.2: macOS,
> > https://cran.r-project.org/doc/manuals/R-admin.html#macOS-packages
> > [2]: Writing R Extensions, Section 1.2.1: Using Makevars,
> > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars
> > [3]: StackOverflow, Understanding the contents of the Makevars file in R
> > (macros, variables, ~/.R/Makevars and pkg/src/Makevars),
> > https://stackoverflow.com/q/43597632/1345455
> > [4]: Initialization at Start of an R Session
> > https://stat.ethz.ch/R-manual/R-patched/library/base/html/Startup.html
> > [5]: How to Show Hidden Files on a Mac
> > https://www.macrumors.com/how-to/show-hidden-files-on-a-mac/
> >
> > On 12/16/19, 9:39 AM, "R-SIG-Mac on behalf of Kasper Daniel Hansen"
> >
> > wrote:
> >
> >Just a comment on the macos-rtools. It seems wrong to me to set the user
> >level ~/.R/Makevars.
> >
> >On Sat, Dec 14, 2019 at 9:29 PM Manuel Spínola
> > wrote:
> >
> >> Thank you very much John.
> >>
> >> I restarted my computer, and everything looks fine now, I fitted a brms
> >> model without the error message.
> >>
> >> Manuel
> >>
> >> El sáb., 14 dic. 2019 a las 19:45, Fox, John ()
> >> escribió:
> >>
> >>> Dear Manuel,
> >>>
> >>> As far as I can tell, a lot of people are experiencing problems with
> >> rstan
> >>> under Catalina -- I don't use brms but rather rstan directly, and I
> >>> thrashed around quite a bit to get it work reliably (at least so far!).
> >>>
> >>> The final bit of the puzzle for me was to modify Makevars in the .R
> >>> subdirectory of my home directory according to the instructions at <
> >>> https://discourse.mc-stan.org/t/dealing-with-catalina-ii/11802/74>.
> >> Maybe
> >>> that will work for you too. If this is in fact a generally satisfactory
> >>> solution, one would hope that it could be made more convenient for macOS
> >>> rstan users.
> >>>
> >>> I hope this helps,
> >>> John
> >>>
> >>> -
> >>> John Fox, Professor Emeritus
> >>> McMaster University
> >>> Hamilton, Ontario, Canada
> >>> Web: http::/socserv.mcmaster.ca/jfox
> >>>
> On Dec 14, 2019, at 6:28 PM, Manuel Spínola
> >>> wrote:
>
> Dear list members,
>
> I updated everything, Catalina, Xcode, CLT, R 3.6.2, rstan from source,
> >>> and
> installed the r-macos-rtools, but I still have problems.
>
> library(brms)
> group <- rep(c("treat", "placebo"), each = 30)
> symptom_post <- c(rnorm(30, mean = 1, sd = 2), rnorm(30, mean = 0, sd =
> >>> 1))
> dat1 <- data.frame(group, symptom_post)
>
> fit1 <- brm(bf(symptom_post ~ group, sigma ~ group),
> data = dat1, family = gaussian())
>
> Chain 4: Iteratio
[R-SIG-Mac] Daily builds
Hi Simon, I wonder if the tarballs and the installers for 4.0 and 4.1 are missing from https://mac.r-project.org/ on purpose. The logs seem to have recent dates, but the installers or the links to them are not there? Thanks much, Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] GUI does not seem to compile with Xcode 12.x
2020-10-29T09:00:02.6267350Z /Users/runner/work/r-builder/r-builder/_build/R4/Mac-GUI/main.m:74:3: error: implicit declaration of function 'R_CleanUp' is invalid in C99 [-Werror,-Wimplicit-function-declaration] FYI, Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] GUI does not seem to compile with Xcode 12.x
Somewhat relatedly, the build scripts also need a small update for Xcode 12, https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4/src/consh.c and https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4/src/fixup.c need to #include for the system() calls. Gabor On Thu, Oct 29, 2020 at 11:56 AM Gábor Csárdi wrote: > > 2020-10-29T09:00:02.6267350Z > /Users/runner/work/r-builder/r-builder/_build/R4/Mac-GUI/main.m:74:3: > error: implicit declaration of function 'R_CleanUp' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > > FYI, > Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Apple Silicon aka M1 Macs
One thing that I noticed both on Silicon and the intel macs at GitHub
Actions, is that the CRAN installer does not create the symlinks in
`/usr/local/bin`. Probably some permission or entitlement issue. So
you'll probably want to create them manually. E.g. on GHA it goes like
this:
https://github.com/r-lib/ps/blob/a24f2c4d1bdba63be14e7729b9ab81d0ed9f719e/.github/workflows/R-CMD-check.yaml#L42-L45
G.
On Tue, Nov 17, 2020 at 3:15 PM Roy Mendelssohn - NOAA Federal via
R-SIG-Mac wrote:
>
> Thank to all who are working on this. Looks like a lot of work. Also looks
> like when and if R can run in native mode on the M1 it will be very fast.
>
> -Roy
>
>
> > On Nov 17, 2020, at 6:57 AM, Prof Brian Ripley
> > wrote:
> >
> > Mine (a 8GB MBA) arrived today, so I have started doing some comparisons.
> >
> > For the CRAN build of R 4.0.3, §2.8 of R-admin recommends checking the
> > installation with
> >
> > pdf("tests.pdf") ## optional, but prevents flashing graphics windows
> > Sys.setenv(LC_COLLATE = "C", LC_TIME = "C", LANGUAGE = "en")
> > tools::testInstalledBasic("both")
> > tools::testInstalledPackages(scope = "base")
> > tools::testInstalledPackages(scope = "recommended")
> >
> > That took 454s (using Rosetta) against 895s for my late-2016 MBP (2.9GHz
> > i5): happily nothing untoward was reported (some recommended packages give
> > differences from reference output on both systems).
> >
> > You need to install XQuartz to provide the X11() devices and support for
> > package Tcl/Tk: everything I tried using that worked as expected.
> >
> > Having done that post-installation check I would happily use the Intel R on
> > an M1 machine.
> >
> > We plan to check many of the Intel-compiled packages under Rosetta.
> >
> > There are many hours of work ahead to build/test a native toolchain: our
> > goal is to have a native distribution for R 4.1.0 ca April 2021.
> >
> > --
> > Brian D. Ripley, rip...@stats.ox.ac.uk
> > Emeritus Professor of Applied Statistics, University of Oxford
> >
> > ___
> > R-SIG-Mac mailing list
> > R-SIG-Mac@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
>
> ___
> 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] Difficulties with R-Studio
This has never happened to me (except when I touch the touchpad accidentally :), so unfortunately I don't have an answer, just some tips. RStudio has an online forum. If you don't get an answer here in a couple of days, you might want to try to ask your question there: https://community.rstudio.com/ You can try the latest daily build from https://dailies.rstudio.com/ RStudio has an API that R code (including R packages) can use to switch panels. Is it possible that you are using some R package that does that? Gabor On Sun, Aug 15, 2021 at 4:04 PM wrote: > > I use the R-Studio app, Version 1.4.1103, for my R programming work on > macOS Big Sur version 11.5. I find that the app switches from one window > to another (within the app) sometimes, without a request that it do so. > Sometimes I work for a long session and this does not occur, but at > other times it does, yet I cannot find an explanation. I had the same > problem with previous versions of R. The problem is annoying, but the > app is so good I have been putting up with it. > > Do others face the same problem? I suppose it is likely an issue within > R-Studio, since it does not occur with any other app. But is there > anything I can do in my macOS configuration to solve the problem? > > Philip > > ___ > 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] ANSI escape weirdness on M1 (libedit issue?)
Anyone else noticed some weirdness with the arm build when the prompt has ANSI escape codes? E.g. in a terminal run this options(prompt = "\033[1m> \033[0m") and then at the new prompt type in some longer word and press CTRL+A. The cursor does not go back to the beginning of the line, probably because the width of the prompt is not calculated correctly by the underlying system library. readline is not listed at https://mac.r-project.org/libs-arm64/ while it is listed among the intel libs. Does that mean that R uses libedit on arm64? Is this an issue with libedit? Thanks, Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] ANSI escape weirdness on M1 (libedit issue?)
On Wed, Nov 3, 2021 at 7:00 PM Prof Brian Ripley wrote: [...] > AFAIK the reason for not distributing readline with binary distributions > of R is perceived licence restrictions. So is the license different for x86_64? Because those builds come with readline: ❯ R-4.1 -q -e 'extSoftVersion()[["readline"]]' > extSoftVersion()[["readline"]] [1] "5.2" Whereas the arm64 build has: ❯ R-4.1-arm64 -q -e 'extSoftVersion()[["readline"]]' > extSoftVersion()[["readline"]] [1] "4.2 (EditLine wrapper)" Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] ANSI escape weirdness on M1 (libedit issue?)
Thanks for the answer, I actually just saw this today, it went into my spam folder for some reason. Anyway, I tried to build readline 5.2 and it wasn't that bad. I got the source for the libreadline-gplv2-dev Debian package (https://packages.debian.org/stretch/libreadline-gplv2-dev). This is readline 5.2 plus some readline patches and some more Debian patches. It is easiest to do this in Debian, where `apt-get source` applies the patches automatically. I used Debian Buster. After that I only had to add two #include lines to terminal.c and rltty.c. I put the patched tarball here if you don't want to patch it yourself: https://files.r-hub.io/readline/ I did build R-devel against it, and it seems to work great. In summary, this should do it: curl -O https://files.r-hub.io/readline/readline5-5.2+dfsg-1.tar.gz tar xzf readline5-5.2+dfsg-1.tar.gz cd readline5-5.2+dfsg ./configure --prefix=/opt/R/arm64 --enable-static --enable-shared=NO make sudo make install (Some info doc is missing for me, but that does not seem important.) I am hopeful that this will work out. Best, Gabor On Wed, Nov 3, 2021 at 11:00 PM Simon Urbanek wrote: > > Gabor, > > as you can see the x86_64 readline is a very old build 5.2-14 - it is the > last version released under GPL-2. Later versions are to my best knowledge > license-incompatible since they are released under GPL-3 only and thus do not > allow the use in GPL-2 software. The arm64 version currently relies on the > system library which is libedit. If it is of interest I can check if readline > 5.2 can be built for arm64, but it predates the architecture by quite a few > years ;). > > Cheers, > Simon > > > > On Nov 4, 2021, at 7:12 AM, Gábor Csárdi wrote: > > > > On Wed, Nov 3, 2021 at 7:00 PM Prof Brian Ripley > > wrote: > > [...] > >> AFAIK the reason for not distributing readline with binary distributions > >> of R is perceived licence restrictions. > > > > So is the license different for x86_64? Because those builds come with > > readline: > > ❯ R-4.1 -q -e 'extSoftVersion()[["readline"]]' > >> extSoftVersion()[["readline"]] > > [1] "5.2" > > > > Whereas the arm64 build has: > > ❯ R-4.1-arm64 -q -e 'extSoftVersion()[["readline"]]' > >> extSoftVersion()[["readline"]] > > [1] "4.2 (EditLine wrapper)" > > > > Gabor > > > > ___ > > 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] R / Rstudio and curl on Mac Mojave
The curl package does not use the command line curl program, it uses
libcurl, the library. You can use curl::curl_version() to see the
libcurl version that the curl package is using.
But in any case, this is not a curl or libcurl bug, but a
libressl/Mojave bug that Apple didn't fix, and probably won't fix
because Mojave is not supported any more.
You can fix it manually. You need to edit the /etc/ssl/cert.pem (make
a backup copy first), and remove the cert that expired on Sep 30
14:01:15 2021 GMT. Its entry starts with ## Digital Signature Trust
Co., until the end of the cert, the first -END CERTIFICATE-
line. You probably need sudo or the root user to edit it.
After you removed it, you can test it with something like
curl -v https://builder.r-hub.io >/dev/null
from a shell. This should fail before, and not fail after your edit.
Depending on which browser you use, you might need to update that as
well, at least I had to update chrome back then, on my Mojave machine.
Gabor
On Sat, Nov 13, 2021 at 5:34 PM wrote:
>
>
> Lets Encrypt and curl under Mojave on a Mac:
>
> How does one work around the expiration of the Lets Encrypt
> certificates when running on Mojave?
>
> Under R control, I download a list of stations, select the proper ones
> and download.
>
> station_link = "https://ntl.gcoos.org/station_table.txt";
> HtmlLink <- paste(station_link)
> dest = paste("data/station_list.txt")
> curl_download(url =HtmlLink ,destfile=dest,quiet=FALSE, mode="wb")
>
> This fails due to the certificate issues.
>
> Similarly, system("curl https://ntl.gcoos.org/station_table.txt
> -output table.txt") fails.
>
> However, curl https://ntl.gcoos.org/station_table.txt -output
> table.txt works from the terminal!
>
> Checking versions, I find that the terminal is using curl 7.8.
> system("curl -V") returns curl 7.54.
>
> From the terminal "which curl" points to curl 7.8 installed by mac ports.
>
> from R, system("which curl") points to curl 7.54 which was installed
> during Mojave installation.
>
> Apparently, "R" ignores the $PATH statement and looks for the binary
> in /usr/bin/, neither curl from Brew, Macports or Anaconda helped.
>
> Curl makes use of cacert.pem which isn't accepted by the Keychain.
>
> Wiping a disk and building a fresh install did not help.
>
> Updating to Catalina upgraded curl to version 7.80 which fixed the
> problem but killed my 32-bit applications.
>
> Does anyone know a way to force R to follow the $PATH specification?
>
> ___
> 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] Nightly build segfaults
This is Monterey: ❯ uname -a Darwin Gabors-MacBook-Pro-3.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000 arm64 The R-devel build segfaults: ❯ curl -O https://mac.r-project.org/monterey/R-devel/arm64/R-devel.tar.gz ❯ sudo tar xzf R-devel.tar.gz -C / ❯ R -q --vanilla zsh: killed R -q --vanilla So does the R-4.1 build: ❯ curl -O https://mac.r-project.org/monterey/R-4.1-branch/arm64/R-4.1-branch.tar.gz ❯ sudo tar xzf R-4.1-branch.tar.gz -C / ❯ R -q --vanilla zsh: killed R -q --vanilla The big-sur arm64 builds at https://mac.r-project.org/big-sur/R-devel/arm64/R-devel.tar.gz and https://mac.r-project.org/big-sur/R-4.1-branch/arm64/R-4.1-branch.tar.gz also do the same. I know that another user has seen this as well, so chances are that it is not some issue on my machine. Can anyone reproduce this? Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Nightly build segfaults
On Wed, Nov 17, 2021 at 8:14 PM Prof Brian Ripley wrote: [...] > With the tarball I get a popup telling me > > “R.framework” cannot be opened because the developer cannot be verified. Interesting. I am on 12.0.1 and there is no popup, but there is a crash report with Exception Type:EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) Possibly the popup was added in 12.1 beta. [...] > The .pkg I tried is unsigned/not notarized so cannot be installed, not > even with 'Open With'. But packages are at least sometimes signed. FWIW I did some local builds on a Big Sur machine with Xcode 12.x with the same settings as the CRAN builds (for readline support primarily), and those (https://files.r-hub.io/macos/readline/) work fine on Monterey as well. Gabor [...] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Nightly build segfaults
On Wed, Nov 17, 2021 at 8:45 PM Prof Brian Ripley wrote: > > On 17/11/2021 19:32, Gábor Csárdi wrote: > > On Wed, Nov 17, 2021 at 8:14 PM Prof Brian Ripley > > wrote: > > [...] > >> With the tarball I get a popup telling me > >> > >> “R.framework” cannot be opened because the developer cannot be verified. > > > > Interesting. I am on 12.0.1 and there is no popup, but there is a > > crash report with > > > > Exception Type:EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) > > > > Possibly the popup was added in 12.1 beta. > > I am running 12.0.1. Interesting. FWIW I tried to start it from an iTerm2 terminal, and there was no popup, just the "Killed" message and the crash report. Nevertheless the .tar.gz builds not working is an inconvenience, because it seems that the only way to run lldb now is to turn off the SIP. AFAICT homebrew signs its arm64 binaries now, but they are not notarized, and they seem to work fine. AFAICT they don't use the hardened runtime, so they are not notarized and I can run lldb on them. Gabor ___ 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-SIG unsubscribe
On Tue, Nov 23, 2021 at 1:23 PM peter dalgaard wrote: > > The button works fine (I did test it before sending), but you do need to > login, since nobody (except possibly the list administrator) should be able > to unsubscribe other people. For the record, I don't think you need to log in. Just type in your email address and press "Unsubscribe" and you'll get a confirmation email. Gabor [...] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] get-task-allow entitlement
Thanks! node.js is notarized with these entitlements, so I am fairly sure that Apple will allow it. I have re-signed all my R installations and added this entitlement some time ago, and haven't seen any issues so far. But yeah, that is not much testing at all. Btw. if anyone wants to add it to already installed R versions, it goes like this. Replace the version number (installation directory) as needed: codesign -d --xml --entitlements - /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/bin/exec/R > ~/r.entitlements /usr/libexec/PlistBuddy -c "Add :com.apple.security.get-task-allow bool true" ~/r.entitlements sudo codesign -s - -f --entitlements ~/r.entitlements /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/bin/exec/R I have also added this to https://github.com/gaborcsardi/rim so you can run rim system allow-debugger --all to update all installed versions of R. Thanks for considering this, G. On Tue, Apr 5, 2022 at 1:04 AM Simon Urbanek wrote: > > Gábor, > > thanks. I will check the notarization process to see if Apple will allow it. > There are some restrictions for processes that have get-task-allow > entitlement, so if it is allowed I'll would ask for some more testing to make > sure this doesn't affect something else in the R ecosystem. I agree that > having to clear the entitlements to debug R is a bit of a pain. > > Thanks, > Simon > > > > > On 5/04/2022, at 4:59 AM, Gábor Csárdi wrote: > > > > Simon, I wonder if you would consider adding the get-task-allow > > entitlement to the R builds. > > > > get-task-allow allows debugging with lldb or other debuggers, and also > > enables core dumps. > > > > Apple suggests that you avoid get-task-allow in production builds: > > https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues?language=objc > > However, they also note here that a legitimate use case for it is > > allowing the debugging of plugins, which is exactly the case we have > > for R: > > > > "To enable debugging a plug-in in the context of a host executable, > > the host can include the com.apple.security.get-task-allow entitlement > > if it also includes the Disable Library Validation Entitlement. Don’t > > disable library validation for executables that don’t host plug-ins > > because library validation protects them from loading untrusted code." > > > > R already has disable-library-validation of course. > > > > FWIW node.js, which is a similar environment to R, in that it needs > > load extension packages, added this to their builds: > > https://github.com/nodejs/node/pull/34378 > > https://github.com/nodejs/node/commit/b0e4970b8fe0dbd6bf437b3b06d0438d906ea94d > > > > G. > > > > ___ > > 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] arm64 R-devel builds use libedit instead of readline
FYI, in case this is not intended: ❯ otool -L /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libR.dylib [...] /usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0) [...] x86_64 builds seem to use readline, still. Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] installing with remotes package
This usually happens when you are on a slow network, and downloading
the archive.rds file fails within the default 60 seconds. You can
increase the timeout from 60 seconds to 600 or even more by setting
the timeout option:
options(timeout = 600)
A more modern option is to use the pak package, which has larger
default timeouts and many other goodies as well:
pak::pkg_install("Seurat@4.4.0")
Gabor
On Thu, Dec 7, 2023 at 9:03 PM Michael Sewell wrote:
>
> Hi - I'm a postdoc at the University of Edinburgh who's urgently trying to
> install an older version of a package (Seurat) listed on CRAN but without
> success. The package is Seurat_4.4.0.tar.gz.
>
> I currently work on a M1 Macbook Pro (with Sonoma installed) with RStudio
> version 4.3.2 and tried to install the package using the following code:
> remotes::install_version(package = 'Seurat', version =
> package_version('4.4.0'))
>
> However this appears to be unsuccessful - I was wondering if there is any
> guidance on how to install these on M1 macbooks? I have also tried
> uninstalling and reinstalling R many times which again did not succeed. Any
> help you could give me on this would be much appreciated.
>
> BW,
> Michael
>
>
> Michael Sewell
> Research Fellow
> Montagne Lab
> UK DRI
> The University of Edinburgh
> Twitter: @pichaelmichael_
> Linkedin
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336. Is e buidheann carthannais a th' ann an
> Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
>
> [[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 mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
