new hash for cores
Update ncurses to dev version 5.9-20131221.
Speed up PARI determinants when stacksize is small
homology, chain complex fixes
15757: make sage.misc.superseded import lazily sage.rings.integer_ring
implemented proper equality testing
Speed up short_vector_list_up_to_length()
Some "long time" fixes in quadratic forms
Completely got rid of the dependency of sage.misc.superseded upon is_Integer thanks to suggestion of Jeroen
Merge remote-tracking branch 'origin/develop' into ticket/15757
Don't use bare except; reviewer patch
#10058: Segfault in backward and inverse FFT for 2**n elements
#Documentation for gsl/fft.pyx
Minor documentation fixes.
GSL FFT: indentation (& related) fixes in docstrings
Fix documentation syntax
Trac #15760: Speed up short vector enumeration

The `short_vector_list_up_to_length` method of quadratic forms uses GP
but the interface is so badly done that the majority of the time is
taken up by the Sage interface, and not by the actual computation.
Still, even with the new implementation, most time is taken by the
conversion from PARI to Sage vectors.

Timings before:
{{{
sage: qf = QuadraticForm(matrix(3, [2, 1, 1,  1, 2, 1,  1, 1, 2]))
sage: %timeit qf.short_vector_list_up_to_length(100)
1 loops, best of 3: 1.13 s per loop
sage: %timeit qf.short_vector_list_up_to_length(1000)
1 loops, best of 3: 6.74 s per loop
}}}

Timings after:
{{{
sage: qf = QuadraticForm(matrix(3, [2, 1, 1,  1, 2, 1,  1, 1, 2]))
sage: %timeit qf.short_vector_list_up_to_length(100)
10 loops, best of 3: 34.4 ms per loop
sage: %timeit qf.short_vector_list_up_to_length(1000)
1 loops, best of 3: 1.03 s per loop
}}}

URL: http://trac.sagemath.org/15760
Reported by: jdemeyer
Ticket author(s): Jeroen Demeyer
Reviewer(s): Peter Bruin
Trac #10058: Segfault in backward and inverse FFT for 2**n elements

Sage crashes when asked to do a backward or inverse FFT for sizes that
are powers of two:
{{{
sage: a = FFT(5)
sage: a[1] = 2
sage: a.forward_transform()
sage: a.backward_transform()
sage: a = FFT(4)
sage: a[1] = 2
sage: a.forward_transform()
sage: a.backward_transform()

------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component
of Sage has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate (sorry).
------------------------------------------------------------
}}}
This is with 4.6.alpha2.

Joal Heagney reported this problem on [http://groups.google.com/group
/sage-devel/browse_thread/thread/7830e0c484a0f38d sage-devel].

URL: http://trac.sagemath.org/10058
Reported by: mpatel
Ticket author(s): Mike Hansen, Luis Felipe Tabera Alonso, Marc
Mezzarobba
Reviewer(s): Luis Felipe Tabera Alonso, Marc Mezzarobba, Punarbasu
Purkayastha
Trac #15617: Update ncurses to dev version 5.9-20131221

This dev release includes a (large) bunch of various fixes, inlcuding
those needed for #15317 (Cygwin) and #15268 (Solaris).

Use (vanilla, only renamed and recompressed to get rid of the dash in
the version number) tarball at:
* http://boxen.math.washington.edu/home/jpflori/upstream/ncurses-5.9.201
31221.tar.bz2

URL: http://trac.sagemath.org/15617
Reported by: jpflori
Ticket author(s): Jean-Pierre Flori
Reviewer(s): Travis Scrimshaw
Trac #15654: PARI discriminant speed depends on stack size

This is weird and bad:
{{{
sage: x = polygen(ZpFM(3,10))
sage: p = ((x-1)^50 + x)._pari_init_()
sage: %time pari(p).poldisc()
CPU times: user 52.73 s, sys: 0.00 s, total: 52.73 s
Wall time: 52.82 s
2*3 + 3^4 + 2*3^6 + 3^7 + 2*3^8 + 2*3^9 + O(3^10)
sage: pari.allocatemem(2<<20)
PARI stack size set to 2097152 bytes
sage: %time pari(p).poldisc()
CPU times: user 0.08 s, sys: 0.00 s, total: 0.08 s
Wall time: 0.08 s
2*3 + 3^4 + 2*3^6 + 3^7 + 2*3^8 + 2*3^9 + O(3^10)
}}}

'''Upstream''': [http://pari.math.u-bordeaux.fr/cgi-
bin/bugreport.cgi?bug=1507]

URL: http://trac.sagemath.org/15654
Reported by: jdemeyer
Ticket author(s): Jeroen Demeyer
Reviewer(s): David Roe