Re: [R-SIG-Mac] How to correct tcltk path?

[Kasper Daniel Hansen]

You need to install XQuartz. This is IMO stated somewhat clearly at
  https://cran.r-project.org/bin/macosx/
("somewhat", because - as always - it seems pretty clear when you know what
its trying to say)

Kasper

On Thu, Apr 4, 2024 at 9:13 AM Gregory via R-SIG-Mac <
r-sig-mac@r-project.org> wrote:

> Hello,
>
> I'm having an issue with R looking for tcltk in the wrong place. Whenever
> I start R, I get a message: tcltk DLL is linked to
> '/opt/X11/lib/libX11.6.dylib'. However, there is no /opt/X11 on my system
> and tcltk is really in /opt/R/arm64, where the R binary installer put it.
> Where is R getting the /opt/X11 path and how do I correct that? So far I've
> tried exporting DYLD_LIBRARY_PATH=opt/R/arm64:$DYLD_LIBRARY_PATH to my
> environment in my zprofile, but that hasn't worked.
>
> Possibly relevant details:
> M2 MacBook Pro, MacOS Sonoma 14.4.1
> R.version 4.3.3 installed with binary installer from CRAN.
>
> Thanks in advance,
> Gregory
>
> Sent with [Proton Mail](https://proton.me/) secure email.
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>


-- 
Best,
Kasper

[[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] symbol not found in flat namespace '___kmpc_critical'

[Kasper Daniel Hansen]

Rodney,

I don't know much about OpenMP and macOS, but note that these days
  https://mac.r-project.org/tools/
says
  "Additional information on the OpenMP page is available for those
interested in OpenMP support which is not supported by Apple, but still
possible with additional libraries."
and links to
  https://mac.r-project.org/openmp/

I _believe_ that this requires the _user_ (or the check/build system) of
the package on macOS to install one of the custom clang compilers listed on
the page. For this reason, I don't think it is trivial to get the
package through CRAN or distribute the package if it links / uses OpenMP. I
could be wrong of course, since it is not something I follow. I am guessing
the best solution (which could be complicated) is to have a configure
script which checks at build time whether the system supports OpenMP. This
feels like something someone has thought about.

Best,
Kasper




On Sat, Apr 29, 2023 at 6:32 PM Sparapani, Rodney via R-SIG-Mac <
r-sig-mac@r-project.org> wrote:

> Oh, that was totally self-inflicted.
> I had commented out PKG_LIBS in Makevars.in
> That does work on Linux with OpenMP somehow.
> However, it does NOT with macOS.  Thanks
>
> --
> Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
> Director, Wisconsin Chapter of the American Statistical Association
> Institute for Health and Equity, Division of Biostatistics
> Medical College of Wisconsin, Milwaukee Campus
>
>
> From: R-SIG-Mac  on behalf of Sparapani,
> Rodney via R-SIG-Mac 
> Date: Saturday, April 29, 2023 at 4:18 PM
> To: r-sig-mac@r-project.org 
> Subject: [R-SIG-Mac] symbol not found in flat namespace '___kmpc_critical'
> ATTENTION: This email originated from a sender outside of MCW. Use caution
> when clicking on links or opening attachments.
> 
>
> Hi Gang:
>
> After hours of debugging, I�m stuck and hoping that someone has an
> idea of what the issue is here.  Any hints/tips/etc. are greatly
> appreciated!
>
> I�m getting this error from my CRAN package, nftbart.  Right now, I�m
> preparing for a new release: v1.6.  However, I�m stumped by this error
> message that I get when installing with OpenMP.  Without OpenMP,
> everything is fine; however, the package benefits greatly from OpenMP.
>
> I am getting the same results for R 4.2.3 and 4.3.0 RC.  The source code is
> on github at
> https://urldefense.com/v3/__https://github.com/rsparapa/bnptools.git__;!!H8mHWRdzp34!4rScCMt0gCJ2ZzuZjzo9CEWXYOBECh814z0fzF0OiVjfFcc609ThiLvNcCYt4sIk7wrZhld1ErXx7PLOgKyTDw$
> <
> https://urldefense.com/v3/__https:/github.com/rsparapa/bnptools.git__;!!H8mHWRdzp34!4rScCMt0gCJ2ZzuZjzo9CEWXYOBECh814z0fzF0OiVjfFcc609ThiLvNcCYt4sIk7wrZhld1ErXx7PLOgKyTDw$
> >
>
> So, to demonstrate, you just need to do something like this�
>
>
> $ git clone
> https://urldefense.com/v3/__https://github.com/rsparapa/bnptools.git__;!!H8mHWRdzp34!4rScCMt0gCJ2ZzuZjzo9CEWXYOBECh814z0fzF0OiVjfFcc609ThiLvNcCYt4sIk7wrZhld1ErXx7PLOgKyTDw$
> <
> https://urldefense.com/v3/__https:/github.com/rsparapa/bnptools.git__;!!H8mHWRdzp34!4rScCMt0gCJ2ZzuZjzo9CEWXYOBECh814z0fzF0OiVjfFcc609ThiLvNcCYt4sIk7wrZhld1ErXx7PLOgKyTDw$>
> DIR
>
> $ cd DIR
>
> $ R CMD build nftbart
>
> $ R CMD INSTALL nftbart_1.6.tar.gz
>
> * installing to library
> �/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library�
>
> * installing *source* package �nftbart� ...
>
> ** using staged installation
>
> checking whether the C++ compiler works... yes
>
> checking for C++ compiler default output file name... a.out
>
> checking for suffix of executables...
>
> checking whether we are cross compiling... no
>
> checking for suffix of object files... o
>
> checking whether we are using the GNU C++ compiler... yes
>
> checking whether clang++ -arch x86_64 -std=gnu++17 accepts -g... yes
>
> checking for clang++ -arch x86_64 -std=gnu++17 option to support OpenMP...
> -lomp -Xclang -fopenmp
>
> configure: creating ./config.status
>
> config.status: creating src/Makevars
>
> ** libs
>
> using C compiler: �Apple clang version 14.0.3 (clang-1403.0.22.14.1)�
>
> using C++ compiler: �Apple clang version 14.0.3 (clang-1403.0.22.14.1)�
>
> using SDK: ��
>
> clang -arch x86_64 -I"/Library/Frameworks/R.framework/Resources/include"
> -DNDEBUG -lomp -Xclang -fopenmp
> -I'/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/Rcpp/include'
> -I/opt/R/x86_64/include-fPIC  -falign-functions=64 -Wall -g -O2  -c
> init.c -o init.o
>
> clang++ -arch x86_64 -std=gnu++17
> -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -lomp
> -Xclang -fopenmp
> -I'/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library/Rcpp/include'
> -I/opt/R/x86_64/include-fPIC  -falign-functions=64 -Wall -g -O2  -c
> nftbart.cpp -o nftbart.o
>
> clang++ -arch x86_64 -std=gnu++17 -dynamiclib
> -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module
> -multiply_defined suppress 

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

[Kasper Daniel Hansen]

I am not an expert, but it seems to me that switching the backend is a
runtime setting. Couldn't we detect which version of OS X we're running and
then select the backend conditionally on that test?

Best,
Kasper

On Wed, Jan 12, 2022 at 5:12 PM Jeroen Ooms  wrote:

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


-- 
Best,
Kasper

[[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] https://mac.r-project.org/benchmarks/

[Kasper Daniel Hansen]

Out of curiosity, do we know if vecLib/Accelerate has been optimized for
M1?

On Sun, Oct 31, 2021 at 10:00 PM Kieran Healy  wrote:

> Thanks, Simon.
>
> With the vecLib/Accelerate BLAS, the results are indeed rather faster :)
>
> Kieran
>
>
> 14” MacBook Pro / M1 Max
>
>R Benchmark 2.5
>===
> Number of times each test is run__:  3
>
>I. Matrix calculation
>-
> Creation, transp., deformation of a 2500x2500 matrix (sec):
> 0.260
> 2400x2400 normal distributed random matrix ^1000 (sec):  0.105
> Sorting of 7,000,000 random values__ (sec):  0.595
> 2800x2800 cross-product matrix (b = a' * a)_ (sec):
> 0.056
> Linear regr. over a 3000x3000 matrix (c = a \ b')___ (sec):
> 0.0448
>   
>  Trimmed geom. mean (2 extremes eliminated):
> 0.115802825957684
>
>II. Matrix functions
>
> FFT over 2,400,000 random values (sec):
> 0.07233329
> Eigenvalues of a 640x640 random matrix__ (sec):
> 0.157
> Determinant of a 2500x2500 random matrix (sec):
> 0.098
> Cholesky decomposition of a 3000x3000 matrix (sec):
> 0.07166654
> Inverse of a 1600x1600 random matrix (sec):
> 0.0826667
>   
> Trimmed geom. mean (2 extremes eliminated):
> 0.0839655943753058
>
>III. Programmation
>--
> 3,500,000 Fibonacci numbers calculation (vector calc)(sec):
> 0.0937
> Creation of a 3000x3000 Hilbert matrix (matrix calc) (sec):
> 0.1123332
> Grand common divisors of 400,000 pairs (recursion)__ (sec):
> 0.07766657
> Creation of a 500x500 Toeplitz matrix (loops)___ (sec):
> 0.0172
> Escoufier's method on a 45x45 matrix (mixed) (sec):
> 0.1119998
>   
> Trimmed geom. mean (2 extremes eliminated):
> 0.0932888677080541
>
>
> Total time for all 15 tests_ (sec):
> 1.957333
> Overall mean (sum of I, II and III trimmed means/3)_ (sec):
> 0.0968018035139188
>   --- End of test ---
>
> > On Oct 31, 2021, at 9:03 PM, Simon Urbanek 
> wrote:
> >
> > Kieran,
> >
> > the reference benchmarks have been calibrated against vecLib/Accelerate
> BLAS. If you use reference BLAS it can be a lot slower. You can switch
> between reference BLAS and vecLib in R CRAN releases simply by switching
> the libRblas.dylib symlink (in $R_HOME/lib), e.g.:
> >
> > ls -l /Library/Frameworks/R.framework/Resources/lib/libRblas*dylib
> > -rwxrwxr-x  1 root admin  226288 Oct 31 14:41
> /Library/Frameworks/R.framework/Resources/lib/libRblas.0.dylib
> > lrwxr-xr-x  1 root.admin  21 Nov  1 09:56
> /Library/Frameworks/R.framework/Resources/lib/libRblas.dylib ->
> libRblas.vecLib.dylib
> > -rwxrwxr-x  1 root admin  154368 Oct 31 14:41
> /Library/Frameworks/R.framework/Resources/lib/libRblas.vecLib.dylib
> >
> > (For recent R you'll need R 4.1.1 or higher)
> >
> > Cheers,
> > Simon
> >
> > PS: reminder to everyone, please test R 4.1.2 RC - now are the last few
> hours to report anything!
> >
> >
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>


-- 
Best,
Kasper

[[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] possible bug in R's make install

[Kasper Daniel Hansen]

I'll file a bug report from memory.

On Tue, May 18, 2021 at 12:46 AM Simon Urbanek 
wrote:

> Has anyone reported this bug at bugs.R-project.org? Quick search doesn't
> yield anything - Peter can you post the reference, please, if you reported
> it there? Since this is not a Mac-specific issue that's where should go if
> it is to be fixed.
>
> Cheers,
> Simon
>
>
> > On May 18, 2021, at 12:32 AM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
> >
> > This bug is still present in the R-4.1.
> >
> > Best,
> > Kasper
> >
> > On Fri, Sep 28, 2018 at 8:02 PM Peter Langfelder <
> peter.langfel...@gmail.com>
> > wrote:
> >
> >> For what it's worth, the same bug is present on linux when compiling R
> >> with a custom BLAS (either ATLAS or OpenBLAS). The directory needs to
> >> be made by hand first. I beleive I have reported this some time ago
> >> but no action was taken. Compiling R with R internal BLAS does not
> >> results in the error.
> >>
> >> Peter
> >> On Fri, Sep 28, 2018 at 10:52 AM Kasper Daniel Hansen
> >>  wrote:
> >>>
> >>> I am trying to compile and install R under High Sierra with Accelerate
> >> BLAS
> >>> but with R lapack.
> >>>
> >>> My relevant configure call is   --with-blas="-framework Accelerate" but
> >>> omitting --with-lapack. Full call is pasted at the end of this email
> >>>
> >>> I can do
> >>>  make
> >>>  make check
> >>> but make install fails with
> >>>
> >>> make[2]: Nothing to be done for `install'.
> >>> /usr/local/clang6/bin/clang -I. -I../../src/include
> >>> -I../../../R-3.5.x-src/src/include -I/opt/X11/include
> >> -I/usr/local/include
> >>> -DHAVE_CONFIG_H-Wall -mtune=native -g -O2  -L/usr/local/clang6/lib
> >>> -L/usr/local/lib -L/usr/local/opt/tcl-tk/lib
> >>> -DR_HOME='"/usr/local/R/R-3.5.x/lib/R"' \
> >>>  -o Rscript ../../../R-3.5.x-src/src/unix/Rscript.c
> >>> mkdir /usr/local/R/R-3.5.x/lib/R/bin/exec
> >>> mkdir /usr/local/R/R-3.5.x/lib/R/modules
> >>> cp: /usr/local/R/R-3.5.x/lib/R/lib/libRlapack.dylib: No such file or
> >>> directory
> >>> make[3]: *** [install] Error 1
> >>> make[2]: *** [install] Error 1
> >>> make[1]: *** [install] Error 1
> >>> make: *** [install] Error 1
> >>>
> >>> I manually verified that libRlapack.dylib had been build in the
> building
> >>> directory's "lib".  I then just did
> >>>
> >>> sudo mkdir /usr/local/R/R-3.5.x/lib/R/lib
> >>>
> >>> (my installation directory is /usr/local/R/R-3.5.x) and redid make
> >> install
> >>> which now worked.  I get
> >>>
> >>> $ ls /usr/local/R/R-3.5.x/lib/R/lib
> >>> libRlapack.dylib
> >>>
> >>> My _guess_ is that since I am using R's lapack and system BLAS that the
> >>> RHOME/lib directory does not get created.
> >>>
> >>> Btw., this might be a bad idea (happy to hear about this) but the
> >>> installation should work since I can do make check
> >>>
> >>> Kasper
> >>>
> >>> configure
> >>>
> >>> ../${SRCDIR}/configure SHELL='/bin/bash' \
> >>>  --prefix=/usr/local/R/R-${R_VERSION} --disable-R-framework\
> >>>  CC="/usr/local/clang6/bin/clang" \
> >>>  CXX="/usr/local/clang6/bin/clang++" \
> >>>  F77="/usr/local/gfortran/bin/gfortran" \
> >>>  FC="$F77" \
> >>>  OBJC="clang" \
> >>>  CFLAGS="-Wall -mtune=native -g -O2" \
> >>>  CXXFLAGS="-Wall -mtune=natuve -g -O2" \
> >>>  OBJCFLAGS="-Wall -mtune=native -g -O2 -fobjc-exceptions" \
> >>>  F77FLAGS="-Wall -g -O2 -mtune=generic" \
> >>>  FCFLAGS="$F77FLAGS" \
> >>>  FLIBS="-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0
> >>> -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm" \
> >>>  LDFLAGS="-L/usr/local/clang6/lib -L/usr/local/lib" \
> >>>  DYLD_FALLBACK_LIBRARY_PATH="/usr/local/clang6/lib:/usr/local/lib" \
> >>>
> >>>
> >>
> PKG_CONFIG_PATH="/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig"
> >>> \
> >>>  JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Home" \
> >>>  JAVA_CPPFLAGS="-I/System/Library/Frameworks/JavaVM.framework/Headers"
> \
> >>>  JAVA_LD_LIBRARY_PATH="" \
> >>>  JAVA_LIBS="-framework JavaVM" \
> >>>  --enable-memory-profiling\
> >>>  --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib\
> >>>  -with-tcltk=/usr/local/opt/tcl-tk/lib\
> >>>  --with-blas="-framework Accelerate" | tee ../configure-${R_VERSION}
> >>>
> >>>[[alternative HTML version deleted]]
> >>>
> >>> ___
> >>> R-SIG-Mac mailing list
> >>> R-SIG-Mac@r-project.org
> >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >>
> >
> >
> > --
> > Best,
> > Kasper
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > R-SIG-Mac mailing list
> > R-SIG-Mac@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >
>
>

-- 
Best,
Kasper

[[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] possible bug in R's make install

[Kasper Daniel Hansen]

This bug is still present in the R-4.1.

Best,
Kasper

On Fri, Sep 28, 2018 at 8:02 PM Peter Langfelder 
wrote:

> For what it's worth, the same bug is present on linux when compiling R
> with a custom BLAS (either ATLAS or OpenBLAS). The directory needs to
> be made by hand first. I beleive I have reported this some time ago
> but no action was taken. Compiling R with R internal BLAS does not
> results in the error.
>
> Peter
> On Fri, Sep 28, 2018 at 10:52 AM Kasper Daniel Hansen
>  wrote:
> >
> > I am trying to compile and install R under High Sierra with Accelerate
> BLAS
> > but with R lapack.
> >
> > My relevant configure call is   --with-blas="-framework Accelerate" but
> > omitting --with-lapack. Full call is pasted at the end of this email
> >
> > I can do
> >   make
> >   make check
> > but make install fails with
> >
> > make[2]: Nothing to be done for `install'.
> > /usr/local/clang6/bin/clang -I. -I../../src/include
> > -I../../../R-3.5.x-src/src/include -I/opt/X11/include
> -I/usr/local/include
> > -DHAVE_CONFIG_H-Wall -mtune=native -g -O2  -L/usr/local/clang6/lib
> > -L/usr/local/lib -L/usr/local/opt/tcl-tk/lib
> > -DR_HOME='"/usr/local/R/R-3.5.x/lib/R"' \
> >   -o Rscript ../../../R-3.5.x-src/src/unix/Rscript.c
> > mkdir /usr/local/R/R-3.5.x/lib/R/bin/exec
> > mkdir /usr/local/R/R-3.5.x/lib/R/modules
> > cp: /usr/local/R/R-3.5.x/lib/R/lib/libRlapack.dylib: No such file or
> > directory
> > make[3]: *** [install] Error 1
> > make[2]: *** [install] Error 1
> > make[1]: *** [install] Error 1
> > make: *** [install] Error 1
> >
> > I manually verified that libRlapack.dylib had been build in the building
> > directory's "lib".  I then just did
> >
> > sudo mkdir /usr/local/R/R-3.5.x/lib/R/lib
> >
> > (my installation directory is /usr/local/R/R-3.5.x) and redid make
> install
> > which now worked.  I get
> >
> > $ ls /usr/local/R/R-3.5.x/lib/R/lib
> > libRlapack.dylib
> >
> > My _guess_ is that since I am using R's lapack and system BLAS that the
> > RHOME/lib directory does not get created.
> >
> > Btw., this might be a bad idea (happy to hear about this) but the
> > installation should work since I can do make check
> >
> > Kasper
> >
> > configure
> >
> > ../${SRCDIR}/configure SHELL='/bin/bash' \
> >   --prefix=/usr/local/R/R-${R_VERSION} --disable-R-framework\
> >   CC="/usr/local/clang6/bin/clang" \
> >   CXX="/usr/local/clang6/bin/clang++" \
> >   F77="/usr/local/gfortran/bin/gfortran" \
> >   FC="$F77" \
> >   OBJC="clang" \
> >   CFLAGS="-Wall -mtune=native -g -O2" \
> >   CXXFLAGS="-Wall -mtune=natuve -g -O2" \
> >   OBJCFLAGS="-Wall -mtune=native -g -O2 -fobjc-exceptions" \
> >   F77FLAGS="-Wall -g -O2 -mtune=generic" \
> >   FCFLAGS="$F77FLAGS" \
> >   FLIBS="-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0
> > -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm" \
> >   LDFLAGS="-L/usr/local/clang6/lib -L/usr/local/lib" \
> >   DYLD_FALLBACK_LIBRARY_PATH="/usr/local/clang6/lib:/usr/local/lib" \
> >
> >
> PKG_CONFIG_PATH="/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig"
> > \
> >   JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Home" \
> >   JAVA_CPPFLAGS="-I/System/Library/Frameworks/JavaVM.framework/Headers" \
> >   JAVA_LD_LIBRARY_PATH="" \
> >   JAVA_LIBS="-framework JavaVM" \
> >   --enable-memory-profiling\
> >   --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib\
> >   -with-tcltk=/usr/local/opt/tcl-tk/lib\
> >   --with-blas="-framework Accelerate" | tee ../configure-${R_VERSION}
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > R-SIG-Mac mailing list
> > R-SIG-Mac@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>


-- 
Best,
Kasper

[[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] [External] Re: [External] Behaviour or Quartz windows

[Kasper Daniel Hansen]

quartz is the graphics layer of OS X (
https://en.wikipedia.org/wiki/Quartz_(graphics_layer)). This is why the
"native" Apple device is called quartz() in R. This is a super nice device
IMO.

Xquartz is a port of X11 to quartz. To use XQuartz on OS X you have to use
the x11() device (or features which uses X11). So basically, they have
nothing to do with each other.

On Tue, Feb 9, 2021 at 8:15 PM Richard M. Heiberger  wrote:

> Your are correct.  I have been using quartz() on the released intel build
> of R_4.0.3 on the
> Mac Silicon.  The misbehavior I reported is about quartz(). R graphics
> defaults to quartz()
> when no device is specified.
>
> I was unaware that XQuartz and quartz are unrelated.   quartz is faster
> and allows pagination.  XQuartz is very slow, you can watch it draw each
> panel, and each bar in a bar graph.
> XQuartz does not have pagination.
>
> 
> From: Prof Brian Ripley 
> Sent: Tuesday, February 9, 2021 1:26 PM
> To: Richard M. Heiberger; Peter West; r-sig-mac@r-project.org
> Subject: [External] Re: [R-SIG-Mac] [External] Behaviour or Quartz windows
>
> The quartz() device has nothing to so with XQuartz.  Quartz is part of
> macOS: https://en.wikipedia.org/wiki/Quartz_(graphics_layer)
>
> Using XQuartz betas is not supported: it is very unfortunate that they
> are persuading users to install a beta version.
>
> You have not followed the posting guide and posted the sessionInfo().
> We are left to guess that you are using an Intel build of R under
> emulation, but homebrew does have (a rather broken) arm64 build of R
> 4.0.3: we do not support arm64 builds on R < 4.1.0.  My understanding is
> that in the CRAN release of R 4.0.3 only the X11() device and parts of
> Tk interact with XQuartz, although other parts may in other builds.
>
> On 09/02/2021 17:33, Richard M. Heiberger wrote:
> > Is R on M1 really talking to the REAL XQuartz?  After I opened XQuartz
> from the spotlignt, it acknowledged the xterm window, but not the R
> graphics window.  When I closed the XQuartz
> > app, the R graphics window was still open and functioning.  dev.cur()
> says "quartz".
> >
> > just checked on my older intel mac.  same behavior.  the Xquartz.app
> menu doesn't list
> > the R graphics window, and the R graphics shows "...", not "XQuartz" in
> the menu bar.
> >
> > 
> > From: R-SIG-Mac  on behalf of Richard
> M. Heiberger 
> > Sent: Tuesday, February 9, 2021 11:56 AM
> > To: Peter West; r-sig-mac@r-project.org
> > Subject: Re: [R-SIG-Mac] [External]  Behaviour or Quartz windows
> >
> > When I draw a 9x7 panel lattice it displays 12 panels, then sits there
> until I resize the window. then the rest appears.  When I display another
> 9x7, it too sits at 12 panels.
> > When I Cmd-left for the previous display, the current one vanishes
> entirely.
> > When I send the command again, after it sits I resize the window.  Now
> the full second display
> > is visible.  When I Cmd-left followed by Cmd-right, the second display
> is lost.
> >
> > I am using R version 4.0.3 (2020-10-10) on Silicon Mac Big Sur 11.1 from
> inside ESS.
> >
> > XQuartz doesn't report correctly.  On the MenuBar it doesn't say
> "XQuartz".  Instead it shows a
> > small Apple Icon which has no information when clicked.  When I search
> using the MenuBar Spotlight icon, it tells me Xquartz 2.8.0_beta1 and
> offers to update to beta3.  Clicking on XQuartz.app in the Spotlight menu
> gives proper XQuartz information in the upper left corner
> > of the MenuBar.
> >
> > Rich
> >
> > Get Outlook for iOS
> > 
> > From: R-SIG-Mac  on behalf of Peter
> West 
> > Sent: Tuesday, February 9, 2021 10:35:59 AM
> > To: r-sig-mac@r-project.org 
> > Subject: [External] [R-SIG-Mac] Behaviour or Quartz windows
> >
> > Hi,
> >
> > I�ll just confirm the odd behaviour of the Quartz window in Big Sur 11.2
> R 4.0.3 GUI 1.73 on M1 silicon. I have installed the beta3 version of
> Quartz. In my case I have to CMD <- twice, then go forward to get the next
> to last plot.
> >
> > Are these Quartz windows constructed using native MacOS graphics or
> XQuartz?
> >
> > Peter
> >
> > �
> > Peter West
> > peter.b.w...@ehealth.id.au
> > �that they might touch even the fringe of his garment. And as many as
> touched it were made well.
> >
> > ___
> > 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
> >
>
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
> ___
> R-SIG-Mac mailing list
> 

Re: [R-SIG-Mac] R for macOS Big Sur

[Kasper Daniel Hansen]

Greg,

Perhaps you're confused by the wording? It says "R compiled for High Sierra
OR HIGHER". This is a minimum OS version. It doesn't mean you need to run
High Sierra to use this binary.

Best,
Kasper

On Thu, Jan 14, 2021 at 8:32 PM Gregory Coats via R-SIG-Mac <
r-sig-mac@r-project.org> wrote:

> The web site https://mac.r-project.org/ 
> specifically shows that as of Thu 2021-01-14 00:56
> 1. R compiled for Big Sur for Macs with the Intel CISC x86_64 chip is NOT
> available.
> 2. R complied for "high-sierra” for Macs with the Intel CISC x86_64 chip
> IS available.
> However, my Mac is running Big Sur OS, and my Mac is too new to be able to
> run the older High Sierra OS.
> Greg Coats
> > On Jan 14, 2021, at 2:10 PM, Jean Thioulouse <
> jean.thioulo...@univ-lyon1.fr> wrote:
> >
> > - On Intel Macs:
> >
> > R 4.0.3 binary is available for macOS 10.13 (High Sierra) and higher
> (including Big Sur)
>
>
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>


-- 
Best,
Kasper

[[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] R for macOS Big Sur

[Kasper Daniel Hansen]

Jean: _guessing_ this may be about parallel processing in BLAS? Does your
timing include linear algebra?

On Mon, Jan 11, 2021 at 2:38 PM Jean Thioulouse <
jean.thioulo...@univ-lyon1.fr> wrote:

> Hi
>
> Both versions seem to run fine indeed, but on my Mac mini M1, the arm
> version (homebrew R) is much slower than the intel version (CRAN R), which
> is quite disappointing.
>
> The speed ratio I get is about 4 times slower for the arm version compared
> to the intel version, both in single processor and parallel computing mode.
>
> Any idea about why I get these results ?
>
> Thanks,
> Jean
>
> —-
> Jean THIOULOUSE - orcid.org/-0001-7664-0598
> http://lbbe.univ-lyon1.fr/-Thioulouse-Jean-.html
> https://www.springer.com/fr/book/9781493988488
>
>
> > Le 11 janv. 2021 à 10:53, Denis-Alexander Engemann <
> denis.engem...@gmail.com> a écrit :
> >
> > I have been using both Rosetta emulation and the homebrew builds and
> > everything looks very good so far.
> >
> > Here are two Twitter threads on M1 benchmarks.
> >
> > https://twitter.com/fxcoudert/status/1342598509418176514?s=20
> >
> > https://twitter.com/dngman/status/1342580260815200257?s=20
> >
> > Best,
> > Denis
> >
> > On Mon, Jan 11, 2021 at 10:11 AM Dr Eberhard W Lisse 
> wrote:
> >>
> >> I use the homebrew R for the Intel and then install.packages(),
> update.package() from scripts and  Rstudio’s Tools->.
> >>
> >> I don’t have an M1 (yet) but would be interested in seeing how that
> works on the M1. Probably this will pull the sources and hence I would be
> grateful to read about that.
> >>
> >>
> >> greetings, el
> >>
> >> —
> >> Sent from Dr Lisse’s iPhone
> >> On 11 Jan 2021, 10:05 +0200, Patrick Schratz ,
> wrote:
> >>> There is a [native arm64 big sur
> >>> binary](
> https://github.com/Homebrew/homebrew-core/blob/8a6807be6abb44634e7d6d153348b6bba2a5ddc6/Formula/r.rb#L16
> )
> >>> in homebrew since some days.
> >>>
> >>> On 10 Jan 2021, at 22:39, Gregory Coats via R-SIG-Mac wrote:
> >>>
>  I purchased a new 13 inch Apple MacBook Pro with the M1 System on a
>  Chip. I understand that R is not yet available compiled for the M1 SoC
>  hardware, and so I am using Apple’s Rosetta 2.
>  However, this MacBook Pro requires Apple macOS Big Sur. From what I
>  see at https://mac.r-project.org/ R has not been compiled for macOS
>  Big Sur. Is there an executable of R for macOS Big Sur available to
>  download?
>  Greg Coats
> 
> 
>  [[alternative HTML version deleted]]
> 
>  ___
>  R-SIG-Mac mailing list
>  R-SIG-Mac@r-project.org
>  https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >>>
> >>> [[alternative HTML version deleted]]
> >>>
> >>> ___
> >>> R-SIG-Mac mailing list
> >>> R-SIG-Mac@r-project.org
> >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >>
> >>[[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
>


-- 
Best,
Kasper

[[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] Rstan compilation hangs misterisouly

[Kasper Daniel Hansen]

This line will essentially overwrite what RStan does for compilation. So
yes, this is potentially a bad thing.

On Mon, Nov 9, 2020 at 4:57 AM Goncalo Ferraz via R-SIG-Mac <
r-sig-mac@r-project.org> wrote:

> ok, found it! Makevars is where you said it would be and it contains only
> this line:
>
> CXX14FLAGS += -O3 -mtune=native -arch x86_64 -ftemplate-depth-256
>
> Does it seem to mean anything relevant?
>
> > On Nov 8, 2020, at 11:24 PM, Ken Beath  wrote:
> >
> > It is actually Makevars. If it is there it will be in the .R directory
> of your home folder.
> >
> > Unless it has been set up for something else, like Rcpp, then it can
> probably be deleted.
> >
> > Ken
> >
> >> On 9 Nov 2020, at 12:43 pm, Goncalo Ferraz  wrote:
> >>
> >> Hi,
> >>
> >> Yes, at some point there was a problem with schools.stan, it needed an
> extra (empty) line added to the end. But that didn’t solve the problem. I
> tried at least three different tests, with different models, and the same
> thing happens.
> >>
> >> Tried to get rid of .MakeVars and as I remember it didn’t change
> anything. I wanted to try it again now, but I am not finding a .MakeVars
> file anywhere on my computer. Where should it be?
> >>
> >> Thanks,
> >>
> >> Gonçalo
> >>
> >>> On Nov 8, 2020, at 8:04 PM, Ken Beath  wrote:
> >>>
> >>> Guessing here. Possibly schools.stan has a problem, that is what teh
> first error is suggesting. The remaining is a possible problem with
> .MakeVars which is no longer needed with R. I would also check that files
> aren’t being saved with a strange encoding.
> >>>
> >>> Ken
> >>>
>  On 9 Nov 2020, at 7:25 am, Roy Mendelssohn - NOAA Federal via
> R-SIG-Mac  wrote:
> 
>  Hi:
> 
>  While it is possible you will get the help you seek here,  I think
> you would likely to get more help,  and more knowledgeable help, on this
> more specialized issue,  at the Stan Forum.  https://discourse.mc-stan.org.
> I remember seeing in the summaries I get some issues with different
> combinations of versions of R,  Stan and compilers.
> 
>  HTH,
> 
>  -Roy
> 
> > On Nov 8, 2020, at 12:16 PM, Goncalo Ferraz via R-SIG-Mac <
> r-sig-mac@r-project.org> wrote:
> >
> > Hi,
> >
> > I’ve been struggling with an rstan problem for weeks. I installed R
> stan following instructions in
> https://github.com/stan-dev/rstan/wiki/RStan-Getting-Started#how-to-use-rstan
> <
> https://github.com/stan-dev/rstan/wiki/RStan-Getting-Started#how-to-use-rstan>
> to the letter, but when I try to compile any model R leaves me hanging
> indefinitely (I’ve waited up to 30 minutes with ridiculously short models).
> When I press esc R says:
> >
> > Warning messages:
> > 1: In readLines(file, warn = TRUE) :
> > incomplete final line found on
> '/Users/gferraz/Documents/MAF/R/schools.stan'
> > 2: In system(paste(CXX, ARGS), ignore.stdout = TRUE, ignore.stderr =
> TRUE) :
> > system call failed: Result too large
> > 3: In system(paste(CXX, ARGS), ignore.stdout = TRUE, ignore.stderr =
> TRUE) :
> > error in running command
> >
> > And then, R won’t quit. I can only close it by force quitting the
> software itself and some R process that is set in motion and appears in the
> Activity Monitor.
> >
> > I have tried everything that was suggested in the stan forum,
> including deleting all the contents of /usr/local, removing xcode, R and
> re-installing everything again.
> >
> > The only thing that I can think of now is to do a clean install of
> Mac OS on my machine and really start from scratch.
> >
> > Anyone has a less radical recommendation?
> >
> > Thank you,
> >
> > Gonçalo
> >   [[alternative HTML version deleted]]
> >
> > ___
> > 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
> 

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

[Kasper Daniel Hansen]

To use veclib you need
   --with-blas="-framework Accelerate"

My full building script on OS X is currently

../${SRCDIR}/configure SHELL='/bin/bash' \
  --prefix=/usr/local/R/${R_VERSION} --disable-R-framework\
  CC="/usr/local/clang8/bin/clang" \
  CXX="/usr/local/clang8/bin/clang++" \
  F77="/usr/local/gfortran/bin/gfortran" \
  FC="/usr/local/gfortran/bin/gfortran" \
  OBJC="clang" \
  CFLAGS="-Wall -mtune=native -g -O2" \
  CXXFLAGS="-Wall -mtune=native -g -O2" \
  OBJCFLAGS="-Wall -mtune=native -g -O2 -fobjc-exceptions" \
  F77FLAGS="-Wall -g -O2 -mtune=generic" \
  FCFLAGS="$F77FLAGS" \
  FLIBS="-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0
-L/usr/local/gfortran/lib -lgfortran -lquadmath -lm" \
  LDFLAGS="-L/usr/local/clang8/lib -L/usr/local/lib" \
  DYLD_FALLBACK_LIBRARY_PATH="/usr/local/clang8/lib:/usr/local/lib" \

PKG_CONFIG_PATH="/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig"
\
  JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Home" \
  JAVA_CPPFLAGS="-I/System/Library/Frameworks/JavaVM.framework/Headers" \
  JAVA_LD_LIBRARY_PATH="" \
  JAVA_LIBS="-framework JavaVM" \
  --enable-memory-profiling\
  --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib\
  --with-blas="-framework Accelerate" | tee ../configure-${R_VERSION}

although I think we have moved back to Apple's clang for C etc compiler for
the CRAN version of R instead of Simon's clang8.

Best,
Kasper


On Tue, Sep 29, 2020 at 9:53 AM roy  wrote:

> Hi Simon,
> Thanks for the info.  I was totally unaware of ABI, vecLib, etc and that
> Apple has blas, lapack, etc.  But after reading up on this and re-reading
> your email, I'm beginning to understand more about this.
>
> So, I would like to first checkout vecLib.  From what you say, would I have
> to do something like the following?
>
> ./configure --enable-BLAS-shlib --with-blas="-lBLAS"  ...
>
> Is this also possible with LAPACK?
>
> tx again.
> cheers, roy
>
>
> On Mon, Sep 28, 2020 at 3:01 PM Simon Urbanek  >
> wrote:
>
> > Rollin,
> >
> > it has been several years since I last tested MKL, so take it with a
> grain
> > of salt, but in general you don't necessarily have to build R with MKL in
> > order to use it - you only need to use --enable-BLAS-shlib and link to
> any
> > ABI-compatible BLAS which can be vecLib as well. Then you can change the
> > link from vecLib to MKL in the BLAS stub. Note that we only need the C
> ABI,
> > there are wrappers vecLibg95f.* which re-map the F entry points to C
> entry
> > points as to avoid Fortran ABI issues thus you don't care about the
> > Fortran. However, historically, MKL has not been much more performant
> than
> > vecLib so it's unclear if it is worth the hassle. As with any accelerated
> > BLAS, note that this may have effects on results in R.
> >
> > Cheers,
> > Simon
> >
> >
> >
> > > On 28/09/2020, at 7:07 PM, rollin  wrote:
> > >
> > > I wanted to build R from source on macos (10.15.5) so I could include
> > > Intel's MKL.  So I first looked at building R from source without MKL.
> > >
> > > From the installation doc, I modified config.site to have the
> following:
> > >
> > > CC=clang
> > > OBJC=$CC
> > > FC=/usr/local/bin/gfortran
> > > CXX=clang++
> > >
> > >
> > > I then ran configuration via the command:
> > >
> > > ./configure -C --enable-R-shlib --enable-memory-profiling
> > > --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib
> > >
> >
> PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig
> > >
> > >
> > > And received the following information and error:
> > >
> > > checking if bzip2 version >= 1.0.6... no
> > > checking whether bzip2 support suffices... configure: error: bzip2
> > library
> > > and headers are required
> > >
> > >
> > > By looking at the log, I saw a compiler error due to an implicit
> > function.
> > > I then made the following change in config.site:
> > >
> > > CFLAGS='-Wno-implicit-function-declaration -g -O2''
> > >
> > >
> > > And configure now ran without errors.
> > >
> > > However, when I looked at configuring to use MKL, I discovered that MKL
> > on
> > > macos does not support gnu fortran so, unless I purchase Intel's
> Fortran
> > > compiler, it looks like I'm sol.
> > >
> > > Has anyone built R with MKL on macos (10.15)?  In any event, I wanted
> to
> > at
> > > least note the issue and work around I encountered when building R on
> > > macos with clang/xcode.
> > >
> > >   [[alternative HTML version deleted]]
> > >
> > > ___
> > > R-SIG-Mac mailing list
> > > R-SIG-Mac@r-project.org
> > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >
> >
>
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

___
R-SIG-Mac 

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

[Kasper Daniel Hansen]

In my understanding, almost all of the speed up comes from using an
optimized BLAS. Optimizing LAPACK tend to have negligible impact on
performance. At least that is my impression, although I won't say I'm an
expert.

Best,
Kasper

On Tue, Sep 29, 2020 at 9:53 AM roy  wrote:

> Hi Simon,
> Thanks for the info.  I was totally unaware of ABI, vecLib, etc and that
> Apple has blas, lapack, etc.  But after reading up on this and re-reading
> your email, I'm beginning to understand more about this.
>
> So, I would like to first checkout vecLib.  From what you say, would I have
> to do something like the following?
>
> ./configure --enable-BLAS-shlib --with-blas="-lBLAS"  ...
>
> Is this also possible with LAPACK?
>
> tx again.
> cheers, roy
>
>
> On Mon, Sep 28, 2020 at 3:01 PM Simon Urbanek  >
> wrote:
>
> > Rollin,
> >
> > it has been several years since I last tested MKL, so take it with a
> grain
> > of salt, but in general you don't necessarily have to build R with MKL in
> > order to use it - you only need to use --enable-BLAS-shlib and link to
> any
> > ABI-compatible BLAS which can be vecLib as well. Then you can change the
> > link from vecLib to MKL in the BLAS stub. Note that we only need the C
> ABI,
> > there are wrappers vecLibg95f.* which re-map the F entry points to C
> entry
> > points as to avoid Fortran ABI issues thus you don't care about the
> > Fortran. However, historically, MKL has not been much more performant
> than
> > vecLib so it's unclear if it is worth the hassle. As with any accelerated
> > BLAS, note that this may have effects on results in R.
> >
> > Cheers,
> > Simon
> >
> >
> >
> > > On 28/09/2020, at 7:07 PM, rollin  wrote:
> > >
> > > I wanted to build R from source on macos (10.15.5) so I could include
> > > Intel's MKL.  So I first looked at building R from source without MKL.
> > >
> > > From the installation doc, I modified config.site to have the
> following:
> > >
> > > CC=clang
> > > OBJC=$CC
> > > FC=/usr/local/bin/gfortran
> > > CXX=clang++
> > >
> > >
> > > I then ran configuration via the command:
> > >
> > > ./configure -C --enable-R-shlib --enable-memory-profiling
> > > --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib
> > >
> >
> PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig
> > >
> > >
> > > And received the following information and error:
> > >
> > > checking if bzip2 version >= 1.0.6... no
> > > checking whether bzip2 support suffices... configure: error: bzip2
> > library
> > > and headers are required
> > >
> > >
> > > By looking at the log, I saw a compiler error due to an implicit
> > function.
> > > I then made the following change in config.site:
> > >
> > > CFLAGS='-Wno-implicit-function-declaration -g -O2''
> > >
> > >
> > > And configure now ran without errors.
> > >
> > > However, when I looked at configuring to use MKL, I discovered that MKL
> > on
> > > macos does not support gnu fortran so, unless I purchase Intel's
> Fortran
> > > compiler, it looks like I'm sol.
> > >
> > > Has anyone built R with MKL on macos (10.15)?  In any event, I wanted
> to
> > at
> > > least note the issue and work around I encountered when building R on
> > > macos with clang/xcode.
> > >
> > >   [[alternative HTML version deleted]]
> > >
> > > ___
> > > R-SIG-Mac mailing list
> > > R-SIG-Mac@r-project.org
> > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >
> >
>
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>


-- 
Best,
Kasper

[[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] Error when fitting a brms model, maybe associated with Catalina MacOS

[Kasper Daniel Hansen]

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: Iteration:1 / 2000 [  0%]  (Warmup)
> > > [1] "Error in sampler$call_sampler(args_list[[i]]) : "
> > > [2] "  c++ exception (unknown reason)"
> > > error occurred during calling the sampler; sampling not done
> > >
> > >
> > >
> > >
> > >
> > >
> > > El jue., 12 dic. 2019 a las 12:51, Balamuta, James Joseph (<
> > > balam...@illinois.edu>) escribió:
> > >
> > >> Greetings and Salutations All,
> > >>
> > >> Great to see the `r-macos-rtools` installer popping up! As the author
> of
> > >> it, please note that it's an unofficial (non-CRAN backed) installer
> that
> > >> seeks to automatically establish the CRAN toolchain in a friendly GUI
> > >> installer. We developed it to help out students in STAT 385 @ UIUC [
> > >> http://stat385.com/ ]  setup the correct developer environment in a
> > >> uniform manner as there wasn't really any prior installer packages
> made
> > >> available at the time. We're grateful for the financial support that
> was
> > >> given by Timothy Bates to sign the installer.
> > >>
> > >> With this being said, each step the installer takes is documented
> > across a
> > >> README file, installer splash screen, and by a post.
> > >>
> > >> README Overview:
> > >>
> https://github.com/rmacoslib/r-macos-rtools#what-does-the-installer-do
> > >> Installer Splash:
> > >>
> >
> https://raw.githubusercontent.com/rmacoslib/r-macos-rtools/master/readme_img/lock_icon.png
> > >> Post:
> > >>
> >
> https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/
> > >>
> > >> That said, there is also Appendix C.3 macOS of R Installation and
> > >> Administration [
> > >> https://cran.r-project.org/doc/manuals/r-release/R-admin.html#macOS ]
> > >> that goes over the details in greater depth.
> > >>
> > >> For those who are worried about security, please note that we've taken
> > >> steps to ensure secure downloads by verifying the installer hashes
> > prior to
> > >> installing per prior remarks by Simon regarding earlier versions of
> the
> > >> installer [ see the prior discussion and my response here:
> > >> https://stat.ethz.ch/pipermail/r-sig-mac/2018-May/012745.html ].
> > >>
> > >> Lastly, and perhaps more critically, please note that just using Xcode
> > CLI
> > >> is not sufficient as it does not match the prescribed compilation
> > toolchain
> > >> (clang7 with OpenMP enabled and gfortran).
> > >>
> > >> Best,
> > >>
> > >> JJB
> > >>
> > >> On 12/11/19, 7:25 PM, "R-SIG-Mac on behalf of Manuel Spínola" <
> > >> r-sig-mac-boun...@r-project.org on behalf of mspinol...@gmail.com>
> > wrote:
> > >>
> > >>An update.
> > >>
> > >>Before doing the suggested installation, I updated Catalina to
> > 10.5.2,
> > >>Xtools to 11.3 and the Command Line Tools and it works.
> > >>
> > >>Manuel
> > >>
> > >>El mié., 11 dic. 2019 a las 16:05, Ken Beath ( >)
> > >>escribió:
> > >>
> > >>> No, it only downloads and installs the right compilers and updates
> > >>> Makevars and REnvirons. These are what Stan and RCpp require so you
> > >> could
> > >>> do these manually.
> > >>>
> > >>> What it does is described at
> > >> https://github.com/rmacoslib/r-macos-rtools
> > 

Re: [R-SIG-Mac] Apparent interaction between XQuartz and the Catalina (10.15) macOS upgrade

[Kasper Daniel Hansen]

Bob,

You ran the betas. On issues like this, that could be a big difference. So
Im not sure it is yet an issue that could be user dependent.

Best,
Kasper

On Tue, Oct 8, 2019 at 10:00 PM Bob Rudis  wrote:

> I've been running Catalina since the first beta and upgraded to GM the day
> of release. Apart from having to stick R things into Full Disk Access I've
> had no issues with R nor XQuartz.
>
> I read through the links provided and, while I do have said symlink in the
> relocated items folder Apple creates (this is new behavior for the GM), it
> gets re-created fine for me & XQuartz works fine (and the minor pkg deps I
> have installed that use it also work fine.
>
> This would appear to be a YMMV situation.
>
> -Bob
>
> > On Oct 8, 2019, at 4:19 PM, Luis Puerto  wrote:
> >
> > Thanks a lot for the heads up!
> >
> > Cheers!
> > Luis
> >
> >> On 8 Oct 2019, at 22:49, Marc Schwartz via R-SIG-Mac <
> r-sig-mac@r-project.org> wrote:
> >>
> >> Hi All,
> >>
> >> Perhaps I missed something relevant along the way someplace, but I ran
> the upgrade to Catalina (10.15) last night. I wanted to give folks a heads
> up on an issue that you may face, especially if you have XQuartz installed
> alongside R.
> >>
> >> One of the sequelae of the upgrade is that some files may get relocated
> during the upgrade, likely in part due to the macOS SIP.
> >>
> >> In my case, this involved the symlink for XQuartz, 'usr/X11R6', which
> gets placed into a "Relocated Items" folder on the Desktop. That folder,
> which is actually an alias to /Users/Shared, contains a folder tree with:
> Security/usr/X11R6. Naively, after seeing this, I elected to move the
> entire folder to the Trash.
> >>
> >> That led me into a cycle of trying to figure out how to then delete
> that folder tree from the Trash, as I would get various OS errors in the
> course of doing so.
> >>
> >> That led me to some Google searches, with incremental attempts at
> solutions, but eventually landing on the following thread in the Apple
> Community forums:
> >>
> >> https://discussions.apple.com/thread/250712783
> >>
> >> After the first review of the thread there, and before user 'faikbey'
> posted a possible solution using Recovery Mode, I filed an Issue on the
> XQuartz github repo here:
> >>
> >> https://github.com/XQuartz/XQuartz/issues/1
> >>
> >> It would seem that, at some level, one workaround would be to uninstall
> XQuartz fully before the Catalina upgrade, but there is no uninstall
> program provided by them. There is a series of CLI commands in a github
> gist here:
> >>
> >>
> https://gist.github.com/pwnsdx/d127873e24cef159d4d603accaf37ee4#file-gistfile1-txt
> >>
> >> which appears to work, but would likely be best used prior to the
> Catalina upgrade, and then re-install XQuartz after the upgrade is complete.
> >>
> >> The solution to the problem posted by 'faikbey' in the Apple forum
> appears to work in the original scenario, albeit, as I noted in my reply in
> that thread, I needed to first mount the user volume in Recovery Mode using
> Disk Utility, before I could proceed with the additional steps of deleting
> the files from the Trash, then rebooting into normal mode.
> >>
> >> If anyone else has experienced this and knows of an alternative/better
> solution, let us know.
> >>
> >> Otherwise, let's see what the XQuartz folks might come up with on this,
> as this was not an issue with prior macOS upgrades.
> >>
> >> Regards,
> >>
> >> Marc Schwartz
> >>
> >> ___
> >> 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
>


-- 
Best,
Kasper

[[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] Warning on XCode / Command Line Tools 11

[Kasper Daniel Hansen]

Thanks a lot for checking this so quickly.

I was alarmed by the label "beta 1", and frankly surprised that this got
pushed to my machine. I believe it is the first time system updated has
suggested a beta version for something on my laptop. I am wondering if this
could have been a mistake; it is Apple Developer Week right now.

On Tue, Jun 4, 2019 at 11:10 AM Prof Brian Ripley 
wrote:

> My Mojave machine today prompted me to update to version 11 of Command
> Line Tools (apparently 'beta 1', but I am not a Beta tester).
>
> In short: don't do that (you can revert to 10.2.1 from the URL above, at
> least if your Apple ID has (free) developer privileges).
>
> CoreFoundation.framework has been removed (and its headers are used in a
> couple of spots compiling R).
>
> Further its seems that
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>
> is no longer included and setting CPPFLAGS did not suffice.
>
> Hopefully we will have solutions in due course, but that version is
> really for 10.15 Catalina which is months away ('in the Fall', whenever
> that is).
>
> --
> 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
>


-- 
Best,
Kasper

[[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] Xcode 10.2.1

[Kasper Daniel Hansen]

Doh! Sorry to have missed that email thread.

This advice solved the issue for me.

On Wed, Apr 24, 2019 at 11:41 AM Roy Mendelssohn - NOAA Federal <
roy.mendelss...@noaa.gov> wrote:

> Hi Kaspar:
>
> There is an issue of where Xcode puts headers.  I have posted on this
> previously.  I did the same update as you,  and not only doesn't Xcode put
> the headers where R expects,  it appears to delete the existing headers.
>
> Anyhow,  try running the following and see if your problems go away:
>
> > sudo installer -pkg \
> >
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
> \
> > -target /
>
> -Roy
>
> > On Apr 24, 2019, at 8:36 AM, Kasper Daniel Hansen <
> kasperdanielhan...@gmail.com> wrote:
> >
> > I am on Mojave. I recently updated to Xcode 10.2.1 and I did the
> associated
> > update of the command line tools. Following this, I reinstalled clang6
> and
> > gfortran 6 from CRAN.
> >
> > When I use the clang6 compiler from CRAN, it is unable to find stdio.h.
> >
> > When I compare the include path from clang6 to the Apple suppled clang
> with
> > `$CC -E - -v` I get
> >
> > with Apple clang
> > #include <...> search starts here:
> > /usr/local/include
> >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.1/include
> >
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks
> > (framework directory)
> > End of search list.
> >
> > with clang6 from CRAN
> > #include <...> search starts here:
> > /usr/local/include
> > /usr/local/clang6/lib/clang/6.0.0/include
> > /System/Library/Frameworks (framework directory)
> > /Library/Frameworks (framework directory)
> > End of search list.
> >
> > Did Apple move the headers around? Or have I somehow hosed my system?
> >
> > Best,
> > Kasper
> >
> >   [[alternative HTML version deleted]]
> >
> > ___
> > 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: http://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.
>
>

[[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] Xcode 10.2.1

[Kasper Daniel Hansen]

I am on Mojave. I recently updated to Xcode 10.2.1 and I did the associated
update of the command line tools. Following this, I reinstalled clang6 and
gfortran 6 from CRAN.

When I use the clang6 compiler from CRAN, it is unable to find stdio.h.

When I compare the include path from clang6 to the Apple suppled clang with
`$CC -E - -v` I get

with Apple clang
#include <...> search starts here:
 /usr/local/include
 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.1/include
 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include
 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks
(framework directory)
End of search list.

with clang6 from CRAN
#include <...> search starts here:
 /usr/local/include
 /usr/local/clang6/lib/clang/6.0.0/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.

Did Apple move the headers around? Or have I somehow hosed my system?

Best,
Kasper

[[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] possible bug in R's make install

[Kasper Daniel Hansen]

I am trying to compile and install R under High Sierra with Accelerate BLAS
but with R lapack.

My relevant configure call is   --with-blas="-framework Accelerate" but
omitting --with-lapack. Full call is pasted at the end of this email

I can do
  make
  make check
but make install fails with

make[2]: Nothing to be done for `install'.
/usr/local/clang6/bin/clang -I. -I../../src/include
-I../../../R-3.5.x-src/src/include -I/opt/X11/include -I/usr/local/include
-DHAVE_CONFIG_H-Wall -mtune=native -g -O2  -L/usr/local/clang6/lib
-L/usr/local/lib -L/usr/local/opt/tcl-tk/lib
-DR_HOME='"/usr/local/R/R-3.5.x/lib/R"' \
  -o Rscript ../../../R-3.5.x-src/src/unix/Rscript.c
mkdir /usr/local/R/R-3.5.x/lib/R/bin/exec
mkdir /usr/local/R/R-3.5.x/lib/R/modules
cp: /usr/local/R/R-3.5.x/lib/R/lib/libRlapack.dylib: No such file or
directory
make[3]: *** [install] Error 1
make[2]: *** [install] Error 1
make[1]: *** [install] Error 1
make: *** [install] Error 1

I manually verified that libRlapack.dylib had been build in the building
directory's "lib".  I then just did

sudo mkdir /usr/local/R/R-3.5.x/lib/R/lib

(my installation directory is /usr/local/R/R-3.5.x) and redid make install
which now worked.  I get

$ ls /usr/local/R/R-3.5.x/lib/R/lib
libRlapack.dylib

My _guess_ is that since I am using R's lapack and system BLAS that the
RHOME/lib directory does not get created.

Btw., this might be a bad idea (happy to hear about this) but the
installation should work since I can do make check

Kasper

configure

../${SRCDIR}/configure SHELL='/bin/bash' \
  --prefix=/usr/local/R/R-${R_VERSION} --disable-R-framework\
  CC="/usr/local/clang6/bin/clang" \
  CXX="/usr/local/clang6/bin/clang++" \
  F77="/usr/local/gfortran/bin/gfortran" \
  FC="$F77" \
  OBJC="clang" \
  CFLAGS="-Wall -mtune=native -g -O2" \
  CXXFLAGS="-Wall -mtune=natuve -g -O2" \
  OBJCFLAGS="-Wall -mtune=native -g -O2 -fobjc-exceptions" \
  F77FLAGS="-Wall -g -O2 -mtune=generic" \
  FCFLAGS="$F77FLAGS" \
  FLIBS="-L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0
-L/usr/local/gfortran/lib -lgfortran -lquadmath -lm" \
  LDFLAGS="-L/usr/local/clang6/lib -L/usr/local/lib" \
  DYLD_FALLBACK_LIBRARY_PATH="/usr/local/clang6/lib:/usr/local/lib" \

PKG_CONFIG_PATH="/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig"
\
  JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Home" \
  JAVA_CPPFLAGS="-I/System/Library/Frameworks/JavaVM.framework/Headers" \
  JAVA_LD_LIBRARY_PATH="" \
  JAVA_LIBS="-framework JavaVM" \
  --enable-memory-profiling\
  --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib\
  -with-tcltk=/usr/local/opt/tcl-tk/lib\
  --with-blas="-framework Accelerate" | tee ../configure-${R_VERSION}

[[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] disabling threads when using Accelerate BLAS

[Kasper Daniel Hansen]

Thanks for the extremely helpful pointers on this.  Clearly I need to
remove --with-lapack in my configure step.

On Sun, Sep 9, 2018 at 4:12 AM Prof Brian Ripley 
wrote:

> On 08/09/2018 22:01, Kasper Daniel Hansen wrote:
> > For timing purposes, is it possible to control the number of threads /
> > cores when I have compiled R to use the BLAS in the Accelerate framework
> > (by building R using
> >./configure --with-blas="-framework Accelerate" --with-lapack
> > )
> >
> > ? (The alternative is of course to build R using the supplied
> > single-threaded BLAS)
>
> This is a question about Accelerate not R.  But the R-admin manual does say
>
> 'In recent versions of macOS, threading in Accelerate is controlled by
> ‘Grand Central Dispatch’ and is said not to need user control.'
>
> It has quite a few other caveats about Accelerate, not least that it
> uses an LAPACK which is missing many bug fixes, some serious.
>
> --
> 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

[R-SIG-Mac] disabling threads when using Accelerate BLAS

[Kasper Daniel Hansen]

For timing purposes, is it possible to control the number of threads /
cores when I have compiled R to use the BLAS in the Accelerate framework
(by building R using
  ./configure --with-blas="-framework Accelerate" --with-lapack
)

? (The alternative is of course to build R using the supplied
single-threaded BLAS)

Best,
Kasper

[[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] Xcode 9

[Kasper Daniel Hansen]

Thanks. Nice to know it got fixed despite the somewhat pessimistic original
post.

Best,
Kasper

On Wed, Sep 27, 2017 at 4:32 AM, peter dalgaard <pda...@gmail.com> wrote:

>
> > On 27 Sep 2017, at 08:43 , Prof Brian Ripley <rip...@stats.ox.ac.uk>
> wrote:
> >
> > On 27/09/2017 03:28, Kasper Daniel Hansen wrote:
> >> I don't see this with
> >>   Xcode 9
> >>   OS X Sierra (10.12.6)
> >> and either
> >> R Under development (unstable) (2017-09-26 r73351) -- "Unsuffered
> >> Consequences"
> >> Copyright (C) 2017 The R Foundation for Statistical Computing
> >> Platform: x86_64-apple-darwin16.7.0 (64-bit)
> >> or
> >> R version 3.4.2 RC (2017-09-26 r73351) -- "Short Summer"
> >> Copyright (C) 2017 The R Foundation for Statistical Computing
> >> Platform: x86_64-apple-darwin16.7.0 (64-bit)
> >> Specifically I can compile R and it passes make check.  Perhaps it got
> >> fixed since the post.
> >
> > It did (look at the logs for r73347 and r73351), but also we have
> discovered that not all upgrades to Xcode 9 had the problem.
> >
>
> Yes. My home desktop machine updated command line tools only and didn't
> see the problem. The laptop wants to upgrade the full Xcode (no idea how
> that came to be...) but claims to need another 1.66GB of disk to upgrade,
> so it is probably not in the cards to check a build there just now. The
> work machine had the problem until I downgraded to Xcode 8.3.3, but as this
> is the machine building the actual release, I'm not touching it until some
> weeks after the 3.4.2 release.
>
> Right now, we just override the configure detected utimensat() declaration
> on all Macs, which should be harmless (also on High Sierra, although we
> wouldn't claim to support an OS which was unreleased at the code freeze).
> We'll think of a better fix --- it looks like the Curl developers have
> fixed a similar issue, so we can copy their approach.
>
> > While we are at it, there is a problem with finding the default time
> zone on High Sierra.  This is worked around already in R-devel and will be
> in 3.4.2 patched: until then setting TZ is a good workaround (and that is
> in the R-admin manual for 3.4.2 RC).
> >
> >> On Fri, Sep 22, 2017 at 4:47 AM, peter dalgaard <pda...@gmail.com>
> wrote:
> >>> Just a quick note: Xcode 9 will not presently create a working R on
> Sierra
> >>> or earlier.
> >
> > (I don't believe Xcode 9 is available for 'earlier'.)
>
> You're probably right. I wasn't sure when I wrote that (& also not sure
> whether one could cross-compile.)
>
> -pd
>
> >
> >>>
> >>> This is because it ships with an SDK for 10.13 (unreleased) and
> defines an
> >>> entry for utimensat(), which is not actually in the system library for
> >>> earlier versions.
> >>>
> >>> There is no way we can fix this reliably for the upcoming 3.4.2
> release,
> >>> so if you intend to build R from sources, either
> >>>
> >>> - just do not upgrade, stay on Xcode 8.3.3
> >>>
> >>> or
> >>>
> >>> - manually remove the line from config.h saying
> >>>
> >>> #define HAVE_UTIMENSAT 1
> >>>
> >>>
> >>> 
> >>>
> >>> The slightly longer story is that Apple decided to have their include
> >>> files generate a _warning_ that utimensat() is only available in 10.13,
> >>> like this:
> >>>
> >>> gcc -I../../../R/src/extra  -I. -I../../src/include
> >>> -I../../../R/src/include  -I/usr/local/include -I../../../R/src/nmath
> >>> -DHAVE_CONFIG_H -g -O2  -c ../../../R/src/main/platform.c -o
> platform.o
> >>> ../../../R/src/main/platform.c:2474:5: warning: 'utimensat' is only
> >>> available on
> >>>   macOS 10.13 or newer [-Wunguarded-availability-new]
> >>> utimensat(AT_FDCWD, to, times, 0);
> >>> ^
> >>> /Applications/Xcode.app/Contents/Developer/Platforms/
> >>> MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/
> include/sys/stat.h:374:5:
> >>> note:
> >>>   'utimensat' has been explicitly marked partial here
> >>> int utimensat(int __fd, const char *__path, const struct timespec
> __...
> >>> ^
> >>> ../../../R/src/main/platform.c:2474:5: note: enclose 'utimensat' in a
> >>>   __builtin_available check to silence this warning
> >>> utime

Re: [R-SIG-Mac] Xcode 9

[Kasper Daniel Hansen]

I don't see this with
  Xcode 9
  OS X Sierra (10.12.6)

and either

R Under development (unstable) (2017-09-26 r73351) -- "Unsuffered
Consequences"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin16.7.0 (64-bit)

or

R version 3.4.2 RC (2017-09-26 r73351) -- "Short Summer"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin16.7.0 (64-bit)

Specifically I can compile R and it passes make check.  Perhaps it got
fixed since the post.

On Fri, Sep 22, 2017 at 4:47 AM, peter dalgaard  wrote:

> Just a quick note: Xcode 9 will not presently create a working R on Sierra
> or earlier.
>
> This is because it ships with an SDK for 10.13 (unreleased) and defines an
> entry for utimensat(), which is not actually in the system library for
> earlier versions.
>
> There is no way we can fix this reliably for the upcoming 3.4.2 release,
> so if you intend to build R from sources, either
>
> - just do not upgrade, stay on Xcode 8.3.3
>
> or
>
> - manually remove the line from config.h saying
>
> #define HAVE_UTIMENSAT 1
>
>
> 
>
> The slightly longer story is that Apple decided to have their include
> files generate a _warning_ that utimensat() is only available in 10.13,
> like this:
>
> gcc -I../../../R/src/extra  -I. -I../../src/include
> -I../../../R/src/include  -I/usr/local/include -I../../../R/src/nmath
> -DHAVE_CONFIG_H -g -O2  -c ../../../R/src/main/platform.c -o platform.o
> ../../../R/src/main/platform.c:2474:5: warning: 'utimensat' is only
> available on
>   macOS 10.13 or newer [-Wunguarded-availability-new]
> utimensat(AT_FDCWD, to, times, 0);
> ^
> /Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/stat.h:374:5:
> note:
>   'utimensat' has been explicitly marked partial here
> int utimensat(int __fd, const char *__path, const struct timespec __...
> ^
> ../../../R/src/main/platform.c:2474:5: note: enclose 'utimensat' in a
>   __builtin_available check to silence this warning
> utimensat(AT_FDCWD, to, times, 0);
> ^
> ../../../R/src/main/platform.c:2890:11: warning: 'utimensat' is only
> available
>   on macOS 10.13 or newer [-Wunguarded-availability-new]
> res = utimensat(AT_FDCWD, fn, times, 0) == 0;
>   ^
> /Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/stat.h:374:5:
> note:
>   'utimensat' has been explicitly marked partial here
> int utimensat(int __fd, const char *__path, const struct timespec __...
> ^
> ../../../R/src/main/platform.c:2890:11: note: enclose 'utimensat' in a
>   __builtin_available check to silence this warning
> res = utimensat(AT_FDCWD, fn, times, 0) == 0;
>   ^
> 2 warnings generated.
>
> Because of dynamic linking, we do not see the effect of this until we
> actually try running the binary:
>
> begin installing recommended package MASS
> dyld: lazy symbol binding failed: Symbol not found: _utimensat
>   Referenced from: /Users/pd/r-release-branch/BUILD-dist/bin/exec/x86_64/R
>   Expected in: /usr/lib/libSystem.B.dylib
>
> dyld: Symbol not found: _utimensat
>   Referenced from: /Users/pd/r-release-branch/BUILD-dist/bin/exec/x86_64/R
>   Expected in: /usr/lib/libSystem.B.dylib
>
> /Users/pd/r-release-branch/BUILD-dist/bin/INSTALL: line 34: 59149 Done
> echo 'tools:::.install_packages()'
>  59150 Abort trap: 6   | R_DEFAULT_PACKAGES= LC_COLLATE=C
> "${R_HOME}/bin/R" $myArgs --slave --args ${args}
>
>
> Same warning also happens during the configure checks, but as it is not an
> error the test program compiles and links OK (but is never run), and we get
>
> checking whether utimensat exists and is declared... yes
>
> Ugh!...
>
>
> - Peter D.
>
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>

[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Experiences with macOS Sierra

[Kasper Daniel Hansen]

Thanks for the work on this, especially the comment on xml2.  I had noticed
problems with xml2 while compiling Emacs 25.1 using the new Xcode on El
Capitan, but I have not had time to track it down.

Best,
Kasper

On Thu, Sep 22, 2016 at 2:39 AM, Prof Brian Ripley 
wrote:

> So far I have encountered few problems.  R.app runs but I do not normally
> use it so my tests were minimal.
>
> My observations are about installing packages from source.
>
> - It seems Apple has been tidying up, and I had ca 20GB more free space
> after upgrading (which is worthwhile on my MBA with a 128GB SSD).  It seems
> that includes removing some headers, including those for openssl (used by
> packages PKI and RSclient - package opensssl uses its own). This is but the
> latest instance in a long-term trend, e.g. iodbc, pcre and liblzma have
> libraries but no headers.
>
> - Finally the POSIX 2008 function clock_gettime is supported (and will be
> used by R): but package scrypt calls it incorrectly.
>
> Xcode 8 is available for EL Capitan but I would caution against using it
> there (despite it being pushed as an update from the AppStore).  AFAICS
> (and googling will find other reports) it defaults to the macOS 10.12 SDK
> and that declares functions such as clock_gettime not available in El
> Capitan.  (I believe that R checks thoroughly enough not to be caught by
> this.)
>
> There is a further problem with Xcode 8, also seen on Sierra.  Packages
> using xml2-config (such as XML) fail to install.  Apple modified
> xml2-config to look on the SDK path, which means packages using it attempt
> to link to .tbd files rather than .dylibs.  Which should be OK but the
> supplied .tbd attempt to link to libraries removed in Sierra and so linking
> fails. (This is not a problem with the version 8 of the Command Line Tools,
> only available for Sierra.)
>
> --
> 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
>

[[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] How to get a Fortran compiler compatible to Xcode?

[Kasper Daniel Hansen]

yeah, I forgot.

Do what Kevin says, grab the texinfo from the r.research.att.com/libs
website.  Basically this is the first place to look.

Kasper

On Sun, May 10, 2015 at 9:49 PM, Marius Hofert marius.hof...@uwaterloo.ca
wrote:

 Hi,

 Thanks again, Kevin.

 @Kasper: I had a new version (as of today) of MacTeX installed and
 texinfo came with it. I had texi2dvi, texi2pdf... but not texi2any,
 that's why I thought it's something 'special' and couldn't find it
 anywhere else.

 @Kevin: I tried homebrew, but it seemed to fail, saying that it won't
 link/install as texinfo is already installed (via MacTeX) :-(.
 Interestingly, /usr/local/Cellar/texinfo existed afterwards and it
 contained ./5.2/bin/texi2any. I then simply linked from /usr/local/bin
 to that file, but still obtained (also after a reboot + as su):

 sklar-2:R-3.2.0_build mhofert$ make info
 ERROR: 'texi2any' v5.1 or later needed but missing on your system.
 make[2]: *** [R-FAQ.info] Error 1
 make[1]: *** [info] Error 2
 make: [info] Error 2 (ignored)
 sklar-2:R-3.2.0_build mhofert$ texi2any --version
 texi2any (GNU texinfo) 5.2

 Copyright (C) 2013 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later 
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.

 Any ideas?

 Cheers,
 Marius


 On Sun, May 10, 2015 at 9:14 PM, Kevin Ushey kevinus...@gmail.com wrote:
  `texi2any` is packaged as part of `texinfo` (note that this is
  documented throughout R-admin), and the latest version is available
  for download (hosted by Simon Urbanek) at:
 
  http://r.research.att.com/libs/texinfo-5.2-darwin10.tar.gz
 
  Or, if you're using homebrew, just use
 
  brew install texinfo
 
  Kevin
 
  On Sun, May 10, 2015 at 6:06 PM, Kasper Daniel Hansen
  kasperdanielhan...@gmail.com wrote:
  This is where you look for add-ons
   http://r.research.att.com/libs
  for OS X.
 
  For texi2any I would install a new version of MacTex.
 
  Finally, see the R-admin manual.
 
  Best,
  Kasper
 
  On Sun, May 10, 2015 at 8:38 PM, Marius Hofert 
 marius.hof...@uwaterloo.ca
  wrote:
 
  Hi Kevin,
 
  Thanks a lot for helping. That pushed me on the right track. I then
  needed some more tools (Java/XQuartz) and could then install R from
  source. Only make pdf; make info failed, saying that 'texi2any'
  couldn't be found on the system. I couldn't find any hints online or
  in the R administration manual on how to install/get it. I do have
  texi2pdf, though. Do you know how to get texi2any?  (hope this is
  still fine to be discussed in this thread, if not, I can open a new
  one).
 
  Thanks  cheers,
  Marius
 
 
 
  On Sun, May 10, 2015 at 2:45 PM, Kevin Ushey kevinus...@gmail.com
 wrote:
   Hi Marius,
  
   I've had success compiling (the latest versions of) R from source
   using Apple's command line tools (shipped with Xcode), alongside
   gfortran 4.8.2 installed from here (as hosted by Simon Urbanek):
  
   http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2
  
   Alternatively, (and what I tend to do by default on OS X), you can
 get
   the latest release of `gfortran` using one of the custom Apple
   'package managers', e.g. with homebrew (http://brew.sh/), you can
 use
  
   brew install gcc
  
   which will get you an up-to-date copy of `gcc` (not really needed
   since you'll have Apple clang), but also `gfortran` (which is needed
   as it's no longer shipped with the Apple command line tools).
  
   After this, as long as `gfortran` is on your PATH (e.g. by symlinking
   the binary into /usr/local/bin), you should be good to go for
 building
   R from source -- it will then be able to automatically discover where
   the Fortran libraries live, and so on.
  
   Kevin
  
   On Sun, May 10, 2015 at 11:00 AM, peter dalgaard pda...@gmail.com
   wrote:
   You do need to read this:
  
   http://cran.r-project.org/doc/manuals/r-release/R-admin.html
  
   People are not inclined to write significant amounts of the same
   information to the list...
  
   -Peter D
  
  
   On 10 May 2015, at 19:27 , Marius Hofert 
 marius.hof...@uwaterloo.ca
   wrote:
  
   Dear Peter,
  
   Thanks for your quick help.
  
   I'm not so familiar with the technicalities (and try to learn):
 Where
   is the file 'config.site' located in your system? Is this supposed
 to
   be a file which provides settings for 'configure'?
  
   Thanks  cheers,
   Marius
  
   PS: Also thanks for the hint towards r.research... I'll look into
 that
   once everything else is running. I already have some things
 running,
   e.g., texinfo, not sure if the 'texinfo' you mentioned is a
 specific
   one (but I'll see then).
  
  
  
   On Sun, May 10, 2015 at 1:04 PM, peter dalgaard pda...@gmail.com
   wrote:
  
   On 10 May 2015, at 17:13 , Marius Hofert
   marius.hof...@uwaterloo.ca wrote:
  
   Hi,
  
   I'm running Mac OS X Yosemite 10.10.3 on a MacBook Pro

Re: [R-SIG-Mac] Command Line Quartz Device in Yosemite

[Kasper Daniel Hansen]

I am self-compiling on Yosemite using the libraries provided by Simon. I
get quartz.

Best,
Kasper

On Fri, Oct 31, 2014 at 6:23 AM, peter dalgaard pda...@gmail.com wrote:


 On 31 Oct 2014, at 10:24 , Colin A. Smith co...@colinsmith.org wrote:

  This thread got a bit off the topics I was originally hoping to discuss.
 Can anyone running Yosemite comment on whether their default graphics
 device is quartz or x11?
 

 Local builds on my laptop switched to quartz yesterday, so there is hope
 that this will make it to the 3.1.2 binaries. (Good thing, I'm still
 getting crashes on plot(0) with x11() - a Floating Exception deep inside
 cairo-something). The big apple / little apple effect is still there though.


  Also, is there any hope that the patch for the quartz command line
 device might be considered?

 Ask Simon... My guess is that he hasn't had the time to look at it
 properly yet.

 -pd


  Cheers,
 
  Colin
 
  On Oct 28, 2014, at 23:33, Colin A. Smith co...@colinsmith.org wrote:
 
  I’ve been using command line R fairly successfully under Yosemite so
 far and have only run into a few issues, mostly related to the quartz
 device.
 
  First, it seems that under Yosemite, the default device is now x11
 instead of quartz. I found this with the exact same pkg install of R that I
 was using in Mavericks, which defaulted to quartz. Installing the latest
 Mavericks build (3.1.1) results in the same behavior. Even when running
 R_DEFAULT_DEVICE=quartz R”, the default device still ends up being x11.
 The quartz device can still be created manually with a call to quartz().
 Does anyone else have this same problem?
 
  Second, the menus for the quartz device created through the command
 line have gotten even stranger under Yosemite. With the current version
 there are actually two (!) Apple menus displayed, which looks quite odd:
 
  https://dl.dropboxusercontent.com/u/21171664/R_Two_Apple_Menus.png
 
  About a year ago I submitted a patch with made the command line quartz
 device act much more like a normal OS X application:
 
  https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15438#c1
 
  This patch continues to work well under Yosemite, and does not display
 the double Apple menu problem. However, it seems to have currently fallen
 off the radar. Given the even stranger behavior of the current code under
 Yosemite, perhaps evaluation of my patch could be given a higher priority?
 If it would help I can provide updated files which are drop-in replacements
 for the current R trunk.
 
  Cheers,
 
  Colin
 
  ___
  R-SIG-Mac mailing list
  R-SIG-Mac@r-project.org
  https://stat.ethz.ch/mailman/listinfo/r-sig-mac

 --
 Peter Dalgaard, Professor,
 Center for Statistics, Copenhagen Business School
 Solbjerg Plads 3, 2000 Frederiksberg, Denmark
 Phone: (+45)38153501
 Email: pd@cbs.dk  Priv: pda...@gmail.com

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


[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] Mac OS X tcltk/X11 issues

[Kasper Daniel Hansen]

On Thu, Jul 17, 2014 at 2:05 AM, Simon Urbanek simon.urba...@r-project.org
wrote:

 On Jul 15, 2014, at 3:01 PM, Kasper Daniel Hansen 
 kasperdanielhan...@gmail.com wrote:

  Prof Ripley and other people involved with tcltk,
 
  You could have the tcltk building routine leave some evidence behind re.
  how it was build.
 
  For example, in Rgraphviz we used to grapple with something similar at
 the
  abstract level - was the Graphviz version used to build a binary
  distributed version of Rgraphviz, the same as the Graphviz installed by
 the
  user (if there was a version mismatch on Windows, there was a high chance
  of an arcane error time).  As part of running configure, we save the
  Graphviz version at build time into a variable kept in a file in /R.
  Specifically we have a file
  R/graphviz_build_version.R.in
  which contains something like
   graphviz_build_version=@GRAPHVIZ_BUILD@
  configure does the usual transformation (code here is from memory).
 
  This was then checked in .onLoad before the Rgraphviz dynamic library was
  loaded.  Now the code is different, because we bundle Graphviz with
  Rgraphviz.
 
  Something similar should not be too hard to introduce for tcltk to keep a
  record of how it was build.
 
  We see a lot of noise about this issue, so it may be worthwhile to solve
  robustly.
 

 Well, but the above is entirely irrelevant to the discussion at hand
 (AFAICT). The problem here is that we are talking about *binary*
 distribution - so the build process was indeed created in a fully working
 environment, but the user failed to re-create the environment and thus the
 assumptions at build time are broken. The assumptions are directly at the
 linking level, and the dependency that fails is not even under our control
 - X11 installation - so it's not something we can modify


It seems that Prof. Ripley has fixed this, but I still want to reply to
this.

As I can tell, this is exactly the same as with tcltk: The binary version
of Rgaphviz build on the Bioconductor Windows machines used a specific
version of Graphviz, which (it used to be) was the user's responsibility to
create.  If the user failed to do so, the package would throw an error when
loaded.

Best,
Kasper




 Brian did indeed describe quite precisely the various issues involved here.

 IMHO the other contributions are a bit off track - I would argue that this
 is only about CRAN binary so adding a very specific extra check in R along
 the lines of what Brian proposed is the most robust and relevant way
 forward (note that the check may be identical for the X11 device). We're
 certainly not talking about a cross-platform solution but rather a very
 specific solution for the CRAN binary.

 Cheers,
 Simon



  Best,
  Kasper
 
 
  On Tue, Jul 15, 2014 at 4:16 PM, Prof Brian Ripley 
 rip...@stats.ox.ac.uk
  wrote:
 
  John talked to me about this a month ago and after some sick
  leave/vacation I had just got around to thinking into it.
 
  Minor points:
 
  1) The usual way to check for OS X in the R sources is
  grepl(darwin, R.version$os)
 
  2) It is perfectly possible to build R on Linuxen without X11
  headers/libraries.
 
  3) There are three branches to the Tk code, X11, Aqua and Windows.  So
  apart from on Windows and OS X you either use X11 or do not have Tk.
 
  4) It is possible to build R without Tcl/Tk, in which case you get a
 stub
  tcltk package.  Then capabilities('tcltk') tells you that you have the
 stub.
 
  5) Just so we are all understand, it is possible (and documented in the
  manuals) for tcltk to be built using the Aqua Tk branch, and then Rcmdr
  works well (in my opinion much better) without X11 present.  So we do
 not
  want Rcmdr checking unconditionally for X11 being present.
 
 
  My understanding is that the main problem is that if someone installs
 one
  of the CRAN binary packages for OS X and does not have X11 installed
 then
  library(tcltk) will fail with a message that they do not understand,
 e.g.
  https://stat.ethz.ch/pipermail/r-sig-mac/2014-July/010954.html .
 
  For the future, probably the best thing to do is for the tcltk startup
  code to try to trap that case and suggest that X11/XQuartz needs to be
  installed.  The problem is accurately identifying 'that case'.
 
  If a package has tcltk in the imports of its NAMESPACE, there is nothing
  it can do about a broken tcltk as the namespaces it imports will be
  processed before any of the code in the package.  So the other
 possibility
  is to not have tcltk in the imports but to load its namespace via
  Rcmd::.onLoad.  I figured out how to to do that but it would be rather
  fragile.
 
 
  There is another possible problem which is that X11 is installed but a X
  server is not running.  That's what capabilities('X11') checks, and on
  modern OS X it ought to launch the X server as required.  However, I do
 not
  think we have a way to telling which Tk branch package tcltk was built
  against.  Since that is only an issue

Re: [R-SIG-Mac] Mac OS X tcltk/X11 issues

[Kasper Daniel Hansen]

Prof Ripley and other people involved with tcltk,

You could have the tcltk building routine leave some evidence behind re.
how it was build.

For example, in Rgraphviz we used to grapple with something similar at the
abstract level - was the Graphviz version used to build a binary
distributed version of Rgraphviz, the same as the Graphviz installed by the
user (if there was a version mismatch on Windows, there was a high chance
of an arcane error time).  As part of running configure, we save the
Graphviz version at build time into a variable kept in a file in /R.
 Specifically we have a file
 R/graphviz_build_version.R.in
which contains something like
  graphviz_build_version=@GRAPHVIZ_BUILD@
configure does the usual transformation (code here is from memory).

This was then checked in .onLoad before the Rgraphviz dynamic library was
loaded.  Now the code is different, because we bundle Graphviz with
Rgraphviz.

Something similar should not be too hard to introduce for tcltk to keep a
record of how it was build.

We see a lot of noise about this issue, so it may be worthwhile to solve
robustly.

Best,
Kasper


On Tue, Jul 15, 2014 at 4:16 PM, Prof Brian Ripley rip...@stats.ox.ac.uk
wrote:

 John talked to me about this a month ago and after some sick
 leave/vacation I had just got around to thinking into it.

 Minor points:

 1) The usual way to check for OS X in the R sources is
 grepl(darwin, R.version$os)

 2) It is perfectly possible to build R on Linuxen without X11
 headers/libraries.

 3) There are three branches to the Tk code, X11, Aqua and Windows.  So
 apart from on Windows and OS X you either use X11 or do not have Tk.

 4) It is possible to build R without Tcl/Tk, in which case you get a stub
 tcltk package.  Then capabilities('tcltk') tells you that you have the stub.

 5) Just so we are all understand, it is possible (and documented in the
 manuals) for tcltk to be built using the Aqua Tk branch, and then Rcmdr
 works well (in my opinion much better) without X11 present.  So we do not
 want Rcmdr checking unconditionally for X11 being present.


 My understanding is that the main problem is that if someone installs one
 of the CRAN binary packages for OS X and does not have X11 installed then
 library(tcltk) will fail with a message that they do not understand, e.g.
 https://stat.ethz.ch/pipermail/r-sig-mac/2014-July/010954.html .

 For the future, probably the best thing to do is for the tcltk startup
 code to try to trap that case and suggest that X11/XQuartz needs to be
 installed.  The problem is accurately identifying 'that case'.

 If a package has tcltk in the imports of its NAMESPACE, there is nothing
 it can do about a broken tcltk as the namespaces it imports will be
 processed before any of the code in the package.  So the other possibility
 is to not have tcltk in the imports but to load its namespace via
 Rcmd::.onLoad.  I figured out how to to do that but it would be rather
 fragile.


 There is another possible problem which is that X11 is installed but a X
 server is not running.  That's what capabilities('X11') checks, and on
 modern OS X it ought to launch the X server as required.  However, I do not
 think we have a way to telling which Tk branch package tcltk was built
 against.  Since that is only an issue on OS X (no other OS can use more
 than one branch) you could use something like

 Tk_is_X11 - function()
 {
 DLL - system.file(libs, tcltk.so, package = tcltk)
 out - system2(otool, c(-L, shQuote(DLL)), stdout = TRUE)
 length(grep(libX11[.][0-9]+[.]dylib, out))  0L
 }

 and then

 if (.Platform$OS.type == unix) {
if (!grepl(darwin, R.version$os) || Tk_is_X11())
if(!capabilities(X11))
 stop(Rcmdr requires a running X server)

 }


 On 15/07/2014 13:05, Marc Schwartz wrote:

 John,

 First, apologies for my narrow focus on the solutions that I proposed
 yesterday. I suffered from tunnel vision on the OS X issue and as Gabor has
 noted, it would not be sufficiently portable. There can be potential
 variations on where X11 is installed on OS X, depending upon the use of
 Xquartz, the original Apple distribution of X11 and presumably could
 further vary if one installs from source, is using Homebrew, Macports or
 similar, which are package management systems for OS X. Thus, as Gabor
 pointed out, capabilities(X11) is the most portable approach.

 With respect to Linux, to the best of my knowledge, X11 (for some time
 X.org) is still a requirement for tk (but not tcl). In checking at least
 the current Fedora repos, X11 is still listed as a dependency for tk. So if
 one is using the common package management systems, X11 will be installed
 if not already, when installing tk, unless one overrides the defaults.

 Also, at least for Fedora and perhaps other Linuxen, X11 is listed as a
 dependency for R itself, so if one is installing R on Fedora, X11 will be
 installed as well, if not present.

 Thus, between the common Linux package 

Re: [R-SIG-Mac] ESS on Mavericks

[Kasper Daniel Hansen]

Do you use the same .emacs as before?  This sounds like having to do with
fortification and the R buffer, and might be solvable by using
  (setq comint-scroll-to-bottom-on-output 'others)
in your .emacs.

It would be strange if this is the source of your problem unless you're
using a new .emacs.

Best,
Kasper


On Mon, Apr 7, 2014 at 1:37 PM, peter dalgaard pda...@gmail.com wrote:

 Hmm,

 Tried aquamacs? Hasn't been giving me problems lately. Otherwise, you
 might check the Activity Monitor and see if any involved processes turns
 App Nap on.

 -pd


 On 07 Apr 2014, at 19:03 , Stephanie M. Gogarten 
 sdmor...@u.washington.edu wrote:

  Hi,
 
  I just upgraded to Mavericks and I'm having trouble with ESS.  I have R
 3.0.3, and I tried both the ESS-included Emacs binary (
 http://vgoulet.act.ulaval.ca/en/emacs/) and the binary without extras (
 http://emacsformacosx.com/) and installing ESS from source.
 
  In both cases, I'm getting really slow response when using the Execute
 this line button in Emacs.  The simplest R functions take several seconds
 to process.  Typing directly in the R buffer doesn't have this problem.
 
  Has anyone else seen this behavior, or know of a fix?
 
  thanks,
  Stephanie
 
  ___
  R-SIG-Mac mailing list
  R-SIG-Mac@r-project.org
  https://stat.ethz.ch/mailman/listinfo/r-sig-mac

 --
 Peter Dalgaard, Professor,
 Center for Statistics, Copenhagen Business School
 Solbjerg Plads 3, 2000 Frederiksberg, Denmark
 Phone: (+45)38153501
 Email: pd@cbs.dk  Priv: pda...@gmail.com

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


[[alternative HTML version deleted]]

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

Re: [R-SIG-Mac] trouble running invoking R from the terminal in a new install

[Kasper Daniel Hansen]

Have you set an alias or soft link somewhere?  Try
  which -a R
and look in your .bashrc / .profile.

Kasper



On Wed, Feb 12, 2014 at 7:39 AM, Catherine A. Lozupone 
catherine.lozup...@colorado.edu wrote:

 Hello,

 I am on Mac OS X Version 10.8.5. I recently installed R-3.0.2.pkg on my
 machine which by default put the R application in my /Applications folder.
 When I envoke R by double clicking on the R application file in my
 Applications folder it opens up a GUI just fine. However, when I try to
 invoke R from a terminal window I get the error -bash: R64: command not
 found. This appears to be unrelated to R not being in my path.
 /Applications is in my path and when I cd to the /Applications folder and
 try and invoke R by typing R or R --help I get the same command not
 found error. I read in the R installation and Administration manual that
 A version of R can be run directly from the command-line as e.g.
 /Library/Frameworks/R.framework/Versions/3.0/Resources/bin/R). However when
 I cd to this directory and type R I get the same command not found
 error again. It also does not appear related to R not being executable. The
 R installation in my /Applications folder looks like thi!
  s with ls -l:

 drwxrwxr-x3 root  admin102 Feb 12 05:20 R.app

 Any advice?

 Thanks,
 Cathy
 ___
 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] Inaccurate inaccuracies on Mac only?

[Kasper Daniel Hansen]

I don't think your assumption that different systems will return the same
(accurate or inaccurate) answers is correct.  I don't even think you can
assume that running the same code twice on the same system will give you
the same answers, although in practice it often will.

Kasper


On Sat, Nov 30, 2013 at 8:54 AM, Hans W Borchers hwborch...@gmail.comwrote:

 Dear R Mac colleagues,

 when I am running the following piece of code on Ubuntu Linux 12.04 LTS or
 on
 Windows 7 -- with R 3.0.2 --, I get the results as indicated:

 set.seed(8237)
 x - runif(32, -1, 1)
 y - runif(32, -1, 1)
 u - cbind(x[1], y[1])

 u1 - u %*% t(u)
 u2 - apply(u * u, 1, sum)
 sqrt(u2 + u2 - 2*u1)
 ##  [,1]
 ## [1,]  NaN
 ## Warning message:
 ##In sqrt(u2 + u2 - 2 * u1) : NaNs produced
 u2 + u2 - 2*u1
 ##   [,1]
 ## [1,] -2.220446e-16

 Theoretically, the last value should be zero. Of course, I am *not*
 surprised
 to see this is not the case under finite precision arithmetics.

 But what did surprise me was that under Mac OS X 10.6 and R 3.0.2 I get the
 following, exact results:

 set.seed(8237)
 x - runif(32, -1, 1)
 y - runif(32, -1, 1)
 u - cbind(x[1], y[1])

 u1 - u %*% t(u)
 u2 - apply(u * u, 1, sum)
 sqrt(u2 + u2 - 2*u1)
 ##  [,1]
 ## [1,]0
 u2 + u2 - 2*u1
 ##  [,1]
 ## [1,]0

 I always thought that all these systems and versions comply to the IEEE
 floating point standard and return the same (accurate or inaccurate)
 answers.

 The problem here is: When I test a package on Mac, I cannot be sure it will
 run without errors on other systems. Actully, I found this when running
 some
 examples from help pages, written on the Mac.

 Was I wrong, or is there something special about the Mac version of R ?

 Many thanks
 Hans Werner

 ___
 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] Automatically detecting and setting CXX compiler using configure/Makevars

[Kasper Daniel Hansen]

Rob,

It is true I have been momentarily confused and Prof. Ripley clarified this
(the reason for th confusion is that if you upgrade from Xcode 4 to Xcode
5, llvm-c++-4.2 does not get removed).  Follow his directions in the post,
and your user will be fine.

But taking a step back, as a package author, this is really not something
you should ever worry about.  It is up to the user to make sure his system
is functioning (this is a quite important principle).  And in this case, I
think it is fair to say that it is unfortunate that Apple decided to remove
this compiler from a stock Xcode 5, but it is hard for the people building
the CRAN binary to predict the future.  If things like this ever happens
again, you can be sure that the Mac binary people will figure out a
solution to this problem (like they did now). [ If llvm-c++-4.2 could not
be downloaded from Apple, they might have had to release new binary ].

Using two different compilers may sometimes work by chance, but it may also
sometimes give you very arcane error messages.  It is certainly not
guaranteed to work and should in general always be avoided.

Best,
Kasper


On Wed, Oct 9, 2013 at 4:03 AM, Prof Brian Ripley rip...@stats.ox.ac.ukwrote:

 This is documented in the current manuals: please read them.  I posted how
 to get the compilers used for the CRAN binary, on this list when Xcode 5
 was released (it is for Mountain Lion only):

 https://stat.ethz.ch/**pipermail/r-sig-mac/2013-**September/010327.htmlhttps://stat.ethz.ch/pipermail/r-sig-mac/2013-September/010327.html

 Otherwise see e.g. http://cran.r-project.org/doc/**
 manuals/r-patched/R-admin.**html#OS-X-packageshttp://cran.r-project.org/doc/manuals/r-patched/R-admin.html#OS-X-packages.



 On 09/10/2013 08:07, Robert Bruggner wrote:

 Hi Kasper,

 Thank you very much for your reply.

 Just to clarify, the situation I'm describing is one in which a user has
 downloaded XCode 5 and installed the command line tools so that they can,
 in theory, compile and install packages from source. However, the compiler
 supplied by XCode5 (Apple LLVM 5.0) is different from the one specified in
 the R 3.0.2 binary Makeconf file (llvm-g++4.2) and hence, despite having an
 installed compiler, they cannot build packages because R attempts to use
 llvm-g++4.2 (which does not exist, even with the XCode command line tools
 installed). I don't know if this is a big problem but I suspect that any
 Mac OS X user who now starts with a fresh install binary install of R and
 XCode5 command line tools will not be able to build and install C/C++
 packages from source without first modifying the Makeconf file (or
 ~/.R/Makeconf) to point to the new compiler supplied by XCode5.

 What I was hoping to use configure for was to detect the compiler (Apple
 LLVM 5.0) that is now distributed with XCode5 and thus, enable users to
 compile packages from source after they'd installed the XCode command line
 tools. However, I don't think I appreciated the problems with compiling a
 package with a compiler different from that which was used to build the R
 binary  - thank you for that info. Does that mean that the only good option
 is to submit the package to CRAN so it can be compiled into a binary with
 the same compiler that's used to build the Mac OS X R binary distribution?

 Thank you again for all your help!

 Cheers,

 -Rob


 On Oct 8, 2013, at 5:57 PM, Kasper Daniel Hansen 
 kasperdanielhan...@gmail.com wrote:

  Rob,

 What you should do, is _always_ inherit the compiler which was used to
 build R.  That is the 'Right' way to go and it is what will happen per
 default if you are using Makevars to compile you package.  If you need to
 use configure, there are hints in R-exts and we can help more specifically,
 preferably you have a package somewhere.  This way you do not run into
 (weird) problems which can arise when you use different compilers for R and
 your package.

 The issue you are seeing right now on the Mac is that some users will
 not be able to compile packages from source using their system.  For most
 users, if you distribute your package via CRAN / Bioconductor they will
 have the option of receiving a binary version of the package and therefore
 do not need a C++ compiler.  In addition, even if you want them to install
 from source, using a configure script will (most likely) not really help at
 all - if they don't have the Xcode supplied compiler, they are extremely
 unlikely to have any other compiler installed on their system.  And really,
 if a user is using the CRAN binary of R and wants to install a package from
 source, it is really their responsibility to setup their system to do so.
 In summary, I don't think you will help anyone with a configure step trying
 to locate an alternative compiler.

 Finally, you can get the Xcode compiler by starting up Xcode, go to
 preferences - Downloads and then click on install command line tools.
  It is irritating you have to do

Re: [R-SIG-Mac] Automatically detecting and setting CXX compiler using configure/Makevars

[Kasper Daniel Hansen]

Rob,

What you should do, is _always_ inherit the compiler which was used to
build R.  That is the 'Right' way to go and it is what will happen per
default if you are using Makevars to compile you package.  If you need to
use configure, there are hints in R-exts and we can help more specifically,
preferably you have a package somewhere.  This way you do not run into
(weird) problems which can arise when you use different compilers for R and
your package.

The issue you are seeing right now on the Mac is that some users will not
be able to compile packages from source using their system.  For most
users, if you distribute your package via CRAN / Bioconductor they will
have the option of receiving a binary version of the package and therefore
do not need a C++ compiler.  In addition, even if you want them to install
from source, using a configure script will (most likely) not really help at
all - if they don't have the Xcode supplied compiler, they are extremely
unlikely to have any other compiler installed on their system.  And really,
if a user is using the CRAN binary of R and wants to install a package from
source, it is really their responsibility to setup their system to do so.
In summary, I don't think you will help anyone with a configure step trying
to locate an alternative compiler.

Finally, you can get the Xcode compiler by starting up Xcode, go to
preferences - Downloads and then click on install command line tools.
 It is irritating you have to do this, but that is the situation.

Best,
Kasper


On Tue, Oct 8, 2013 at 3:00 PM, Robert Bruggner rbrugg...@gmail.com wrote:

 Hi all,

 I'm developing a package that needs to be compiled on installation but am
 unsure how to ensure that the proper C++ compiler is invoked when
 installing this package from source. Is there anyway to, at build time,
 auto-detect and set the available compiler using configure / Makevars?

 More specifically, I'm using the CRAN-provided  binary of R 3.02 running
 on Mac OS 10.8.5 with XCode 5 installed. By default, the Makeconf included
 with the R installation ($RHOME/Resources/Makeconf) has CXX set as:

 CXX = llvm-g++-4.2 -arch x86_64

 However, as llvm-g++-4.2 is no longer distributed with XCode5, package
 installation fails when I attempt to install from source with an expected
 llvm-g++-4.2: command not found message.

 I see that one solution is to manually set CXX in the ~/.R/Makevars file.
 However,  I'm wondering if it's possible to have the combination of a
 configure script / Makevars.in automatically detect and set the CXX
 variable upon installation.

 As I have it specified currently, my configure.ac script use the
 AC_PROG_CXX macro to detect and set CXX.
 https://github.com/nolanlab/Rclusterpp/blob/dev/configure.ac

 Then, in my Makevars.in, I attempt to specify the value of CXX detected by
 the configure script
 https://github.com/nolanlab/Rclusterpp/blob/dev/src/Makevars.in

 I can then run the configure script manually and, in the produced Makevars
 file, it appears to detect and set CXX to the proper complier, i.e.:

 CXX=g++ -arch x86_64

 However, when I then try and install the package, it seems to default back
 to the using llvm-g++-4.2 as the compiler and thus, installation fails.

 I of course could be approaching this in completely the wrong way. Any
 suggestions on how I might be able to auto-detect and set the appropriate
 compiler at build time?

 -Rob

 ___
 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] Installing packages with type=source instead of the default binary?

[Kasper Daniel Hansen]

The advantages are very minor (although I do source compilation myself).
 To Prof Ripley's list I will add that I personally like to know I can
compile from source for packages that I depend on in package development,
so I can trace down bugs and run R CMD check - but this is a very, very
minor advantage.

Best,
Kasper


On Mon, Sep 9, 2013 at 6:42 AM, Rainer M Krug rai...@krugs.de wrote:

 Prof Brian Ripley rip...@stats.ox.ac.uk writes:

  On 09/09/2013 10:56, Rainer M Krug wrote:
  Hi
 
  I am using Snow Leopard and I can compile packages (I have all tools
  installed) but I am asking myself:
 
  Is there an advantage to using type=source instead of the binary
  install of the packages? For certain packages it makes sense to have
  fine grained control to link to certain versions of C libraries
  (e.g. rgdal), but is there a general advantage of compiling locally?
 
  There is an advantage if you run multiple versions of R and want to
  share a library directory.  The CRAN binary versions are tied to the
  R.framework installation.
 
  But otherwise
 
  - for the majority of packages (which have no compiled code), there is
  almost no advantage in installing from source, but also very little
  loss (you need no extra tools).

 True.

 
  - The CRAN binaries are built for 3.0.0 I believe, and certainly not
  re-built for patch versions.  For a very few packages it is
  advantageous to use the latest patch version (I am thinking of some
  issues with non-Sweave vignettes in recent history, but there have
  been other issues).
 
  - You might well want to use different external C/C++/Fortran
  software, and you may even need to do so or use a different compiler
  (there are packages which install with clang but not llvm-gcc and
  v.v.).


 Thanks for this detailed response.

 So if my tool chain for compilation is up and running, there can be an
 advantage to compile from source. So I will likely stick to that habit.

 Thanks,

 Rainer


 
 
  Or is that simply a leftover from my Linux days, that I prefer locally
  compiled packages?
 
  Thanks,
 
  Rainer
 
 
 
  ___
  R-SIG-Mac mailing list
  R-SIG-Mac@r-project.org
  https://stat.ethz.ch/mailman/listinfo/r-sig-mac
 
 #secure method=pgpmime mode=sign

 --
 Rainer M. Krug

 email: RMKrugatgmaildotcom

 ___
 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] Trouble with tcltk

[Kasper Daniel Hansen]

For those of us who compile from source, I assume this
  tcl8.6.0-darwin10-x86_64.tar.gz
from
  http://r.research.att.com/libs/
is the recommend version? Indeed, I always assume I should just grab the
newest version of everything I need from this location.

Best,
Kasper




On Tue, Sep 3, 2013 at 6:40 AM, Prof Brian Ripley rip...@stats.ox.ac.ukwrote:

 On 03/09/2013 11:21, Michael Kubovy wrote:

 Many packages require tcltk.

 I have installed http://cran.r-project.org/bin/**
 macosx/tools/tcltk-8.5.5-x11.**pkghttp://cran.r-project.org/bin/macosx/tools/tcltk-8.5.5-x11.pkgand
  yet, when I try


 That is the wrong version for R 3.0.1, so please remove it.  You may need
 to re-install R, as that ships with the correct tcltk.

  library(gamlss.demo)
 I get
 Loading required package: rpanel
 Loading required package: tcltk
 Error : .onLoad failed in loadNamespace() for 'tcltk', details:
call: dyn.load(file, DLLpath = DLLpath, ...)
error: unable to load shared object '/Library/Frameworks/R.**
 framework/Versions/3.0/**Resources/library/tcltk/libs/**tcltk.so':
dlopen(/Library/Frameworks/R.**framework/Versions/3.0/**
 Resources/library/tcltk/libs/**tcltk.so, 10): Library not loaded:
 /usr/local/lib/libtcl8.6.dylib
Referenced from: /Library/Frameworks/R.**framework/Versions/3.0/**
 Resources/library/tcltk/libs/**tcltk.so
Reason: image not found
 Error: package ‘tcltk’ could not be loaded


  sessionInfo()

 R version 3.0.1 (2013-05-16)
 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] datasets  utils stats graphics  grDevices methods   base

 other attached packages:
 [1] sos_1.3-7   brew_1.0-6  ggplot2_0.9.3.1 car_2.0-18
  nnet_7.3-7  MASS_7.3-28

 loaded via a namespace (and not attached):
   [1] colorspace_1.2-2   dichromat_2.0-0digest_0.6.3   grid_3.0.1
 gtable_0.1.2   labeling_0.2
   [7] munsell_0.4.2  plyr_1.8   proto_0.3-10
 RColorBrewer_1.0-5 reshape2_1.2.2 scales_0.2.3
 [13] stringr_0.6.2

 __**
 Professor Michael Kubovy
 University of Virginia
 Department of Psychology
 for mail add:   for FedEx or UPS
 add:
 P.O.Box 400400  Gilmer Hall, Room 102
 Charlottesville, VA 22904-4400  485 McCormick Road
 USA Charlottesville,
 VA 22903
 roomphone
 Office:B011 +1-434-982-4729
 Lab:B019+1-434-982-4751
 WWW:
 http://www.people.virginia.**edu/~mk9y/http://www.people.virginia.edu/~mk9y/


 [[alternative HTML version deleted]]



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



 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  
 http://www.stats.ox.ac.uk/~**ripley/http://www.stats.ox.ac.uk/~ripley/
 University of Oxford, Tel:  +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UKFax:  +44 1865 272595


 __**_
 R-SIG-Mac mailing list
 R-SIG-Mac@r-project.org
 https://stat.ethz.ch/mailman/**listinfo/r-sig-machttps://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] R.app doesn't respect DYLD_FALLBACK_LIBRARY_PATH

[Kasper Daniel Hansen]

Setting
  DYLD_FALLBACK_LIBRARY_PATH
is super dangerous and I would be highly suspicious of whoever told you to
do that (in the sense that they don't really know how this works)   It has
the potential to really wreck your system.  Especially if you set it in
such a way that all GUI apps inherit it.

Please don't come back here and complain if your system starts to behave
strangely.  For example (as you see) sending weird messages in terminal
windows.

Kasper

On Thu, Aug 8, 2013 at 10:33 PM, Tom Schoenemann t...@indiana.edu wrote:

 DYLD_FALLBACK_LIBRARY_PATH

[[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] hidden files and directories

[Kasper Daniel Hansen]

Rohmatul,

Check by doing
  R CMD build pkgName
  R CMD check pkgName_X_Y_Z.tar.gz

The building step excludes many common files, and is recommended.

Kasper


On Tue, Aug 6, 2013 at 3:43 AM, Prof Brian Ripley rip...@stats.ox.ac.ukwrote:

 On 06/08/2013 08:41, Rohmatul Fajriyah wrote:

 Dear Prof. Ripley and Prof. Winsemius,

 I have deleted the .Rapp.history (hope, it was all of them), but still
 got the same message when run the R CMD check PkgName.
 I'll shutdown the laptop, start a fresh session and will rename the R
 functions for the package and the package itself differently.
 Then I will see what happened and report it here.


 You are supposed to check the tarball produced by R CMD build 


 Many thanks for the respond and thoughts.

 With kind regards,
 Ema


 --**--**
 
 *From:* Prof Brian Ripley rip...@stats.ox.ac.uk
 *To:* David Winsemius dwinsem...@comcast.net
 *Cc:* Rohmatul Fajriyah rfajri...@yahoo.com; r-sig-mac@r-project.org
 r-sig-mac@r-project.org
 *Sent:* Tuesday, August 6, 2013 8:06 AM
 *Subject:* Re: [R-SIG-Mac] hidden files and directories


 On 06/08/2013 01:16, David Winsemius wrote:
  
   On Aug 5, 2013, at 5:00 PM, Rohmatul Fajriyah wrote:
  
   Dear All,
  
   I tried to build an R package (from the terminal) and everything was
 ok until R CMD check PackageName and I got this message:
   ..
   * checking for hidden files and directories ... NOTE
   Found the following hidden files and directories:
  .DS_Store
  man/.Rapp.history
  
   Those files would both be invisible when using the Finder.app unless
 you used ls in a terminal session, but I guess you figured that out

 invisible *by default*: it is a Finder setting.

  
   These were most likely included in error. See section ‘Package
   structure’ in the ‘Writing R Extensions’ manual.
   ..
  
   I, then:
   a. went through the archives of this mailing list (until January
 2011) and I could not find a similar problem.
   (apologise, if I missed it)
  
   In 2008 it was reported in the NEWS for R 2.7.1 that:
  
  
 http://markmail.org/search/?q=**list%3Aorg.r-project.r-help+**
 DS_Store#query:list%3Aorg.r-**project.r-help%20DS_Store+**
 page:1+mid:cx3hryqssis2slx7+**state:resultshttp://markmail.org/search/?q=list%3Aorg.r-project.r-help+DS_Store#query:list%3Aorg.r-project.r-help%20DS_Store+page:1+mid:cx3hryqssis2slx7+state:results
  
   o R CMD build tries harder to clean up the inst/doc directory from
 the remnants of earlier builds.
  
   It also removes any directories with extension .Rcheck, and files
 .DS_Store and ._* (created by tar on Mac OS X under some circumstances:
 it now sets environment variables to ask for such files not to be
 created by that tar.)
  
   So we need to ask if this was just a warning message. It appears that
 there are mechanisms in place to remove those files.
  
   (It's arguably an R-devel topic.)

 It seems the OP did not use R CMD build, rather R CMD check.

 But files like man/.Rapp.history will need to be removed manually.




 --
 Brian D. Ripley, rip...@stats.ox.ac.uk mailto:rip...@stats.ox.ac.uk

 Professor of Applied Statistics, 
 http://www.stats.ox.ac.uk/~**ripley/http://www.stats.ox.ac.uk/~ripley/
 University of Oxford,   Tel:  +44 1865 272861 (self)
 1 South Parks Road,+44 1865 272866 (PA)
 Oxford OX1 3TG, UKFax:  +44 1865 272595




 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  
 http://www.stats.ox.ac.uk/~**ripley/http://www.stats.ox.ac.uk/~ripley/
 University of Oxford, Tel:  +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UKFax:  +44 1865 272595

 __**_
 R-SIG-Mac mailing list
 R-SIG-Mac@r-project.org
 https://stat.ethz.ch/mailman/**listinfo/r-sig-machttps://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] R 3.0.0 beta

[Kasper Daniel Hansen]

I have heard rumors of GCC 4.7.2, has this been abandoned?

Kasper

On Wed, Mar 20, 2013 at 5:23 AM, Prof Brian Ripley
rip...@stats.ox.ac.uk wrote:
 R 3.0.0 is due to be released on Apr 3, and is now in beta.  Simon is
 travelling but before he left put up a binary distribution at
 http://r.research.att.com/snowleopard/R-3.0-branch/R-3.0-branch-snowleopard-signed.pkg
 .   A high proportion of CRAN is available as binary packages, and we will
 improve that over the next two weeks.

 UseRs and especially package developers are encouraged to try this out.  For
 CRAN packages there are logs available at
 http://cran.r-project.org/web/checks/check_results_NAME.html (replace NAME
 by the name of your package).

 Note that there are quite a few changes in this pre-release:

 - it requires Snow Leopard or later.

 - it is x86_64 only and sub-architectures are not used.

 - the recommended compilers have changed and the CRAN distribution uses
 rather specific names for them to make it easier to match them.  Those
 compilers need Xcode 4.2 or later and (if relevant) a Fortran compiler from
 http://r.research.att.com.  Note that the binary is set up for the matching
 gfortran for 10.6: if you have Lion or Mountain Lion you will need to edit
 FLIBS in etc/Makeconf.

 - the relevant manuals are part of the distribution, or see
 http://cran.r-project.org/doc/manuals/r-devel/R-admin.html, especially
 chapter 4 and sections 6.3.2 and C.4.

 I've reported most of the issues thrown up with CRAN packages to their
 maintainers.  Common issues are

 - including headers such as R.h which have #defines before system headers
 and/or without R_NO_REMAP or similar (see 'Writing R Extensions').

 - misuse of 'inline' in C code: only 'static inline' is really portable.

 - lack of care with OpenMP: the CRAN distribution does not support OpenMP
 and this toolchain has flaky OpenMP support.

 Note too that checking with clang (at least the version in Xcode 4.6) rather
 than gcc shows up further problems: the R-admin manual shows you how to set
 that up for yourself.

 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford, Tel:  +44 1865 272861 (self)
 1 South Parks Road, +44 1865 272866 (PA)
 Oxford OX1 3TG, UKFax:  +44 1865 272595

 ___
 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.0.0 beta

[Kasper Daniel Hansen]

Prof Ripley,

I highly appreciated the clarifications in this thread.  I am sure I
am not the only one.

Good luck with finding a new compiler; I am happy to provide whatever
help I can.

Best,
Kasper

On Wed, Mar 20, 2013 at 1:08 PM, Marc Schwartz marc_schwa...@me.com wrote:
 Prof Ripley,

 A quick note to indicate that it appears that the primary 'tests' directory, 
 which contains the code and related files for running 
 tools::testInstalledBasic() is not present in the current OSX binary package 
 for 3.0.0 beta 
 (http://r.research.att.com/snowleopard/R-3.0-branch/R-3.0-branch-snowleopard-signed.pkg).

 As a consequence, the following fails:

 testInstalledBasic(both)
 Error in setwd(file.path(R.home(), tests)) :
   cannot change working directory

 with the missing directory being:

 file.path(R.home(), tests)
 [1] /Library/Frameworks/R.framework/Resources/tests


 Similarly, it seems that the individual 'tests' directories, where 
 appropriate, for base and recommended packages (used via 
 tools::testInstalledPackages()) are also not present in the current OSX beta 
 binary package.

 I presume that this may have been inadvertent in the preparation of this 
 build prior to Simon's departure.

 Beyond that, I also wanted to note and say thanks (Fritz?) for modifying 
 Sweave so that the output now includes the line number for the chunk being 
 processed. A major help for debugging.

 Regards,

 Marc Schwartz

 ___
 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] error: unrecognized option ‘-arch’ -- suggestion!

[Kasper Daniel Hansen]

On Fri, Sep 28, 2012 at 10:58 AM, Prof Brian Ripley
rip...@stats.ox.ac.uk wrote:
 On 28/09/2012 15:29, Kasper Daniel Hansen wrote:

 So I had a few emails with Peder, and I think he gets it now.

 However, one point came up which I have been wondering about as well.
 In Makeconf R only stores the name of the compiler, say gcc or
 perhaps gcc-4.2.  Why not store the full path?  Peder's situation is
 that he has installed another compiler that resolves to gcc in his
 environment, masking the one in /usr/bin.  It seems to me that it
 would be more safe to save the entire path to the compiler, both on
 multi-user systems on in case like (for os x) the binary is downloaded
 from somewhere else.  [ on the other hand, it may be easier on Windows
 to not have the full path ]

 Now, there is probably a perfectly good reason to do what is happening
 now.  Or perhaps changing it is not worth the effort.  But I just
 wanted to raise the issue for 2 seconds.


 You get what you specified when you configured R.  I usually configure with
 full paths except on Windows (where paths like /usr/local do not exist in
 general).

Thanks.  I see how this works now, and I should have investigated a bit more.

Kasper

 The point is that you can do what suits you.  If you choose to use a binary
 distribution you get what suits the distributor: if you don't like that,
 build from the sources yourself.

 The documentation for the CRAN Mac binary distribution is a bit scattered.
 I am not sure it would help, but we could add some more words to the R-admin
 manual.  I suspect few people want to work with source packages with
 compiled code and use the CRAN distribution (not least as it is hard to make
 portable binary packages that way).



 Kasper

 On Thu, Sep 27, 2012 at 10:29 AM, Kasper Daniel Hansen
 kasperdanielhan...@gmail.com wrote:

 On Thu, Sep 27, 2012 at 10:07 AM, Peder Axensten peder.axens...@slu.se
 wrote:


 On 27 sep 2012, at 14:27, Simon Urbanek simon.urba...@r-project.org
 wrote:

 On Sep 27, 2012, at 5:02 AM, Peder Axensten wrote:

 The compiler (clang) and linker that Apple includes (with Xcode) uses
 the argument -arch to specify the architecture to build for. This is not
 recognized by, for instance, the gcc compilers. Because this argument is
 'hardcoded' into the Makeconfig files,


 It is not - those (assuming you mean Makeconf) are generated from the
 flags used to build R, so if you use any other compiler with other flags
 they will be reflected in the Makeconf accordingly.


 I know little about how this is set up, is it not possible to change
 some kind of template to change the way this is done? Some base variables
 that are generated from the flags, these variables are then used in the 
 rest
 of the Makeconf along the lines I suggested?

 it is an involved process to compile libraries for R with any other
 compiler.


 R doen't care what you compile libraries with as long as R can links
 against them at configure time. Again, this has nothing to do with 
 Makevars.


 As I understand it, if I use R CMD INSTALL I'm stuck with what is
 defined in the Makeconf files. If I use any other compiler other than
 Apple's clang as my default compiler, I get errors when I run R CMD
 INSTALL –– that is, if I from R try to install any package that requires
 compilation. I think it would be better to determine the value of the
 variables when R CMD INSTALL is run, rather than when R is installed (or
 even compiled?).


 Peder,

 You seem a bit confused.  Let me explain it a bit clearer.  When you
 compile R, the settings (and compiler) with which you compiled R is
 stored in Makeconf and used to compile new packages using R CMD
 INSTALL.  This ensures that you use the same compiler settings to
 build R and add-on packages, which is obviously an _extremely good_
 idea.  If you want to use another compiler with R, you will need to
 re-compile R using this compiler, which should work.

 My guess is that you are using the CRAN binary of R (compiled using
 the official compiler) and you want to use another compiler to build
 an add-on package.  This is not supported, and it should not be
 supported, because it is an extremely bad idea.

 Below is my configure call for building R from svn, using Simon's
 build of Apple's GCC codebase (aka the official compiler).  It should
 be easy to modify this to build R using a different compiler.  I am
 just including this as an example.  Once you have build R using you
 new compiler, R CMD INSTALL should work out of the box.

 Note that if you want aqua support, you need a compiler that supports
 objective-C (as far as I understand).  I don't use a GUI, but I use an
 aqua device, like
 R  quartz()

 (I may use imprecise terminology here, wrt. aqua and quartz).

 Kasper

 configure:

 export LANG=en_US.UTF-8
 ../${SRCDIR}/configure SHELL='/bin/bash' \
--prefix=/usr/local/R/R-${R_VERSION} --disable-R-framework\
CC=/usr/bin/gcc-4.2 -arch x86_64 -std=gnu99 \
CFLAGS=-g -O2 -std

Re: [R-SIG-Mac] error: unrecognized option ‘-arch’ -- suggestion!

[Kasper Daniel Hansen]

On Thu, Sep 27, 2012 at 10:07 AM, Peder Axensten peder.axens...@slu.se wrote:

 On 27 sep 2012, at 14:27, Simon Urbanek simon.urba...@r-project.org wrote:

 On Sep 27, 2012, at 5:02 AM, Peder Axensten wrote:

 The compiler (clang) and linker that Apple includes (with Xcode) uses the 
 argument -arch to specify the architecture to build for. This is not 
 recognized by, for instance, the gcc compilers. Because this argument is 
 'hardcoded' into the Makeconfig files,

 It is not - those (assuming you mean Makeconf) are generated from the flags 
 used to build R, so if you use any other compiler with other flags they will 
 be reflected in the Makeconf accordingly.

 I know little about how this is set up, is it not possible to change some 
 kind of template to change the way this is done? Some base variables that are 
 generated from the flags, these variables are then used in the rest of the 
 Makeconf along the lines I suggested?

 it is an involved process to compile libraries for R with any other 
 compiler.

 R doen't care what you compile libraries with as long as R can links against 
 them at configure time. Again, this has nothing to do with Makevars.

 As I understand it, if I use R CMD INSTALL I'm stuck with what is defined in 
 the Makeconf files. If I use any other compiler other than Apple's clang as 
 my default compiler, I get errors when I run R CMD INSTALL –– that is, if I 
 from R try to install any package that requires compilation. I think it would 
 be better to determine the value of the variables when R CMD INSTALL is run, 
 rather than when R is installed (or even compiled?).

Peder,

You seem a bit confused.  Let me explain it a bit clearer.  When you
compile R, the settings (and compiler) with which you compiled R is
stored in Makeconf and used to compile new packages using R CMD
INSTALL.  This ensures that you use the same compiler settings to
build R and add-on packages, which is obviously an _extremely good_
idea.  If you want to use another compiler with R, you will need to
re-compile R using this compiler, which should work.

My guess is that you are using the CRAN binary of R (compiled using
the official compiler) and you want to use another compiler to build
an add-on package.  This is not supported, and it should not be
supported, because it is an extremely bad idea.

Below is my configure call for building R from svn, using Simon's
build of Apple's GCC codebase (aka the official compiler).  It should
be easy to modify this to build R using a different compiler.  I am
just including this as an example.  Once you have build R using you
new compiler, R CMD INSTALL should work out of the box.

Note that if you want aqua support, you need a compiler that supports
objective-C (as far as I understand).  I don't use a GUI, but I use an
aqua device, like
R  quartz()

(I may use imprecise terminology here, wrt. aqua and quartz).

Kasper

configure:

export LANG=en_US.UTF-8
../${SRCDIR}/configure SHELL='/bin/bash' \
  --prefix=/usr/local/R/R-${R_VERSION} --disable-R-framework\
  CC=/usr/bin/gcc-4.2 -arch x86_64 -std=gnu99 \
  CFLAGS=-g -O2 -std=gnu99 -march=nocona \
  CXX=/usr/bin/g++-4.2 -arch x86_64 \
  CXXFLAGS=-g -O2 -march=nocona \
  OBJC=/usr/bin/gcc-4.2 -arch x86_64 \
  F77=/usr/bin/gfortran-4.2 -arch x86_64 \
  FFLAGS=-g -O2 -march=nocona \
  FC=/usr/bin/gfortran-4.2 -arch x86_64 \
  FCFLAGS=-g -O2 -march=nocona \
  --enable-memory-profiling\
  --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib\
  --with-system-zlib\
  --with-blas='-framework vecLib' --with-lapack





 I'm sure it could be implemented better, but something like:
 ~
 GCCPATH =

 # If we are using the Apple compiler [that supports the -arch option], this 
 is the argument to that option.
 ARCH = x86_64

 # Get information on the gcc to be used.
 ISAPPLESTRING := $(shell $(GCCPATH)gcc --version)
 ISAPPLEKEY := Apple

 # This will either be nothing or '-arch $(ARCH)'
 MYARCH := $(if $(findstring $(ISAPPLEKEY),$(ISAPPLESTRING)),-arch $(ARCH))

 MYGCC = $(GCCPATH)gcc $(MYARCH)
 MYGPP = $(GCCPATH)g++ $(MYARCH)
 MYFORTRAN = $(GCCPATH)gfortran $(MYARCH)

 ## etc.
 ~


 All the best,
 /Peder


 Cheers,
 Simon



 Either all all `-arch i386` and `-arch x86_64` must be removed from these 
 files (this must be done every time R is updated) or you create a file 
 `~/.R/Makevars` with something like
 ~~~
 MYARCH = -arch x86_64

 # Comment the next line to return to the original setting:
 MYARCH =

 CC = gcc $(MYARCH) -std=gnu99
 CXX=g++ $(MYARCH)
 CXXCPP = g++ $(MYARCH) -E
 FC = gfortran $(MYARCH)
 F77 = gfortran $(MYARCH)
 OBJC = gcc $(MYARCH)
 OBJCXX = g++ $(MYARCH)

 DYLIB_LD = gcc $(MYARCH) -std=gnu99
 MAIN_LD = gcc $(MYARCH) -std=gnu99
 SHLIB_CXXLD = g++ $(MYARCH)
 SHLIB_FCLD = gfortran $(MYARCH)
 SHLIB_LD = gcc $(MYARCH) -std=gnu99
 ~~~
 Unfortunately, a few instances of `-arch` are outside the variables and can 
 not be reached this way.

Re: [R-SIG-Mac] compiling from source on ML, tcltk

[Kasper Daniel Hansen]

On Sun, Sep 2, 2012 at 3:54 PM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote:
 Do you need R.app?  If not, I would recommend using ActiveTcl Tcl/Tk by e.g.

 ./configure ...
 --with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh
 --with-tk-config=/Library/Frameworks/Tk.framework/tkConfig.sh

I don't have (Tcl|Tk).framework in /Library/Frameworks.  I seem to
recall they were there in earlier versions of the OS.

I did some more investigation.  Following a suggestion on Stack overflow I did
  sudo ln -s /opt/X11/include/X11 /usr/include
and that suddenly gave me tcltk capabilities.  To be honest, I don't
understand why. I use
  --X-Includes=/Usr/X11/Include --X-Libraries=/Usr/X11/Lib
in my configure script so I don't fully understand why the presence of
this symbolic link fixes it.  But it is an empirical fact it does

Kasper




 I've been using it for some time, and it has much nicer ttk widgets.



 On 02/09/2012 19:21, Kasper Daniel Hansen wrote:

 I now want to get tcltk support working under ML (because I need to
 test a few packages).

 I have installed Xquartz and I have just install the new tcltk 8.5.5
 from CRAN (which is not signed btw).

 Running configure, I get

 checking for tclConfig.sh... no
 checking for tclConfig.sh in library (sub)directories...
 /usr/local/lib/tclConfig.sh
 checking for tkConfig.sh... no
 checking for tkConfig.sh in library (sub)directories...
 /usr/local/lib/tkConfig.sh
 checking tcl.h usability... yes
 checking tcl.h presence... yes
 checking for tcl.h... yes
 checking tk.h usability... no
 checking tk.h presence... no
 checking for tk.h... no
 checking /usr/local/include/tk8.5/generic/tk.h usability... no
 checking /usr/local/include/tk8.5/generic/tk.h presence... no
 checking for /usr/local/include/tk8.5/generic/tk.h... no
 checking /usr/local/include/tk8.5/tk.h usability... no
 checking /usr/local/include/tk8.5/tk.h presence... no
 checking for /usr/local/include/tk8.5/tk.h... no
 checking /usr/local/include/tcl8.5/tk.h usability... no
 checking /usr/local/include/tcl8.5/tk.h presence... no
 checking for /usr/local/include/tcl8.5/tk.h... no
 checking /usr/local/include/tk.h usability... no
 checking /usr/local/include/tk.h presence... no
 checking for /usr/local/include/tk.h... no
 checking for tk.h... yes

 So it seems to find tcltk.  I get a few warnings when it checks for X11
 headers:

 checking X11/Intrinsic.h presence... no
 configure: WARNING: X11/Intrinsic.h: accepted by the compiler,
 rejected by the preprocessor!
 configure: WARNING: X11/Intrinsic.h: proceeding with the compiler's result

 and

 checking X11/Xmu/Atoms.h presence... no
 configure: WARNING: X11/Xmu/Atoms.h: accepted by the compiler,
 rejected by the preprocessor!
 configure: WARNING: X11/Xmu/Atoms.h: proceeding with the compiler's result

 I assume these are unrelated.  Although configure seems to find tcltk,
 at the end of configure, I get

 R is now configured for x86_64-apple-darwin12.1.0

Source directory:  ../R-2.15.x-src
Installation directory:/usr/local/R/R-2.15.x

C compiler:/usr/bin/gcc-4.2 -arch x86_64 -std=gnu99
 -g -O2 -std=gnu99 -march=nocona
Fortran 77 compiler:   /usr/bin/gfortran-4.2 -arch x86_64  -g
 -O2 -march=nocona

C++ compiler:  /usr/bin/g++-4.2 -arch x86_64  -g -O2
 -march=nocona
Fortran 90/95 compiler:/usr/bin/gfortran-4.2 -arch x86_64 -g -O2
 -march=nocona
Obj-C compiler:/usr/bin/gcc-4.2 -arch x86_64 -g -O2
 -fobjc-exceptions

Interfaces supported:  X11, aqua
External libraries:readline, BLAS(vecLib), LAPACK(in blas), ICU
Additional capabilities:   PNG, JPEG, NLS
Options enabled:   R profiling, memory profiling, Java

Recommended packages:  yes

 which does not mention tcltk support under 'Interfaces supported'.

 This used to work on Lion, and I am wondering what I am doing wrong.


 I think you should be wondering what Apple is doing wrong   But you need
 to look in config.log to find the root cause.


 My configure script is

 export LANG=en_US.UTF-8
 ../${SRCDIR}/configure SHELL='/bin/bash' \
--prefix=/usr/local/R/R-${R_VERSION} --disable-R-framework\
CC=/usr/bin/gcc-4.2 -arch x86_64 -std=gnu99 \
CFLAGS=-g -O2 -std=gnu99 -march=nocona \
CXX=/usr/bin/g++-4.2 -arch x86_64 \
CXXFLAGS=-g -O2 -march=nocona \
OBJC=/usr/bin/gcc-4.2 -arch x86_64 \
F77=/usr/bin/gfortran-4.2 -arch x86_64 \
FFLAGS=-g -O2 -march=nocona \
FC=/usr/bin/gfortran-4.2 -arch x86_64 \
FCFLAGS=-g -O2 -march=nocona \
--enable-memory-profiling\
--X-Includes=/Usr/X11/Include --X-Libraries=/Usr/X11/Lib\
--with-system-zlib\
--with-blas='-framework vecLib' --with-lapack

 Thanks,
 Kasper

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



 --
 Brian D. Ripley,  rip...@stats.ox.ac.uk

[R-SIG-Mac] building R under Lion

[Kasper Daniel Hansen]

I am running Lion, with the newest version of Xcode, and the 5666
build of gcc+gfortran from Simon's page.  This is on Macbook pro last
generation, with a quad core i7.  I have installed the latest stable
release of Xquartz.

I am building R, not as a framework (--disable-framework), but I am
using --with-blas='-framework vecLib' which at least used to be much
better than the built-in BLAS.

My entire configure call is
../${SRCDIR}/configure SHELL='/bin/bash' \
  --prefix=/usr/local/R/R-${R_VERSION} --disable-R-framework\
  CC=/usr/bin/gcc-4.2 -arch x86_64 -std=gnu99 \
  CFLAGS=-g -O2 -std=gnu99 -march=nocona \
  CXX=/usr/bin/g++-4.2 -arch x86_64 \
  CXXFLAGS=-g -O2 -march=nocona \
  OBJC=/usr/bin/gcc-4.2 -arch x86_64 \
  F77=/usr/bin/gfortran-4.2 -arch x86_64 \
  FFLAGS=-g -O2 -march=nocona \
  FC=/usr/bin/gfortran-4.2 -arch x86_64 \
  FCFLAGS=-g -O2 -march=nocona \
  --enable-memory-profiling\
  --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib\
  --with-system-zlib\
  --with-blas='-framework vecLib' --with-lapack

When I build R-2.15.1-patched, I get

making internet.d from ../../../../R-2.15.x-src/src/modules/internet/internet.c
In file included from
../../../../R-2.15.x-src/src/modules/lapack/vecLibg95c.c:5:
/System/Library/Frameworks/vecLib.framework/Headers/vecLib.h:22:4:
error: #error vecLib/vecLib.h is deprecated.  Please #include
Accelerate/Accelerate.h and link to Accelerate.framework.
make[3]: *** [vecLibg95c.d] Error 1
make[2]: *** [make.lapack] Error 2
make[2]: *** Waiting for unfinished jobs
making nanoftp.d from ../../../../R-2.15.x-src/src/modules/internet/nanoftp.c

SNIP

/usr/bin/gcc-4.2 -arch x86_64 -std=gnu99 -I. -I../../../src/include
-I../../../../R-2.15.x-src/src/include -I/usr/local/include
-DHAVE_CONFIG_H   -fopenmp -fPIC  -g -O2 -std=gnu99 -march=nocona   -c
../../../../R-2.15.x-src/src/modules/internet/sockconn.c -o sockconn.o
/usr/bin/gcc-4.2 -arch x86_64 -std=gnu99 -dynamiclib
-Wl,-headerpad_max_install_names  -undefined dynamic_lookup
-single_module -multiply_defined suppress -L/usr/local/lib -o
internet.so Rhttpd.o Rsock.o internet.o nanoftp.o nanohttp.o sock.o
sockconn.o   -Wl,-framework -Wl,CoreFoundation
mkdir /Users/khansen/build/R/R-2.15.x-build/modules
make[1]: *** [R] Error 1
make: *** [R] Error 1

So it seems that it does not like -framework vecLib.  I tried with
-framework Accelerate, but I get the same error.

My guess is that there is some new thing I have to do here, but I
tried reading the admin guide for R-devel and could not see anything
particular (except I do not need -arch x86_64 anymore).

Thanks,
Kasper

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

Re: [R-SIG-Mac] texi2dvi error Sweave and exams

[Kasper Daniel Hansen]

Paul,

The standard way to install Tex on the Mac is to use MacTex (a port of
Texlive to the Mac), see
  http://tug.org/mactex/

You should probably install the big 2.1GB package on the front page.
That should also place the tex utilities on your path (as far as I
recall).

Kasper

On Sun, Aug 19, 2012 at 3:23 PM, Paul Ossenbruggen p...@cisunix.unh.edu wrote:



 I have installed Sweave as recommended. 
 http://lifeasclay.wordpress.com/tag/sweave/.Placing a test.Rnw file, for 
 instance, in  
 /Library/Frameworks/R.framework/Versions/2.15/Resources/library/utils/Sweave
  generates test.tex files that generate pdf files with LaTeX. To be honest, 
 placing Rnw files seem to make sense. The exams package does require not 
 this step. It uses texi2dvi and other tools to accomplish this result. Since 
 I have a cursory knowledge of Mac OSX and the role that texi2dvi plays, I 
 cannot understand the error message obtained below. The error occurs when 
 executing the Example from R help(exams).

 library(exams)
 Loading required package: tools
 starting httpd help server ... done
 getwd()
 [1] /Users/PJO
 library(exams)
 options(device.ask.default = FALSE)

 myexam - list(
 +   boxplots,
 +   c(tstat, ttest, confint),
 +   c(regression, anova),
 +   scatterplot,
 +   relfreq
 + )

 sol - exams(myexam)
 Error in texi2dvi(out_tex[j], pdf = TRUE, clean = TRUE, quiet = quiet) :
   Running 'texi2dvi' on 'plain1.tex' failed.

 I am running:
 R version 2.15.1 (2012-06-22) -- Roasted Marshmallows
 Copyright (C) 2012 The R Foundation for Statistical Computing
 ISBN 3-900051-07-0
 Platform: i386-apple-darwin9.8.0/i386 (32-bit)

 and Mac OSX Version 10.8.

 After submitting the above to r-help-request 12. texi2dvi error 
 Sweave and exams (Paul Ossenbruggen), I delved further into the problem 
 and discovered the source of the problem:

 exams(file = tstat.Rnw, quiet = FALSE)
 Writing to file tstat.tex
 Processing code chunks with options ...
  1 : keep.source term hide

 You can now run (pdf)latex on ‘tstat.tex’
 Error in texi2dvi(out_tex[j], pdf = TRUE, clean = TRUE, quiet = quiet) :
   Running 'texi2dvi' on 'plain1.tex' failed.
 Output:
 You don't have a working TeX binary (tex) installed anywhere in
 your PATH, and texi2dvi cannot proceed without one.  If you want to use
 this script, you'll need to install TeX (if you don't have it) or change
 your PATH or TEX environment variable (if you do).  See the --help
 output for more details.

 For information about obtaining TeX, please see http://www.tug.org.  If
 you happen to be using Debian, you can get it with this command:
   apt-get install tetex-bin

 Apparently, it is a simple matter to fix the error; however, I don't 
 have sufficient knowledge to know how to proceed.

 I installed LaTeX using TeX Live and use TeXShop as my LaTeX driver. 
 A bibtex folder is stored on the path /library/texmf but TeX is not. I 
 suspect that I must install TeX in this folder but again unsure.

 Any help will be greatly appreciated.

 Thanks,
 Paul


 [[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] graphics device with record=TRUE

[Kasper Daniel Hansen]

On Thu, Jul 5, 2012 at 9:42 AM, David Winsemius dwinsem...@comcast.net wrote:

 On Jul 4, 2012, at 11:47 PM, Richard M. Heiberger wrote:

 David,

 thank you.  it works.

 Where is it documented?

 The first place I find written documentation of the cmd-arrow
 functions  is in the R MacOSX FAQ:
 12.8 Why are Quartz plots much bigger than they used to be?
 (Second paragraph)

 (I may have read about the stack depth in one of the postings from
 Simon in this venue. The figure of ten is a rough guess. The true
 value is somewhere  in the range of 8 to 15.)

  I want to set the depth to something much larger than 10.

 I have not found a place for users to change this. May be that a
 compile time change is needed. (Simon will hopefully correct me if
 this is wrong.)

 I tried searching MarkMail's archive with a couple of strategies, ...
 the last unsuccessful one was:

 http://markmail.org/search/?q=simon+urbanek+list%3Aorg.r-project.r-sig-mac+graphics+increase#query
 :simon%20urbanek%20list%3Aorg.r-project.r-sig-mac%20graphics%20increase
 +page:2+mid:ykmzj6mwesj3wywu+state:results

 (I don't know if that will be paste-worthy or click-worthy.)


 I don't see anything about the stack on the ?quartz page
 and there appears not to be any control option on the quartz menu
 item on the device
 itself.

 If the Quartz window is the focus, the Quartz menu options will become
 active  and even if not the focus the menu will also tell you the
 keyboard equivalents (standard Mac behavior). I think that is where I
 learned it.

When the quartz window is in focus I get (this is R compiled myself
and started from Terminal.  The same from within emacs):

On the menu bar I get headings
...
R
Edit
Quartz
Window

Edit has submenus copy and paste which are very nice if you want to
save the plot
Quartz has submenus Back and Forward bound to Apple + Left/Right arrow





 Rich

 On Wed, Jul 4, 2012 at 11:35 PM, David Winsemius dwinsem...@comcast.net
  wrote:

 On Jul 4, 2012, at 11:12 PM, Richard M. Heiberger wrote:

 The windows feature I miss most on the Mac is a graphics device that
 remembers the previous graphs,
 specifically
 windows.options(record=TRUE)  ## R for Windows

 Is there a similar feature available on the macintosh?

 There is a graphics stack, whose default depth is 10, and you can
 scroll backward with cmd-left-arrow  ... at least in the R64.app
 and r.app GUI's.

 --
 David Winsemius, MD
 West Hartford, CT



 David Winsemius, MD
 West Hartford, CT


 [[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] Lion and X11

[Kasper Daniel Hansen]

For what it is worth I don't see this problem on Snow Leopard, self-compiled.

You can make quartz the default device by putting
 Sys.setenv(R_INTERACTIVE_DEVICE = quartz)
in your .Rprofile.

Kasper

On Fri, Jan 27, 2012 at 7:17 PM, Martin Renner greatauk...@gmail.com wrote:
 Hi All,

 Is anybody else experiencing problems with X11 and R under Mac OS X 10.7 
 (Lion)? If yes, maybe it's not specific to my machine. R segfaults when I try 
 to plot to a X11 device, e.g. open R in the terminal and calling
 plot (1:10)
 (see below). Plotting to a quartz device works fine. I'm using R-2.14.1 (see 
 below), compiled from source using homebrew. I've seen the same issue with 
 the CRAN binaries, with a vanilla compile from source of R-2.14.1 and even 
 with an old R-2.9.2.

 I wonder whether I'd have to wait for a fix from Apple, or whether there's a 
 work-around like something that can be done during configuration?

 Cheers,
 Martin



 plot (1:10)

  *** caught segfault ***
 address 0x0, cause 'memory not mapped'

 Traceback:
  1: axis(side = side, at = at, labels = labels, ...)
  2: Axis.default(...)
  3: Axis(...)
  4: localAxis(if (is.null(y)) xy$x else x, side = 1, ...)
  5: plot.default(1:10)
  6: plot(1:10)



 sessionInfo()
 R version 2.14.1 (2011-12-22)
 Platform: x86_64-apple-darwin11.2.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  methods   base


 ___
 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] LogicReg package problems

[Kasper Daniel Hansen]

On Mon, Jan 16, 2012 at 2:57 AM, BEES INC bees@gmail.com wrote:
 Hey there

 I am having a bit of trouble getting this working, I had to do a bit
 of fiddling with makefiles to get it to find the right gfortran, but
 it builds  links without error, however the install gives the
 following error:

You have used some special (?) gfortran at compile time (based on the
above, but I am not sure).  This may not work with R that has been
compiled with another gfortran and it might also not work at run time.

We really need more information about exactly what you have done.

Kasper



 Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object
 '/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so':
  dlopen(/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so,
 6): no suitable image found.  Did find:
        
 /Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so:
 out of address space

 Full install is as follows:

 $ R CMD INSTALL --no-multiarch LogicReg_1.4.11.tar.gz
 * installing to library
 ‘/Library/Frameworks/R.framework/Versions/2.14/Resources/library’
 * installing *source* package ‘LogicReg’ ...
 ** package ‘LogicReg’ successfully unpacked and MD5 sums checked
 ** Creating default NAMESPACE file
 ** libs
 *** arch - i386
 gfortran   -fPIC  -g -O2 -c My_own_scoring.f -o My_own_scoring.o
 gfortran   -fPIC  -g -O2 -c external.f -o external.o
 gfortran   -fPIC  -g -O2 -c slogic.f -o slogic.o
 gcc-4.2 -arch i386 -std=gnu99
 -I/Library/Frameworks/R.framework/Resources/include
 -I/Library/Frameworks/R.framework/Resources/include/i386
 -I/usr/local/include    -fPIC  -g -O2 -c swrite.c -o swrite.o
 gcc-4.2 -arch i386 -std=gnu99 -dynamiclib
 -Wl,-headerpad_max_install_names -single_module -multiply_defined
 suppress -L/usr/local/lib
 -L/usr/local/gfortran/lib/gcc/i686-apple-darwin9/4.6.2 -o LogicReg.so
 My_own_scoring.o external.o slogic.o swrite.o -lgfortran
 -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
 -Wl,CoreFoundation
 installing to 
 /Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386
 ** R
 ** data
 ** inst
 ** preparing package for lazy loading
 ** help
 *** installing help indices
 ** building package indices ...
 ** testing if installed package can be loaded
 Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object
 '/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so':
  dlopen(/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so,
 6): no suitable image found.  Did find:
        
 /Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so:
 out of address space
 Error: loading failed
 Execution halted
 ERROR: loading failed
 * removing 
 ‘/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg’
 $

 Any ideas?

 Thanks

 ___
 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] LogicReg package problems

[Kasper Daniel Hansen]

Ok, I was wondering if you were picking up the same gfortran at run
and compile time.  I see the error on the cran building machine, so it
is probably an issue at the package level.

I suggest emailing the two authors about it.  I know for sure Ingo is
using a Mac as a laptop, so perhaps he has something insightful to say
about this.

Kasper

On Mon, Jan 16, 2012 at 9:31 AM, BEES INC bees@gmail.com wrote:
 I should add, it is the same version of gfortran that R is expecting,
 just installed in a different location

 On Tue, Jan 17, 2012 at 1:25 AM, BEES INC bees@gmail.com wrote:
 I do not believe gfortran comes with OS X, so I installed the latest
 version. R was picking up a version that had been installed with
 octave, which is why I needed to make some changes as I did not want
 to link R libs with something packaged with octave (because if i
 update or remove octave all my R libs will break).

 I don't think that is a material part of the issue, and doing some
 digging I see it is not just my machine:

 http://cran.r-project.org/web/checks/check_results_LogicReg.html
 http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/LogicReg-00install.html

 Which shows the same error. Can you build the package OK?

 Thanks

 On Tue, Jan 17, 2012 at 1:16 AM, Kasper Daniel Hansen
 kasperdanielhan...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 2:57 AM, BEES INC bees@gmail.com wrote:
 Hey there

 I am having a bit of trouble getting this working, I had to do a bit
 of fiddling with makefiles to get it to find the right gfortran, but
 it builds  links without error, however the install gives the
 following error:

 You have used some special (?) gfortran at compile time (based on the
 above, but I am not sure).  This may not work with R that has been
 compiled with another gfortran and it might also not work at run time.

 We really need more information about exactly what you have done.

 Kasper



 Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object
 '/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so':
  dlopen(/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so,
 6): no suitable image found.  Did find:
        
 /Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so:
 out of address space

 Full install is as follows:

 $ R CMD INSTALL --no-multiarch LogicReg_1.4.11.tar.gz
 * installing to library
 ‘/Library/Frameworks/R.framework/Versions/2.14/Resources/library’
 * installing *source* package ‘LogicReg’ ...
 ** package ‘LogicReg’ successfully unpacked and MD5 sums checked
 ** Creating default NAMESPACE file
 ** libs
 *** arch - i386
 gfortran   -fPIC  -g -O2 -c My_own_scoring.f -o My_own_scoring.o
 gfortran   -fPIC  -g -O2 -c external.f -o external.o
 gfortran   -fPIC  -g -O2 -c slogic.f -o slogic.o
 gcc-4.2 -arch i386 -std=gnu99
 -I/Library/Frameworks/R.framework/Resources/include
 -I/Library/Frameworks/R.framework/Resources/include/i386
 -I/usr/local/include    -fPIC  -g -O2 -c swrite.c -o swrite.o
 gcc-4.2 -arch i386 -std=gnu99 -dynamiclib
 -Wl,-headerpad_max_install_names -single_module -multiply_defined
 suppress -L/usr/local/lib
 -L/usr/local/gfortran/lib/gcc/i686-apple-darwin9/4.6.2 -o LogicReg.so
 My_own_scoring.o external.o slogic.o swrite.o -lgfortran
 -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
 -Wl,CoreFoundation
 installing to 
 /Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386
 ** R
 ** data
 ** inst
 ** preparing package for lazy loading
 ** help
 *** installing help indices
 ** building package indices ...
 ** testing if installed package can be loaded
 Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object
 '/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so':
  dlopen(/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so,
 6): no suitable image found.  Did find:
        
 /Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg/libs/i386/LogicReg.so:
 out of address space
 Error: loading failed
 Execution halted
 ERROR: loading failed
 * removing 
 ‘/Library/Frameworks/R.framework/Versions/2.14/Resources/library/LogicReg’
 $

 Any ideas?

 Thanks

 ___
 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] L after a number returns that number, what does it mean?

[Kasper Daniel Hansen]

This is not the appropriate email list for this question, but I can
tell you that L means integer.

Kasper

On Tue, Nov 22, 2011 at 9:16 PM, Colstat cols...@gmail.com wrote:
 Hi, all
 When you enter 3L or 10L in R console, it still returns the number 3, 10,
 respectively.  It's amazing that there's no error, but I was expecting one.
 What does that mean?  What is 3L, I assume it has something to do with
 list()?
 -C

        [[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] Screen device under macOS X

[Kasper Daniel Hansen]

I am on Snow Leopard.  As Brian mentions, my DISPLAY variable is set
(to echo $DISPLAY
/tmp/launch-SN2m7Z/org.x:0
), but this is not something I do myself.  I have always thought that
on (newer) OS X, DISPLAY got set automatically.  Not too infrequently
do I use X11 on a remote server and I always login with ssh -Y.

Kasper

On Thu, Oct 6, 2011 at 9:35 AM, Simon Urbanek
simon.urba...@r-project.org wrote:
 Are you on Lion? (You failed to mention that crucial detail)
 If so, R cannot detect window session on Lion (the OS says there is none even 
 if there is one) so it must assume that you are using ssh or other tunneling, 
 so if falls back to whatever other device it can use.

 Cheers,
 Simon


 On Oct 5, 2011, at 9:31 PM, John Maindonald wrote:

 When I start up R (or at least 64-bit R) from the command line
 or from ESS, and plot a graph without first opening a graphics
 screen window, I get an X11 window.

 If I type capabilities(), I get:

 capabilities()
    jpeg      png     tiff    tcltk      X11     aqua http/ftp  sockets
    TRUE     TRUE     TRUE     TRUE     TRUE     TRUE     TRUE     TRUE
  libxml     fifo   cledit    iconv      NLS  profmem    cairo
    TRUE     TRUE    FALSE     TRUE     TRUE     TRUE     TRUE

 Given that aqua is available, why do I not get a quartz window?
 (I can of course open such a window.)

 sessionInfo()
 R version 2.13.2 (2011-09-30)
 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

 locale:
 [1] C

 attached base packages:
 [1] stats     graphics  grDevices utils     datasets  methods   base

 other attached packages:
 [1] lattice_0.19-33

 loaded via a namespace (and not attached):
 [1] grid_2.13.2  tools_2.13.2

 John Maindonald             email: john.maindon...@anu.edu.au
 phone : +61 2 (6125)3473    fax  : +61 2(6125)5549
 Centre for Mathematics  Its Applications, Room 1194,
 John Dedman Mathematical Sciences Building (Building 27)
 Australian National University, Canberra ACT 0200.
 http://www.maths.anu.edu.au/~johnm

 ___
 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] Minor bug in Quartz sizing

[Kasper Daniel Hansen]

On Sat, Sep 3, 2011 at 12:47 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 With a current R-patched (2.13.1 Patched (2011-09-02 r56906)), the following
 code generates plots missing the bottom labels:

 par(mfrow = c(4, 5), mar = c(2.1, 2.1, 4.1, 1.1))
 for (i in 1:20) plot(1)

 If I resize the plot at all, it's redrawn correctly, with all margins
 showing.  After resizing, repetitions in the old window are fine, but if I
 close it and try again, the error re-surfaces.

 I'm on Mac OSX 10.6.8.

I have often seen the issue missing bottom labels on the default
window on my old 13in macbook.  I have always assumed (and I could be
wrong) that this had something to do with the actual dimensions of the
screen.  Recently I switched to a 15in macbook pro and I have never
had this problem (and I never observed it when I connected my 13in to
an external display).  I have various incoherent theories about why
this happens, but I will just state my observation: this only happens
on the native screen of a smaller laptop.

Kasper

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

Re: [R-SIG-Mac] install.packages: location of system-wide library tree

[Kasper Daniel Hansen]

.Library.site becomes not empty when you create a site library, for example by
  mkdir  {PATH to R}/R/lib64/site-library
(of course lib64 assumes a 64 bit architecture)

Kasper

On Wed, May 25, 2011 at 6:51 AM, Sean Davis sdav...@mail.nih.gov wrote:
 See help(.Library).

 Sean

 On Wed, May 25, 2011 at 6:35 AM, jochen laubrock
 jochen.laubr...@gmail.com wrote:
 Dear expeRts,

 On (my?) macs, .libPaths() contains two entries, with the first pointing to 
 a user's library tree and the second to the system-wide library tree, as in

 ## begin code
 v - getRversion()
 userLib - Sys.glob(sprintf(~/Library/R/%s.%s/library, v$major, v$minor))
 systemLib - 
 sprintf(/Library/Frameworks/R.framework/Versions/%s.%s/Resources/library, 
 v$major, v$minor)
 userLib == .libPaths()[1]
 systemLib == .libPaths()[2]
 # both return TRUE (on my system)
 ## end code

 When installing new packages, I would like to make them available to all 
 users. However, the 'lib' parameter of 'install.packages' defaults to the 
 first element of '.libPaths()'. How do I reliably specify the location of 
 the system library: Is it always equal to '.libPaths()[-1]'? And why is 
 '.Library.site' empty?

 Jochen


 sessionInfo()
 R version 2.13.0 (2011-04-13)
 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

 
 Jochen Laubrock, Dept. of Psychology, University of Potsdam,
 Karl-Liebknecht-Strasse 24-25, 14476 Potsdam, Germany
 phone: +49-331-977-2346, fax: +49-331-977-2793

 ___
 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] Where are my packages?

[Kasper Daniel Hansen]

You can have packages two places
  (1) system wide
  (2) user specific
The packages that ship with R always install system wide which is why
- when you look in your user specific packages - you don't see any.

You need to reinstall the packages for 2.13.  You cannot just copy the
directories.  You can use the directory to figure out which packages
you did install.

Kasper

On Thu, May 19, 2011 at 2:48 PM, Wayne Gray gr...@rpi.edu wrote:
 I just upgraded to 2.13 from 2.12.

 As far as I can figure things are working well except that none of the 
 packages I downloaded for 2.12 are available to 2.13. That would not be an 
 issue as it is easy to download packages as needed. I can do this and they 
 work.

 What is the issue is that I don't know where they are being stored. The ones 
 for 2.12 are here:

 /Users/wgray/Library/R/2.12/library

 2.13 created a similar directory but there is nothing in it.

 In the Preferences for 2.13 I do have the box checked to make  ~/Library/R... 
 the default path (as per the screen shot attached to this email but probably 
 stripped out by the listserv software). And, yes, I have restarted my machine 
 several times since this was checked (I think I set this two days ago).

 So stuff is somewheres as the package install when I load them. I would like 
 to know (a) where they are, (b) how I can get them to go into the 
 ~/Library/R... directory, and (c) whether it is prudent and reasonable to 
 move everything that is in the 2.12 library into the 2.13 library.

 Thanks



 ___
 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] problem checking packages with R 2.13.0

[Kasper Daniel Hansen]

On Sun, Apr 17, 2011 at 7:16 PM, John Fox j...@mcmaster.ca wrote:
 Dear Kaspar,

 -Original Message-
 From: Kasper Daniel Hansen [mailto:kasperdanielhan...@gmail.com]
 Sent: April-17-11 5:59 PM
 To: John Fox
 Cc: Prof Brian Ripley; r-sig-mac@r-project.org
 Subject: Re: [R-SIG-Mac] problem checking packages with R 2.13.0

 John,

 I don't know about Eclipse, but on a Mac it is completely standard that a
 GUI does not inherit anything from .bashrc/.profile.  So it is pretty
 standard that you may have problems with environment variables.
  You can do two things
   (1) use environment.plist (google it)
   (2) use Sys.setenv() inside your .Rprofile

 That helps a bit. That is, I didn't previously have a .Rprofile file, so I
 put one in my home directory, setting the PATH to
 /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin. Now
 both R CMD check in a terminal window and checking inside eclipse fail with
 the same error, !pdfTeX error: pdflatex (file 8r.enc): cannot open encoding
 file (etc.), rather than with different errors. So, at this point, I don't
 think that finding pdflatex is the issue.


 Now, regarding latex, the standard on Mac would be to run MacTex.  I am
 unaware of how R.app deals with MacTex but I would be ready to guess that
 the PATH might be semi-build in (I am sure some of the R.app people will
 correct me on this).  So you might want to add info about what tex
 distribution you are using.

 Good point. I used the MacTeX-2010 distribution, which I got to from item
 2.1 in the R for Mac OS X FAQ.

 Thanks for trying to

Since this is a new Mac, what file system are you using?  I have no
idea on how to troubleshoot your error, but I guess that info about
the file system might help more knowledgeable people.

Or could this be e problem with the encoding of (one of) the help
files in the package?

Kasper





 On Sun, Apr 17, 2011 at 4:21 PM, John Fox j...@mcmaster.ca wrote:
  Dear Brian and others,
 
  Yes, I installed the CRAN build of R, and yes, something is changing
  the path in R.app, and in eclipse, but not apparently when R is run in
  a terminal window.
 
  From a terminal window:
 
  - snip --
 
  John-Foxs-MacBook-Pro:Rmpi jfox$ R
 
  R version 2.13.0 (2011-04-13)
  Copyright (C) 2011 The R Foundation for Statistical Computing ISBN
  3-900051-07-0
  Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
 
  . . .
 
  Sys.getenv(PATH)
  [1]
 /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin
 
  - snip --
 
  In R.app (and in R64.app):
 
  - snip --
 
  R version 2.13.0 (2011-04-13)
  Copyright (C) 2011 The R Foundation for Statistical Computing ISBN
  3-900051-07-0
  Platform: i386-apple-darwin9.8.0/i386 (32-bit)
 
  . . .
 
  [R.app GUI 1.40 (5751) i386-apple-darwin9.8.0]
 
  [History restored from /Users/jfox/.Rapp.history]
 
  Sys.getenv(PATH)
  [1] /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
 
  - snip --
 
  And in eclipse:
 
  - snip --
 
  R version 2.13.0 (2011-04-13)
  Copyright (C) 2011 The R Foundation for Statistical Computing ISBN
  3-900051-07-0
  Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
 
  . . .
 
  Sys.getenv(PATH)
  [1]
  /Library/Frameworks/R.framework/Versions/2.13/Resources/bin:/usr/bin:
  /bin:/
  usr/sbin:/sbin
 
  - snip --
 
  I've had no luck, however, figuring out what's changing the path: As
  far as I can tell, I have no Rprofile.site file, no .Rprofile file,
  and the R_PROFILE and R_PROFILE_USER environment variables are unset.
  In fact the only R initialization files that I could find anywhere on
  my system are the Rprofile files in the base and Rmpi packages; as far
  as I can see, the former can't shorten the path and I'm not using the
 latter.
 
  Finally, looking more closely at the errors I'm getting when I try to
  check a package, the errors in a terminal window and from eclipse look
 different:
 
  From a terminal window, I think that pdflatex is actually found; to
  repeat
  the error message:
 
  - snip --
 
  * checking PDF version of manual ... WARNING LaTeX errors when
  creating PDF version.
  This typically indicates Rd problems.
  LaTeX errors found:
  !pdfTeX error: pdflatex (file 8r.enc): cannot open encoding file for
  reading == Fatal error occurred, no output PDF file produced!
  * checking PDF version of manual without hyperrefs or index ... ERROR
 
  - snip --
 
  From eclipse, pdflatex clearly isn't found:
 
  - snip --
 
  * checking PDF version of manual ... WARNING LaTeX errors when
  creating PDF version.
  This typically indicates Rd problems.
  * checking PDF version of manual without hyperrefs or index ... ERROR
  Re-running with no redirection of stdout/stderr.
  Hmm ... looks like a package
  You may want to clean up by 'rm -rf
  /var/folders/ay/ayD

Re: [R-SIG-Mac] plot() does not give labels under quartz

[Kasper Daniel Hansen]

This _may_ be unrelated to a corrupt font cache.  Note that the OP
says the issue is fixed by resizing the quartz screen.

To see this in action (explanation below) I have posted
  http://www.biostat.jhsph.edu/~khansen/screen1.png
(the initial look of the quartz window)
  http://www.biostat.jhsph.edu/~khansen/screen2.png
(after resize)

I have always had a (somewhat) similar experience: the first quartz
window does not show the entire plotting area.  If one looks closely
(in my case) you can see the top of the xlab in the plotting window,
but there are no scroll bars indicating that the plot is bigger than
the screen estate, despite the fact that the little icon in the lower
left corner indicates that this is really the lower left corner (I am
referring to the resize triangle - no idea what the technical term
is).

When I click the green button (maximize) twice I now get a window
where I can see everything (screen2).

I have also assumed that this is because the default size of the
quartz device was bigger my laptop's screen (physical size, I am on a
Macbook right now).  This is not an issue on an external monitor.
Specifically I have assumed that the window manager has problems
initializing a window that is physically bigger than the  screen (note
that I say initializing - of course the window can be bigger than the
physical screen if I resize it to be so...).  This is pure
speculation, I have no basis for these claims.  I have always assumed
that this was a problem with Apple's SDK and not R.  And while I have
the issue I have always felt it was not worth spending time fixing (if
it is even fixable by someone else than Apple).

Now, the OP can see even less than I can.  Perhaps she is using a new
Macbook Air with even less vertical physical size?  Please respond to
this Tena.

Finally, this was using R-2.12.1, compiled by myself, running from the
terminal but using the quartz device.

Kasper


On Wed, Jan 19, 2011 at 6:22 AM, Prof Brian Ripley
rip...@stats.ox.ac.uk wrote:
 Missing labels has been reported several times, and AFAIK has always
 indicated a corrupt font cache (or other problems in the font book). There
 are various ways to repair that, so I'll leave you to Google for one.

 On Wed, 19 Jan 2011, Phillip Jardine wrote:

 Tena,

 I had the same problem myself a few months ago, when I upgraded to OS X
 10.6.5 (from OS X 10.4) I don't know why this happened, but by trial and
 error I found that putting family = sans into the plot command brought
 back the labels.

 Bizarrely though things recently started working normally again, with no
 updates/upgrades on my part. Strange, eh?

 Anyway, try the family = sans thing, it might help.

 Best wishes,

 Phil
 --
 Phil Jardine
 Geosystems Research Group
 School of Geography, Earth, and Environmental Sciences
 University of Birmingham
 Edgbaston
 Birmingham
 B15 2TT

 pej...@bham.ac.uk
 Tel. 0121 414 6146
 http://www.gees.bham.ac.uk/staff/pgpej083.shtml
 
 From: r-sig-mac-boun...@r-project.org [r-sig-mac-boun...@r-project.org] On
 Behalf Of Tena Sakai [tsa...@gallo.ucsf.edu]
 Sent: 19 January 2011 04:29
 To: r-sig-mac@r-project.org
 Subject: [R-SIG-Mac] plot() does not give labels under quarts.

 Greetings,

 I have noticed a bit odd behavior of plot() on OS X 10.6.5.
 The R I downloaded from cran is R-2.12.1.pkg.  Below is
 what I did:

       R version 2.12.1 (2010-12-16)
              .
              .
       [R.app GUI 1.35 (5665) x86_64-apple-darwin9.8.0]

        foo - c( 4, 6, 9 ,12 )
        moo - c( 34, 37, 41, 49 )
        plot( foo ~ moo )

 This gives me a plot with no labels.  No moo, foo, or numbers under
 tics.  But,

        X11()
        plot( foo ~ moo )

 This gives me xlabel (moo), ylabel (foo), and numbers under tics.
 In the first case, by default, I am using quartz, while the second,
 obviously, I am using X11.

 Does anybody know why this happens under quartz and not under X11?

 Thank you.

 Tena Sakai
 tsa...@gallo.ucsf.edu

 --
 Brian D. Ripley,                  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford,             Tel:  +44 1865 272861 (self)
 1 South Parks Road,                     +44 1865 272866 (PA)
 Oxford OX1 3TG, UK                Fax:  +44 1865 272595

 ___
 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