Sage 3.2.2.rc1 released

[mabshoff]

Hello folks,

here goes 3.2.2.rc1. We finally merge the Sage Words library and with
that the last major piece of code is in 3.2.2. We also fixed a bad
memory leak in coercion due to some debug code that snuck in. So 3.2.2
should be very solid.

Unfortunately there will be a 3.2.2.rc2 with at least an ATLAS update
since the new sage.math needs excessive build time to build the
current atlas.spkg. I attempted to monkey patch the fix in, but it
doesn't work, so we will do the 3.8.2 upgrade in 3.2.2.rc2. But since
Mike Hansen will rebase 12MB patches for the ReST transition very
little new code and especially invasive patches will have to wait for
3.3.1 or 3.4 - depending if we need to do a quick bug fix release.

Since the sage.math switchover to new hardware is imminent [it has
been "tomorrow" for about two days now :)] I am sticking the tarball
also on to sagemath.org. The sage.math only binary will not work on
the new sage.math hardware, so I will not copy it over.

Sources and a sage.math only binary is in

http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/

You can upgrade to this release by running

./sage -upgrade http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/sage-3.2.2.rc1/

In case sage.math is down and/or unreachable the sources to upgrade as
well as the tarball is temporarily at

http://sagemath.org/temp/

Please give this release a good beating and report any issues.

Cheers,

Michael

#4237: William Stein: magma -- finite field matrix conversions
[Reviewed by Michael Abshoff]
#4639: Robert Bradshaw: bad memory leak with exponentiation [Reviewed
by Michael Abshoff]
#4653: Franco Saliola, Arnaud Bergeron, Amy Glen, Sebastien Labbe:
Merge sage-words code into Sage [Reviewed by Mike Hansen]
#4778: Ronan Paixao: Creates Scilab pexpect interface [Reviewed by
Jaap Spies, Michael Abshoff]
#4803: Sebastien Barthelemy: improvements to the polyhedra module
documentation [Reviewed by Marshall Hampton]
#4811: Gary Furnish: Sage 3.2.2.a2: doctesting line numbers in report
are now wrong [Reviewed by Michael Abshoff]
#4816: John Cremona: fix numerical noise issue in
ell_rational_field.py [Reviewed by Michael Abshoff]
#4819: Robert Bradshaw: update Cython to 0.10.3 [Reviewed by Michael
Abshoff]

[Jaap Spies]

On Fedora 9, 32 bits:

No surprise:

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

The following tests failed:

sage -t pha2/devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed
----------------------------------------------------------------------
Total time for all tests: 4613.0 seconds

Jaap

[Jaap Spies]

Jaap Spies wrote:

>
> ----------------------------------------------------------------------
>
> The following tests failed:
>
> sage -t pha2/devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed
> ----------------------------------------------------------------------
> Total time for all tests: 4613.0 seconds
>

I don't like the prefix pha2 :(! I prefer the possibility to copy and paste in a new test.

Jaap

[mabshoff]

On Dec 17, 1:27 pm, Jaap Spies <j.sp...@hccnet.nl> wrote:
> Jaap Spies wrote:

Hi Jaap,

Hmm, looks like a line wrap, but I guess this might be a side effect
of #4811. Can you post the actual full failure of that test, i.e
showing how you invoke the test and so on?

> Jaap

Cheers,

Michael

[Gary Furnish]

It should give the relative path to where you ran the test from... if
its not, thats a bug.

[Jaap Spies]

Gary Furnish wrote:
> It should give the relative path to where you ran the test from... if
> its not, thats a bug.
>

I did ./sage -tp 2 devel/sage/sage

Jaap

[mhampton]

All tests passed on an intel mac, 10.4.11.

-M. Hampton

On Dec 17, 12:20 pm, mabshoff <mabsh...@googlemail.com> wrote:
> Hello folks,
>
> here goes 3.2.2.rc1. We finally merge the Sage Words library and with
> that the last major piece of code is in 3.2.2. We also fixed a bad
> memory leak in coercion due to some debug code that snuck in. So 3.2.2
> should be very solid.
>
> Unfortunately there will be a 3.2.2.rc2 with at least an ATLAS update
> since the new sage.math needs excessive build time to build the
> current atlas.spkg. I attempted to monkey patch the fix in, but it
> doesn't work, so we will do the 3.8.2 upgrade in 3.2.2.rc2. But since
> Mike Hansen will rebase 12MB patches for the ReST transition very
> little new code and especially invasive patches will have to wait for
> 3.3.1 or 3.4 - depending if we need to do a quick bug fix release.
>
> Since the sage.math switchover to new hardware is imminent [it has
> been "tomorrow" for about two days now :)] I am sticking the tarball
> also on to sagemath.org. The sage.math only binary will not work on
> the new sage.math hardware, so I will not copy it over.
>
> Sources and a sage.math only binary is in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/
>
> You can upgrade to this release by running
>

> ./sage -upgradehttp://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/sa...

[Jaap Spies]

Hi Michael,

[jaap@paix sage-3.2.2.alpha2]$ ./sage -t devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed
sage -t "devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py"
**********************************************************************
File "/home/jaap/work/downloads/sage-3.2.2.alpha2/devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py", line 58:
sage: S.<a,b> = R.quotient((x^2 + y^2, 17))
Expected:
verbose 0 ... Warning: falling back to very slow toy implementation.
Got nothing
**********************************************************************
1 items had failures:
1 of 47 in __main__.example_0
***Test Failed*** 1 failures.
For whitespace errors, see the file /home/jaap/downloads/sage-3.2.2.alpha2/tmp/.doctest_multi_polynomial_ideal.py
[16.5 s]
exit code: 1024

----------------------------------------------------------------------
The following tests failed:

sage -t "devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py"
Total time for all tests: 16.5 seconds

At the end of ./sage -tp 2 devel/sage/sage

I got

> ----------------------------------------------------------------------
>
> The following tests failed:
>
> sage -t pha2/devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed
> ----------------------------------------------------------------------

Jaap

[Justin C. Walker]

On Dec 17, 2008, at 10:20 , mabshoff wrote:

>
> Hello folks,
>
> here goes 3.2.2.rc1. We finally merge the Sage Words library and with
> that the last major piece of code is in 3.2.2. We also fixed a bad
> memory leak in coercion due to some debug code that snuck in. So 3.2.2
> should be very solid.
>
> Unfortunately there will be a 3.2.2.rc2 with at least an ATLAS update
> since the new sage.math needs excessive build time to build the
> current atlas.spkg. I attempted to monkey patch the fix in, but it
> doesn't work, so we will do the 3.8.2 upgrade in 3.2.2.rc2. But since
> Mike Hansen will rebase 12MB patches for the ReST transition very
> little new code and especially invasive patches will have to wait for
> 3.3.1 or 3.4 - depending if we need to do a quick bug fix release.
>
> Since the sage.math switchover to new hardware is imminent [it has
> been "tomorrow" for about two days now :)] I am sticking the tarball
> also on to sagemath.org. The sage.math only binary will not work on
> the new sage.math hardware, so I will not copy it over.
>
> Sources and a sage.math only binary is in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/
>
> You can upgrade to this release by running
>
> ./sage -upgrade http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/sage-3.2.2.rc1/

Built (full build) w/o problems on Mac OS X, 10.5.6 (Dual Quad Xeon).
One test failure:
sage -t "devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py"
due to having M2 accessible from my PATH. I clipped PATH and reran
the test; this time no failure.

Full build on Mac OS X, 10.4.11 underway.

Justin

--
Justin C. Walker
Curmudgeon-at-large
--
Network, n., Difference between work
charged for and work done

[John Cremona]

Built fine and all tests passed on: 32-bit ubuntu; 64-bit Suse.

John

2008/12/18 Justin C. Walker <jus...@mac.com>:

[daveloeffler]

Same for me on 32-bit Suse.

On Dec 18, 8:54 am, "John Cremona" <john.crem...@gmail.com> wrote:
> Built fine and all tests passed on: 32-bit ubuntu;  64-bit Suse.
>
> John
>
> 2008/12/18 Justin C. Walker <jus...@mac.com>:
>
>
>
> > On Dec 17, 2008, at 10:20 , mabshoff wrote:
>
> >> Hello folks,
>
> >> here goes 3.2.2.rc1. We finally merge the Sage Words library and with
> >> that the last major piece of code is in 3.2.2. We also fixed a bad
> >> memory leak in coercion due to some debug code that snuck in. So 3.2.2
> >> should be very solid.
>
> >> Unfortunately there will be a 3.2.2.rc2 with at least an ATLAS update
> >> since the new sage.math needs excessive build time to build the
> >> current atlas.spkg. I attempted to monkey patch the fix in, but it
> >> doesn't work, so we will do the 3.8.2 upgrade in 3.2.2.rc2. But since
> >> Mike Hansen will rebase 12MB patches for the ReST transition very
> >> little new code and especially invasive patches will have to wait for
> >> 3.3.1 or 3.4 - depending if we need to do a quick bug fix release.
>
> >> Since the sage.math switchover to new hardware is imminent [it has
> >> been "tomorrow" for about two days now :)] I am sticking the tarball
> >> also on to sagemath.org. The sage.math only binary will not work on
> >> the new sage.math hardware, so I will not copy it over.
>
> >> Sources and a sage.math only binary is in
>
> >>    http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/
>
> >> You can upgrade to this release by running
>

> >>    ./sage -upgradehttp://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/sa...

[Justin C. Walker]

On Dec 17, 2008, at 10:20 , mabshoff wrote:

>
> Hello folks,
>
> here goes 3.2.2.rc1. We finally merge the Sage Words library and with
> that the last major piece of code is in 3.2.2. We also fixed a bad
> memory leak in coercion due to some debug code that snuck in. So 3.2.2
> should be very solid.
>
> Unfortunately there will be a 3.2.2.rc2 with at least an ATLAS update
> since the new sage.math needs excessive build time to build the
> current atlas.spkg. I attempted to monkey patch the fix in, but it
> doesn't work, so we will do the 3.8.2 upgrade in 3.2.2.rc2. But since
> Mike Hansen will rebase 12MB patches for the ReST transition very
> little new code and especially invasive patches will have to wait for
> 3.3.1 or 3.4 - depending if we need to do a quick bug fix release.
>
> Since the sage.math switchover to new hardware is imminent [it has
> been "tomorrow" for about two days now :)] I am sticking the tarball
> also on to sagemath.org. The sage.math only binary will not work on
> the new sage.math hardware, so I will not copy it over.
>
> Sources and a sage.math only binary is in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/

Full build on Mac OS X, 10.4.11 (Core 2 Duo) completed without
problems. All tests passed!

Justin

--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's income
-----------
--
They said it couldn't be done, but sometimes,
it doesn't work out that way.
- Casey Stengel
--

[Kiran Kedlaya]

I get the same failure in multi_polynomial_ideal.py in 64-bit RHEL5
(and nothing else).

Kiran

On Dec 17, 4:43 pm, Jaap Spies <j.sp...@hccnet.nl> wrote:
> mabshoff wrote:
> > On Dec 17, 1:27 pm, Jaap Spies <j.sp...@hccnet.nl> wrote:
> >> Jaap Spies wrote:
>
> > Hi Jaap,
>
> >>> ----------------------------------------------------------------------
> >>> The following tests failed:
> >>>    sage -t  pha2/devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed
> >>> ----------------------------------------------------------------------
> >>> Total time for all tests: 4613.0 seconds
> >> I don't like the prefix pha2 :(!  I prefer the possibility to copy and paste in a new test.
>
> > Hmm, looks like a line wrap, but I guess this might be a side effect
> > of #4811. Can you post the actual full failure of that test, i.e
> > showing how you invoke the test and so on?
>
> Hi Michael,
>
> [jaap@paix sage-3.2.2.alpha2]$ ./sage -t  devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed
> sage -t  "devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py"
> **********************************************************************

> File "/home/jaap/work/downloads/sage-3.2.2.alpha2/devel/sage/sage/rings/polynomi al/multi_polynomial_ideal.py", line 58:

[John H Palmieri]

On Dec 17, 10:20 am, mabshoff <mabsh...@googlemail.com> wrote:
>
> Please give this release a good beating and report any issues.

On Intel Mac OS X 10.5, built fine from scratch, all tests passed.
However, if I run 'sage -clone TEMP' and then run sage, I get an error
from an accent in "Thiery":

SyntaxError: Non-ASCII character '\xc3' in file /Applications/
sage_builds/sage-3.2.2.rc1/local/lib/python2.5/site-packages/sage/
combinat/ranker.py on line 3, but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details (ranker.py, line
3)
Error importing ipy_profile_sage - perhaps you should run %upgrade?
WARNING: Loading of ipy_profile_sage failed.

If I modify ranker.py to delete the accent, the error goes away.

John

[mabshoff]

On Dec 18, 10:05 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:
> On Dec 17, 10:20 am, mabshoff <mabsh...@googlemail.com> wrote:
>

Hi,

>
> > Please give this release a good beating and report any issues.
>
> On Intel Mac OS X 10.5, built fine from scratch, all tests passed.
> However, if I run 'sage -clone TEMP' and then run sage, I get an error
> from an accent in "Thiery":
>
> SyntaxError: Non-ASCII character '\xc3' in file /Applications/
> sage_builds/sage-3.2.2.rc1/local/lib/python2.5/site-packages/sage/

> combinat/ranker.py on line 3, but no encoding declared; seehttp://www.python.org/peps/pep-0263.htmlfor details (ranker.py, line

> 3)
> Error importing ipy_profile_sage - perhaps you should run %upgrade?
> WARNING: Loading of ipy_profile_sage failed.
>
> If I modify ranker.py to delete the accent, the error goes away.

I thought that had been fixed by another patch, but apparently it
didn't. I fixed this and one other documentation build issue at #4828,
so if anyone reviews that patch I will cut 3.2.2.

>   John

Cheers,

Michael

[Justin C. Walker]

Hi, Michael,

On Dec 18, 2008, at 22:36 , mabshoff wrote:
> On Dec 18, 10:05 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:
>> On Dec 17, 10:20 am, mabshoff <mabsh...@googlemail.com> wrote:

[snip]

>> If I modify ranker.py to delete the accent, the error goes away.
>
> I thought that had been fixed by another patch, but apparently it
> didn't. I fixed this and one other documentation build issue at #4828,
> so if anyone reviews that patch I will cut 3.2.2.

I applied the 'doc' patch to the rc1 build, and it failed:

applying /SandBox/DownLoads/trac_4828_doc.patch
unable to find 'commontex/patchlevel.tex' for patching
1 out of 1 hunk FAILED -- saving rejects to file commontex/
patchlevel.tex.rej
unable to find 'ref/files' for patching
1 out of 1 hunk FAILED -- saving rejects to file ref/files.rej
abort: patch failed to apply

This seems to happen whether I apply the 'sage' patch first, or not.

Thoughts?

Justin

--
Justin C. Walker, Curmudgeon-at-Large
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email

[mabshoff]

On Dec 18, 11:00 pm, "Justin C. Walker" <jus...@mac.com> wrote:
> Hi, Michael,

Hi Justin,

> I applied the 'doc' patch to the rc1 build, and it failed:
>
> applying /SandBox/DownLoads/trac_4828_doc.patch
> unable to find 'commontex/patchlevel.tex' for patching
> 1 out of 1 hunk FAILED -- saving rejects to file commontex/
> patchlevel.tex.rej
> unable to find 'ref/files' for patching
> 1 out of 1 hunk FAILED -- saving rejects to file ref/files.rej
> abort: patch failed to apply
>
> This seems to happen whether I apply the 'sage' patch first, or not.

Yes.

> Thoughts?

That is expected since my patchlevel.tex is different than in
3.2.2.rc1 since I have run the documentation rebuild script a couple
times. Just delete that hunk, all that counts is the removal of
word.tex

> Justin

Cheers,

Michael

[Justin C. Walker]

On Dec 18, 2008, at 23:03 , mabshoff wrote:

>
>
>
> On Dec 18, 11:00 pm, "Justin C. Walker" <jus...@mac.com> wrote:
>> Hi, Michael,
>
> Hi Justin,
>
>> I applied the 'doc' patch to the rc1 build, and it failed:
>>
>> applying /SandBox/DownLoads/trac_4828_doc.patch
>> unable to find 'commontex/patchlevel.tex' for patching
>> 1 out of 1 hunk FAILED -- saving rejects to file commontex/
>> patchlevel.tex.rej
>> unable to find 'ref/files' for patching
>> 1 out of 1 hunk FAILED -- saving rejects to file ref/files.rej
>> abort: patch failed to apply
>>
>> This seems to happen whether I apply the 'sage' patch first, or not.
>
> Yes.
>
>> Thoughts?
>
> That is expected since my patchlevel.tex is different than in
> 3.2.2.rc1 since I have run the documentation rebuild script a couple
> times. Just delete that hunk, all that counts is the removal of
> word.tex

Rats. Dan beat me to it.

You're good to go.

Justin

--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
My wife 'n kids 'n dogs are gone,
I can't get Jesus on the phone,
But Ol' Milwaukee's Best is my best friend.
-----------

[mhampton]

I had an interesting failure on an intel mac running 10.5. Let me
describe my setup a bit since I think its relevant: because of the new
upgrade flexibility, I decided to have a "stable" sage and an
"unstable" sage on my machine, and I delete almost all of my other
sage builds. I changed the sage script in my /usr/bin to point to the
unstable one, which I called "wildsage". One of the sage folders I
deleted was for 3.2.1.rc0. With all that in mind, here is the error I
got in qqbar:

sage -t "devel/sage/sage/rings/qqbar.py"
Exception exceptions.TypeError: TypeError(RuntimeError('Unable to
start maxima',),) in 'sage.structure.parent_old._unregister_pair'
ignored
**********************************************************************
File "/Users/mh/sagestuff/wildsage/devel/sage/sage/rings/qqbar.py",
line 2556:
sage: QQbar(I) == QQbar(I * (2^100+1)/(2^100))
Exception raised:
Traceback (most recent call last):
File "/Users/mh/sagestuff/sage-3.2.1.rc0/local/bin/
ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Users/mh/sagestuff/sage-3.2.1.rc0/local/bin/
sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Users/mh/sagestuff/sage-3.2.1.rc0/local/bin/
ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_64[3]>", line 1, in <module>
QQbar(I) == QQbar(I * (Integer(2)**Integer(100)+Integer(1))/
(Integer(2)**Integer(100)))###line 2556:
sage: QQbar(I) == QQbar(I * (2^100+1)/(2^100))
File "element.pyx", line 1102, in
sage.structure.element.RingElement.__mul__ (sage/structure/element.c:
8632)
File "coerce.pyx", line 663, in
sage.structure.coerce.CoercionModel_cache_maps.bin_op (sage/structure/
coerce.c:5359)
File "coerce.pyx", line 1079, in
sage.structure.coerce.CoercionModel_cache_maps.get_action (sage/
structure/coerce.c:9137)
File "coerce.pyx", line 1192, in
sage.structure.coerce.CoercionModel_cache_maps.discover_action (sage/
structure/coerce.c:10066)
File "parent.pyx", line 1063, in
sage.structure.parent.Parent.get_action (sage/structure/parent.c:9294)
File "parent_old.pyx", line 586, in
sage.structure.parent_old.Parent._get_action_ (sage/structure/
parent_old.c:6506)
File "parent_old.pyx", line 197, in
sage.structure.parent_old.Parent.get_action_c (sage/structure/
parent_old.c:2411)
File "parent_old.pyx", line 209, in
sage.structure.parent_old.Parent.get_action_impl (sage/structure/
parent_old.c:2698)
File "parent_old.pyx", line 268, in
sage.structure.parent_old.Parent.get_action_c_impl (sage/structure/
parent_old.c:3359)
File "parent_old.pyx", line 632, in
sage.structure.parent_old._register_pair (sage/structure/parent_old.c:
7314)
NotImplementedError: Infinite loop in multiplication of
0 (parent Symbolic Ring)
and 1 (parent Integer Ring)!

**********************************************************************
1 items had failures:

1 of 4 in __main__.example_64
***Test Failed*** 1 failures.

It looks like its trying to use the maxima from my deleted 3.2.1.rc0
build for some reason.

My ppc powerbook is still slaving away on tests, its almost done and
so far just has timeout failures on eisenstein and calculus.py.

-M. Hampton

On Dec 17, 12:20 pm, mabshoff <mabsh...@googlemail.com> wrote:

> Hello folks,
>
> here goes 3.2.2.rc1. We finally merge the Sage Words library and with
> that the last major piece of code is in 3.2.2. We also fixed a bad
> memory leak in coercion due to some debug code that snuck in. So 3.2.2
> should be very solid.
>
> Unfortunately there will be a 3.2.2.rc2 with at least an ATLAS update
> since the new sage.math needs excessive build time to build the
> current atlas.spkg. I attempted to monkey patch the fix in, but it
> doesn't work, so we will do the 3.8.2 upgrade in 3.2.2.rc2. But since
> Mike Hansen will rebase 12MB patches for the ReST transition very
> little new code and especially invasive patches will have to wait for
> 3.3.1 or 3.4 - depending if we need to do a quick bug fix release.
>
> Since the sage.math switchover to new hardware is imminent [it has
> been "tomorrow" for about two days now :)] I am sticking the tarball
> also on to sagemath.org. The sage.math only binary will not work on
> the new sage.math hardware, so I will not copy it over.
>
> Sources and a sage.math only binary is in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/
>
> You can upgrade to this release by running
>

> ./sage -upgradehttp://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.2/sa...

[mabshoff]

On Dec 19, 5:21 am, mhampton <hampto...@gmail.com> wrote:
> I had an interesting failure on an intel mac running 10.5.  Let me
> describe my setup a bit since I think its relevant: because of the new
> upgrade flexibility, I decided to have a "stable" sage and an
> "unstable" sage on my machine, and I delete almost all of my other
> sage builds.  I changed the sage script in my /usr/bin to point to the
> unstable one, which I called "wildsage".  One of the sage folders I
> deleted was for 3.2.1.rc0.  With all that in mind, here is the error I
> got in qqbar:
>
> sage -t  "devel/sage/sage/rings/qqbar.py"
> Exception exceptions.TypeError: TypeError(RuntimeError('Unable to
> start maxima',),) in 'sage.structure.parent_old._unregister_pair'
> ignored

<SNIP>

> It looks like its trying to use the maxima from my deleted 3.2.1.rc0
> build for some reason.

Something else looks wrong, i.e the string "3.2.1.rc0" should not
appear in the backtrace at all. There can be numerous issues like a
bungled SAGE_ROOT setting at some point that is now causing trouble.
Does maxima from that install work via "sage -maxima"? Just because
the doctest claims that is doesn't start does not mean that it doesn't
work in general. I would also check the repos for unresolved merges,
multiple heads and so on. Some environment variable can also play a
role here. Since linking the sage script just works I would always
recommend linking it into $PATH somewhere under a different name
instead of setting $SAGE_ROOT manually as recommended in the
documentation since it is too easy to scrw that up. The checking code
if SAGE_ROOT is overwritten also makes it too still possible to shoot
yourself in the foot.

> My ppc powerbook is still slaving away on tests, its almost done and
> so far just has timeout failures on eisenstein and calculus.py.

Ok. I would suggest to rerun the failed tests with -long to see what
happens. If the CPU usage stays near 0 it is a synchronization /
maxima issue, but the timeout will be raised after 30 minutes.

> -M. Hampton

Cheers,

Michael

[mhampton]

I reran the test and it passed. sage -maxima works fine. I did
realize that I said something incorrect, it looks like the install I
am using was originally from the 3.2.1.rc0 source, and I have upgraded
and renamed it several times since then. So it is not too weird an
event. Some of the c source code still makes references to the
sage-3.2.1.rc0 folder. I assume a complete rebuild would probably fix
that.

-Marshall

[mabshoff]

On Dec 19, 8:53 am, mhampton <hampto...@gmail.com> wrote:

Hi Marshall,

> I reran the test and it passed.  sage -maxima works fine.  I did
> realize that I said something incorrect, it looks like the install I
> am using was originally from the 3.2.1.rc0 source, and I have upgraded
> and renamed it several times since then.  So it is not too weird an
> event.

There is still one issue we have a ticket for that can introduce
issues when running -upgrade: When one moves the tree and then run
"sage -upgrade" the rebasing of Sage is not run, so that can cause
build issues.

> Some of the c source code still makes references to the
> sage-3.2.1.rc0 folder.  

What references? In what c sources? If it is in the Cython generated
files it shouldn't matter.

> I assume a complete rebuild would probably fix that.
>
> -Marshall

Cheers,

Michael

[Craig Citro]

> My ppc powerbook is still slaving away on tests, its almost done and
> so far just has timeout failures on eisenstein and calculus.py.
>

What file was the eisenstein timeout on?

-cc

[mhampton]

eisenstein_submodule, sorry I wasn't more specific.

-Marshall

[Craig Citro]

> eisenstein_submodule, sorry I wasn't more specific.
>

Hmm, interesting. Do you have the log? I'm just surprised that
anything could cause that file to timeout, especially without causing
anything else to timeout. Could I con you into running that test
again, and seeing if it still times out? If it does, could you do it
with -verbose to see what's taking so long?

-cc

[mhampton]

I reran it and all tests passed in 54 seconds. This is after
rebuilding sage to make sure all the cython stuff was in the right
place. The machine has a 1.5 Ghz powerpc G4 with 512 MB of RAM.

-Marshall

[William Stein]

When I just built some of the binaries for sage-3.2.2 I had this file
(eisenstein_submodule.py) timeout on two of my build machines after
360 seconds. One is the G5 in Clement's office, and another is a
32-bit Ubuntu virtual machine with 512MB RAM running on my office
computer.

Using --verbose, first, this doctest takes a *long* time (minutes):

z, n = sage.modular.modform.eisenstein_submodule.cyclotomic_restriction(L,N)###line
401:_sage_ >>> z, n =
sage.modular.modform.eisenstein_submodule.cyclotomic_restriction(L,N)
Expecting nothing

This also takes a very long time:

z = sage.modular.modform.eisenstein_submodule.cyclotomic_restriction_tower(L,K)###line
478:_sage_ >>> z =
sage.modular.modform.eisenstein_submodule.cyclotomic_restriction_tower(L,K)

So I'm guessing maybe there was a massive performance regression in
cyclotomic_restriction, whatever that is.

-- William

[mabshoff]

On Dec 20, 10:21 am, "William Stein" <wst...@gmail.com> wrote:
> On Fri, Dec 19, 2008 at 4:07 PM, Craig Citro <craigci...@gmail.com> wrote:

<SNIP>

Hi,

> When I just built some of the binaries for sage-3.2.2 I had this file
> (eisenstein_submodule.py) timeout on two of my build machines after
> 360 seconds.   One is the G5 in Clement's office, and another is a
> 32-bit Ubuntu virtual machine with 512MB RAM running on my office
> computer.
>
> Using --verbose, first, this doctest takes a *long* time (minutes):
>
>     z, n = sage.modular.modform.eisenstein_submodule.cyclotomic_restriction(L,N)###lin e
> 401:_sage_    >>> z, n =
> sage.modular.modform.eisenstein_submodule.cyclotomic_restriction(L,N)
> Expecting nothing
>
> This also takes a very long time:
>
>     z = sage.modular.modform.eisenstein_submodule.cyclotomic_restriction_tower(L,K) ###line
> 478:_sage_    >>> z =
> sage.modular.modform.eisenstein_submodule.cyclotomic_restriction_tower(L,K)
>
> So I'm guessing maybe there was a massive performance regression in
> cyclotomic_restriction, whatever that is.
>
>  -- William

Yep, notice the total difference on the same machine:

[mabshoff@eno sage-3.2.1-eno]$ ./sage -t devel/sage/sage/modular/
modform/eisenstein_submodule.py
sage -t "devel/sage/sage/modular/modform/eisenstein_submodule.py"
[15.4 s]

[mabshoff@eno sage-3.2.2-eno]$ ./sage -t devel/sage/sage/modular/
modform/eisenstein_submodule.py
sage -t "devel/sage/sage/modular/modform/eisenstein_submodule.py"
[80.5 s]

I am poking around, but since this is in rc1 I am not sure which patch
is at fault.

Cheers,

Michael

[Craig Citro]

> Using --verbose, first, this doctest takes a *long* time (minutes):
>
> z, n = sage.modular.modform.eisenstein_submodule.cyclotomic_restriction(L,N)###line
> 401:_sage_ >>> z, n =
> sage.modular.modform.eisenstein_submodule.cyclotomic_restriction(L,N)
> Expecting nothing
>

So just running this through prun suggests that it's something related
to coercion:

ncalls tottime percall cumtime percall filename:lineno(function)
17/11 13.884 0.817 14.137 1.285
number_field.py:1502(_coerce_map_from_)

I'll have time to start looking into this later this afternoon, unless
someone beats me to it ...

-cc

[mabshoff]

On Dec 20, 12:11 pm, "Craig Citro" <craigci...@gmail.com> wrote:


<SNIP>

> So just running this through prun suggests that it's something related
> to coercion:
>
>    ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>     17/11   13.884    0.817   14.137    1.285
> number_field.py:1502(_coerce_map_from_)
>
> I'll have time to start looking into this later this afternoon, unless
> someone beats me to it ...

Yep, a likely candidate is #4276, but that is a 100kb diff, so maybe
you should ask RoberWB for a hint.

Note that in the modular/modform directory that is the only doctest
that got measurably slower, but I would not be surprised if something
else in number fields would also show some performance differences.
This is another case where the timeit framework would come in handy.
Since it has been in for a while and basically unchanged hopefully we
can run regression tests back a couple of releases. Getting timeit to
compare different runs is definitely an excellent project for SD12
should we not have it in place by then.

> -cc

Cheers,

Michael

[Robert Bradshaw]

Hmm... I think I know what causes this. Basically, to find a coercion
between two cyclotomic fields, it finds all roots of each (by
factoring the polynomial over the complex numbers) and matches up the
closest one. For cyclotomic fields it could easily determine right
away where the root goes.

Do you have examples of the size of fields it's dealing with here?

- Robert

[Craig Citro]

That example was with CyclotomicField(12) and CyclotomicField(132) ...

-cc

[mabshoff]

On Dec 20, 12:31 pm, "Craig Citro" <craigci...@gmail.com> wrote:

Hi,

> That example was with CyclotomicField(12) and CyclotomicField(132) ...
>
> -cc

Please open a ticket against 3.3, but I think the patch (should it
exist by then [working with reverse psychology here :)]) will only go
in after 3.3.alpha0, i.e. when all the ReST patches are in.

Cheers,

Michael

[Robert Bradshaw]

On Dec 20, 2008, at 12:31 PM, Craig Citro wrote:

> That example was with CyclotomicField(12) and CyclotomicField(132) ...

Ah. I bet the time was spent resolving the roots of CyclotomicField
(132) to high enough precision to distinguish them. If you don't come
up with a patch for this, I'll (probably) do it later tonight.

- Robert

[mabshoff]

On Dec 20, 12:45 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:

> On Dec 20, 2008, at 12:31 PM, Craig Citro wrote:
>
> > That example was with CyclotomicField(12) and CyclotomicField(132) ...
>
> Ah. I bet the time was spent resolving the roots of CyclotomicField
> (132) to high enough precision to distinguish them. If you don't come  
> up with a patch for this, I'll (probably) do it later tonight.
>
> - Robert
>

This is now http://trac.sagemath.org/sage_trac/ticket/4842 - feel free
to correct the subject and summary.

Cheers,

Michael