Re: [sage-devel] Patching policy

2018-06-07 Thread Ralf Stephan
On Thursday, June 7, 2018 at 2:36:35 PM UTC+2, Timo Kaufmann wrote: > > In some cases where upstream has vanished and sage effectiely maintains > the project through patches anyways, it may be a better idea to just fork > the project. > It might be an idea to semi-automatize this, i.e., build a

Re: [sage-devel] Patching policy

2018-06-07 Thread Timo Kaufmann
2018-06-07 15:06 GMT+02:00 Jeroen Demeyer : > And I'm not saying there should be absolutely no patches, just that they >> should be the very last resort. >> > > I mostly agree with this, it's what I'm already doing. It just depends > where you put the borderline of "very last resort" and there we

Re: [sage-devel] Patching policy

2018-06-07 Thread Jeroen Demeyer
On 2018-06-07 14:36, Timo Kaufmann wrote: For what its worth, here is debians fix (self-labeled as "extra-hacky") for that issue: https://salsa.debian.org/science-team/sagemath/blob/master/debian/patches/dt-version-glpk-4.60-extra-hacky-fixes.patch That's not a fix at all. I could easily come

Re: [sage-devel] Patching policy

2018-06-07 Thread Timo Kaufmann
2018-06-07 14:16 GMT+02:00 Jeroen Demeyer : > On 2018-06-07 13:24, Timo Kaufmann wrote: > >> I don't really agree but even if that was the case, the PARI stackwarn >> patch could have been handled through filtering within sage instead >> (which I proposed in that ticket). >> > > You proposed

[sage-devel] NTL 11.1.0

2018-06-07 Thread Victor Shoup
Just posted a new version of NTL, version 11.1.0. I've completely re-written the low-level small-prime FFT to use a truncated FFT algorithm. More details here: http://www.shoup.net/ntl/doc/tour-changes.html -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Patching policy

2018-06-07 Thread Jeroen Demeyer
On 2018-06-07 13:24, Timo Kaufmann wrote: I don't really agree but even if that was the case, the PARI stackwarn patch could have been handled through filtering within sage instead (which I proposed in that ticket). You proposed filtering *in the testsuite*. That comes back to my point about

Re: [sage-devel] Patching policy

2018-06-07 Thread Timo Kaufmann
2018-06-07 11:12 GMT+02:00 Jeroen Demeyer : > I think that your post is focusing too much on tests, as if the only > purpose of Sage is to pass its testsuite. It's actually the other way > around: the purpose of the testsuite is to ensure that Sage functions > correctly. Of course. But the

Re: [sage-devel] random_element and randtest_element

2018-06-07 Thread Jori Mäntysalo
On Wed, 6 Jun 2018, Travis Scrimshaw wrote: Heisenfailures are very difficult to debug: One run, doctests fail. You make a small tweak (one that changes the random seed), which you think fixes the issue, and then tests pass. However, if it is a random test, then you have no idea if you have

Re: [sage-devel] Patching policy

2018-06-07 Thread Jeroen Demeyer
I think that your post is focusing too much on tests, as if the only purpose of Sage is to pass its testsuite. It's actually the other way around: the purpose of the testsuite is to ensure that Sage functions correctly. By patching the testsuite to accept buggy output anyway, you're not really

[sage-devel] Re: Suggestion for the SageMath website

2018-06-07 Thread Vincent Klein
> > > On side note: Is there any problem with alphabetical order if the whole > list is there? > > Yes in my opinion. The animation takes 180 sec to display the whole list. I think that's way longer than the average time people stay on the home page. The result is a inequal exposure because the