Opened 3 years ago

Closed 3 years ago

Last modified 22 months ago

#26596 closed enhancement (fixed)

Replace expect r interface with rpy2

Reported by: gh-timokau Owned by:
Priority: major Milestone: sage-8.5
Component: packages: standard Keywords:
Cc: fbissey, jdmeyer, embray Merged in:
Authors: Timo Kaufmann Reviewers: François Bissey
Report Upstream: N/A Work issues:
Branch: 513cea9 (Commits, GitHub, GitLab) Commit:
Dependencies: Stopgaps:

Status badges

Description

Using rpy2 instead of manually interacting with the r repl gives us many benefits, the biggest of which is that we don't have to maintain the details of the interface ourselves. This should solve the dputs issue in #25674 and make sage compatible with r 3.4.x as well as 3.5.x (not actually tested yet).

The interface currently still inherits from the Expect interface since untangling that seems non-trivial. It is a bit awkward to force rpy2's output into the output sage expects. That output also isn't documented (it seems like its basically "whatever dput gave us"). I've implemented conversions so that the doctests pass, but there are likely differences between the presentation of r objects that are not covered by the doctesting framework.

Change History (59)

comment:1 Changed 3 years ago by gh-timokau

  • Branch changed from u/gh-timokau/r-3.5.1 to u/gh-timokau/r-rpy2
  • Commit changed from db4d8bb7795a9014421d98585c7bd7d72cb5e964 to 747360e2fe28d4e80fbf592b7852a9ee16fb920a

New commits:

747360eReplace expect r interface with rpy

comment:2 Changed 3 years ago by git

  • Commit changed from 747360e2fe28d4e80fbf592b7852a9ee16fb920a to b1daa1744a394fb9021d4b077b6c53d3cf901010

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

b1daa17Replace expect r interface with rpy

comment:3 Changed 3 years ago by fbissey

  • Cc fbissey added

comment:4 Changed 3 years ago by git

  • Commit changed from b1daa1744a394fb9021d4b077b6c53d3cf901010 to afb49e3968eec0f3da5d5abb9d001e6ab706417c

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

afb49e3Replace expect r interface with rpy

comment:5 Changed 3 years ago by gh-timokau

All doctests pass now except a Bad exit: 1 in sage/combinat/tableau.py that I can only reproduce when running the whole testsuite. I have no clue what may be causing this. As far as I can see, tableau.py doesn't use r in any way.

Immediately before the exit the following tests (which are simply the last ones in the file) were run:

sage: [ T for T in IncreasingTableaux(3, (1,0,1)) ] ## line 9285 ##
[[[1, 3], [3]]]
sage: [ T for T in IncreasingTableaux(4, (1,0,1,1)) ] ## line 9287 ##
[[[1, 3, 4], [3]],
 [[1, 3, 4], [4]],
 [[1, 3], [3, 4]],
 [[1, 3], [3], [4]],
 [[1, 4], [3], [4]]]
sage: IT = IncreasingTableaux(4, (1,0,1,1)) ## line 9293 ##
sage: IT[0].parent() is IT ## line 9294 ##
True
sage: sig_on_count() # check sig_on/off pairings (virtual doctest) ## line 9296 ##
0
sage: IT = IncreasingTableaux(4, (1,0,1,1)) ## line 9306 ##
sage: all(it in IT for it in IT) ## line 9307 ##
True
sage: all(it in IT for it in IncreasingTableaux([2,2], (1,0,1,1))) ## line 9309 ##
True
sage: sig_on_count() # check sig_on/off pairings (virtual doctest) ## line 9311 ##
0

New commits:

afb49e3Replace expect r interface with rpy

comment:6 Changed 3 years ago by git

  • Commit changed from afb49e3968eec0f3da5d5abb9d001e6ab706417c to f9617433187c81aaf324060b61660b06f8a6b3f1

Branch pushed to git repo; I updated commit sha1. New commits:

d3001aaRemove leftover bits of the r expect interface
8ce6788Move r to sage converter setup to a function
08590bcUse lower level rpy2 interface
f961743Add a bunch of tests for the R to sage conversion

comment:7 Changed 3 years ago by gh-timokau

I'm reasonably sure that this matches the old api now, I've compared the output of the available examples. Everything passes except the previously mentioned tableau.py. No idea about that.

I would appreciate help debugging this and maybe some manual testing of the interface.

comment:8 Changed 3 years ago by gh-timokau

  • Cc jdmeyer embray added

Okay I've figured out the tableau.py failure. It does reproduce when run individually after all, I just forgot to add the --long flag. Turns out it is caused by the rpy2 imports taking up some memory. The test passes when using --memlimit 3302 (2 megabytes over the default limit). Before my changes, it started failing with 3238 or less. So that's a 63MB increase.

Any suggestions what to do about this? When and how are lazy imports used? I think tableau.py doesn't actually use r.py in any way.

Also we should improve error handling in case the memlimit is overstepped. Debugging this was not fun.

comment:9 Changed 3 years ago by git

  • Commit changed from f9617433187c81aaf324060b61660b06f8a6b3f1 to 7ffc3441486e99f412aeff4640e7656ea971f241

Branch pushed to git repo; I updated commit sha1. New commits:

7ffc344Improve R to sage conversion documentation

comment:10 Changed 3 years ago by fbissey

Sorry for not making a better contribution to this thread but can you fix the English in the last commit

+    Simple numeric values are represented as vecotrs in R. So `1` would actually
+    be an array of length 1. We convert all vectory of length 1 to simple values,
+    weather or not they "originally" were simple values or not:
  • line 1: vecotrs -> vectors
  • line 2: vectory -> vectors
  • line 3: weather -> whether
Last edited 3 years ago by fbissey (previous) (diff)

comment:11 Changed 3 years ago by fbissey

Further from earlier commits

+    Set up a the converter used to convert from rpy2's
+    representation of R objects to the one sage expects.

Set up a converter to go from rpy2's representation of R objects to the one sage expects.

+            # if not names are present, convert to a normal list or a single value

If no names are present...

comment:12 Changed 3 years ago by git

  • Commit changed from 7ffc3441486e99f412aeff4640e7656ea971f241 to 813df6a573c11e7ae96699dee117449ebc379054

Branch pushed to git repo; I updated commit sha1. New commits:

813df6aFix typos in r interface

comment:13 Changed 3 years ago by gh-timokau

Thanks for taking a look at it!

comment:14 Changed 3 years ago by git

  • Commit changed from 813df6a573c11e7ae96699dee117449ebc379054 to 46a550546c9c2f84f7118f615a293ce217f3c3d1

Branch pushed to git repo; I updated commit sha1. New commits:

46a5505Cleanup the rpy2 r interface

comment:15 Changed 3 years ago by gh-timokau

I did some digging into the difference in precision. The difference is:

r('3 * 5.6').sage() # old interface
16.8
r('3 * 5.6').sage() # new interface
16.799999999999997
r('1/10.4').sage() # old interface
0.09615384615384615
r('1/10.4').sage() # new interface
0.0961538461538461

The first case seems problematic, but doesn't appear to occur very often. The reason for this is that dput by default does some magic formatting. The precise internal value we get with the new interface (probably because rpy2 directly uses the c interface) is equivalent to setting the digits17 option[0] in dput. I did some digging into R's source code to see what it does when digits17 is not set. Confusingly, in the C code that actually implements dput, the option is now called DIGITS16[1] (probably legacy reasons). If that is not set, it calls some EncodeElement which in turn[2] calls formatReal. I didn't find the source code for that.

So in conclusion since this is not a clear regression (more precision, sometimes genuine precision and sometimes rounding glitches) and I don't see an easy way to change it I think it is fine as-is.

[0] https://rdrr.io/r/base/deparseOpts.html [1] https://github.com/wch/r-source/blob/trunk/src/main/deparse.c#L1743 [2] https://github.com/wch/r-source/blob/trunk/src/main/printutils.c#L805

comment:16 Changed 3 years ago by git

  • Commit changed from 46a550546c9c2f84f7118f615a293ce217f3c3d1 to 647157591b1ede9d0ecdd9eead1c66d4d11f9dcf

Branch pushed to git repo; I updated commit sha1. New commits:

d979fdfEnable R error handling
6471575Remove lazy R initialization

comment:17 Changed 3 years ago by gh-timokau

Erik, since you relatively recently did #25907 do you have an idea about the memory issue described here?

Other than that, I'm now happy with this. I'll post an overview of the changes when 8 is resolved.

comment:18 follow-up: Changed 3 years ago by embray

I can't imagine why merely importing rpy2 would cause such a large memory allocation. That does not seem right. Are you sure there isn't something more to it?

comment:19 Changed 3 years ago by embray

Relatedly, I don't know why you made this change:

  • src/sage/doctest/test.py

    diff --git a/src/sage/doctest/test.py b/src/sage/doctest/test.py
    index 2f4f74c..c6c1bf9 100644
    a b Test ``atexit`` support in the doctesting framework:: 
    500500    ....:     pass
    501501
    502502Test the ``--memlimit`` option and ``# optional - memlimit``
    503 (but only on Linux)::
     503(but only on Linux). If this test fails, the memory needed to
     504run it may have increased. Try increasing the limit. ::
    504505
    505506    sage: from platform import system
    506507    sage: ok = True
    507508    sage: if system() == "Linux":
    508     ....:     P = subprocess.Popen(["sage", "-t", "--warn-long", "0", "--memlimit=2000", "memlimit.rst"], stdout=subprocess.PIPE, **kwds)
     509    ....:     P = subprocess.Popen(["sage", "-t", "--warn-long", "0", "--memlimit=2100", "memlimit.rst"], stdout=subprocess.PIPE, **kwds)
    509510    ....:     out, err = P.communicate()
    510511    ....:     ok = ("MemoryError: failed to allocate" in out)
    511512    sage: ok or out
Last edited 3 years ago by embray (previous) (diff)

comment:20 in reply to: ↑ 18 Changed 3 years ago by gh-timokau

Replying to embray:

I can't imagine why merely importing rpy2 would cause such a large memory allocation. That does not seem right. Are you sure there isn't something more to it?

Pretty sure. I removed all the changes except the import statements and it still failed.

Another change is that R is now always initialized (by setting its options) at startup (when r = R()) is assigned. I temporarily implemented some lazy initialization to try to work around it, but that didn't fix it either.

The other change is for the same reason, more memory required and the 2G limit is pretty tight.

comment:21 Changed 3 years ago by gh-timokau

When testing this on-distro with R 3.5 I encountered an interesting error:

matrix(CDF, 0, 0).is_unitary(algorithm="orthonormal")

would segfault with RRuntimeWarning: Error: BLAS/LAPACK routine 'ZGEES ' gave error code -6. The from rpy2 import robjects line is the "cause" for this. That only happened when running the testsuite on-distro, not on sage-the-distro. However I reduced it to this:

from rpy2 import robjects; import scipy.linalg; import numpy as np; scipy.linalg.schur(np.empty(shape=[0,0]))

Which will segfault sage-the-distro (or just ./sage -python as well. I'll try it with the latest openblas master. Wondering how the rpy import may cause this. Maybe it always segfaults and rpy somehow hijacks error handling or something?

comment:22 Changed 3 years ago by gh-timokau

Segfaults on archlinux with python2 or python3 as well.

comment:23 Changed 3 years ago by fbissey

I don't have the segfault (although I haven't tested the ticket yet) but we had an interesting discussion about a failing doctest that is extremely similar. https://github.com/cschwan/sage-on-gentoo/commit/1a5fefec74c222ee5d0673bb439c6d5a3b0c6e1e#commitcomment-30999803

tl;dr

There is a subtle difference of behavior in xerblas as shipped by openblas (as a part of blas) and netlib's lapack function of the same name (shipped as part of lapack). If you ship an integrated openblas with lapack included you get the base blas function from openblas (that's the one vanilla sage sees). If you have a separate lapack based on netlib you get to load netlib's xerblas first. You may find that if you preload openblas first the problem may go away.

comment:24 follow-up: Changed 3 years ago by gh-timokau

Thank you! Saved me a lot of time. LD_PRELOAD'ing openblas does fix the segfault. I have no idea what blas library it is picking up instead though. Shouldn't be anything available except linbox maybe. strace shows access to the same so files (with blas or lapack in their name) before and after adding rpy. linbox doesn't seem to be used.

You're not getting the segfault in plain python either?

comment:25 Changed 3 years ago by gh-timokau

With LD_PRELOAD and a slightly increased --memlimit for tests, all doctests pass with R 3.5 as well as 3.4.

comment:26 in reply to: ↑ 24 ; follow-up: Changed 3 years ago by fbissey

Replying to gh-timokau:

Thank you! Saved me a lot of time. LD_PRELOAD'ing openblas does fix the segfault. I have no idea what blas library it is picking up instead though. Shouldn't be anything available except linbox maybe. strace shows access to the same so files (with blas or lapack in their name) before and after adding rpy. linbox doesn't seem to be used.

You're not getting the segfault in plain python either?

On your distro I am guessing you have distinct libraries for blas and lapack - vanilla sage just has a combined blas/cblas/lapack in a single library. The issue here is that both your blas and lapack libraries have a xerbla_ symbol. If lapack is loaded first (and where you use lapack it usually will be) you'll use lapack version.

So here there is a subtle difference of behavior between xerbla implemented by openblas and netlib. And honestly I don't know which one is actually buggy or which one is not conforming. Netlib is supposed to be the reference but it is the one leading to a crash.

comment:27 follow-up: Changed 3 years ago by fbissey

As for crash with plain python

Python 2.7.15 (default, Sep 13 2018, 20:02:33) 
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> import scipy.linalg
>>> scipy.linalg.schur(np.empty(shape=[0,0]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/scipy/linalg/decomp_schur.py", line 139, in schur
    result = gees(lambda x: None, a1, lwork=-1)
ValueError: On entry to DGEES parameter number 6 had an illegal value

In the case of the crash you reproduce with "sage-the-distro" it would be interesting to check which blas/lapack R is linked too. If R is external you may have loaded blas/lapack external to sage-the-distro.

comment:28 in reply to: ↑ 26 Changed 3 years ago by gh-timokau

Replying to fbissey:

Replying to gh-timokau:

Thank you! Saved me a lot of time. LD_PRELOAD'ing openblas does fix the segfault. I have no idea what blas library it is picking up instead though. Shouldn't be anything available except linbox maybe. strace shows access to the same so files (with blas or lapack in their name) before and after adding rpy. linbox doesn't seem to be used.

You're not getting the segfault in plain python either?

On your distro I am guessing you have distinct libraries for blas and lapack - vanilla sage just has a combined blas/cblas/lapack in a single library. The issue here is that both your blas and lapack libraries have a xerbla_ symbol. If lapack is loaded first (and where you use lapack it usually will be) you'll use lapack version.

No my distro uses openblas as lapack and blas. I've reported this upstream (scipy, rpy2. In the rpy2 ticket there are some library traces, showing that only openblas is used on nixos. ArchLinux? uses different libraries but the crash still occurs.

comment:29 in reply to: ↑ 27 Changed 3 years ago by gh-timokau

Replying to fbissey:

As for crash with plain python

Python 2.7.15 (default, Sep 13 2018, 20:02:33) 
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> import scipy.linalg
>>> scipy.linalg.schur(np.empty(shape=[0,0]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/scipy/linalg/decomp_schur.py", line 139, in schur
    result = gees(lambda x: None, a1, lwork=-1)
ValueError: On entry to DGEES parameter number 6 had an illegal value

In the case of the crash you reproduce with "sage-the-distro" it would be interesting to check which blas/lapack R is linked too. If R is external you may have loaded blas/lapack external to sage-the-distro.

I get the same if I do that, but what happens if you do import rpy2.robjects first?

comment:30 Changed 3 years ago by fbissey

sage's python and then system python

fbissey@moonloop ~/sandbox/git-fork/sage $ ./sage -python
Python 2.7.15 (default, Oct 30 2018, 11:04:09) 
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from rpy2 import robjects; import scipy.linalg; import numpy as np; scipy.linalg.schur(np.empty(shape=[0,0]))
/home/fbissey/sandbox/git-fork/sage/local/lib/python2.7/site-packages/rpy2/rinterface/__init__.py:185: RRuntimeWarning: Error: BLAS/LAPACK routine 'DGEES ' gave error code -6

  warnings.warn(x, RRuntimeWarning)
/home/fbissey/sandbox/git-fork/sage/local/lib/python2.7/site-packages/rpy2/rinterface/__init__.py:185: RRuntimeWarning: Fatal error: unable to initialize the JIT


  warnings.warn(x, RRuntimeWarning)
Segmentation fault (core dumped)
fbissey@moonloop ~/sandbox/git-fork/sage $ python
Python 2.7.15 (default, Sep 13 2018, 20:02:33) 
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from rpy2 import robjects; import scipy.linalg; import numpy as np; scipy.linalg.schur(np.empty(shape=[0,0]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/scipy/linalg/decomp_schur.py", line 139, in schur
    result = gees(lambda x: None, a1, lwork=-1)
ValueError: On entry to DGEES parameter number 6 had an illegal value

comment:31 Changed 3 years ago by gh-timokau

So you do get it with sage-the-distribution. Very interesting that you don't get it with system python, at least that shows that its not a fundamental r/rpy problem but somehow has to do with the setup. What blas/lapack libs are used there?

comment:32 Changed 3 years ago by fbissey

On the system openblas-0.3.3 for blas/cblas + netlib lapack 3.8.0 as a separate library. Standard openblas-0.2.20.p2 spkg for sage-the-distro.

comment:33 Changed 3 years ago by embray

I would still like to investigate this, but right now I'm working on the GAP 4.10 integration which I believe has higher priority.

comment:34 Changed 3 years ago by gh-timokau

Alright. To be clear the segfault is only marginally related (somehow doesn't even happen during the sage-the-distro doctests although the minimal example does reproduce on sage-the-distro python). I think the RAM increase is just because R is now initialized at startup while it was initialized lazily before. 60MB doesn't seem that much. To avoid that, we'd need to lazily import rpy2 on first use but that would be a bit error prone.

By the way if gap 4.10 is a priority because of the debian freeze, this would probably be one too. I'm guessing they're using R 3.5, so R integration on debian should (still guessing here) be broken right now.

comment:35 Changed 3 years ago by gh-timokau

Discussion about the segfault is mostly going on on the rpy2 issue tracker on bitbucket.

comment:36 Changed 3 years ago by git

  • Commit changed from 647157591b1ede9d0ecdd9eead1c66d4d11f9dcf to 8a27cc83d5722ed207a190da244aabbe77fbd1e0

Branch pushed to git repo; I updated commit sha1. New commits:

8a27cc8Initialize the rpy2 R interface lazily

comment:37 Changed 3 years ago by gh-timokau

  • Status changed from new to needs_review

I implemented some lazyness (as it was effectively done in the old expect interface). This solves the memory issues and also "fixes" the import order issue as long as one assumes that some blas library will always be used/imported somehow before r is used. That assumption is probably not unreasonable.

All doctests pass in sage-the-distro as well as on-distro. This is ready for review. I hope we can get this in by the 2018-12-01 deadline so that distros can finally use sage with a recent R.

comment:38 Changed 3 years ago by gh-timokau

Some notes on the differences:

  • slight difference in precision in some cases (see 15)
  • r('NA').sage() will now actually return NA (of type rpy2.rinterface.NALogicalType) as opposed to None (which it did before)
  • r('NaN').sage() will now return nan, while it threw a NameError before
  • same thing with Inf: name error before, correct behaviour now
  • same thing with imaginary numbers: parsing error before, correct behaviour now
  • errors were ignored before (because some faulty pattern matching) and are actually handled now
    • that led to the discovery and fix of a bug: is_string was not overriden in RElement. Because of that dumping strings didn't work properly. See commit d979fdf70da0476b648d2f703fa7bf00cb9e3d03 for details.

So this brings bugfixes, compatibility to R 3.4 *and* R 3.5 and less maintenance burdon.

comment:39 Changed 3 years ago by fbissey

The patchbot report some strange errors but that one seems relevant to this ticket

sage -t --long src/sage/interfaces/r.py
**********************************************************************
File "src/sage/interfaces/r.py", line 1428, in sage.interfaces.r.RElement.tilde
Failed example:
    d['DATA']['coefficients']['DATA'][1]
Expected:
    2
Got:
    2.0000000000000004

Can you double check?

comment:40 Changed 3 years ago by gh-timokau

I cannot reproduce that locally, but that is probably a result of the precision difference described in 15. Basically R gives us its exact results and their precision is probably a bit platform dependent. Not sure how best to deal with this. Add # abs tol in a lot of places? Introduce some rounding?

comment:41 Changed 3 years ago by gh-timokau

  • Status changed from needs_review to needs_work

comment:42 Changed 3 years ago by fbissey

For that particular one I would go with # abs tol but I wouldn't only put it in in actual reported case or where you have prior knowledge it could happen. Bots are there to find that kind of stuff.

comment:43 Changed 3 years ago by git

  • Commit changed from 8a27cc83d5722ed207a190da244aabbe77fbd1e0 to 513cea95d31e656b47c7857f6dbe3c6d8c87c6c1

Branch pushed to git repo; I updated commit sha1. New commits:

513cea9Limit R result precision to 15 significant places

comment:44 Changed 3 years ago by gh-timokau

  • Status changed from needs_work to needs_review

I looked into dputs behaviour again. Turns out it actually doesn't do anything smart by default. It just rounds the number to 15 significant places. Not sure why I thought it did something smarter than that.

So I've just implemented that. This was the old behaviour. It should smooth out platform-dependent differences. Now all the tested parts of the interface should behave exactly as before (except those that were buggy before).

comment:45 Changed 3 years ago by gh-timokau

Patchbot says All tests passed!! There are some pyflakes warnings, but not all of them are actually related to this ticket and those that are have to do with pyflakes apparently being confused by lazy_import.

comment:46 Changed 3 years ago by fbissey

  • Reviewers set to François Bissey
  • Status changed from needs_review to positive_review

If the patchbot is happy, I am happy.

comment:47 Changed 3 years ago by gh-timokau

  • Reviewers François Bissey deleted

Great, thanks! I have rebased this patch on 8.4 for distro maintainers that need compatibility with R 3.5: https://gist.github.com/timokau/144262860a5d777fa1700d25344fc5f2

comment:48 Changed 3 years ago by gh-timokau

  • Reviewers set to François Bissey

comment:49 Changed 3 years ago by vbraun

  • Branch changed from u/gh-timokau/r-rpy2 to 513cea95d31e656b47c7857f6dbe3c6d8c87c6c1
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:50 Changed 3 years ago by embray

  • Commit 513cea95d31e656b47c7857f6dbe3c6d8c87c6c1 deleted

I still need to play around with this a bit more, but if I find any issues I'll add them in follow-ups. This is already much, much better though +1

comment:51 Changed 3 years ago by gh-timokau

Thanks :) I just successfully built and tested 8.5.beta5 with R 3.5.

comment:52 Changed 3 years ago by dimpase

what is required from an installation of R do be used in Sage? executables+headers? something else?

comment:53 Changed 3 years ago by gh-timokau

I guess so, but I'm not sure. Why are you asking?

comment:54 Changed 3 years ago by dimpase

In order to be able to use system-wide R, as we already do with e.g. patch, gcc - see #26286 for more, we'd need appropriate spkg-configure.m4.

comment:55 Changed 3 years ago by fbissey

Well R is not called directly much. Except by rpy now. It is not linked to by any standard packages that I can see and that includes rpy. So we just need to make sure that the environment that may be set by the system R finds its way in the sage environmnet and that seem to be mainly R_HOME. R also installs some .pc files here and I guess they should be fully visible to pkg-config from the sage-environment - which I hope is already properly set up by default (if something is in the sage environment it should be seen first but system pc should still be discoverable if there isn't a match in the sage environment).

comment:56 Changed 3 years ago by dimpase

Perhaps the 1st step should be to check whether there is a system-wide pkg-config. Then we can just add SAGE_LOCAL to PKG_CONFIG_PATH (or something along these lines), and don't install the Sage's one.

comment:57 follow-up: Changed 3 years ago by embray

Having Sage able to use a system R is definitely on my todo list. The tricky part is that R is packaged a number of different ways on a number of different systems. On most Linuxes it should be straightforward, but on OSX it's more complicated (is there an "official" R / RStudio installer for OSX? Or maybe they're using Homebrew?) And on Windows it's complicated too--there is an R package for Cygwin I would like to be able to use if possible, but again a lot of people may want to integrate with their existing RStudio for Windows and that's again more complicated...

comment:58 in reply to: ↑ 57 Changed 3 years ago by dimpase

Replying to embray:

Having Sage able to use a system R is definitely on my todo list. The tricky part is that R is packaged a number of different ways on a number of different systems. On most Linuxes it should be straightforward, but on OSX it's more complicated (is there an "official" R / RStudio installer for OSX? Or maybe they're using Homebrew?) And on Windows it's complicated too--there is an R package for Cygwin I would like to be able to use if possible, but again a lot of people may want to integrate with their existing RStudio for Windows and that's again more complicated...

From R project website, I gather they are doing a similar to Sage's thing (or even go further, by supplying Clang 6 too) on OSX: supply their own compilers for building from source...

Note: CRAN does not have Mac OS X systems and cannot check these binaries for viruses. Altough we take precautions when assembling binaries, please use the normal precautions with downloaded executables.

Important note: R 3.5.0 El Capitan binaries are using Clang 6.0.0 and GNU Fortran 6.1 to provide OpenMP parallelization support and C++17 standard features. If you want to compile R packages from sources, please download GNU Fortran binary from the official GNU Fortran Binaries page - in particular OS X 10.11 gfortran 6.1. Alternatively, we are providing a copy here as well as Clang 6.0.0 binaries for OS X 10.11 and higher - see below for the download links. You can also try to use clang from Xcode, but it will be missing required features so your mileage may vary and it is not recommended.

comment:59 Changed 22 months ago by dimpase

I'm seeing this segfault now on Arch with R and (open)blas from the system.

Last edited 22 months ago by dimpase (previous) (diff)
Note: See TracTickets for help on using tickets.