[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

[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

[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

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

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

[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

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

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

[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

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

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

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

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

[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

[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

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

[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