Re: [sage-devel] Re: r-3.6.0 unable to download due to a libcurl issue

It works! Thank you so much! On Sat, May 25, 2019 at 6:26 PM darwin doppelganger wrote: > I had the very same problem > . > The libcurl version was plenty new enough (7.6.4), but still somehow failed > to be >= 7.22. After un

[sage-devel] Re: r-3.6.0 unable to download due to a libcurl issue

I had the very same problem . The libcurl version was plenty new enough (7.6.4), but still somehow failed to be >= 7.22. After uninstalling anaconda, everything worked just fine. I can't remember exactly how I removed anacon

Re: [sage-devel] Re: r-3.6.0 unable to download due to a libcurl issue

Do you know how I would fully get rid of Anaconda? I deleted it from my computer but the download still does not seem to work. On Sat, May 25, 2019 at 3:54 PM Volker Braun wrote: > Its picking up /anaconda3/bin/curl-config and that one is too old. Either > update or move it out of the way to bu

[sage-devel] Re: r-3.6.0 unable to download due to a libcurl issue

Its picking up /anaconda3/bin/curl-config and that one is too old. Either update or move it out of the way to build R On Saturday, May 25, 2019 at 9:26:46 PM UTC+2, Anna Chlopecki wrote: > > I am running into an issue with r-3.6.0 not being able to download due to > a libcurl issue. My libcurl i

[sage-devel] Re: R fails to compile

Hi, A bit more clarification. I upgraded to 7.5.1 using sage --upgrade. There is a copy of libiconv in /usr/local/lib and one that the Mac OS installs in /usr/lib. The command "sage -installed" reports that iconv is installed. This is obviously a minor problem, given that no one else has rep

[sage-devel] Re: R fails to compile

Tue 2017-01-17 02:24:54 UTC, Rob Gross: > I tried to upgrade to 7.5.1 on several different Macs which I thought had identical software. > > However, on one of them, R failed to compile, with the error: > > installing 'sysdata.rda' > dyld: Symbol not found: __libiconv_version > Referenced fr

[sage-devel] Re: R fails to compile

It did get built and installed. I even reinstalled with sage -i -f to make sure. libiconv-1.14 is installed on all of the three Macs that I tried to upgrade. On one system, no problem with the upgrade. On the other two, R failed to compile (though everything else is fine). Understanding thi

Re: [sage-devel] Re: R fails to compile

On Wednesday, January 18, 2017 at 7:36:37 PM UTC+1, Emmanuel Charpentier wrote: > > It also used to build pcre, an lzma library and SSL tools. No longer since > 3.3, which is an itch I tried to scratch for 8 months... Hence also my > insistence on the SSL tragicomedy. > No I mean Sage itself!

Re: [sage-devel] Re: R fails to compile

It also used to build pcre, an lzma library and SSL tools. No longer since 3.3, which is an itch I tried to scratch for 8 months... Hence also my insistence on the SSL tragicomedy. -- Emmanuel Charpentier Le 18 janv. 2017 19:32, "Jean-Pierre Flori" a écrit : > Strange, Sage used to optionally

[sage-devel] Re: R fails to compile

Strange, Sage used to optionally build iconv on retarded systems. On Wednesday, January 18, 2017 at 2:22:47 PM UTC+1, Emmanuel Charpentier wrote: > > Forgot to add : ISTR that R has depended on an external iconv for a long > while. I didn't see it would now be mandatory... > > -- > Emmanuel Char

[sage-devel] Re: R fails to compile

Forgot to add : ISTR that R has depended on an external iconv for a long while. I didn't see it would now be mandatory... -- Emmanuel Charpentier Le mercredi 18 janvier 2017 14:15:57 UTC+1, Emmanuel Charpentier a écrit : > > Do you have iconv installed systemwide ? > > Le mardi 17 janvier 2017 0

[sage-devel] Re: R fails to compile

Do you have iconv installed systemwide ? Le mardi 17 janvier 2017 03:24:54 UTC+1, Rob Gross a écrit : > > Hi, > > I tried to upgrade to 7.5.1 on several different Macs which I thought had > identical software. > > However, on one of them, R failed to compile, with the error: > > installing 'sys

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

Dear Jean-Pierre, Le mercredi 2 novembre 2016 11:40:30 UTC+1, Jean-Pierre Flori a écrit : > > I would say we even have a shorter-time solution: close the tickets for > including curl (modulo adding a SAGE_FAT_BINARY mode to avoid overlinking) > ?? What do you mean ? > and updating R (modulo a

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

I would say we even have a shorter-time solution: close the tickets for including curl (modulo adding a SAGE_FAT_BINARY mode to avoid overlinking) and updating R (modulo adding a 6-line patch to not check for https support, note that most of the time https will be supported anyway). On Wednesd

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

So far, the only plan I can propose which is consistent with the various points that have been stated is : I) short-term workaround : add a dependance for Sage, by : a) depending on libcurl and its development files, or b) depending on a systemwide R + its development files II) solve current is

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

Le mardi 1 novembre 2016 15:03:19 UTC+1, Samuel Lelievre a écrit : > > > > Fri 2016-10-28 17:03:26 UTC+2, William: > > >>- Python stats have come a *LONG* way in the last 10 years, with >> libraries like Pandas. Why use rpy2 when you can much more >> effectively use pandas and statsmode

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

Fri 2016-10-28 17:03:26 UTC+2, William: >- Python stats have come a *LONG* way in the last 10 years, with > libraries like Pandas. Why use rpy2 when you can much more > effectively use pandas and statsmodels and so on. > > In my opinion, it would be way, way better to completely remov

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

Dear William, Sorry to have sounded frightened by *you* : I'm frightened by the amount of *my* ignorance... Since it seems that I'm (almost) alone among Sage users to be interested by the development of an interface to R, I'm exploring the options. And I'm trying to understand things I was use

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

On Sun, Oct 30, 2016 at 12:09 PM, Emmanuel Charpentier wrote: > Dear William, > > thanks for this advice, which I'll consider seriously, notwithstanding its > total opacity to me at the moment > > I just checked that the r interface in SMC is indeed different from what > exists in sage "standa

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

Dear William, thanks for this advice, which I'll consider seriously, notwithstanding its total opacity to me at the moment I just checked that the r interface in SMC is indeed different from what exists in sage "standalone". It is also a bit difficult to understand, due to present lack of

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier wrote: > OK. It seems that a clear consensus exists for the excision of R _proprio > dictu_ from Sage. > > If we break it, can we at least keep the (Sage's) pieces ? An optional > package offering the current R interface(s) depending on a syst

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

OK. It seems that a clear consensus exists for the excision of R _proprio dictu_ from Sage. If we break it, can we at least keep the (Sage's) pieces ? An optional package offering the current R interface(s) depending on a systemwide(at least user-reachable) version of R and the R library might

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

On Friday, October 28, 2016 at 5:24:35 PM UTC, William wrote: > > On Fri, Oct 28, 2016 at 9:38 AM, Dima Pasechnik > wrote: > > > > > > On Friday, October 28, 2016 at 3:03:26 PM UTC, William wrote: > >> > >> Hi, > >> > >> Regarding the openssl dependency issue, the standard way people > >

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

> > It's ridiculous that we spend no effort on pandas/statsmodels, and all > this > effort on R. +1 > For example, I recall that there are some issues involving pandas + > statsmodels + the sage preparser. > I use Pandas in the default Sage Interpreter on a daily basis and have only

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

On Friday, October 28, 2016 at 8:03:26 AM UTC-7, William wrote: > > we should **completely and totally remove R > from Sage**. > We could also demote the R package to "optional" or "experimental" status. I'd support that. -- You received this message because you are subscribed to the Google

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

On Fri, Oct 28, 2016 at 9:38 AM, Dima Pasechnik wrote: > > > On Friday, October 28, 2016 at 3:03:26 PM UTC, William wrote: >> >> Hi, >> >> Regarding the openssl dependency issue, the standard way people >> justify getting around it is the "system library exemption", which >> allows for GPL'd progr

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

On Friday, October 28, 2016 at 3:03:26 PM UTC, William wrote: > > Hi, > > Regarding the openssl dependency issue, the standard way people > justify getting around it is the "system library exemption", which > allows for GPL'd programs to link in system libraries that are not > GPL'd (otherwis

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

Hi, Regarding the openssl dependency issue, the standard way people justify getting around it is the "system library exemption", which allows for GPL'd programs to link in system libraries that are not GPL'd (otherwise, things like GPL software on MS Windows would be impossible!). Some links her

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

On Friday, October 28, 2016 at 3:58:42 PM UTC+2, Volker Braun wrote: > > I think you are making it more difficult than it is. I'm pretty sure our > binaries already depend on openssl being installed, and we do this under > the GPL system library exception. We just can't ship our own openssl (no

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

I think you are making it more difficult than it is. I'm pretty sure our binaries already depend on openssl being installed, and we do this under the GPL system library exception. We just can't ship our own openssl (nor would I want to). So we may just as well include libcurl, linked to the sys

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

Hi, On 28/10/2016 15:39, Emmanuel Charpentier wrote: However, this does not seem to be a problem per se : Debian (one of the most nitpicking distros in terms of licensing) happily ships libraries and utilities (such as cups, for starter) linked with openssl-linked libcurl. I think that it wou

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

My thoughts so far : I : Is there really a problem ? = What all the brouhaha around libcurl boils down to is that there *might* be a (pseudo)-legal difficulty in shipping a libcurl liibrary requiring OpenSSL and a GPL-licensed piece of software *in the same package*. This m

[sage-devel] Re: R failed to build (GOMP_4.0 not found)

I understand that due to #17349 a workaround would be to do > SAGE_FAT_BINARY=yes ./sage -f r but this is weird... On Sunday, 31 May 2015 16:31:12 UTC+1, Dima Pasechnik wrote: > > on Ubuntu 14.04 and Sage 6.8.beta2, I see > > SAGEROOT/local/lib$ ldd R/lib/libR.so > R/lib/libR.so: /usr/lib/x86_

[sage-devel] Re: R failed to build (GOMP_4.0 not found)

on Ubuntu 14.04 and Sage 6.8.beta2, I see SAGEROOT/local/lib$ ldd R/lib/libR.so R/lib/libR.so: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found (required by R/lib/libR.so) linux-vdso.so.1 => (0x7fff066ae000) libf77blas.so.3 => not found libatlas.s

[sage-devel] Re: R 3.1 for sage

*I* do not care that much about cygwin, but I know that other people do (the previous port of a newer upstream R to sage was hijacked for months in order to be able to be used with Cygwin...). So I thought that signaling the problem was the polite thing to do. BTW, I just pushed an update to tr

[sage-devel] Re: R 3.1 for sage

IMHO there is no need to wait for somebody to test on Cygwin. If you care about Cygwin support then set up a buildbot, that would help much more than delaying package upgrades with some additional manual steps. On Thursday, July 3, 2014 2:33:06 PM UTC-4, Emmanuel Charpentier wrote: > > R 3.1 f

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

On Fri, May 2, 2014 at 2:38 PM, leif wrote: > William Stein wrote: >> >> I just spent a while trying to figure out how to get R png graphics to >> work again in Sage-6.2rc0 on Ubuntu 14.04. Note that graphics worked >> fine with Sage-6.2beta1 on Ubuntu 12.04.Karl Dieter's many random >> posts

[sage-devel] Re: R graphics and pkg-config (trac #15742)

William Stein wrote: I just spent a while trying to figure out how to get R png graphics to work again in Sage-6.2rc0 on Ubuntu 14.04. Note that graphics worked fine with Sage-6.2beta1 on Ubuntu 12.04.Karl Dieter's many random posts around the web asking about this problem were helpful, thou

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

On Fri, May 02, 2014 at 09:48:50AM +, Francois Bissey wrote: > I know what you want to say Felix but once the pre-requisite are in place > we are more less performing all the install from a "sage shell" in which > sage-env is used to set the environment. a sage shell is not necessary to run th

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

I know what you want to say Felix but once the pre-requisite are in place we are more less performing all the install from a "sage shell" in which sage-env is used to set the environment. When spkg-install is at work, sage-env is read. At least that's how I understand it works. Francois On 2/05/2

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

On Fri, May 02, 2014 at 09:12:34AM +1200, François Bissey wrote: > > We could put it into sage-env as well, but regarding how often that's > > called... > > I was actually thinking of feeding it to sage-env :) sage-env is a part of sage ("the library"). the environment for pkgconfig (and probably

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

On Fri, 02 May 2014 01:34:42 leif wrote: > François Bissey wrote: > > On Thu, 01 May 2014 15:05:03 Volker Braun wrote: > >> On Thursday, May 1, 2014 9:58:47 PM UTC+1, leif wrote: > pkg-config --variable pc_path pkg-config > >>> > >>> That doesn't always work. (See my other post on how to get

[sage-devel] Re: R graphics and pkg-config (trac #15742)

François Bissey wrote: On Thu, 01 May 2014 15:05:03 Volker Braun wrote: On Thursday, May 1, 2014 9:58:47 PM UTC+1, leif wrote: pkg-config --variable pc_path pkg-config That doesn't always work. (See my other post on how to get it.) Where does it not work? My SLES11SP1 system on power7 rep

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

On Fri, 02 May 2014 11:04:35 François Bissey wrote: > On Thu, 01 May 2014 15:05:03 Volker Braun wrote: > > On Thursday, May 1, 2014 9:58:47 PM UTC+1, leif wrote: > > > > pkg-config --variable pc_path pkg-config > > > > > > That doesn't always work. (See my other post on how to get it.) > > > > W

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

On Thu, 01 May 2014 15:05:03 Volker Braun wrote: > On Thursday, May 1, 2014 9:58:47 PM UTC+1, leif wrote: > > > pkg-config --variable pc_path pkg-config > > > > That doesn't always work. (See my other post on how to get it.) > > Where does it not work? My SLES11SP1 system on power7 reports: frb1

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

On Thu, May 01, 2014 at 10:58:47PM +0200, leif wrote: > Felix Salfelder wrote: > >pkg-config --variable pc_path pkg-config > > That doesn't always work. (See my other post on how to get it.) if so (when?), how about fallback to something more complex *in case it does not*? reportedly, --debug d

[sage-devel] Re: R graphics and pkg-config (trac #15742)

On Thursday, May 1, 2014 9:25:52 PM UTC+1, leif wrote: > > $ pkg-config --debug 2>&1 | awk '/^Scanning /{print Pkgconf (the implementation that we are actually using in Sage) does not have a --debug switch. -- You received this message because you are subscribed to the Google Groups "sage-

[sage-devel] Re: R graphics and pkg-config (trac #15742)

On Thursday, May 1, 2014 9:58:47 PM UTC+1, leif wrote: > > > pkg-config --variable pc_path pkg-config > That doesn't always work. (See my other post on how to get it.) > Where does it not work? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. T

[sage-devel] Re: R graphics and pkg-config (trac #15742)

It does have a configure option: $ ./configure --help `configure' configures pkgconf 0.9.4 to adapt to many kinds of systems. [...] --with-pkg-config-dir specify the place where pc files will be found On Thursday, May 1, 2014 10:45:12 PM UTC+1, leif wrote: > > Well, we could just patch our p

[sage-devel] Re: R graphics and pkg-config (trac #15742)

François Bissey wrote: On Thu, 01 May 2014 23:06:53 leif wrote: François Bissey wrote: On Thu, 01 May 2014 22:58:47 leif wrote: Felix Salfelder wrote: pkg-config --variable pc_path pkg-config That doesn't always work. (See my other post on how to get it.) Using configure is certainly a g

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

On Thu, 01 May 2014 23:06:53 leif wrote: > François Bissey wrote: > > On Thu, 01 May 2014 22:58:47 leif wrote: > >> Felix Salfelder wrote: > >>> pkg-config --variable pc_path pkg-config > >> > >> That doesn't always work. (See my other post on how to get it.) > > > > Using configure is certainly

[sage-devel] Re: R graphics and pkg-config (trac #15742)

François Bissey wrote: On Thu, 01 May 2014 22:58:47 leif wrote: Felix Salfelder wrote: pkg-config --variable pc_path pkg-config That doesn't always work. (See my other post on how to get it.) Using configure is certainly a good option. +1, I like it. Sage's top-level 'configure' or pkg-

Re: [sage-devel] Re: R graphics and pkg-config (trac #15742)

On Thu, 01 May 2014 22:58:47 leif wrote: > Felix Salfelder wrote: > > pkg-config --variable pc_path pkg-config > > That doesn't always work. (See my other post on how to get it.) > > Using configure is certainly a good option. +1, I like it. Francois -- You received this message because you

[sage-devel] Re: R graphics and pkg-config (trac #15742)

Felix Salfelder wrote: pkg-config --variable pc_path pkg-config That doesn't always work. (See my other post on how to get it.) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

[sage-devel] Re: R graphics and pkg-config (trac #15742)

Francois Bissey wrote: That's a serious issue that Volker and I have overlooked when pushing for pkg-config. For those who don't the tipping point for inclusion was building recent matplotlib in OS X. matplotlib absolutely relies on using pkgconfig and all the previous work around failed with 1.3

Re: [sage-devel] Re: R

> > > > > On the subject of the time taken to compile R: R itself compiles > in > > > parallel relatively > > > fast. > > Really? I find that, when building sufficiently in parallel, R is > > actually the *second slowest* package of all packages to compile, > after >

Re: [sage-devel] Re: R

On 2013-11-22 14:58, Jean-Pierre Flori wrote: On Friday, November 22, 2013 2:27:28 PM UTC+1, Jeroen Demeyer wrote: On 2013-11-22 10:15, Fran�ois wrote: > On the subject of the time taken to compile R: R itself compiles in > parallel relatively > fast. Really? I find th

Re: [sage-devel] Re: R

On Friday, November 22, 2013 2:27:28 PM UTC+1, Jeroen Demeyer wrote: > > On 2013-11-22 10:15, Fran�ois wrote: > > On the subject of the time taken to compile R: R itself compiles in > > parallel relatively > > fast. > Really? I find that, when building sufficiently in parallel, R is > actu

Re: [sage-devel] Re: R

On 2013-11-22 10:15, François wrote: On the subject of the time taken to compile R: R itself compiles in parallel relatively fast. Really? I find that, when building sufficiently in parallel, R is actually the *second slowest* package of all packages to compile, after ATLAS. -- You received t

Re: [sage-devel] Re: R

Recent blog on this kind of issue: http://www.r-bloggers.com/the-homogenization-of-scientific-computing-or-why-python-is-steadily-eating-other-languages-lunch/ On 22 November 2013 14:16, Javier López Peña wrote: > On Thursday, November 21, 2013 1:50:07 PM UTC, Volker Braun wrote: >> >> ... but

[sage-devel] Re: R

On Thursday, November 21, 2013 1:50:07 PM UTC, Volker Braun wrote: > > ... but there is very little that we currently can do to replace R > functionality. Having said that, there is a serious lack of statistics in > Sage. > In my personal experience the pandas package [1] is capable of doing mos

Re: [sage-devel] Re: R

On Friday, November 22, 2013 3:47:16 PM UTC+13, William wrote: > > On Thu, Nov 21, 2013 at 6:40 PM, kcrisman > > wrote: > > > > > > On Thursday, November 21, 2013 3:08:44 PM UTC-5, François wrote: > >> > >> On Thu, 21 Nov 2013 09:54:10 Jason Grout wrote: > >> > On 11/21/13 9:35 AM, kcrisma

Re: [sage-devel] Re: R

On Thu, Nov 21, 2013 at 6:40 PM, kcrisman wrote: > > > On Thursday, November 21, 2013 3:08:44 PM UTC-5, François wrote: >> >> On Thu, 21 Nov 2013 09:54:10 Jason Grout wrote: >> > On 11/21/13 9:35 AM, kcrisman wrote: >> > > I love that the Sage cell supports it (there was a fascinating blog >> > >

Re: [sage-devel] Re: R

On Thursday, November 21, 2013 3:08:44 PM UTC-5, François wrote: > > On Thu, 21 Nov 2013 09:54:10 Jason Grout wrote: > > On 11/21/13 9:35 AM, kcrisman wrote: > > > I love that the Sage cell supports it (there was a fascinating blog > post > > > about embedding R a year or so ago), ... it woul

[sage-devel] Re: R

I would be in favor of keeping R, it is basically the only thing that we have for statistics. This is different from Octave, say---anything that you could do with Octave you can basically do with Sage, but there is very little that we currently can do to replace R functionality. Having said tha

[sage-devel] Re: R

On Thursday, November 21, 2013 1:45:41 PM UTC+1, jason wrote: > I think we should keep the > rpy2 python module in the standard packages to be able to interface > easily with an already-installed R. > I would be very happy if R + RPy2 would be more recent. Said that, maybe as an optional pac

Re: [sage-devel] Re: R

On Thu, 21 Nov 2013 09:54:10 Jason Grout wrote: > On 11/21/13 9:35 AM, kcrisman wrote: > > I love that the Sage cell supports it (there was a fascinating blog post > > about embedding R a year or so ago), ... it would be very, very > > unfortunate if we were to drop support for this. > > Just to b

Re: [sage-devel] Re: R

On Thu, Nov 21, 2013 at 2:50 PM, Volker Braun wrote: > I would be in favor of keeping R Since I might not have been clear on this. I'm +1 on keeping R, even though it is not up to date. It's in my eyes very good, that "%r" and "R worksheet mode" work out of the box. OT: There are (additionally t

Re: [sage-devel] Re: R

> I would be in favor of keeping R > > Since I might not have been clear on this. I'm +1 on keeping R, even > though it is not up to date. It's in my eyes very good, that "%r" and > "R worksheet mode" work out of the box. > > I am constantly encountering this in discussions with other users.

[sage-devel] Re: R

On 11/21/13 9:35 AM, kcrisman wrote: I love that the Sage cell supports it (there was a fascinating blog post about embedding R a year or so ago), ... it would be very, very unfortunate if we were to drop support for this. Just to be clear: the Sage cell would *certainly* still have R (along w

[sage-devel] Re: R

> > > I tried searching the source for instances of rpy---which would indicate > we were using R through the rpy or rpy2 python module, and none of these > references are actually using R.: As I've pointed out on other occasions, we never used R via rpy in the first place. However, it would

[sage-devel] Re: R

On 11/21/13 7:07 AM, Harald Schilly wrote: Secondly, I don't think you can keep rpy2 but get rid of R. RPy2 interfaces on a lower level and requires the R header files, right? Or at least the specific libraries? Good point; I think you are right: http://rpy.sourceforge.net/rpy2/doc-2.3/html/ov

[sage-devel] Re: R build error in 5.10 was Re: ATLAS build error on CentOS

leif wrote: leif wrote: leif wrote: Ursula Whitcher wrote: ... gcc -std=gnu99 -shared -fopenmp -o libR.so CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o arithmetic.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o co

Re: [sage-devel] Re: R build error in 5.10 was Re: ATLAS build error on CentOS

On 6/5/2013 10:13 PM, leif wrote: Ursula, can you confirm that `LIBRARY_PATH` is set in your shell? E.g., what does the following give? $ ./sage --sh -c 'echo $LIBRARY_PATH' /home/whitchua/sage-5.10.rc0/local/lib --Ursula. -- You received this message because you are subscribed to the Goo

Re: [sage-devel] Re: R build error in 5.10 was Re: ATLAS build error on CentOS

On 6/5/2013 8:50 PM, leif wrote: This appears to be an upstream bug; despite that we configure with '--with-readline="$SAGE_LOCAL"', the corresponding '-L...' is missing in the linker command such that your system's libreadline gets picked up. You can try: $ env LDFLAGS="-L/home/whitchua/sage-

[sage-devel] Re: R build error in 5.10 was Re: ATLAS build error on CentOS

leif wrote: leif wrote: Ursula Whitcher wrote: ... gcc -std=gnu99 -shared -fopenmp -o libR.so CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o arithmetic.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o context.o cov.o

[sage-devel] Re: R build error in 5.10 was Re: ATLAS build error on CentOS

leif wrote: Ursula Whitcher wrote: ... gcc -std=gnu99 -shared -fopenmp -o libR.so CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o arithmetic.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o context.o cov.o cum.o dcf.o

[sage-devel] Re: R build error in 5.10 was Re: ATLAS build error on CentOS

Ursula Whitcher wrote: On 6/5/2013 11:39 AM, William Stein wrote: Given that she is having build issues, I strongly recommend just building a clean sage-5.10.rc0 from scratch. There may be (many?) changes to the Sage library, etc., that are related to updated ATLAS for the first time in years,

Re: [sage-devel] Re: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance

Well, to be more clear I have only xvfb + dependencies, so I should have said I have "headless Xes" On Fri, Apr 12, 2013 at 4:48 PM, Volker Braun wrote: > On Friday, April 12, 2013 3:35:41 PM UTC+1, Andrzej Giniewicz wrote: >> >> Well, there are no X-es on this machine, but it is ready to use png

Re: [sage-devel] Re: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance

On Friday, April 12, 2013 3:35:41 PM UTC+1, Andrzej Giniewicz wrote: > Well, there are no X-es on this machine, but it is ready to use png > backend with or without cairo when compiled with freetype on host There are 3 backends that can write png in R, and they are cairo, Xlib, and quartz. If

Re: [sage-devel] Re: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance

Well, there are no X-es on this machine, but it is ready to use png backend with or without cairo when compiled with freetype on host: > capabilities() jpeg png tifftcltk X11 aqua http/ftp sockets TRUE TRUE TRUE TRUEFALSEFALSE TRUE TRUE

[sage-devel] Re: R in Sage uses system cairo, conflicting freetype versions: cannot generate png, undefined symbol FT_Get_Advance

Can you use the Xlib backend in R? sage: print r.eval('capabilities()') jpeg png tifftcltk X11 aqua http/ftp sockets libxml fifo cledit FALSEFALSEFALSEFALSEFALSEFALSE TRUE TRUE TRUE TRUE TRUE iconv NLS profm

Re: [sage-devel] Re: R users conference

Thanks for the useful comments. I'll try to make it to the interfaces session tomorrow. John On Tue, Aug 16, 2011 at 1:16 PM, kcrisman wrote: > > > On Aug 16, 7:39 am, John Cremona wrote: >> I have just noticed that there's an international R users conference, >> with over 400 participants,  t

[sage-devel] Re: R users conference

On Aug 16, 7:39 am, John Cremona wrote: > I have just noticed that there's an international R users conference, > with over 400 participants,  taking place right now in my building > (which houses both Mathematics and Statistics departments).   > Seehttp://www.warwick.ac.uk/statsdept/useR-2011/

[sage-devel] Re: R + GLPK

On Jul 14, 5:30 pm, Nathann Cohen wrote: > > Has this > > already been done, or should I file a patch for this? > > If you would be so kind... I  saw no mention of it until I read your > message :-) Done, including patch, at http://trac.sagemath.org/sage_trac/ticket/9598 Also, I'll mention that

Re: [sage-devel] Re: R + GLPK

On 15 July 2010 16:38, Robert Miller wrote: > On Thu, Jul 15, 2010 at 1:51 PM, David Kirkby wrote: >> 3) GLPK should be built before R if we ever hope to use it in R >> 4) GLPK should be built before CVXOPT if there is any hope of using >> those together. > > Shouldn't we wait until we implement

Re: [sage-devel] Re: R + GLPK

On Thu, Jul 15, 2010 at 1:51 PM, David Kirkby wrote: > 3) GLPK should be built before R if we ever hope to use it in R > 4) GLPK should be built before CVXOPT if there is any hope of using > those together. Shouldn't we wait until we implement using GLPK from these? Otherwise we are potentially s

[sage-devel] Re: R + GLPK

> > Has this > > already been done, or should I file a patch for this? > > If you would be so kind... I  saw no mention of it until I read your > message :-) Ok, I'll do it in the next couple of days, taking into account David's comment about skpg build order. Nathan -- To post to this group, s

Re: [sage-devel] Re: R + GLPK

On 15 July 2010 12:29, François Bissey wrote: >> In my email above, I just appended '$(INST)/$(GLPK)' to the end of the >> CVXOPT line as it currently is in spkg/standard/deps.. I did not add >> NUMPY myself. If a dependency can be removed, it would be useful, as >> it might permit more efficient

Re: [sage-devel] Re: R + GLPK

> In my email above, I just appended '$(INST)/$(GLPK)' to the end of the > CVXOPT line as it currently is in spkg/standard/deps.. I did not add > NUMPY myself. If a dependency can be removed, it would be useful, as > it might permit more efficient parallel builds. sorry Dave, I didn't imply you di

Re: [sage-devel] Re: R + GLPK

On 15 July 2010 10:04, François Bissey wrote: >> On 07/14/10 10:58 PM, Nathan Dunfield wrote: >> I strongly suspect you would also need to make sure glpk builds before >> cvxopt by editing spkg/standard/deps. The cvxopt entry would then look >> like this. >> >> >> $(INST)/$(CVXOPT): $(BASE) $(INS

[sage-devel] Re: R + GLPK

CVXOPT has no dependencies on Numpy (but can exchange data with Numpy arrays efficiently via a buffer protocol). On Jul 15, 11:04 am, François Bissey wrote: > > On 07/14/10 10:58 PM, Nathan Dunfield wrote: > > >> On a similar note cvxopt can make use of glpk as well. > > > > Yes, it can --- I was

Re: [sage-devel] Re: R + GLPK

> On 07/14/10 10:58 PM, Nathan Dunfield wrote: > >> On a similar note cvxopt can make use of glpk as well. > > > > Yes, it can --- I was just using this yesterday. > > > > The trick is that you have to tell cvxopt that glpk is available when > > it is compiled/installed. Now that glpk is standa

Re: [sage-devel] Re: R + GLPK

On 07/14/10 10:58 PM, Nathan Dunfield wrote: On a similar note cvxopt can make use of glpk as well. Yes, it can --- I was just using this yesterday. The trick is that you have to tell cvxopt that glpk is available when it is compiled/installed. Now that glpk is standard, the install script f

[sage-devel] Re: R + GLPK

> Has this > already been done, or should I file a patch for this? If you would be so kind... I saw no mention of it until I read your message :-) Nathann -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubsc

[sage-devel] Re: R + GLPK

> On a similar note cvxopt can make use of glpk as well. Yes, it can --- I was just using this yesterday. The trick is that you have to tell cvxopt that glpk is available when it is compiled/installed. Now that glpk is standard, the install script for cvxopt should be told to make use of it.

Re: [sage-devel] Re: R graphics on the command line

On Thu, Jul 1, 2010 at 8:36 AM, kcrisman wrote: > > > On Jul 1, 10:30 am, Jason Grout wrote: >> Is there an easy way to make this work? >> >> % sage -R >> >> R version 2.10.1 (2009-12-14) >> Copyright (C) 2009 The R Foundation for Statistical Computing >> ISBN 3-900051-07-0 >> >> R is free softwa

Re: [sage-devel] Re: R and the ICU library

On 07/ 3/10 02:28 PM, kcrisman wrote: When R is built on Solaris, the configure option --without-ICU is added. Otherwise R will not build. The problem seems to be that R's configure script does not appear to have the sense to disable the library if it can't find the library. One might reasonab

[sage-devel] Re: R and the ICU library

> When R is built on Solaris, the configure option --without-ICU is added. > Otherwise R will not build. > > The problem seems to be that R's configure script does not appear to have the > sense to disable the library if it can't find the library. One might > reasonably > expect the configure scr

[sage-devel] Re: R graphics on the command line

On Jul 1, 10:30 am, Jason Grout wrote: > Is there an easy way to make this work? > > % sage -R > > R version 2.10.1 (2009-12-14) > Copyright (C) 2009 The R Foundation for Statistical Computing > ISBN 3-900051-07-0 > > R is free software and comes with ABSOLUTELY NO WARRANTY. > You are welcome to

  1   2   >