[R-SIG-Mac] Cairo / X11 problem in Mavericks

2013-10-27 Thread Jeroen Ooms 
I just upgraded my macbook to maverick and i'm running into an old problem.
When I do:

png(tempfile(), type=cairo)

or

svg(tempfile())

or even:

library(Cairo)

R exists with a warning that X11 is required. I also tried:

options(bitmapType = 'cairo')
png(tempfile())

but same result. If I recall correctly this was not the case in OSX 10.8.
Is there any way to use png() or svg() on Mavericks without installing
xquartz?

[[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] Cairo / X11 problem in Mavericks

2013-10-28 Thread Jeroen Ooms 
 R exists with a warning that X11 is required.
 You need to re-install XQuartz after an update.  See the R-admin manual.

I'm not sure I understand (apologies, I'm not really a mac user). We
are using these devices in non-interactive R sessions (RApache,
RScript). So the Cairo devices can only be used on machines that have
xquartz is installed? IIRC, we had some mac server at some point that
did not have xquartz but was still capable of generating cairo based
svg and png. The r-admin manual says cairo support (without Pango)
has been added to the binary distribution.


 Is there any way to use png() or svg() on Mavericks without installing 
 xquartz?
 png() yes: use the quartz-based device.

Well part of the problem is that even running capabilities() to see if
Cairo is available at all makes R exit. Is this really expected
behavior?

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

Re: [R-SIG-Mac] Forking issues in Mavericks

2013-10-29 Thread Jeroen Ooms 
On Tue, Oct 29, 2013 at 12:35 PM, Steve Lianoglou
lianoglou.st...@gene.com wrote:
 Is this happening when you are running R from w/in R.app (which, I
 think, is not new), or are you running R from the terminal and still
 seeing this)?

It happens when a forked child process tries to use some fork unsafe
opratation, after the parent has already done so as well, see [1]. It
is related to R.app in the sense that the GUI uses the CF event
loop which is considered fork unsafe, and therefore a forked child
process can't do any fork unsafe operations anymore. However it also
happens in other contexts such as prefork in RApache [2].

But my actual question is: what is it about using httr::GET that is
considered fork unsafe, which was not considered unsafe in 10.8?

[1] 
http://objectivistc.tumblr.com/post/16187948939/you-must-exec-a-core-foundation-fork-safety-tale
[2] 
http://stackoverflow.com/questions/2344368/problem-configuring-rapache-on-os-x-10-5-8/2358834#2358834

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

Re: [R-SIG-Mac] Forking issues in Mavericks

2013-10-30 Thread Jeroen Ooms 
On Wed, Oct 30, 2013 at 10:08 AM, Simon Urbanek
simon.urba...@r-project.org wrote:
 I didn't have time to look (will do later today), but a wild guess is that 
 Apple was moving away from some common libraries like OpenSSL and replacing 
 them with their own which could be CF-based and thus unsafe. Again, that's 
 wild guess, I'll have to look at the trace to confirm that.

Thanks. It's unfortunate though, these developments are limiting the
usefulness of the parallel package on the mac, because a lot of basic
functionality is now considered unsafe to use in a forked process,
even though on Linux there is no problem at all. I also don't get why
osx decides to kill both the parent and child process when the child
attempt to do something unsafe. That doesn't seem the most graceful
way of dealing with things.

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

Re: [R-SIG-Mac] Forking issues in Mavericks

2013-10-30 Thread Jeroen Ooms 
On Wed, Oct 30, 2013 at 1:41 PM, Simon Urbanek
simon.urba...@r-project.org wrote:
 Jeroen,

 actually, it works just fine for me on 10.9 (with CRAN build of R):

Hmm interesting. Here is a clip of what happens on my machine:
http://youtu.be/GAtKa6P75Qs. Note that it shows the error messages
from the child proc, but afterwards the parent process is also broken.
I think it is no longer allowed to use fork() or exec().

This mac is an almost completely blank installation of Mavericks. I
formatted and did a recovery of 10.8 before updating to 10.9.
Afterwards installed R.app and xquarts. Other than that almost
everything on the machine is factory settings.

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

Re: [R-SIG-Mac] Forking issues in Mavericks

2013-10-30 Thread Jeroen Ooms 
On Wed, Oct 30, 2013 at 2:57 PM, Simon Urbanek
simon.urba...@r-project.org wrote:
 Ah, you're running it in R.app?

Well this was the easiest way to show it; the same problem appears
when forking form inside httpuv or so.

 Anyway, my hunch was correct - it's libcurl crashing in SSL trying to use CF.

I wish there was at least way to make situations like these fail more
gracefully... it's fine if the misbehaved child proc is killed, but
it's a bit painful that it also takes down its parent(s). There's
nothing we can do to catch these situations before it is too late?

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

[R-SIG-Mac] Missing binary packages for Mavericks

2014-04-10 Thread Jeroen Ooms 
Running update.packages on R 3.1 for Mavericks complains that some
CRAN packages do not have binary builds available. For example lme4 is
missing from http://cran.r-project.org/bin/macosx/mavericks/contrib/3.1/.

Is there any reason for this, or do I just need some patience? I
installed lme4 from source and it seems to build without problems.

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

[R-SIG-Mac] Cairo: Fontconfig error: Cannot load default config file

2014-04-15 Thread Jeroen Ooms 
Running on R 3.1 on my Mavericks laptop:

options(bitmapType = cairo);
svg(cars.svg, width=11.69, height=8.27)
plot(cars)
dev.off()

Gives a message: Fontconfig error: Cannot load default config file.
The text in the svg seems heavily pixelated. The same happens when
using png().

IIRC, this did not happen on R 3.0, although I am now starting to
doubt this. Is there anything on my machine that I try to
update/reinstall to fix this?

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

Re: [R-SIG-Mac] Cairo: Fontconfig error: Cannot load default config file

2014-04-18 Thread Jeroen Ooms 
I am also experiencing a performance regression for svg and png after
upgrading to R 3.1 on Linux. Could that be related to this problem, or
was this problem specific to OSX?






On Wed, Apr 16, 2014 at 7:50 AM, Simon Urbanek
simon.urba...@r-project.org wrote:
 Thanks, this was an issue in the fontconfig used by 3.1.0, now fixed. You 
 will need to upgrade R and possibly packages that use fontconfig.

 Cheers,
 Simon


 On Apr 15, 2014, at 7:55 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote:

 Running on R 3.1 on my Mavericks laptop:

 options(bitmapType = cairo);
 svg(cars.svg, width=11.69, height=8.27)
 plot(cars)
 dev.off()

 Gives a message: Fontconfig error: Cannot load default config file.
 The text in the svg seems heavily pixelated. The same happens when
 using png().

 IIRC, this did not happen on R 3.0, although I am now starting to
 doubt this. Is there anything on my machine that I try to
 update/reinstall to fix this?

 ___
 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] cairo devices not working in 3.2.0

2015-04-24 Thread Jeroen Ooms 
My cairo problems went away after reinstalling xQuartz + R 3.2.0 and rebooting.

On Fri, Apr 24, 2015 at 8:05 AM, Amos B. Elberg amos.elb...@gmail.com wrote:
 I had this issue but it went away when I installed the 3.2-patched binary.

 On Apr 24, 2015, at 10:52 AM, Noam Ross noam.r...@gmail.com wrote:

 Apologies, I meant `cairo_ps()` yields an error, rather than `cairo_png()`,
 and Yosemite rather than Mavericks. My session info:

 sessionInfo()
 R version 3.2.0 (2015-04-16)
 Platform: x86_64-apple-darwin13.4.0 (64-bit)
 Running under: OS X 10.10.2 (Yosemite)

 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  methods   base

 loaded via a namespace (and not attached):
 [1] tools_3.2.0

 On Fri, Apr 24, 2015 at 7:39 AM Brandon Hurr bhiv...@gmail.com wrote:

 Noam,

 I've just recently upgraded too and everything works except cairo_png().

 capabilities(cairo)
 cairo
 TRUE
 svg()
 cairo_png()
 Error: could not find function cairo_png
 cairo_pdf()

 sessionInfo()
 R version 3.2.0 (2015-04-16)
 Platform: x86_64-apple-darwin13.4.0 (64-bit)
 Running under: OS X 10.10.3 (Yosemite)

 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  methods   base

 Brandon

[[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 mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] R 3.2.2 Hangs Reading Files in El Capitan

2015-12-04 Thread Jeroen Ooms 
Can you include a reproducible example? This seems to work for me as expected:

  x <- rnorm(1e8)
  saveRDS(x, tmp <- tempfile())
  file.info(tmp)$size
  y <- readRDS(tmp)
  identical(x,y)

Could be a hw issue with your disk.




On Sun, Nov 29, 2015 at 4:34 PM, Charles DiMaggio
 wrote:
> Hi. After upgrading to el capitan R hangs on readRDS() and load()  for 
> largish (say 500MB or larger) files, requiring a Force Quit of R.  I am 
> working on a 64 GB Mac Pro machine and had no problem loading these size 
> files prior to upgrade.  Reading and loading smaller files (1MB or less) 
> seems to work fine. I re-installed R 3.2.2 GUI 1.66 Mavericks, XQuartz and 
> CLT after the upgrade. Turned off SIP but experienced the same problem.
>
> I've looked over recent list posting about R behavior after upgrade to el 
> capitan, and have not seen anything about this.  Am hoping 
> soon-to-be-released R version 3.2.3 (Wooden Christmas-Tree) will address this 
> weirdness, but wondering if anyone else has experienced anything similar?
>
> First few of lines of Mac Error Report below:
>
> Date/Time:   2015-11-28 15:45:00 -0500
> OS Version:  Mac OS X 10.11.1 (Build 15B42)
> Architecture:x86_64
> Report Version:  22
>
> Command: R
> Path:/Applications/R.app/Contents/MacOS/R
> Version: R 3.2.2 GUI 1.66 Mavericks build (6996)
> Parent:  launchd [1]
> PID: 563
>
> Event:   hang
> Duration:1.70s (process was unresponsive for 25 seconds before 
> sampling)
> Steps:   17 (100ms sampling interval)
>
> Hardware model:  MacPro6,1
> Active cpus: 8
>
> ...
>
> Heaviest stack for the main thread of the target process:
>   17  start + 1 (libdyld.dylib + 13741) [0x7fff88f2f5ad]
>   17  main + 815 (R + 5967) [0x1053e374f]
>   17  -[REngine runREPL] + 138 (R + 75578) [0x1053f473a]
>   17  run_REngineRmainloop + 295 (R + 123751) [0x105400367]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1243228) [0x10561d85c]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 675070) [0x105592cfe]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1044002) [0x1055ece22]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 674823) [0x105592c07]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1029000) [0x1055e9388]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 673910) [0x105592876]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 750621) [0x1055a541d]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1601435) [0x105674f9b]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1592422) [0x105672c66]
>   17  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1594038) [0x1056732b6]
>   14  ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1596619) [0x105673ccb]
>   7   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1595584) [0x1056738c0]
>   6   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1592773) [0x105672dc5]
>   6   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 1600194) [0x105674ac2]
>   6   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 383889) [0x10554bb91]
>   6   ??? (<56AA7B12-7A0D-3F36-8116-218A93BC3CB3> + 316653) [0x10553b4ed]
>   1   inflate + 258 (libz.1.dylib + 20735) [0x7fff9e4e30ff] (running)
>
>
> Process: R [563]
> Path:/Applications/R.app/Contents/MacOS/R
> Architecture:x86_64
> Parent:  launchd [1]
> UID: 501
> Task size:   350330 pages (+14553)
> CPU Time:1.604s
> Note:Unresponsive for 25 seconds before sampling
> Note:2 idle work queue threads omitted
>
>
> Cheers
>
> Charles
>
>
> Charles DiMaggio, PhD, MPH
> Director of Injury Research
> Department of Surgery
> New York University School of Medicine
> Division of Trauma, Emergency Surgery and Critical Care Surgery
> Bellevue Hosptial Center
> 462 First Avenue, NBV 15
> New York, NY 10016-9196
> charles.dimag...@nyumc.org
> Office: 212.263.3202
> Mobile: 516.308.6426
>
>
>
>
>
>
>
> [[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

Re: [R-SIG-Mac] Could not install Package:pdftools in Mac lion 10.7.5

2016-12-27 Thread Jeroen Ooms 
How did you install libpoppler? Such errors typically appear when you
link to a shared library which was built with another (incompatible)
compiler than the one you use for compiling R packages.

Note that Mac lion 10.7.5 has been deprecated for 2 over two years;
upgrading your OS is highly recommended.



On Tue, Dec 27, 2016 at 7:05 PM, Christofer Bogaso
 wrote:
> Hi,
>
> I am trying to install "pdftools" package in R from source, however
> could not succeeded due to following error.
>
> Source file is downloaded from
> https://cran.r-project.org/web/packages/pdftools/index.html
>
> Appreciate for any pointer how to install it properly.
>
> I am using R version 3.2.1 (2015-06-18)
>
> The loading error :
>
> tar: Failed to set default locale
> During startup - Warning messages:
> 1: Setting LC_CTYPE failed, using "C"
> 2: Setting LC_TIME failed, using "C"
> 3: Setting LC_MESSAGES failed, using "C"
> 4: Setting LC_MONETARY failed, using "C"
> * installing *source* package 'pdftools' ...
> ** package 'pdftools' successfully unpacked and MD5 sums checked
> Found pkg-config cflags and libs!
> Using PKG_CFLAGS=-I/usr/local/Cellar/poppler/0.50.0/include/poppler/cpp
> -I/usr/local/Cellar/poppler/0.50.0/include/poppler
> Using PKG_LIBS=-L/usr/local/Cellar/poppler/0.50.0/lib -lpoppler-cpp
> ** libs
> llvm-g++-4.2 -arch x86_64
> -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG
> -I/usr/local/Cellar/poppler/0.50.0/include/poppler/cpp
> -I/usr/local/Cellar/poppler/0.50.0/include/poppler
> -I/usr/local/include
> -I"/Library/Frameworks/R.framework/Versions/3.2/Resources/library/Rcpp/include"
>   -fPIC  -mtune=core2 -g -O2  -c RcppExports.cpp -o RcppExports.o
> llvm-g++-4.2 -arch x86_64
> -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG
> -I/usr/local/Cellar/poppler/0.50.0/include/poppler/cpp
> -I/usr/local/Cellar/poppler/0.50.0/include/poppler
> -I/usr/local/include
> -I"/Library/Frameworks/R.framework/Versions/3.2/Resources/library/Rcpp/include"
>   -fPIC  -mtune=core2 -g -O2  -c bindings.cpp -o bindings.o
> llvm-g++-4.2 -arch x86_64
> -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG
> -I/usr/local/Cellar/poppler/0.50.0/include/poppler/cpp
> -I/usr/local/Cellar/poppler/0.50.0/include/poppler
> -I/usr/local/include
> -I"/Library/Frameworks/R.framework/Versions/3.2/Resources/library/Rcpp/include"
>   -fPIC  -mtune=core2 -g -O2  -c init.cpp -o init.o
> llvm-g++-4.2 -arch x86_64 -dynamiclib -Wl,-headerpad_max_install_names
> -undefined dynamic_lookup -single_module -multiply_defined suppress
> -L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib
> -L/usr/local/lib -o pdftools.so RcppExports.o bindings.o init.o
> -L/usr/local/Cellar/poppler/0.50.0/lib -lpoppler-cpp
> -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
> -Wl,CoreFoundation
> installing to 
> /Library/Frameworks/R.framework/Versions/3.2/Resources/library/pdftools/libs
> ** R
> ** preparing package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** testing if installed package can be loaded
> During startup - Warning messages:
> 1: Setting LC_CTYPE failed, using "C"
> 2: Setting LC_TIME failed, using "C"
> 3: Setting LC_MESSAGES failed, using "C"
> 4: Setting LC_MONETARY failed, using "C"
> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>   unable to load shared object
> '/Library/Frameworks/R.framework/Versions/3.2/Resources/library/pdftools/libs/pdftools.so':
>   
> dlopen(/Library/Frameworks/R.framework/Versions/3.2/Resources/library/pdftools/libs/pdftools.so,
> 6): Symbol not found: __ZN7poppler14version_stringEv
>   Referenced from:
> /Library/Frameworks/R.framework/Versions/3.2/Resources/library/pdftools/libs/pdftools.so
>   Expected in: flat namespace
>  in 
> /Library/Frameworks/R.framework/Versions/3.2/Resources/library/pdftools/libs/pdftools.so
> Error: loading failed
> Execution halted
> ERROR: loading failed
> * removing 
> '/Library/Frameworks/R.framework/Versions/3.2/Resources/library/pdftools'
> * restoring previous
> '/Library/Frameworks/R.framework/Versions/3.2/Resources/library/pdftools'
>
> ___
> 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] Could not install Package:pdftools in Mac lion 10.7.5

2016-12-27 Thread Jeroen Ooms 
On Tue, Dec 27, 2016 at 8:09 PM, Christofer Bogaso
 wrote:
> It giving below error  :(
>
>> install.packages('/Users/ARR/pdftools_1.0.tgz', repos = NULL)
> tar: Failed to set default locale

I think that is an unrelated problem on your system. See:

 
http://stackoverflow.com/questions/3907719/how-to-fix-tar-failed-to-set-default-locale-error

But if you didn't get any other error the installation might have
succeeded? Try loading the package:

  library(pdftools)

If that works you might be OK.

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

Re: [R-SIG-Mac] Could not install Package:pdftools in Mac lion 10.7.5

2016-12-27 Thread Jeroen Ooms 
On Tue, Dec 27, 2016 at 7:27 PM, Christofer Bogaso
 wrote:
>
> I have installed poppler as instructed in below site. However, not
> libpoppler. Let me know if I need to install libpoppler as well, in
> that case appreciate any pointer how should I install.

No that's the same thing. It's difficult for me to debug this since
you're using such an old version of OSX and R. Chances are poppler
simply doesn't work on such an old system.

But one thing you could try is manually installing the mavericks
binary package. Download this file to your system:

   https://cran.r-project.org/bin/macosx/mavericks/contrib/3.2/pdftools_1.0.tgz

And then install it in R using:

  install.packages('~/Downloads/pdftools_1.0.tgz', repos = NULL)

If you're lucky it works :)

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

[R-SIG-Mac] Disable readline echo in R for mac GUI

2018-11-15 Thread Jeroen Ooms 
When prompting the user for a password, we need to temporarily disable
echo. In a tty we can call posix stty -echo (example below). The
RStudio GUI has a native password entry function that can be triggered
via getOption('askpass'). Is there simple method to prompt for a
password in the R for Mac GUI (without depending on shiny or tcltk)?

readline_password <- function(prompt = "Please enter password\n"){
  if(isatty(stdin())){
if(system('stty -echo') == 0){
  on.exit(system('stty echo'))
}
  }
  base::readline(prompt)
}

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

Re: [R-SIG-Mac] PACKAGES file missing

2020-02-13 Thread Jeroen Ooms 
On Thu, Feb 13, 2020 at 1:55 AM Simon Urbanek
 wrote:
>
> Thanks, indeed, there were some disruptions, but now the build machine has 
> its own dedicated port and location in Auckland so hopefully things will 
> settle.
> I have also fortified the sync scripts to not sync with the Mac master if 
> there is no PACKAGES file to avoid such issues in case something goes wrong.

Thanks, that's great news.

Minor note: the server no longer allows for directory listing, is this
on purpose? E.g.
https://mac.r-project.org/bin/macosx/el-capitan/contrib/3.6/ . It's
sometimes useful to be able to see what is on the server, e.g. to see
the timestamps or file sizes of the packages.

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

Re: [R-SIG-Mac] Building R 4.0.2 from source via clang/xcode for MKL on macOS

2020-10-02 Thread Jeroen Ooms 
On Tue, Sep 29, 2020 at 4:32 PM Prof Brian Ripley  wrote:
>
> On 29/09/2020 12:27, Kasper Daniel Hansen wrote:
> > To use veclib you need
> > --with-blas="-framework Accelerate"
>
> Details are in the R-admin manual, including that R fails one of its checks.

It may be worth mentioning that python and homebrew have removed all
dependency on Accelerate due to bugs and Apple's (lack of)
maintenance: https://github.com/scipy/scipy/wiki/Dropping-support-for-Accelerate

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

Re: [R-SIG-Mac] Link-Time Optimization (LTO)

2020-07-15 Thread Jeroen Ooms 
On Tue, Jul 14, 2020 at 4:22 PM Prof Brian Ripley  wrote:
>
> This is a rather technical post about how libraries of compiled code can
> be further optimized.  LTO generally produces smaller[*] and faster code
> (typically by a few percent) at the expense of increased installation
> time and is being used for large projects such as browsers and soon for
> some Linux distributions.
>
> I have committed a series of enhancements to LTO support in R-devel and
> will shortly port the more important of these to R-patched.

Would it be worthwhile looking into this for Windows? We did enable
support for LTO in the rtools40 toolchains*, but those are gcc-8.3.0
and some of the benefits require gcc-9.

* 
https://github.com/r-windows/rtools-packages/blob/master/mingw-w64-gcc/PKGBUILD#L166

___
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

2020-12-24 Thread Jeroen Ooms 
On Thu, Dec 24, 2020 at 7:32 PM Denis-Alexander Engemann
 wrote:
>
> Hi everyone,
>
> I'm finally joining the party here and so far made good progress
> following Taras' instructions.
>
> Disclaimer - I'm new to working with R sources.
> But would be very happy to help with testing and reporting to
> accelerate support native M1 builds.
>
> I am using the R-4.0.3 sources with the latest gfortran release from
> François-Xavier Coudert:
> https://github.com/fxcoudert/gfortran-for-macOS/releases/tag/11-arm-alpha2
>
> Currently I'm facing some issues at step 5.
> It seems that for some reasons liblzma cannot be found although it is
> well installed via xz at step 3.
> I also verified that the liblzma can be easily discovered along the lines of 
> 3.
>
> The lines before ./configure stops are:
>
> ```
> checking lzma.h usability... no
> checking lzma.h presence... no
> checking for lzma.h... no
> configure: error: "liblzma library and headers are required"
> ```
>
> As mentioned, all is well installed in the include and lib directories at:
> /opt/homebrew/Cellar/xz/5.2.5
>
> Would you have a suggestion where I should link the headers/library to
> be picked up by ./configure ?

Homebrew now has an arm64 binary for R:
https://github.com/homebrew/homebrew-core/blob/master/Formula/r.rb .
Hence you can simply use: brew install r

To tweak the build, use "brew edit r", save your changes, and then:
brew install r --build-from-source

___
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 4.1 for my Mac M1 crashing on installing packages

2021-05-19 Thread Jeroen Ooms 
On Wed, May 19, 2021 at 11:34 AM Renato Morais
 wrote:
>
> Hi all,
>
> I'm new here, so please forgive my clumsy error reporting.
>
> I have just downloaded *R-4.1-branch.pkg* for my Mac M1, as I wanted to
> finally enjoy a native normal-speed R (for some reason running v 4.0.5 on
> Rosetta was extremely slow on my machine). I also installed the latest
> XQuartz, as indicated (v 2.8.1).
>
> Sad story is, when I try a simple install.packages command, it first
> appears to ignore me, after returning 'Please select a CRAN mirror for use
> in this session'. if I insist, it crashes. No useful error messages. Trying
> via the Package Installer tab didn't work either. It doesn't find any
> packages, indeed it crashes if I ask it to load the list.

This indeed sounds like an xQuartz issue, failing to popup the mirror
selection menu. Does everything work if you manually set your CRAN
mirror first, e.g:

  options(repos=c(CRAN="https://cloud.r-project.org;))

Alternatively you can disable the popup menus all-together using:

  options(menu.graphics=FALSE)

Which should probably be the default.

___
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

2021-11-13 Thread Jeroen Ooms 
On Sat, Nov 13, 2021 at 6:01 PM Gábor Csárdi  wrote:
>
> 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.

What Gabor says works; an alternative solution is just to update the
entire CA bundle. I use the following script on old macs:

sudo cp /etc/ssl/cert.pem /etc/ssl/cert.bak
sudo curl -k https://curl.se/ca/cacert.pem -o /etc/ssl/cert.pem

This will update the CA bundle to the current one from Mozilla, for
details see: https://curl.se/docs/caextract.html

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

Re: [R-SIG-Mac] Libre SSL bug on MacOS Monterey => error in download.file()

2022-01-10 Thread Jeroen Ooms 
On Mon, Jan 10, 2022 at 11:22 AM Petr Bouchal  wrote:
>
> Dear all,
>
> In brief: on Monterey, R cannot reach certain web domains due to a bug in 
> Libre SSL - and perhaps not relying on system curl/openssl in R would be a 
> systematic solution to this and símilar issues.
>
> Specifically: on MacOS Monterey 12.1 using R 4.1.2, download.file() and other 
> functions that rely on system-provided curl/openssl/Libre SSL (including in 
> the curl package) have been failing on specific domains.
>
> So running
>
> download.file(“https://www.czso.cz/”, tempfile())
>
> returns:
>
> status was ‘SSL connect error’
>
> the underlying error being
>
> error:06FFF089:digital envelope routines:CRYPTO_internal:bad key length.

I have to investigate this further (it looks like a buggy TLS server
actually), but as a workaround you can set an environment variable
CURL_SSL_BACKEND=SecureTransport when starting R, see for details:
https://curl.se/libcurl/c/libcurl-env.html

The version of libcurl that is included with the past few versions of
MacOS is actually built with support for 2 TLS back-ends: LibreSSL and
native apple TLS (aka SecureTransport). You can override the default
using the environment variable above, but you have to set it before
libcurl gets initiated, hence before making any http connections in
the R session, e.g. in your .Renviron.

You can see which version is active by looking at
curl::curl_version()$ssl_version, the version in parenthesis is  Try
running:

   CURL_SSL_BACKEND=openssl R -e "curl::curl_version()$ssl_version"
   CURL_SSL_BACKEND=SecureTransport R -e "curl::curl_version()$ssl_version"

The same version of libcurl is also used by base-R in download.file().
I've also explained this a bit (mostly for windows) in this vignette:
https://cran.r-project.org/web/packages/curl/vignettes/windows.html

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

Re: [R-SIG-Mac] Libre SSL bug on MacOS Monterey => error in download.file()

2022-01-12 Thread Jeroen Ooms 
On Tue, Jan 11, 2022 at 10:12 PM Simon Urbanek
 wrote:
>
> Petře,
>
> thanks, for the detailed analysis. It is rather curious that the issue 
> appears only on _newer_ systems - we are more used to issues due to older CA 
> chains and similar. It looks like an Apple bug on specific systems, so 
> hopefully it will be fixed eventually. In general I was trying to avoid 
> having to supply our own SSL library since that opens a whole can of worms - 
> on one hand due the dependency issues (which libraries get compiled against 
> what) and on the other hand we become responsible for security updates.
>
> Thanks to Jeroen for the work-around (CURL_SSL_BACKEND=SecureTransport), 
> using the native API is certainly preferred, there have been several issues 
> with both OpenSSL and LibreSSL before. It seems that Apple has been 
> flip-flopping with libcurl a lot - on El Capitan it was shipped with 
> SecureTransport, on High-Sierra with LibreSSL, on Catalina and higher with 
> both, but Libre the default.
>
> I am somewhat less apprehensive to use static libcurl for R than SSL 
> libraries as the fallout is a bit smaller. As a trial I have added static 
> curl[2] which is close to the Apple build minus MultiSSL to big-sur nightly 
> builds of R[3] and as expected that solves the problem. It may not be 
> entirely unproblematic for package space, because packages often forget to 
> prepend  --static when using static builds of libraries, and so do other 
> dependencies that may use curl, but I'll see what comes out of it.

I would much recommend to stick with the apple version of libcurl;
perhaps override the default ssl-backend if you like. There is some
example code to do this in the curl package that you could adapt for
base r: https://github.com/jeroen/curl/blob/master/src/ssl.c

The benefit of dynamically linking to apple's libcurl is that we
automatically get a version of libcurl+deps+certs that is tuned and
maintained for that version of macos, including future ones. If you
ship a version of base-R with a static libcurl now, that version of R
may not work anymore a few years from now or on a future version of
macos, when things have moved on (for example, when servers start to
require TLS1.3).

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

Re: [R-SIG-Mac] Libre SSL bug on MacOS Monterey => error in download.file()

2022-01-12 Thread Jeroen Ooms 
On Wed, Jan 12, 2022 at 10:05 PM Simon Urbanek
 wrote:
> Yes, but if you are using an old version of R on a new system, you have a lot 
> of other worries - you can't expect new technologies to work with old 
> software. CURL itself has fewer evolution issues than SSL libraries. As I 
> said, I am a big proponent of re-using system libraries as much as possible, 
> but, for example, High Sierra doesn't ship with ST back-end support, so using 
> a static version that does is better there as Apple doesn't not maintain the 
> curl CAs but it does the system ones so it's arguably better. The current 
> issue is quite curious since breaking on the latest system is quite unusual, 
> just preferring ST works only because it is the latest system that breaks and 
> it has the ST option.
>
> As Brian pointed out static curl has its own issues since its pkg-config 
> flags are broken - that's why I have not activated the add-on recipes by 
> default, I have seen those issues before.
>
> For R itself there are thee options:
>
> a) add CURL_SSL_BACKEND=${CURL_SSL_BACKEND-'SecureTransport'} to 
> $R_HOME/etc/Renviron of the distribution
>
> b) add something like your 
> https://github.com/r-devel/r-svn/pull/75/commits/79b22b461e527e8a46de84c145e8e5fb59e75d14
>  to R
>
> c) build against static libcurl
>
>
> The big advantage of the first one is that it applies to all processes, so 
> even command line curl will then work and so will all packages.
>
> The drawback of the second one is that it only applies the R itself. The 
> third one could be done both for R and packages, but causes headaches resp. 
> requires slight patching of libcurl.pc. The advantage is that it can bring 
> more recent curl to all older systems.
>
> I don't have a strong opinion. I am not thrilled with option b) because that 
> is a hack just to react to something which is never a good idea from 
> maintenance point of view (we would require all curl-based code to use it). 
> So I think a) and c) are more palatable with a) having the benefit of 
> handling non-R cases. A slight benefit of c) is that some dependencies 
> require more recent curl version than provided by older systems, so that 
> would cover it at the cost of maintaining the curl binaries. Finally, the 
> real benefit of c) is that if Apple screws things up even more we don't care 
> - we may not be at that point yet, though.

I don't think apple screwed up per se; they probably tested several
configurations and picked this one to be the safest default. TLS is a
complex protocol with many versions and implementations; if some weird
server uses some non-standard cipher or unusual response, it may just
depend on the TLS library if it can handle that. I'm sure you'll be
able to find counter examples where libre/openssl works and
SecureTransport does not. For example, a case that we often encounter
on Windows are corporate networks which require connecting via
authenticated proxy servers or using a TLS client cert, which only
works on certain back-ends, see the table in:
https://cran.r-project.org/web/packages/curl/vignettes/windows.html

So I much favor of option A. This introduces the least complexity, and
keeps the ability for users to undo our change and switch back to
CURL_SSL_BACKEND=openssl in their .Renviron. Also it is a big benefit
in practice that curl in R behaves the same as command line curl on
that same machine, in order to narrow down if a connection problem is
a bug in our R code, or if it also exists outside of R.

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

Re: [R-SIG-Mac] Please test R 4.2.0 pre-releases

2022-04-19 Thread Jeroen Ooms 
On Sun, Apr 17, 2022 at 4:38 AM Simon Urbanek
 wrote:
>
> Dear Mac users,
>
> we are nearing the release of R 4.2.0 (on Friday) which introduces some 
> significant changes not only in R itself, but also in some Mac-specific build 
> settings. Please help us by testing R pre-releases *before* the release such 
> that any obvious issues can be caught prior to the release. The nightly 
> pre-releases both for Intel Macs (high-sierra build) as well as M1 Macs 
> (big-sur build) are available at
>
> https://mac.r-project.org/
>
> The nightly Installer packages (R-4.2-branch.pkg) are created just like the 
> release and signed, but not always Apple notarized, so to install hold the 
>  key when opening and pick "Open" in the dialog box if prompted.
>
> Package binaries for R 4.2.0 are also now available on CRAN, please report 
> any issues to me. The Mac Builder has also been updated to use latest 
> libraries and it now defaults to the R pre-release.

Is the m1 macbuilder (https://mac.r-project.org/macbuilder/submit.html
) still supported? I tried uploading a package, but it still says
"Please check back later" after an hour, and I did not receive any
email, and the auto-refresh seems broken (the embedded jquery url is
404). Afaict, the package check logs for mac-4.2 are also still not
available on cran, so this makes it quite difficult for package
authors to help with timely reporting the Mac-specific build issues
that you mention.

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

Re: [R-SIG-Mac] Permission issues running R in terminal

2024-02-19 Thread Jeroen Ooms 
On Sun, Feb 18, 2024 at 11:57 PM Duncan Murdoch 
wrote:

> I wanted to see the options to R CMD INSTALL, and was surprised to see
> this output:
>
> $ R CMD INSTALL --help
> shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
> Error in tools:::.install_packages() :
>current working directory cannot be ascertained
> shell-init: error retrieving current directory: getcwd: cannot access
> parent directories: Operation not permitted
>
> I installed R from CRAN, and am not running the current version:  I'm
> still on 4.3.1, with OS also kind of old:  Monterey 12.7.3, so I was
> surprised by this.  Is anyone else seeing it?
>

This happens when you don't have write access in the current dir:

mkdir /tmp/test
cd /tmp/test
chmod 0 .
R CMD INSTALL --help

[[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] Cross compilation and linking without -undefined

2024-01-02 Thread Jeroen Ooms 
R on MacOS defaults to linking with "-undefined dynamic_lookup" when
building packages, which suppresses linking errors due to undefined
symbols. Undefined symbols often indicate that the package has omitted
a required library in PKG_LIBS, or that the architecture of the static
lib does not match the target. When this happens, CMD INSTALL usually
fails to load the package dylib in the subsequent "test-load" step,
unless the undefined symbols are already preloaded in the process via
base R (e.g. zlib, iconv, etc) in which case it goes unnoticed.

I was wondering what is the benefit of suppressing linking errors this
way? Afaik R does not do this on other platforms. A failure at the
"test-load" step gives a cryptic error indicating only the mangled
name of the first undefined symbol. The linker can provide much nicer
error messages, detailing the names and locations of undefined
symbols.

Another motivation for looking into this is to support cross compiling
of R packages on MacOS. We are exploring several ways to cross compile
R packages, including:

  macos-x86_64 -> macos-arm64 (by overriding -arch in Makeconf)
  linux-x86_64 -> macos-x86_64 (using osxcross)
  linux-x86_64 -> macos-arm64 (using osxcross)

The main challenge with cross compiling is that we cannot test-load
the R package on the host machine, so we always have to build with
--no-test-load. However this is dangerous in combination with the
"-undefined" flag, because we don't catch undefined symbols anymore.

Unfortunately undefined symbols are a common problem when cross
compiling, because some packages mistakenly assume host == target, and
then build/link a lib for the wrong arch. If we don't catch this, we
end up shipping broken binary R packages to end-users, which we want
to prevent.

To remedy this, I am testing to build packages using the same setup as
CRAN (MacOSX11.sdk + libs from
https://mac.r-project.org/bin/darwin20/) but without the "-undefined
dynamic_lookup" flag, like so:

  sed -i.bak 's/-undefined dynamic_lookup//g' $(R RHOME)/etc/Makeconf

This works fine for almost all packages. Some do reveal a linking
problem, but these are mostly real bugs and easily fixable. For
example the httpuv package fails with:

ld: Undefined symbols:
  _deflate, referenced from:
  GZipDataSource::getData(unsigned long) in gzipdatasource.o
  GZipDataSource::deflateNext() in gzipdatasource.o
  _deflateEnd, referenced from:
  GZipDataSource::~GZipDataSource() in gzipdatasource.o

Note how the above message from the linker is very clear in what is
missing and where. This error is accurate, because httpuv indeed calls
external libz, but fails to set "-lz" in PKG_LIBS. This was never
noticed because libz.dylib is preloaded in R, hence the test-load does
not notice the bug.

Another example is 'arrow' which was missing "-framework Security" in
PKG_LIBS. This will be fixed in the upcoming CRAN release. There were
a few more of such cases where PKG_LIBS was missing some lib of
Framework, but they are mostly fixable.

One problem I have not solved is the RcppParallel package, which
bundles another library (libtbb) which is not linked but lazy-loaded
(not sure why). This causes linking errors or some other packages that
have LinkingTo: RcppParallel. Perhaps this can be solved by providing
a static libtbb via the cran recipes, such that RcppParallel does not
have to bundle one.

It would be really nice if eventually R could remove "-undefined" from
the default linker flags when building R packages. This makes build
logs more informative and easier to debug, and forces packages to
specify complete linker flags, which will eventually enable safer
cross-compiling (including of universal binaries).

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

Re: [R-SIG-Mac] Debugging Symbols

2024-04-04 Thread Jeroen Ooms 
On Thu, Apr 4, 2024 at 9:47 AM Hannes Mühleisen  wrote:
>
> Hello List,
>
> we would like to bring up the topic of debug symbols in the CRAN OSX
> binaries again. I realize this has been discussed before [1] and
> realize the symbols are there for a reason, but in the duckdb package
> their inclusion is particularly problematic.
>
> Currently, the CRAN binary for OSX Arm64 weighs in at a whopping 97 MB
> [2]. Inside it lives a 311 MB (uncompressed) folder with the debugging
> symbols. When I remove the debugging symbols and re-create the
> compressed tarball, its compressed size goes down to 11 MB, a pretty
> drastic difference.
>
> We are getting feedback from users that the package is too large for
> them to be useful, so we would really like to improve this situation.

FWIW, the binaries on https://duckdb.r-universe.dev/duckdb are built
with _R_SHLIB_STRIP_: TRUE and those are indeed around 10M (both for
Linux and MacOS).

For similar reasons p3m (formerly rspm) also strips debugging symbols
these days, e.g:
https://p3m.dev/cran/latest/bin/macosx/big-sur-x86_64/contrib/4.3/duckdb_0.10.1.tgz
See also this comment:
https://github.com/rocker-org/rocker-versioned2/issues/340#issuecomment-1301157428

I agree it would be nice for a package to be able to opt-out
altogether, including on CRAN. I don't think that is possible right
now.

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