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

[sage-devel] are roots of dynatomic_polynomial projective?

this question pops up here: https://trac.sagemath.org/ticket/18920#comment:61 Updated Maxima returns a different scaling for what appears to be a homogeneous bivariate polynomial, which documentation, written in an NT creole (;-P), doesn't really spell out; I need to decide whether the

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] Trac error on push

On Friday, October 28, 2016 at 5:01:54 PM UTC, jhonrubia6 wrote: > > Is not 104.197.143.230? > > > OnoSendaiII:sage J_Honrubia$ host trac.sagemath.org > > trac.sagemath.org has address 104.197.143.230 > the IP might have remained, but the (virtual) machine got changed, and got SSH keys

Re: [sage-devel] Trac error on push

Is not 104.197.143.230? OnoSendaiII:sage J_Honrubia$ host trac.sagemath.org trac.sagemath.org has address 104.197.143.230 El jueves, 27 de octubre de 2016, 20:29:30 (UTC+2), John Cremona escribió: > > The machine hosting trac did change recently. > > On 27 October 2016 at 19:17,

Re: [sage-devel] Multivariate polynomial factoring and bug(?)

5 variables and degree 100 is really, really huge. Especially over QQ, the coefficients of polynomials will just totally blow. In fact, 5 variables and degree 10 might still be quite hard, in particular over QQ or other char. 0 fields. On Friday, October 28, 2016 at 7:55:02 AM UTC, Jori

Re: [sage-devel] Re: Installing JupyterHub and LDAP

On Friday, October 28, 2016 at 10:26:28 AM UTC, Jori Mäntysalo wrote: > > On Wed, 26 Oct 2016, Luca De Feo wrote: > > >> Some other things: Is it possible to run plain R (or GAP or...) from > >> Jupyter? > > > You can change the kernel via the "Kernel" menu (there are kernels for > > R, GAP,

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

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

Le vendredi 28 octobre 2016 13:13:10 UTC+2, Jean-Pierre Flori a écrit : > > > > On Friday, October 28, 2016 at 12:33:42 PM UTC+2, Emmanuel Charpentier > wrote: >> >> I just checked (by installation on a virtual machine) that a *virgin* >> (base + destktop + usual utilities) debian stable

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

On Friday, October 28, 2016 at 12:33:42 PM UTC+2, Emmanuel Charpentier wrote: > > I just checked (by installation on a virtual machine) that a *virgin* > (base + destktop + usual utilities) debian stable (jessie) has openssl > installed. Tentatively asking for its removal (apt-get remove -s

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

I just checked (by installation on a virtual machine) that a *virgin* (base + destktop + usual utilities) debian stable (jessie) has openssl installed. Tentatively asking for its removal (apt-get remove -s openssl) tells that it would remove a ton of system utilities. The same is true on

Re: [sage-devel] Re: Installing JupyterHub and LDAP

On Wed, 26 Oct 2016, Luca De Feo wrote: Some other things: Is it possible to run plain R (or GAP or...) from Jupyter? You can change the kernel via the "Kernel" menu (there are kernels for R, GAP, PARI/GP, Python, etc.) Kernel menu shows only Python3 and SageMath, so it does not show

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

On Thursday, October 27, 2016 at 8:15:38 PM UTC+2, kcrisman wrote: > > > So either they will stop distribute R or they will patch >>> en-masse. >>> >> >> Somehow, I doubt it. >> >> > Probably nobody even bothered to notice or notify e.g. Debian? > > I think people at Debian ar well aware of

[sage-devel] Re: vote on behaviour of is_similar for matrices

Hi John, On 2016-10-27, John H Palmieri wrote: >>The OOP way would be to have a mix-in class and subclasses for square >> matrices that implement these methods. The category's parent_class resp. element_class are such mix-in classes. >> This would mean setting the

[sage-devel] Re: vote on behaviour of is_similar for matrices

On 2016-10-27, William Stein wrote: > On Thu, Oct 27, 2016 at 11:25 AM, kcrisman wrote: >> On Thursday, October 27, 2016 at 2:11:58 PM UTC-4, John H Palmieri wrote: >>> >>> (1) Why should a nonsquare matrix even have an "is_similar" method? Can we >>> get

[sage-devel] Re: vote on behaviour of is_similar for matrices

Hi John, On 2016-10-27, John H Palmieri wrote: > (1) Why should a nonsquare matrix even have an "is_similar" method? Can we > get rid of that? (Same for "determinant" and some other methods.) It would be possible using the category framework's "ElementMethods".

Re: [sage-devel] Multivariate polynomial factoring and bug(?)

On Thu, 27 Oct 2016, Dima Pasechnik wrote: factorisation of multivariate polynomials is very slow. This is a fact of life. True, but is it normal that some specific polynomial takes gigabytes, whereas others show no big increase in memory use? I have found bugs in Singular before, and then

Re: [sage-devel] vote on behaviour of is_similar for matrices

On Thu, 27 Oct 2016, Travis Scrimshaw wrote: 1 - the definition (as even given in the docstring) still makes full sense if the matrices are not the same size or if they are not square. There does not exist such a matrix P. To compare: (meet-)pseudocomplemet is defined for (meet-)semilattices,