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 statsmodels and so on. >> >> In my opinion, it would be way, way better to completely remove R from >> Sage and instead do the following: >> >>1. Include the R jupyter kernel config files. >> >>2. Includes the modern Python stats libraries pandas and >> statsmodels in Sage. >> >> Our time would be much better spent supporting 2 than 1. It's >> ridiculous that we spend no effort on pandas/statsmodels, and all this >> effort on R. That was a strategy that made sense 10 years ago, but >> not today. >> >> For example, I recall that there are some issues involving pandas + >> statsmodels + the sage preparser. We could put effort into >> addressing those, like Robert Bradshaw did with numpy (which used to >> be very unhappy with Sage integers, reals, etc.). Fixing this stuff >> probably wouldn't be hard, and would make Sage a better environment >> for stats. There may be similar remarks around machine learning, >> where Python has really come into its own recently (e.g., see >> tensorflow). >> > > These issues with Sage integers were recently illustrated > by this Ask Sage question: > > > https://ask.sagemath.org/question/35270/sage-vs-python-integers-and-floats-in-pandas-matplotlib-etc/ > > If anyone knows how to fix that, it would be very appreciated. > Auto-casting ? That should be solved on Panda's side... -- Emmanuel Charpentietr -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
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 remove R from > Sage and instead do the following: > >1. Include the R jupyter kernel config files. > >2. Includes the modern Python stats libraries pandas and > statsmodels in Sage. > > Our time would be much better spent supporting 2 than 1. It's > ridiculous that we spend no effort on pandas/statsmodels, and all this > effort on R. That was a strategy that made sense 10 years ago, but > not today. > > For example, I recall that there are some issues involving pandas + > statsmodels + the sage preparser. We could put effort into > addressing those, like Robert Bradshaw did with numpy (which used to > be very unhappy with Sage integers, reals, etc.). Fixing this stuff > probably wouldn't be hard, and would make Sage a better environment > for stats. There may be similar remarks around machine learning, > where Python has really come into its own recently (e.g., see > tensorflow). > These issues with Sage integers were recently illustrated by this Ask Sage question: https://ask.sagemath.org/question/35270/sage-vs-python-integers-and-floats-in-pandas-matplotlib-etc/ If anyone knows how to fix that, it would be very appreciated. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
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 "standalone". It is also a bit difficult to understand, due
> to present lack of documentation. Cut-n'paste from a sagews :
>
> help("r")
> ︡983aebe0-3f6e-46ff-9d40-ce8e153480d2︡{"stdout":"no Python documentation
> found for 'r'\n\n"}︡{"done":true}︡
>
> But the behavior of R in % cells is crystal-clear. The first difficulty I
> have is to understand how to exchange data (or other structures) between R
> and Sage (which is the *whole* point of the exercise...).
>
> Do you think that this R interface, specific to Sagemath Cloud, could be
> ported to Sage ? And do you think that t would involve R-version specific
> code ?
I don't think this question really makes any sense. What you have to
do is simply learn Jupyter... then rethink the question. Except
that's harder than it should be...! I just posted this to
https://gitter.im/jupyter/jupyter: "Hi, I just spent a shockingly
large amount of time searching and googling for basically an overview
of what a Jupyter kernel is and how to write one. There's some old
deprecated docs about this, which all have big pointers to newer docs.
I can't find any new docs that simply explain what a Jupyter kernel is
and how to write one. I'm trying to convince other Sage developers to
use Jupyter kernels instead of the pexpect interfaces I wrote for Sage
-- at least for R mode -- and it's impossible to convince them if I
can't even point to the docs. So help... For example, going here, I
would expect under "Kernels" the docs I want, but I can't find
anything."
>
> Another potential stumbling point it that the main part of the interface
> (the IRkernel package), has not (het) been accepted by CRAN, rendering its
> future ability questionable.
>
> I plan to look also at what is offered by the Rpy2 interface It would take a
> bit of work to emulate the behavior of the pexpect nterface, but that might
> offer a good interim solution (at this time, I have *no* idea about what the
> IRkernel and its companion libraries are supposed to do).
>
> Last recourse : the R library itself. Again, I don't know (yet) what it
> offers.
>
> Again, thank you for your (a bit frightening...) advice,
Sorry for being scary. It's just advice. Feel free to ignore, of course.
> --
> Emmanuel Charpentier
>
> Le dimanche 30 octobre 2016 17:10:31 UTC+1, William a écrit :
>>
>> 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
>> > systemwide(at
>> > least user-reachable) version of R and the R library might offer the
>> > functionality without entailing the (not so trivial) work of maintaining
>> > our
>> > own R port.
>> >
>> > Do you have an idea of the amount of work involved ? And how to, do it ?
>> > The
>> > rpy2 part is probably easy, but I expect surprises on the pexpec(t)
>> > front
>> > (at least if we want to keep compatibility with existing code using
>> > current
>> > R interface facilities...). Any hint on the right starting point(s)
>> > would
>> > be welcome...
>> >
>> > BTW : I have also had a (quite superficial) look at what pandas and
>> > statsmodel claim to do. They (and scikit-learn, which look interesting,
>> > and
>> > stan, already available from Python) might be indeed useful for
>> > run-of-the-mill descriptive analysis and regression models (and Stan for
>> > more exotic modeling). Packaging them for Sage might prove useful.
>> >
>> > However, those 9000+ R packages are here for a reason : if some of them
>> > (a
>> > small minority, IMHO) are obvious PhD-earning byproducts, others aim to
>> > solve difficult (if specialized) problems, badly solved (or not even
>> > considered) by the aforementioned trio. keeping a way to reach them from
>> > Sage might be important. Hence my plea for an "R interface(s)" package.
>> >
>> > Another (IMHO futile) reason for keeping an R interface in our arsenal
>> > is
>> > "name recognition" : quoting R in a "Materials and methods" section no
>> > longer raises questions from reviewers ; somehow, I doubt that pandas
>> > and
>> > statmodels get the same answer...
>> >
>> > What can you add ? Can someone propose a work plan ?
>>
>> I'm not thinking about politics and name recognition below - I'm just
>> providing a technical/engineering perspective.
>>
>> If anybody is seriously planning to work on the R pexpect interface, I
>> would personally suggest they consider instead working on the R
>> Jupyter kernel bridge instead, and maybe create a drop in replacement
>> for the current pexpe
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 documentation. Cut-n'paste from a sagews :
help("r")
︡983aebe0-3f6e-46ff-9d40-ce8e153480d2︡{"stdout":"no Python documentation
found for 'r'\n\n"}︡{"done":true}︡
But the behavior of R in % cells is crystal-clear. The first difficulty I
have is to understand how to exchange data (or other structures) between R
and Sage (which is the *whole* point of the exercise...).
Do you think that this R interface, specific to Sagemath Cloud, could be
ported to Sage ? And do you think that t would involve R-version specific
code ?
Another potential stumbling point it that the main part of the interface
(the IRkernel package), has not (het) been accepted by CRAN, rendering its
future ability questionable.
I plan to look also at what is offered by the Rpy2 interface It would take
a bit of work to emulate the behavior of the pexpect nterface, but that
might offer a good interim solution (at this time, I have *no* idea about
what the IRkernel and its companion libraries are supposed to do).
Last recourse : the R library itself. Again, I don't know (yet) what it
offers.
Again, thank you for your (a bit frightening...) advice,
--
Emmanuel Charpentier
Le dimanche 30 octobre 2016 17:10:31 UTC+1, William a écrit :
>
> 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
> systemwide(at
> > least user-reachable) version of R and the R library might offer the
> > functionality without entailing the (not so trivial) work of maintaining
> our
> > own R port.
> >
> > Do you have an idea of the amount of work involved ? And how to, do it ?
> The
> > rpy2 part is probably easy, but I expect surprises on the pexpec(t)
> front
> > (at least if we want to keep compatibility with existing code using
> current
> > R interface facilities...). Any hint on the right starting point(s)
> would
> > be welcome...
> >
> > BTW : I have also had a (quite superficial) look at what pandas and
> > statsmodel claim to do. They (and scikit-learn, which look interesting,
> and
> > stan, already available from Python) might be indeed useful for
> > run-of-the-mill descriptive analysis and regression models (and Stan for
> > more exotic modeling). Packaging them for Sage might prove useful.
> >
> > However, those 9000+ R packages are here for a reason : if some of them
> (a
> > small minority, IMHO) are obvious PhD-earning byproducts, others aim to
> > solve difficult (if specialized) problems, badly solved (or not even
> > considered) by the aforementioned trio. keeping a way to reach them from
> > Sage might be important. Hence my plea for an "R interface(s)" package.
> >
> > Another (IMHO futile) reason for keeping an R interface in our arsenal
> is
> > "name recognition" : quoting R in a "Materials and methods" section no
> > longer raises questions from reviewers ; somehow, I doubt that pandas
> and
> > statmodels get the same answer...
> >
> > What can you add ? Can someone propose a work plan ?
>
> I'm not thinking about politics and name recognition below - I'm just
> providing a technical/engineering perspective.
>
> If anybody is seriously planning to work on the R pexpect interface, I
> would personally suggest they consider instead working on the R
> Jupyter kernel bridge instead, and maybe create a drop in replacement
> for the current pexpect interface that uses the R Jupyter kernel.
> This would likely be time well spent. This is what we (mostly Hal
> Snyder) have been doing with SageMathCloud, where now the %r mode in
> Sage worksheets is implemented entirely using Jupyter (which we did
> due to user bug/robustness reports with the sage pexpect interface):
>
>
> https://github.com/sagemathinc/smc/blob/master/src/smc_sagews/smc_sagews/sage_jupyter.py
>
>
> Some history - I wrote those (stupid) pexpect interfaces in
> 2005-2006 as a way to bootstrap making Python talk to everything else.
> However, they are basically the worst *viable* approach to the
> problem. Jupyter kernels are potentially a lot more work than using
> pexpect, but they are clearly a better approach.
>
> Yes, using pexpect is one way to write a Jupyter kernel, but
> fortunately there are better ways. For example, the Jupyter kernel is
> 1000(s) of lines of nontrivial code written in the R language, which
> is being improved all the time due to extensive use by users. The
> Jupyter R kernel is a serious actively developed project:
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 systemwide(at > least user-reachable) version of R and the R library might offer the > functionality without entailing the (not so trivial) work of maintaining our > own R port. > > Do you have an idea of the amount of work involved ? And how to, do it ? The > rpy2 part is probably easy, but I expect surprises on the pexpec(t) front > (at least if we want to keep compatibility with existing code using current > R interface facilities...). Any hint on the right starting point(s) would > be welcome... > > BTW : I have also had a (quite superficial) look at what pandas and > statsmodel claim to do. They (and scikit-learn, which look interesting, and > stan, already available from Python) might be indeed useful for > run-of-the-mill descriptive analysis and regression models (and Stan for > more exotic modeling). Packaging them for Sage might prove useful. > > However, those 9000+ R packages are here for a reason : if some of them (a > small minority, IMHO) are obvious PhD-earning byproducts, others aim to > solve difficult (if specialized) problems, badly solved (or not even > considered) by the aforementioned trio. keeping a way to reach them from > Sage might be important. Hence my plea for an "R interface(s)" package. > > Another (IMHO futile) reason for keeping an R interface in our arsenal is > "name recognition" : quoting R in a "Materials and methods" section no > longer raises questions from reviewers ; somehow, I doubt that pandas and > statmodels get the same answer... > > What can you add ? Can someone propose a work plan ? I'm not thinking about politics and name recognition below - I'm just providing a technical/engineering perspective. If anybody is seriously planning to work on the R pexpect interface, I would personally suggest they consider instead working on the R Jupyter kernel bridge instead, and maybe create a drop in replacement for the current pexpect interface that uses the R Jupyter kernel. This would likely be time well spent. This is what we (mostly Hal Snyder) have been doing with SageMathCloud, where now the %r mode in Sage worksheets is implemented entirely using Jupyter (which we did due to user bug/robustness reports with the sage pexpect interface): https://github.com/sagemathinc/smc/blob/master/src/smc_sagews/smc_sagews/sage_jupyter.py Some history - I wrote those (stupid) pexpect interfaces in 2005-2006 as a way to bootstrap making Python talk to everything else. However, they are basically the worst *viable* approach to the problem. Jupyter kernels are potentially a lot more work than using pexpect, but they are clearly a better approach. Yes, using pexpect is one way to write a Jupyter kernel, but fortunately there are better ways. For example, the Jupyter kernel is 1000(s) of lines of nontrivial code written in the R language, which is being improved all the time due to extensive use by users. The Jupyter R kernel is a serious actively developed project: https://github.com/IRkernel/IRkernel Compare that to the Sage R pexpect interface... https://github.com/sagemath/sage/commits/master/src/sage/interfaces/r.py -- William -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
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 > >> 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 here: > >> > >> > >> > http://opensource.stackexchange.com/questions/2233/gpl-v3-with-openssl-exception > > >> > >> As the person who chose to add R to Sage in the first place, my > >> instinct on this is that we should **completely and totally remove R > >> from Sage**. Why? > >> > >> - Our pexpect based interface to R sucks. It was mostly written by > >> Mike Hansen and me, so I take the blame. In SageMathCloud Sage > >> worksheets > >> we just switched to making the %r mode be implemented using Jupyter's > >> R kernel, which is way more robust. > >> > >> - It's easy enough to install R in other ways outside of Sage. > >> I've heard of a lot of people installing Sage in order to install X > >> (where X is say Pari or Singular or even Cython at one point); I've > >> *never* heard of anybody installing Sage in order to get R. > >> > >> - The main technical reason for installing R into Sage, as opposed > >> to just finding a system-wide R install, is to ensure that rpy2 -- the > >> C-level bindings to R -- actually work. > > > > > > What would prevent it from working if R is not included in Sage? > > Since you ask, some of the things I can immediately think of: > > 1. R isn't installed systemwide (obvious) > > 2. The version of R that is installed is very old or too new compared > to the version of Sage and rpy2 that are installed. > > 3. The version of R that the user installed doesn't provide a shared > object library or dynamic link library (maybe on OS X or Windows?) > > 4. The user installed R in some local location, and there are shared > object libraries there, but Sage's Python knows nothing about this > copy of R or its libraries, so rpy2 won't build. > > That said, I'm also for rpy2 being optional and pip installable, as > you propose. Many of the above problems are best addressed by > improving rpy2 and pip, and maybe that's already happened. > I talked to R people here at GSoC summit, and they say it should not be a problem to have rpy2 install correctly on any platform they support (the libraries rpy2 needs are always bundled, and the non-standard location of R is supported too.) > > -- William > > > rpy2 is pip-installable. > > > > Doing "pip install rpy2" on my system python (3.5) gave me a running > version > > of > > rpy2 (talking to system-wide R 3.3.1). > > I didn't try with python2, but they say it's supported this way too. > > > > Just make rpy2 an optional Sage package... > > > > Dima > > > > > > > >> > >> However, in retrospect, I > >> don't think rpy2 is really that great. > >> > >>- 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 remove R from > >> Sage and instead do the following: > >> > >>1. Include the R jupyter kernel config files. > >> > >>2. Includes the modern Python stats libraries pandas and > >> statsmodels in Sage. > >> > >> Our time would be much better spent supporting 2 than 1. It's > >> ridiculous that we spend no effort on pandas/statsmodels, and all this > >> effort on R. That was a strategy that made sense 10 years ago, but > >> not today. > >> > >> For example, I recall that there are some issues involving pandas + > >> statsmodels + the sage preparser. We could put effort into > >> addressing those, like Robert Bradshaw did with numpy (which used to > >> be very unhappy with Sage integers, reals, etc.). Fixing this stuff > >> probably wouldn't be hard, and would make Sage a better environment > >> for stats. There may be similar remarks around machine learning, > >> where Python has really come into its own recently (e.g., see > >> tensorflow). > >> > >> Anyway, just my two cents. But if anybody was out there wanting to > >> propose something similar, but worried that the person who included R > >> in Sage in the first place would be really annoyed -- fear not. > >> > >> -- William > >> > >> On Fri, Oct 28, 2016 at 6:39 AM, Emmanuel Charpentier > >> wrote: > >> > 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 difficul
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 encountered a few quirks, all I think related to the Sage Integer vs. Python Integer distinction. I don't use statsmodel though. Nathan -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
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 Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
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 programs to link in system libraries that are not >> GPL'd (otherwise, things like GPL software on MS Windows would be >> impossible!). Some links here: >> >> >> http://opensource.stackexchange.com/questions/2233/gpl-v3-with-openssl-exception >> >> As the person who chose to add R to Sage in the first place, my >> instinct on this is that we should **completely and totally remove R >> from Sage**. Why? >> >> - Our pexpect based interface to R sucks. It was mostly written by >> Mike Hansen and me, so I take the blame. In SageMathCloud Sage >> worksheets >> we just switched to making the %r mode be implemented using Jupyter's >> R kernel, which is way more robust. >> >> - It's easy enough to install R in other ways outside of Sage. >> I've heard of a lot of people installing Sage in order to install X >> (where X is say Pari or Singular or even Cython at one point); I've >> *never* heard of anybody installing Sage in order to get R. >> >> - The main technical reason for installing R into Sage, as opposed >> to just finding a system-wide R install, is to ensure that rpy2 -- the >> C-level bindings to R -- actually work. > > > What would prevent it from working if R is not included in Sage? Since you ask, some of the things I can immediately think of: 1. R isn't installed systemwide (obvious) 2. The version of R that is installed is very old or too new compared to the version of Sage and rpy2 that are installed. 3. The version of R that the user installed doesn't provide a shared object library or dynamic link library (maybe on OS X or Windows?) 4. The user installed R in some local location, and there are shared object libraries there, but Sage's Python knows nothing about this copy of R or its libraries, so rpy2 won't build. That said, I'm also for rpy2 being optional and pip installable, as you propose. Many of the above problems are best addressed by improving rpy2 and pip, and maybe that's already happened. -- William > rpy2 is pip-installable. > > Doing "pip install rpy2" on my system python (3.5) gave me a running version > of > rpy2 (talking to system-wide R 3.3.1). > I didn't try with python2, but they say it's supported this way too. > > Just make rpy2 an optional Sage package... > > Dima > > > >> >> However, in retrospect, I >> don't think rpy2 is really that great. >> >>- 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 remove R from >> Sage and instead do the following: >> >>1. Include the R jupyter kernel config files. >> >>2. Includes the modern Python stats libraries pandas and >> statsmodels in Sage. >> >> Our time would be much better spent supporting 2 than 1. It's >> ridiculous that we spend no effort on pandas/statsmodels, and all this >> effort on R. That was a strategy that made sense 10 years ago, but >> not today. >> >> For example, I recall that there are some issues involving pandas + >> statsmodels + the sage preparser. We could put effort into >> addressing those, like Robert Bradshaw did with numpy (which used to >> be very unhappy with Sage integers, reals, etc.). Fixing this stuff >> probably wouldn't be hard, and would make Sage a better environment >> for stats. There may be similar remarks around machine learning, >> where Python has really come into its own recently (e.g., see >> tensorflow). >> >> Anyway, just my two cents. But if anybody was out there wanting to >> propose something similar, but worried that the person who included R >> in Sage in the first place would be really annoyed -- fear not. >> >> -- William >> >> On Fri, Oct 28, 2016 at 6:39 AM, Emmanuel Charpentier >> wrote: >> > 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 might >> > be a >> > part of the reasons for the R core team to have thrown the towel on this >> > (but probably only patr of the reason : they alo threw the towel on xz >> > an >> > pcre, which do not give the same headache). >> > >> > 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 would be interesting to ask them how
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 (otherwise, things like GPL software on MS Windows would be > impossible!). Some links here: > > > http://opensource.stackexchange.com/questions/2233/gpl-v3-with-openssl-exception > > > As the person who chose to add R to Sage in the first place, my > instinct on this is that we should **completely and totally remove R > from Sage**. Why? > > - Our pexpect based interface to R sucks. It was mostly written by > Mike Hansen and me, so I take the blame. In SageMathCloud Sage > worksheets > we just switched to making the %r mode be implemented using Jupyter's > R kernel, which is way more robust. > > - It's easy enough to install R in other ways outside of Sage. > I've heard of a lot of people installing Sage in order to install X > (where X is say Pari or Singular or even Cython at one point); I've > *never* heard of anybody installing Sage in order to get R. > > - The main technical reason for installing R into Sage, as opposed > to just finding a system-wide R install, is to ensure that rpy2 -- the > C-level bindings to R -- actually work. What would prevent it from working if R is not included in Sage? rpy2 is pip-installable. Doing "pip install rpy2" on my system python (3.5) gave me a running version of rpy2 (talking to system-wide R 3.3.1). I didn't try with python2, but they say it's supported this way too. Just make rpy2 an optional Sage package... Dima > However, in retrospect, I > don't think rpy2 is really that great. > >- 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 remove R from > Sage and instead do the following: > >1. Include the R jupyter kernel config files. > >2. Includes the modern Python stats libraries pandas and > statsmodels in Sage. > > Our time would be much better spent supporting 2 than 1. It's > ridiculous that we spend no effort on pandas/statsmodels, and all this > effort on R. That was a strategy that made sense 10 years ago, but > not today. > > For example, I recall that there are some issues involving pandas + > statsmodels + the sage preparser. We could put effort into > addressing those, like Robert Bradshaw did with numpy (which used to > be very unhappy with Sage integers, reals, etc.). Fixing this stuff > probably wouldn't be hard, and would make Sage a better environment > for stats. There may be similar remarks around machine learning, > where Python has really come into its own recently (e.g., see > tensorflow). > > Anyway, just my two cents. But if anybody was out there wanting to > propose something similar, but worried that the person who included R > in Sage in the first place would be really annoyed -- fear not. > > -- William > > On Fri, Oct 28, 2016 at 6:39 AM, Emmanuel Charpentier > > wrote: > > 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 might > be a > > part of the reasons for the R core team to have thrown the towel on this > > (but probably only patr of the reason : they alo threw the towel on xz > an > > pcre, which do not give the same headache). > > > > 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 would be interesting to ask them how they reconcile the > > (inconsistent) wordings of the licenses involved. > > > > According to their answer, we might have an easy way out : hide behind > the > > same legal curtain as Debian (it remains to see what it is...), package > > libcurl (essentially done) and silently ship it with Sage (it remains to > > check if other libraries are not more or less silently involved in the > > support of https: in libcurl, in which case we might have to use them > also). > > This is option : > > > > a) Do nothing : > > > > > > II ? If there is really a problem, what can we do ? > > === > > > > We might also bite the bullet, modify our licensing terms to add the > > advertising clause required by openssl's license and ship openly > libcurl. > > Tha requires, it seems, explicit permiss
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 here: http://opensource.stackexchange.com/questions/2233/gpl-v3-with-openssl-exception As the person who chose to add R to Sage in the first place, my instinct on this is that we should **completely and totally remove R from Sage**. Why? - Our pexpect based interface to R sucks. It was mostly written by Mike Hansen and me, so I take the blame. In SageMathCloud Sage worksheets we just switched to making the %r mode be implemented using Jupyter's R kernel, which is way more robust. - It's easy enough to install R in other ways outside of Sage. I've heard of a lot of people installing Sage in order to install X (where X is say Pari or Singular or even Cython at one point); I've *never* heard of anybody installing Sage in order to get R. - The main technical reason for installing R into Sage, as opposed to just finding a system-wide R install, is to ensure that rpy2 -- the C-level bindings to R -- actually work. However, in retrospect, I don't think rpy2 is really that great. - 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 remove R from Sage and instead do the following: 1. Include the R jupyter kernel config files. 2. Includes the modern Python stats libraries pandas and statsmodels in Sage. Our time would be much better spent supporting 2 than 1. It's ridiculous that we spend no effort on pandas/statsmodels, and all this effort on R. That was a strategy that made sense 10 years ago, but not today. For example, I recall that there are some issues involving pandas + statsmodels + the sage preparser. We could put effort into addressing those, like Robert Bradshaw did with numpy (which used to be very unhappy with Sage integers, reals, etc.). Fixing this stuff probably wouldn't be hard, and would make Sage a better environment for stats. There may be similar remarks around machine learning, where Python has really come into its own recently (e.g., see tensorflow). Anyway, just my two cents. But if anybody was out there wanting to propose something similar, but worried that the person who included R in Sage in the first place would be really annoyed -- fear not. -- William On Fri, Oct 28, 2016 at 6:39 AM, Emmanuel Charpentier wrote: > 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 might be a > part of the reasons for the R core team to have thrown the towel on this > (but probably only patr of the reason : they alo threw the towel on xz an > pcre, which do not give the same headache). > > 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 would be interesting to ask them how they reconcile the > (inconsistent) wordings of the licenses involved. > > According to their answer, we might have an easy way out : hide behind the > same legal curtain as Debian (it remains to see what it is...), package > libcurl (essentially done) and silently ship it with Sage (it remains to > check if other libraries are not more or less silently involved in the > support of https: in libcurl, in which case we might have to use them also). > This is option : > > a) Do nothing : > > > II ? If there is really a problem, what can we do ? > === > > We might also bite the bullet, modify our licensing terms to add the > advertising clause required by openssl's license and ship openly libcurl. > Tha requires, it seems, explicit permission of all the people havng > contributed to Sage, which might prove a difficult (impossble ?) task. That > gives us option : > > b) Acknowledge libcurl > - > > We can also emulate the R core team, throw the towel and simply add (an > https-capable) libcurl to our initial requirements in README.md, possibly > other places), leaving the user with the responsibility of installing it. > This is option : > > c) Throw the towel > --- > > Another possibility in the same vein is to throw the whole linen cabinet : > instead of placing on user's shoulders the responsibility of finding > libcurl, we might leave it the responsibility of installing R
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 would be interesting to ask them how they reconcile the (inconsistent) wordings of the licenses involved. It's easy to ask: https://www.debian.org/legal/ Snark on #debian-science -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
