On Tue, Feb 23, 2016 at 7:29 AM, Clemens Heuberger <clemens.heuber...@aau.at> wrote: > On 2016-02-23 16:57, Jeroen Demeyer wrote: >> On 2016-02-23 15:50, Clemens Heuberger wrote: >>> It is also impossible to compile Sage 6.5 nowadays >> >> I assume this was a build from git? That's indeed not supported. A real >> build-from-source-tarball should still work. > > yes, I tried to build from git. I found the tarball in the meantime and am > currently compiling it. > > How long do we support old tarballs?
Forever. The first-ever release of Sage is here: http://old.files.sagemath.org/src-old/ However, "support" only means that if you setup a VM or computer with a supported OS from then (e.g., some old debian or redhat) then you can build using *that* OS. We definitely don't update old tarballs to keep running on new versions of Linux; that would be impossibly hard, and get harder every time we do a new release. > As an illustration, one of the problems I encountered: > > cheuberg@rk01-math:/local/sage$ sage-6.7/sage -c "if x != infinity: print > 'yes'" > yes > cheuberg@rk01-math:/local/sage$ sage-6.8/sage -c "if x != infinity: print > 'yes'" > > Relying on the old behaviour was probably a bug, but behaviour changed anyhow > without a deprecation. It seems to me that sage: x = var('x') sage: bool(x!=infinity) False *is* a newly introduced bug. I can't understand how the above behavior could be justified, especially given that sage: bool(x != 2) True People do introduce bugs into Sage... -- William > > I try to pinpoint the other examples and will then report those. > >> >>> Of course, I could have opened a ticket and included my code into the >>> src/sage/tests directory. But I cannot imagine that this approach would >>> scale >>> very well. I assume that there are many papers out there with a substantial >>> amount of CPU time required for reproducability. >> >> What if you just add a simple case? Imagine your code computes f(n) for all >> n up >> to 10^6. Then you could use f(10) as test case. > > Essentially, we computed one generating function for one very specific > problem, > using concatenations of transducers to get it. > > We could have included the doctests and marking some of them as optional or > long > (do we have "very long"? we are regularly running ptestlong, and you don't > want > to include all of that stuff...), and the issue above would have been covered. > But I am not yet sure about the others. > > -- > 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. -- 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.
