Re: [R-SIG-Mac] installing with remotes package

[Gábor Csárdi]

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

[R-SIG-Mac] arm64 R-devel builds use libedit instead of readline

[Gábor Csárdi]

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] get-task-allow entitlement

[Gábor Csárdi]

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

Re: [R-SIG-Mac] R-SIG unsubscribe

[Gábor Csárdi]

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] Nightly build segfaults

[Gábor Csárdi]

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] Nightly build segfaults

[Gábor Csárdi]

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

[R-SIG-Mac] Nightly build segfaults

[Gábor Csárdi]

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] R / Rstudio and curl on Mac Mojave

[Gábor Csárdi]

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

Re: [R-SIG-Mac] ANSI escape weirdness on M1 (libedit issue?)

[Gábor Csárdi]

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] ANSI escape weirdness on M1 (libedit issue?)

[Gábor Csárdi]

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] ANSI escape weirdness on M1 (libedit issue?)

[Gábor Csárdi]

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] Difficulties with R-Studio

[Gábor Csárdi]

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

Re: [R-SIG-Mac] Apple Silicon aka M1 Macs

[Gábor Csárdi]

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] GUI does not seem to compile with Xcode 12.x

[Gábor Csárdi]

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

[R-SIG-Mac] GUI does not seem to compile with Xcode 12.x

[Gábor Csárdi]

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

[R-SIG-Mac] Daily builds

[Gábor Csárdi]

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

Re: [R-SIG-Mac] Error when fitting a brms model, maybe associated with Catalina MacOS

[Gábor Csárdi]

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: 

Re: [R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/

[Gábor Csárdi]

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] CRAN build of R linking to /usr/local/clang4/

[Gábor Csárdi]

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/

[Gábor Csárdi]

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

[R-SIG-Mac] CRAN build of R linking to /usr/local/clang4/

[Gábor Csárdi]

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] Feature request: install R in ~/Library/Frameworks

[Gábor Csárdi]

On Tue, Feb 7, 2017 at 4:17 PM, Gábor Csárdi <csardi.ga...@gmail.com> 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] Feature request: install R in ~/Library/Frameworks

[Gábor Csárdi]

On Tue, Feb 7, 2017 at 4:07 PM, Prof Brian Ripley <rip...@stats.ox.ac.uk>
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 <csardi.ga...@gmail.com
>> <mailto:csardi.ga...@gmail.com>> wrote:
>>
>> On Tue, Feb 7, 2017 at 10:22 AM, Prof Brian Ripley
>> <rip...@stats.ox.ac.uk <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

[Gábor Csárdi]

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

[Gábor Csárdi]

./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 <csardi.ga...@gmail.com>
wrote:

> On Tue, Feb 7, 2017 at 9:52 AM, David Winsemius <dwinsem...@comcast.net>
> wrote:
>
>>
>> > On Feb 7, 2017, at 1:11 AM, Gábor Csárdi <csardi.ga...@gmail.com>
>> 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, 美彦 馬場 <babayoshih...@mac.com> wrote:
>> >
>> >> Hi,
>> >>
>> >>> On Feb 7, 2017, at 17:46, Gábor Csárdi <csardi.ga...@gmail.com>
>> 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

[Gábor Csárdi]

On Tue, Feb 7, 2017 at 9:52 AM, David Winsemius <dwinsem...@comcast.net>
wrote:

>
> > On Feb 7, 2017, at 1:11 AM, Gábor Csárdi <csardi.ga...@gmail.com> 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, 美彦 馬場 <babayoshih...@mac.com> wrote:
> >
> >> Hi,
> >>
> >>> On Feb 7, 2017, at 17:46, Gábor Csárdi <csardi.ga...@gmail.com> 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

[R-SIG-Mac] Feature request: install R in ~/Library/Frameworks

[Gábor Csárdi]

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] Download data from Internet contained in a Zip file

[Gábor Csárdi]

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/=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/=NAV_File_23122016.zip",temp)
> Error in 
> download.file("https://npscra.nsdl.co.in/download.php?path=download/=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

Re: [R-SIG-Mac] detecting cores

[Gábor Csárdi]

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] Command Line Quartz Device in Yosemite

[Gábor Csárdi]

On Wed, Oct 29, 2014 at 9:57 AM, Grant Rettke g...@wisdomandwonder.com wrote:
 On Tue, Oct 28, 2014 at 5:33 PM, Colin A. Smith co...@colinsmith.org 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] Unload CRAN package and locally built package

[Gábor Csárdi]

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
simon.urba...@r-project.org 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 csardi.ga...@gmail.com 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

[Gábor Csárdi]

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 csardi.ga...@gmail.com 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
 simon.urba...@r-project.org 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 csardi.ga...@gmail.com 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

[R-SIG-Mac] Unload CRAN package and locally built package

[Gábor Csárdi]

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] Mac OS X tcltk/X11 issues

[Gábor Csárdi]

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 marc_schwa...@me.com wrote:

 On Jul 14, 2014, at 4:53 PM, Marc Schwartz marc_schwa...@me.com wrote:

 On Jul 14, 2014, at 4:13 PM, John Fox j...@mcmaster.ca 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

[Gábor Csárdi]

Hi John,

On Mon, Jul 14, 2014 at 8:12 PM, John Fox j...@mcmaster.ca 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 marc_schwa...@me.com
 wrote:
 
  On Jul 14, 2014, at 4:53 PM, Marc Schwartz marc_schwa...@me.com
 wrote:
 
  On Jul 14, 2014, at 4:13 PM, John Fox j...@mcmaster.ca 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] [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit

[Gábor Csárdi]

On Tue, Apr 15, 2014 at 7:14 AM, Duncan Murdoch murdoch.dun...@gmail.comwrote:

 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] making R.app and home-brew live happily together

[Gábor Csárdi]

On Wed, Mar 5, 2014 at 9:21 AM, Simon Urbanek
simon.urba...@r-project.orgwrote:

 On Mar 5, 2014, at 8:04 AM, Federico Calboli f.calb...@imperial.ac.uk
 wrote:

  On 4 Mar 2014, at 18:41, Davor Cubranic cubra...@stat.ubc.ca 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 f.calb...@imperial.ac.uk
 wrote:
 
  Simon,
 
  snip
 
  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

[Gábor Csárdi]

On Wed, Mar 5, 2014 at 9:53 AM, Simon Urbanek
simon.urba...@r-project.orgwrote:
[...]


 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,
  
   snip
  
   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] Shortcut for launching command line R?

[Gábor Csárdi]

On Thu, Jan 23, 2014 at 11:40 PM, Tyler Ritchie tyler.ritc...@gmail.comwrote:

 
  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] [Rd] My first package

[Gábor Csárdi]

On Mon, Jan 20, 2014 at 9:58 AM, Federico Calboli
f.calb...@imperial.ac.ukwrote:
[...]

 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