3 views

Skip to first unread message

Jul 27, 2010, 1:34:43 AM7/27/10

to sage-r...@googlegroups.com

Hello,

Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1.tar

Upgrade path:

http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1/

This release has been tested on sage.math and bsd.math. A build on

t2.math is underway. Please build and test.

This release is now pretty much in feature freeze. We don't plan on

merging any tickets unless they fix blocker issues.

* Known issues

This release includes two tiny unreviewed change: I merged #5396, which

makes lcalc a build prerequisite for the Sage library. Rather than leave

things as they were and have everyone's build fail, I changed

spkg/standard/deps. Someone should test that lcalc really is a build

prereq for the library by removing line 442 of spkg/standard/deps and

trying to build alpha1; it should fail with an error as seen in

http://trac.sagemath.org/sage_trac/ticket/5396#comment:86. Someone

should test that.

The second unreviewed change is the deletion of several extra files in

spkg/standard, as I mentioned in

https://groups.google.com/group/sage-release/t/b6fd67d4d4543129. In the

unlikely case that those files were important or necessary, we can just

copy them from the alpha0 tarball.

Blocker ticket #9582 has not been fixed, so there will be at least one

doctest failure on OS X.

There are a couple Sphinx warnings from the Matlab interface. A ticket

for those will be opened shortly.

Mitesh saw a doctest failure in doc/en/tutorial/latex.rst involving

"\usepackage{tikz}", so please confirm if you see that.

Merged in sagenb:

#8369: Mitesh Patel: Mistake in text on data file upload page [Reviewed by Robert Mařík; merged in sagenb-0.8]

#9554: Leif Leonhardy: Doctest failure in SageNB's sageinspect.py with #8988 [Reviewed by Volker Braun; merged in sagenb-0.8.2]

#9580: Tim Dumol: Check in, ignore, or delete sagenb.po in SageNB package [Reviewed by Mitesh Patel; merged in sagenb-0.8.2]

We merged 83 tickets in sage-4.5.2.alpha1:

#2119: Mike Hansen: matlab matrix conversion issue [Reviewed by Ross Kyprianou]

#3342: Willem Jan Palenstijn: bizarre source code introspection output [Reviewed by John Palmieri]

#5396: Rishikesh, Yann-Laigle Chapuy: Wrapping lcalc library [Reviewed by John Cremona, David Kirkby, Alex Ghitza]

#6186: Craig Citro: two probably-easy-to-fix scope bugs [Reviewed by Carl Witty]

#8156: Paul Zimmermann, Mitesh Patel: new function readdata [Reviewed by Tim Dumol, John H Palmieri, Paul Zimmermann]

#8413: Florent Hivert: Add "Unknown" truth value [Reviewed by Robert Bradshaw]

#8641: Dan Drake, John Palmieri, Mitesh Patel: "sage -t" should exit with nonzero exit code if doctests fail [Reviewed by Willem Jan Palenstijn]

#8976: Leif Leonhardy: squarefree_part() fails on Python types [Reviewed by Robert Miller]

#8993: Simon King: Representation of polynomial quotient rings in Singular [Reviewed by Martin Albrecht]

#9002: Karl-Dieter Crisman: Noise on PPC Mac in parametric_surface.pyx [Reviewed by David Kirkby]

#9027: Rob Beezer: Explain Sage and tex interactions in the tutorial [Reviewed by John Palmieri]

#9066: Karl-Dieter Crisman: Improve documentation in shapes2.py [Reviewed by Minh Van Nguyen]

#9083: Dan Drake, John Palmieri: 'make distclean' fails to remove some files or directories. [Reviewed by Mitesh Patel]

#9222: Alex Ghitza: improve doctest coverage of databases/conway.py [Reviewed by David Loeffler]

#9223: Alex Ghitza, John Cremona: improve doctest coverage of databases/cremona.py [Reviewed by John Cremona, Alex Ghitza]

#9226: David Kirkby: README.txt says " Sage builds with GCC >= 3.x" but it does NOT [Reviewed by Robert Bradshaw]

#9242: David Loeffler: Add docstrings and tests for sage/rings/ideal_monoid.py [Reviewed by Alex Ghitza]

#9243: Dan Drake, Willem Jan Palenstijn: sage-doctest should use powers of 2 for return codes [Reviewed by Willem Jan Palenstijn, Mitesh Patel]

#9251: Florent Hivert: Lazy attribute does not properly handles the doc of Cython methods [Reviewed by Robert Bradshaw]

#9278: Alex Ghitza: remove databases/kohel.py since it is not used and broken [Reviewed by Robert Miller]

#9279: Alex Ghitza: remove databases/tables.py since superseded by newer code [Reviewed by Robert Miller]

#9316: Willem Jan Palenstijn: Spurious (?) "# File not found" error at end of doctests [Reviewed by Mitesh Patel]

#9377: Kwankyu Lee: unable to coerce matrix over finite field into magma [Reviewed by Mariah Lenox]

#9398: Nils Bruin: Sage meddles with soft rlimits [Reviewed by William Stein]

#9456: John Palmieri: zlib should be a prerequisite for libpng [Reviewed by David Kirkby]

#9462: Willem Jan Palenstijn: warning in matrix_modn_dense.pyx [Reviewed by John Palmieri]

#9501: William Stein: Make an @fork decorator [Reviewed by Martin Albrecht]

#9527: William Stein: improve "sage -sh" prompt so it doesn't confuse everybody [Reviewed by Martin Albrecht]

#9561: Karl-Dieter Crisman: Docbuild warnings caused by #9219 [Reviewed by John Palmieri]

#9566: Fredrik Johansson: Allow sage.libs.mpmath.call(..., parent=something) [Reviewed by Harald Schilly]

#9570: Nathann Cohen, Leonardo Sampaio: Wrong LP solver ordering [Reviewed by Nathann Cohen, Leonardo Sampaio]

#9571: Nathann Cohen: Sphinx Warning: Missing title for sage.misc.exceptions after #9249 [Reviewed by John Palmieri]

#9572: Mitesh Patel: SageNB 0.8.2 [Reviewed by Carl Witty]

#9573: Andrey Novoseltsev: Error building the PDF reference manual [Reviewed by John Palmieri]

#9574: Dan Drake: Ignore zope-testrunner in the scripts repository [Reviewed by Mitesh Patel]

#9579: Nathan Cohen: Raise an exception when arguments to add_constraint are not admissible [Reviewed by Harald Schilly]

#9583: Dan Drake: Unhandled SIGSEGV with 4.5.2.alpha0 on t2 [Reviewed by Mitesh Patel]

#9584: Leif Leonhardy: Weird timeouts in doctesting generic_graph with 4.5.2.alpha0 on some systems [Reviewed by John Palmieri]

#9588: Armin Straub: Extend is_prime_power to negative exponents [Reviewed by Carl Witty]

#9589: Alexandre Blondin Masse: Doctest failures in nfactor_enumerable_word.py on 32-bit Linux [Reviewed by Leif Leonhardy]

#9590: Andrey Novoseltsev: Doctest failures in cone.py and toric_lattice_element.pyx on 32-bit Linux [Reviewed by Leif Leonhardy]

#9594: Leif Leonhardy: Spring layout for graphs is currently random across platforms: mark the doctest accordingly [Reviewed by John Palmieri]

#9597: Mitesh Patel: Fix first line of pari-2.3.5.p1's spkg-install [Reviewed by Dan Drake]

--

--- Dan Drake

----- http://mathsci.kaist.ac.kr/~drake

-------

Jul 27, 2010, 3:35:23 AM7/27/10

to sage-r...@googlegroups.com

On 07/27/2010 12:34 AM, Dan Drake wrote:

> * Known issues

>

> This release includes two tiny unreviewed change: I merged #5396, which

> makes lcalc a build prerequisite for the Sage library. Rather than leave

> things as they were and have everyone's build fail, I changed

> spkg/standard/deps. Someone should test that lcalc really is a build

> prereq for the library by removing line 442 of spkg/standard/deps and

> trying to build alpha1; it should fail with an error as seen in

> http://trac.sagemath.org/sage_trac/ticket/5396#comment:86. Someone

> should test that.

> * Known issues

>

> This release includes two tiny unreviewed change: I merged #5396, which

> makes lcalc a build prerequisite for the Sage library. Rather than leave

> things as they were and have everyone's build fail, I changed

> spkg/standard/deps. Someone should test that lcalc really is a build

> prereq for the library by removing line 442 of spkg/standard/deps and

> trying to build alpha1; it should fail with an error as seen in

> http://trac.sagemath.org/sage_trac/ticket/5396#comment:86. Someone

> should test that.

Unless someone objects, this is part of

http://trac.sagemath.org/sage_trac/ticket/5396

> The second unreviewed change is the deletion of several extra files in

> spkg/standard, as I mentioned in

> https://groups.google.com/group/sage-release/t/b6fd67d4d4543129. In the

> unlikely case that those files were important or necessary, we can just

> copy them from the alpha0 tarball.

This is now

http://trac.sagemath.org/sage_trac/ticket/9609

> There are a couple Sphinx warnings from the Matlab interface. A ticket

> for those will be opened shortly.

This is now

http://trac.sagemath.org/sage_trac/ticket/9608

> Mitesh saw a doctest failure in doc/en/tutorial/latex.rst involving

> "\usepackage{tikz}", so please confirm if you see that.

This is now

http://trac.sagemath.org/sage_trac/ticket/9607

> Merged in sagenb:

By the way, we merged a new SageNB package chiefly to fix a doctest

(#9554) and to merge #3342's sage and sagenb repository patches into the

same Sage release.

Jul 27, 2010, 3:59:47 AM7/27/10

to sage-r...@googlegroups.com

On 07/27/10 06:34 AM, Dan Drake wrote:

> This release includes two tiny unreviewed change: I merged #5396, which

> makes lcalc a build prerequisite for the Sage library. Rather than leave

> things as they were and have everyone's build fail, I changed

> spkg/standard/deps. Someone should test that lcalc really is a build

> prereq for the library by removing line 442 of spkg/standard/deps and

> trying to build alpha1; it should fail with an error as seen in

> http://trac.sagemath.org/sage_trac/ticket/5396#comment:86. Someone

> should test that.

Dan,

that's risky. If the builds are performed in parallel, the order of builds would

not be fixed, so what works for 99 people, might fail for the 100th.

The best way to solve it is to find out for sure whether lcalc is a prerequisite

or not by analysis of the source code - not trial and error.

On my Sun Ultra 27 (a relatively fast machine), lcalc takes only 12 seconds to

build, so I doubt making it an unnecessary prerequisite would have a major

impact on the build time of Sage. The Sage library takes about 5 minutes to

build on here, and packages like Singular take over 9 minutes, so I don't think

this would slow down parallel builds significantly.

Dave

Jul 27, 2010, 7:32:45 AM7/27/10

to sage-release

On 27 Jul., 07:34, Dan Drake <dr...@kaist.edu> wrote:

> Mitesh Patel and I have released 4.5.2.alpha1.

I did a complete new build and it resolves the problems reported
> Mitesh Patel and I have released 4.5.2.alpha1.

earlier by me, but now there are two new ones:

sage -t "devel/sage/doc/en/tutorial/

latex.rst"

**********************************************************************

File "/scratch/scratch/schilly/sage/sage-4.5.2.alpha1/devel/sage/doc/

en/tutorial/latex.rst", line 459:

sage:

latex.extra_preamble()

Expected:

'\\usepackage{tikz}\n\\usepackage{tkz-graph}\n\\usepackage{tkz-

berge}\n'

Got:

'\\usepackage{tikz}

\n'

**********************************************************************

sage -t "devel/sage/sage/libs/lcalc/

lcalc_Lfunction.pyx"

-----------------------------------------------

Name of L_function:

number of dirichlet coefficients = 5

coefficients are periodic

b[1] = 1

b[2] = -1

b[3] = -1

b[4] = 1

b[5] = 0

Q = 1.26156626101

OMEGA = (1,4.96506830649e-17)

a = 1 (the quasi degree)

gamma[1] =0.5 lambda[1] =(0,0)

number of poles (of the completed L function) = 0

-----------------------------------------------

-----------------------------------------------

Name of L_function:

number of dirichlet coefficients = 5

coefficients are periodic

b[1] = (1,0)

b[2] = (6.12323399574e-17,1)

b[3] = (-6.12323399574e-17,-1)

b[4] = (-1,0)

b[5] = (0,0)

Q = 1.26156626101

OMEGA = (0.850650808352,0.525731112119)

a = 1 (the quasi degree)

gamma[1] =0.5 lambda[1] =(0.5,0)

number of poles (of the completed L function) = 0

-----------------------------------------------

**********************************************************************

File "/scratch/scratch/schilly/sage/sage-4.5.2.alpha1/devel/sage/sage/

libs/lcalc/lcalc_Lfunction.pyx", line 780:

sage: L.value(0.5)

Expected:

0

Got:

-1.28235854574334e-17

-----------------------------------------------

Name of L_function:

number of dirichlet coefficients = 5

coefficients are periodic

b[1] = 1

b[2] = -1

b[3] = -1

b[4] = 1

b[5] = 0

Q = 1.26156626101

OMEGA = (1,4.96506830649e-17)

a = 1 (the quasi degree)

gamma[1] =0.5 lambda[1] =(0,0)

number of poles (of the completed L function) = 0

-----------------------------------------------

**********************************************************************

Jul 27, 2010, 9:19:50 AM7/27/10

to sage-r...@googlegroups.com

On Tue, 27 Jul 2010 at 04:32AM -0700, Harald Schilly wrote:

> I did a complete new build and it resolves the problems reported

> earlier by me, but now there are two new ones:

>

> sage -t "devel/sage/doc/en/tutorial/

> latex.rst"

> I did a complete new build and it resolves the problems reported

> earlier by me, but now there are two new ones:

>

> sage -t "devel/sage/doc/en/tutorial/

> latex.rst"

That's known: #9607.

> sage -t "devel/sage/sage/libs/lcalc/

> lcalc_Lfunction.pyx"

Haven't seen that before. What platform did you build this on?

Dan

Jul 27, 2010, 9:26:57 AM7/27/10

to sage-release

On 27 Jul., 15:19, Dan Drake <dr...@kaist.edu> wrote:

> > sage -t "devel/sage/sage/libs/lcalc/

> > lcalc_Lfunction.pyx"

>

> Haven't seen that before. What platform did you build this on?

>

Ubuntu 8.10 32-bit
> > sage -t "devel/sage/sage/libs/lcalc/

> > lcalc_Lfunction.pyx"

>

> Haven't seen that before. What platform did you build this on?

>

Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz

gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)

It didn't happen in alpha0 though. Should I try rebuilding lcalc?

H

Jul 27, 2010, 10:46:30 AM7/27/10

to sage-release

With 64-bit KUbuntu 9.10 on Intel Core Duo long tests passed after

parallel package building.

On 32-bit Ubuntu 10.04 on Pentium M I get the same results as Harald,

though the non-zero value in the lcalc test is slightly different

(~e-18).

I should have a patch together soon for the latex/tikz failure at trac

9607.

Rob

parallel package building.

On 32-bit Ubuntu 10.04 on Pentium M I get the same results as Harald,

though the non-zero value in the lcalc test is slightly different

(~e-18).

I should have a patch together soon for the latex/tikz failure at trac

9607.

Rob

Jul 27, 2010, 1:39:56 PM7/27/10

to sage-r...@googlegroups.com

Dan Drake wrote:

> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1.tar

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1/

>

> This release has been tested on sage.math and bsd.math. A build on

> t2.math is underway. Please build and test.

> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1.tar

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1/

>

> This release has been tested on sage.math and bsd.math. A build on

> t2.math is underway. Please build and test.

Ubuntu 9.04 x86_64 (Core2, gcc 4.5.0, native code):

make build: OK (parallel build with 12 jobs)

make doc: OK (except the already reported 2 warnings and *)

make testlong: OK (all tests passed with #9607 applied)

Builds/tests on two 32-bit systems in progress...

Btw, thanks for managing this release, well done so far. :-)

-Leif

_____________

* As reported many times before (I haven't opened a ticket for that

though), there's still a conf.py file missing for thematic tutorials.

(This gives a Sphinx ERROR, that Sage simply ignores - I've opened a

ticket for *that* some time ago: #9426, but haven't yet had the time to

fix it.)

Jul 27, 2010, 2:06:40 PM7/27/10

to sage-release

There is one numerical noise from #5396 ticket. I will write a patch

which tests that L.value(0.5).abs() is less than 1e-14, instead of

current value of 0.

The long messages giving out some data about L function are from a

test function in lcalc library. It is helpful in testing. It just

prints out to standard output. Please ignore them.

Rishi

which tests that L.value(0.5).abs() is less than 1e-14, instead of

current value of 0.

The long messages giving out some data about L function are from a

test function in lcalc library. It is helpful in testing. It just

prints out to standard output. Please ignore them.

Rishi

Jul 27, 2010, 2:46:49 PM7/27/10

to sage-release

On Jul 26, 10:34 pm, Dan Drake <dr...@kaist.edu> wrote:

> Hello,

>

> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4...
> Hello,

>

> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4...

>

> This release has been tested on sage.math and bsd.math. A build on

> t2.math is underway. Please build and test.

I'm building on a bunch of machines; some have completed and some are
> This release has been tested on sage.math and bsd.math. A build on

> t2.math is underway. Please build and test.

still going. I'll give a full report in a few hours. Meanwhile, on

every machine which has gotten this far, I'm seeing a failure on sage/

parallel/decorate.py, perhaps related to #9501? This happens during

testing when I run "make ptestlong", and it is repeatable from the

command line afterwards. For example, I see this on sage.math. My

build is in /scratch/palmieri/sage-4.5.2.alpha1/ in case anyone wants

to see if they can replicate it.

sage -t -long devel/sage/sage/parallel/decorate.py

------------------------------------------------------------

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).

------------------------------------------------------------

**********************************************************************

File "/mnt/usb1/scratch/palmieri/sage-4.5.2.alpha1/devel/sage-main/

sage/parallel/decorate.py", line 300:

sage: g()

Expected:

'10'

Got:

[Errno 16] Device or resource busy: '/home/palmieri/.sage/temp/

sage.math.washington.edu/28889/dir_0/.nfs000000000059746a000693d1'

'10'

**********************************************************************

File "/mnt/usb1/scratch/palmieri/sage-4.5.2.alpha1/devel/sage-main/

sage/parallel/decorate.py", line 311:

sage: g()

Expected:

'a'

Got:

[Errno 16] Device or resource busy: '/home/palmieri/.sage/temp/

sage.math.washington.edu/28889/dir_1/.nfs0000000000597471000693d3'

'a'

**********************************************************************

File "/mnt/usb1/scratch/palmieri/sage-4.5.2.alpha1/devel/sage-main/

sage/parallel/decorate.py", line 300:

sage: g()

Expected:

'10'

Got:

[Errno 16] Device or resource busy: '/home/palmieri/.sage/temp/

sage.math.washington.edu/28889/dir_0/.nfs000000000059746a000693d1'

'10'

**********************************************************************

File "/mnt/usb1/scratch/palmieri/sage-4.5.2.alpha1/devel/sage-main/

sage/parallel/decorate.py", line 311:

sage: g()

Expected:

'a'

Got:

[Errno 16] Device or resource busy: '/home/palmieri/.sage/temp/

sage.math.washington.edu/28889/dir_1/.nfs0000000000597471000693d3'

'a'

**********************************************************************

--

John

Jul 27, 2010, 3:18:09 PM7/27/10

to sage-release

32-bit Ubuntu 10.04, 64-bit Kubuntu 9.10, five or six runs each, no

errors in either case.

On Jul 27, 11:46 am, John H Palmieri <jhpalmier...@gmail.com> wrote:

> sage -t -long devel/sage/sage/parallel/decorate.py

errors in either case.

On Jul 27, 11:46 am, John H Palmieri <jhpalmier...@gmail.com> wrote:

> sage -t -long devel/sage/sage/parallel/decorate.py

Jul 27, 2010, 4:22:35 PM7/27/10

to sage-release

On Jul 27, 10:39 am, leif <not.rea...@online.de> wrote:

> * As reported many times before (I haven't opened a ticket for that

> though), there's still a conf.py file missing for thematic tutorials.

A file conf.py is actually part of #8465. I may try to work on that
> * As reported many times before (I haven't opened a ticket for that

> though), there's still a conf.py file missing for thematic tutorials.

ticket soon to repair this problem. Or is Minh around? He's the

right person, but I don't know if he's active these days.

--

John

Jul 27, 2010, 4:31:27 PM7/27/10

to sage-r...@googlegroups.com

Ubuntu 9.04 x86_64 (Core2):

100 runs, all passed, no files left around afterwards.

Perhaps John's ptestlong did leave one [locked?]?

-Leif

Jul 27, 2010, 4:44:40 PM7/27/10

to sage-r...@googlegroups.com

I think that's a real bug that pops up when testing on a slow/nfs

filesystem. Martin Albrecht saw it once when refereeing the patch.

The patch should be bounced until I find a way to correctly deal with

this problem.

William

--

William Stein

Professor of Mathematics

University of Washington

http://wstein.org

Jul 27, 2010, 5:03:08 PM7/27/10

to sage-r...@googlegroups.com

William Stein wrote:

> On Tue, Jul 27, 2010 at 1:31 PM, leif <not.r...@online.de> wrote:

>> Rob Beezer wrote:

>>> 32-bit Ubuntu 10.04, 64-bit Kubuntu 9.10, five or six runs each, no

>>> errors in either case.

>>>

>>> On Jul 27, 11:46 am, John H Palmieri <jhpalmier...@gmail.com> wrote:

>>>> sage -t -long devel/sage/sage/parallel/decorate.py

>> Ubuntu 9.04 x86_64 (Core2):

>>

>> 100 runs, all passed, no files left around afterwards.

>>

>> Perhaps John's ptestlong did leave one [locked?]?

>>

>

> I think that's a real bug that pops up when testing on a slow/nfs

> filesystem. Martin Albrecht saw it once when refereeing the patch.

> The patch should be bounced until I find a way to correctly deal with

> this problem.

> On Tue, Jul 27, 2010 at 1:31 PM, leif <not.r...@online.de> wrote:

>> Rob Beezer wrote:

>>> 32-bit Ubuntu 10.04, 64-bit Kubuntu 9.10, five or six runs each, no

>>> errors in either case.

>>>

>>> On Jul 27, 11:46 am, John H Palmieri <jhpalmier...@gmail.com> wrote:

>>>> sage -t -long devel/sage/sage/parallel/decorate.py

>> Ubuntu 9.04 x86_64 (Core2):

>>

>> 100 runs, all passed, no files left around afterwards.

>>

>> Perhaps John's ptestlong did leave one [locked?]?

>>

>

> I think that's a real bug that pops up when testing on a slow/nfs

> filesystem. Martin Albrecht saw it once when refereeing the patch.

> The patch should be bounced until I find a way to correctly deal with

> this problem.

I've rerun the test 20 times with a timeout that always "hits"; at least

this doesn't leave any files (nor orphans) around. I'll try later with

DOT_SAGE pointing to some NFS-mounted filesystem...

Btw, we have uses of $DOT_SAGE/tmp, $DOT_SAGE/tmp/tmp and $DOT_SAGE/temp

(perhaps even others, too).

-Leif

Jul 27, 2010, 5:07:21 PM7/27/10

to sage-release

On Jul 27, 1:44 pm, William Stein <wst...@gmail.com> wrote:

> On Tue, Jul 27, 2010 at 1:31 PM, leif <not.rea...@online.de> wrote:

> > Rob Beezer wrote:

> >> 32-bit Ubuntu 10.04, 64-bit Kubuntu 9.10, five or six runs each, no

> >> errors in either case.

>

> >> On Jul 27, 11:46 am, John H Palmieri <jhpalmier...@gmail.com> wrote:

> >>> sage -t -long devel/sage/sage/parallel/decorate.py

>

> > Ubuntu 9.04 x86_64 (Core2):

>

> > 100 runs, all passed, no files left around afterwards.

>

> > Perhaps John's ptestlong did leave one [locked?]?

>

> I think that's a real bug that pops up when testing on a slow/nfs

> filesystem. Martin Albrecht saw it once when refereeing the patch.

> The patch should be bounced until I find a way to correctly deal with

> this problem.

More information: I saw this failure on all of the skynet machines
> > Rob Beezer wrote:

> >> 32-bit Ubuntu 10.04, 64-bit Kubuntu 9.10, five or six runs each, no

> >> errors in either case.

>

> >> On Jul 27, 11:46 am, John H Palmieri <jhpalmier...@gmail.com> wrote:

> >>> sage -t -long devel/sage/sage/parallel/decorate.py

>

> > Ubuntu 9.04 x86_64 (Core2):

>

> > 100 runs, all passed, no files left around afterwards.

>

> > Perhaps John's ptestlong did leave one [locked?]?

>

> I think that's a real bug that pops up when testing on a slow/nfs

> filesystem. Martin Albrecht saw it once when refereeing the patch.

> The patch should be bounced until I find a way to correctly deal with

> this problem.

that have gotten to that test so far, building in my home directory

there. Is that nfs? I also saw it on sage.math, building in /

scratch. After a failure on sage.math, I deleted my whole .sage

directory and got the failure again (running just the one test from

the command line). Then I did

export DOT_SAGE=/scratch/palmieri/.sage

and ran the test several more times. The first time, it ran for more

than three minutes before I hit ctrl-c. The second time it passed.

The third time I ran "verbose" and it claimed to pass, although toward

the end it says

------------------------------------------------------------

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).

------------------------------------------------------------

3 items had no tests:

__main__

__main__.change_warning_output

__main__.warning_function

10 items passed all tests:

2 tests in __main__.example_0

6 tests in __main__.example_1

2 tests in __main__.example_2

3 tests in __main__.example_3

6 tests in __main__.example_4

12 tests in __main__.example_5

2 tests in __main__.example_6

4 tests in __main__.example_7

6 tests in __main__.example_8

19 tests in __main__.example_9

62 tests in 13 items.

62 passed and 0 failed.

Test passed.

[5.2 s]

----------------------------------------------------------------------

All tests passed!

Total time for all tests: 5.2 seconds

Is this a serious bug in the doctesting structure? How can a

segmentation fault not lead to a doctest failure?

--

John

Jul 27, 2010, 5:12:58 PM7/27/10

to sage-release

segmentation fault is supposed to be caught by the @fork'ed process.

So it's okay, right?

--

John

Jul 27, 2010, 5:23:40 PM7/27/10

to sage-r...@googlegroups.com

Yes. The referee specifically wanted an example of a segfault.

@fork is a cool-arse new decorator we wrote that lets you do stuff

like:

@fork

def crazy_function(...):

crazy stuff that segfaults, leaks memory, etc.

z = crazy_function(...)

and happily go along without any serious trouble.

William

Jul 27, 2010, 7:02:58 PM7/27/10

to sage-r...@googlegroups.com

On Tue, Jul 27, 2010 at 1:34 AM, Dan Drake <dr...@kaist.edu> wrote:

> Hello,

>

> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1.tar

>

> Hello,

>

> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1.tar

>

...

>

> Blocker ticket #9582 has not been fixed, so there will be at least one

> doctest failure on OS X.

The following tests failed:

sage -t "devel/sage/doc/en/tutorial/latex.rst"

sage -t "devel/sage/sage/symbolic/random_tests.py"

Total time for all tests: 6966.2 seconds

This is on a power mac running 10.6.4.

>

...

Jul 27, 2010, 7:35:46 PM7/27/10

to sage-r...@googlegroups.com

David Joyner wrote:

> On Tue, Jul 27, 2010 at 1:34 AM, Dan Drake <dr...@kaist.edu> wrote:

>> Hello,

>>

>> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>>

>> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1.tar

>>

>

> ...

>

>> Blocker ticket #9582 has not been fixed, so there will be at least one

>> doctest failure on OS X.

>

>

> The following tests failed:

>

>

> sage -t "devel/sage/doc/en/tutorial/latex.rst"

> On Tue, Jul 27, 2010 at 1:34 AM, Dan Drake <dr...@kaist.edu> wrote:

>> Hello,

>>

>> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>>

>> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4.5.2.alpha1.tar

>>

>

> ...

>

>> Blocker ticket #9582 has not been fixed, so there will be at least one

>> doctest failure on OS X.

>

>

> The following tests failed:

>

>

> sage -t "devel/sage/doc/en/tutorial/latex.rst"

That one is most probably fixed at #9607 (already positive review).

Jul 27, 2010, 7:42:44 PM7/27/10

to sage-release

On Jul 26, 10:34 pm, Dan Drake <dr...@kaist.edu> wrote:

> Hello,

>

> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>

>

> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4...

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4...

>

>

> Upgrade path:

>

> http://sage.math.washington.edu/home/release/sage-4.5.2.alpha1/sage-4...

>

> This release has been tested on sage.math and bsd.math. A build on

> t2.math is underway. Please build and test.

Here's what I have so far: I've built successfully and only seen
> t2.math is underway. Please build and test.

previously reported failures (decorate.py, lcalc_Lfunction.pyx, and

random_tests.py on OS X) on the following machines:

- sage.math

- t2 (I started this build late and doctesting is still going)

- a Mac OS X box

- skynet machines cleo, eno, flavius, iras, lena, menas, sextus,

taurus.

skynet machine cicero is still doctesting.

skynet machine mark (sparc solaris) is still building: it's been more

than 8 hours now. We'll have a race: see if you can release rc1

before mark finishes building and doctesting alpha1. On the bright

side, on this solaris machine with the new gcc compiler built to use

the sun linker, it's gotten farther in the build than I've ever seen.

skynet machine fulvia (solaris on x86): the build failed. I think gcc

is misconfigured.

In case you're keeping score, I saw the lcalc_Lfunction failure on

cicero (x86-Linux-pentium4-fc), cleo (ia64-Linux-rhel), and iras (ia64-

Linux-suse).

On iras I also saw the non-timeout failure described at

http://trac.sagemath.org/sage_trac/ticket/9584: this failure was not

fixed by this ticket, but it also only occurs sporadically.

--

John

Jul 27, 2010, 10:43:08 PM7/27/10

to sage-r...@googlegroups.com

On Tue, 27 Jul 2010 at 11:06AM -0700, r Rishikesh wrote:

> There is one numerical noise from #5396 ticket. I will write a patch

> which tests that L.value(0.5).abs() is less than 1e-14, instead of

> current value of 0.

> There is one numerical noise from #5396 ticket. I will write a patch

> which tests that L.value(0.5).abs() is less than 1e-14, instead of

> current value of 0.

The ticket for those lcalc doctest failures is #9615. It's a blocker for

4.5.2.

Dan

Jul 27, 2010, 10:59:03 PM7/27/10

to sage-r...@googlegroups.com

This is now #9616. William, you mentioned that we should just yank the

patch from #9501; is that what you would like for 4.5.2?

As a note to anyone who would like to do that, you can use

hg backout --merge 21d255f024a0

to create a changeset that represents the inverse of the patch at #9501.

Dan

Jul 27, 2010, 11:24:33 PM7/27/10

to sage-r...@googlegroups.com

On 07/28/10 12:42 AM, John H Palmieri wrote:

> skynet machine mark (sparc solaris) is still building: it's been more

> than 8 hours now. We'll have a race: see if you can release rc1

> before mark finishes building and doctesting alpha1. On the bright

> side, on this solaris machine with the new gcc compiler built to use

> the sun linker, it's gotten farther in the build than I've ever seen.

That's good news, though I think later you said on a ticket it failed at cvxopt.

It should be possible to build on mark. I've built Sage on a range of SPARCs

* Netra T1

* Blade 1000

* Blade 2000

* T5240

I'm sure we can add Blade 2500 to that list!

> skynet machine fulvia (solaris on x86): the build failed. I think gcc

> is misconfigured.

Was this a 32-bit or 64-bit build?

I've managed to build Sage on OpenSolaris on x86 hardware as a 64-bit binary,

but it crashes at startup. But it needs a few patches - not all of which I have

put on tickets. I hit problems earlier in the build process when I first tried a

32-bit build, and decided it was less hassle and more worthwhile to just

concentrate on a 64-bit build. So I have not tried 32-bit much on x86

> John

>

Dave

Jul 28, 2010, 2:39:06 PM7/28/10

to sage-release

On Jul 27, 7:34 am, Dan Drake <dr...@kaist.edu> wrote:

> Hello,

>

> Mitesh Patel and I have released 4.5.2.alpha1. Source tarball is at

>

>

> Please build and test.

Hello,

Successfully built on a MacBook Pro with Mac OS X 10.5.8.

Below build success report and make testlong error list.

Samuel

[Tue 2010-07-27]

$ make

...

build succeeded.

Build finished. The built documents can be found in /Applications/

s452a1/devel/sage/doc/output/html/fr/tutorial

$make testlong

...

The following tests failed:

sage -t -long "devel/sage/doc/en/tutorial/latex.rst"

sage -t -long "devel/sage/sage/interfaces/ecm.py" # Time out

sage -t -long "devel/sage/sage/symbolic/random_tests.py"

Total time for all tests: 17431.1 seconds

Jul 28, 2010, 3:46:27 PM7/28/10

to sage-r...@googlegroups.com

Samuel Lelievre wrote:

> Successfully built on a MacBook Pro with Mac OS X 10.5.8.

> Below build success report and make testlong error list.

>

> [...]> Successfully built on a MacBook Pro with Mac OS X 10.5.8.

> Below build success report and make testlong error list.

>

>

> $make testlong

>

> ...

>

> The following tests failed:

>

>

> sage -t -long "devel/sage/doc/en/tutorial/latex.rst"

This one is fixed at #9607.

http://trac.sagemath.org/sage_trac/ticket/9607

> sage -t -long "devel/sage/sage/interfaces/ecm.py" # Time out

You can increase the timeouts (in seconds) by e.g.

$ export SAGE_TIMEOUT=900 # 15 minutes, for testing without "-long"

$ export SAGE_TIMEOUT_LONG=3600 # 1 hour, for doctesting with "-long"

(The timeouts are wall/real time allowed for each *file* being tested,

not CPU/user time.)

> sage -t -long "devel/sage/sage/symbolic/random_tests.py"

This is most probably #9582, which has not been fixed yet.

http://trac.sagemath.org/sage_trac/ticket/9582

> Total time for all tests: 17431.1 seconds

Wow! ;-)

-Leif

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu