Sage 4.6.rc0 released
Mitesh Patel
We've released Sage 4.6.rc0.
Source archive:
http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar
Upgrade path:
http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
Please build, test, and report! We'd love to hear about your
experiences with this release.
== Notes ==
* The 4.6 cycle is still in feature freeze.
* We've merged #9896 into this release so it gets more widely tested,
but it still needs a review.
* Jeroen Demeyer will manage the 4.6.1 cycle.
== Tickets ==
Closed:
#9926: Doctest error in sage/schemes/generic/toric_divisor.py on OS X
#10081: Another doctest failure in sage/graphs/graphs.py
Merged in sage-4.6.rc0:
#6235: John Palmieri: set MPLCONFIGDIR environment variable when Sage
starts up [Reviewed by Leif Leonhardy]
#8677: Volker Braun, William Stein: Race condition creating dirs during
Sage build [Reviewed by Volker Braun, Mitesh Patel]
#9210: Jason Grout: pkg-config's prefix statements in
SAGE_LOCAL/lib/pkgconfig not changed upon Sage move [Reviewed by David
Kirkby, Karl-Dieter Crisman]
#9422: Nathann Cohen: Slightly improving is_forest [Reviewed by Leonardo
Sampaio]
#9798: Volker Braun: Accelerate Polyhedron constructor and fix cddlib
output ordering [Reviewed by Dmitrii Pasechnik, Marshall Hampton]
#9896: Leif Leonhardy: Upgrading from 4.5.3 to 4.6.alpha* can fail (not
limited to MacOS X) [Reviewed by ???]
#9959: Jeroen Demeyer: Get PARI/GP to stop starting automatically
[Reviewed by John Cremona]
#10041: Joris Vankerschaver: Doctest failure in
sage/tensor/differential_forms.py [Reviewed by Niles Johnson]
#10042: Dima Pasechnik: Doctest failure in
sage/rings/polynomial/polynomial_element.pyx [Reviewed by Leif Leonhardy]
#10053: Joris Vankerschaver: Equality testing instead of comparisons in
differential forms code [Reviewed by Niles Johnson]
#10098: Volker Braun: Flaky doctest in sage/interfaces/expect.py
[Reviewed by Mitesh Patel]
#10104: Mike Hansen: #9920 breaks bdisted binaries [Reviewed by Mitesh
Patel]
Marshall Hampton
The following tests failed:
sage -t devel/sage/sage/interfaces/sage0.py # 3 doctests failed
sage -t devel/sage/sage/libs/ntl/all.py # 0 doctests failed
sage -t devel/sage/sage/rings/all.py # 0 doctests failed
The second two don't occur when retesting single-threaded. The
sage0.py is reproducible, and gives:
sage -t "devel/sage/sage/interfaces/sage0.py"
**********************************************************************
File "/Volumes/E/sage-4.6.rc0/devel/sage/sage/interfaces/sage0.py",
line 105:
sage: a
Expected:
10
Got:
<BLANKLINE>
**********************************************************************
File "/Volumes/E/sage-4.6.rc0/devel/sage/sage/interfaces/sage0.py",
line 114:
sage: s3('"x"')
Expected:
8
Got:
<BLANKLINE>
**********************************************************************
File "/Volumes/E/sage-4.6.rc0/devel/sage/sage/interfaces/sage0.py",
line 116:
sage: s('x')
Expected:
5
Got:
<BLANKLINE>
-Marshall
Marshall Hampton
-Marshall
Mike Witt
Fedora 11, gcc 4.4.1
Fails with the issue already reported for Sage 4.6.alpha3
http://groups.google.com/group/sage-release/browse_thread/thread/a72cd417c5312470
Fedora 12, gcc 4.4.4
Appears to build with no serious problems
Fedora 13, gcc 4.4.4
ATLAS won't build, same issue reported on 'asksage'
http://ask.sagemath.org/question/107/building-atlas
(This is on a very low-powered "netbook" but it was able
to build sage up until I put Fedora 13 on it.)
If any of the logs of these builds are of interest, I'll
make them available.
-Mike
Mitesh Patel
Does anyone else see this or know why this could happen?
Here are Sage Buildbot reports for bsd.math (OS X 10.6):
32-bit
http://build.sagemath.org/sage/builders/bsd%20full/builds/20
64-bit
http://build.sagemath.org/sage/builders/bsd%2064%20full/builds/4
Running
./sage -t "devel/sage/sage/interfaces/sage0.py"
about 10 times with each of these builds doesn't give any failures.
Justin C. Walker
On Oct 21, 2010, at 17:19 , Mitesh Patel wrote:
> Ave Sage user-developers!
>
> We've released Sage 4.6.rc0.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':
Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.
Five failures during testing (sage -t -long -force_lib):
devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed
devel/sage/sage/calculus/desolvers.py # 1 doctests failed
devel/sage/sage/misc/trace.py # 1 doctests failed
devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed
devel/sage/sage/symbolic/assumptions.py # 2 doctests failed
ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log
Core i7, upgraded from "a3", no problems.
One failure during testing (sage -t -long -force_lib):
devel/sage/sage/misc/trace.py # 1 doctests failed
ptestlong log a sage.math.washington.edu:~justin/logs/4.6.rc0-i7.log
Justin
--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's income
-----------
Question 43:
What if the hokey pokey
really *is* what it’s all about?
--
Mitesh Patel
> On Oct 21, 2010, at 17:19 , Mitesh Patel wrote:
>> Ave Sage user-developers!
>>
>> We've released Sage 4.6.rc0.
>>
>> Source archive:
>>
>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar
>>
>> Upgrade path:
>>
>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
>
> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':
>
> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.
> Five failures during testing (sage -t -long -force_lib):
> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed
> devel/sage/sage/calculus/desolvers.py # 1 doctests failed
> devel/sage/sage/misc/trace.py # 1 doctests failed
> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed
> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed
> ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log
http://sage.math.washington.edu/home/justin/logs/4.6.rc0-DQX.log
> Core i7, upgraded from "a3", no problems.
> One failure during testing (sage -t -long -force_lib):
> devel/sage/sage/misc/trace.py # 1 doctests failed
> ptestlong log a sage.math.washington.edu:~justin/logs/4.6.rc0-i7.log
http://sage.math.washington.edu/home/justin/logs/4.6.rc0-i7.log
The base.pyx (#10059) and trace.py (#10138) errors are known. The
plotting.rst error is
OSError: [Errno 17] File exists:
'/Users/justin/.sage//matplotlib-1.0.0/tex.cache'
and may stem from the recent matplotlib upgrade (#9221, #6235). I think
the others relate to Maxima.
http://trac.sagemath.org/sage_trac/ticket/6235
http://trac.sagemath.org/sage_trac/ticket/9221
http://trac.sagemath.org/sage_trac/ticket/10059
http://trac.sagemath.org/sage_trac/ticket/10138
Mitesh Patel
> FWIW,
>
> Fedora 11, gcc 4.4.1
> Fails with the issue already reported for Sage 4.6.alpha3
>
> http://groups.google.com/group/sage-release/browse_thread/thread/a72cd417c5312470
This is likely to be a GCC bug.
http://trac.sagemath.org/sage_trac/ticket/10120
What happens if you build from scratch with
export SAGE_DEBUG=yes
make
? This skips the -O3 GCC optimization flag for at least PARI.
leif
> On 10/21/2010 11:58 PM, Mike Witt wrote:
>> FWIW,
>>
>> Fedora 11, gcc 4.4.1
>> Fails with the issue already reported for Sage 4.6.alpha3
>>
>> http://groups.google.com/group/sage-release/browse_thread/thread/a72cd417c5312470
>
> This is likely to be a GCC bug.
>
> http://trac.sagemath.org/sage_trac/ticket/10120
>
> What happens if you build from scratch with
>
> export SAGE_DEBUG=yes
> make
>
> ? This skips the -O3 GCC optimization flag for at least PARI.
It should be sufficient to just continue the build with SAGE_DEBUG (or
CFLAGS appropriately) set, or - if the Sage scripts are already
installed - do
env SAGE_DEBUG=yes ./sage -i pari-2.4.3.svn-12577.p9
make # continue normal build
-Leif
leif
> Ave Sage user-developers!
>
> We've released Sage 4.6.rc0.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
Amen.
Note that upgrading (the rebuild process, not the downloads) will
probably now take longer than it used to, because now all packages that
depend on new ones will get rebuilt.
To reduce the number of (unfortunately unnecessarily) rebuilt packages,
one could do the following *before* upgrading on any system other than
SunOS/Solaris, Cygwin and HP-UX:
touch spkg/installed/iconv-1.13.1.p3
(This package is in fact only required/used on the above platforms, but
"installing" it triggers the rebuild of *many* other packages on *every*
platform. There's currently no other way to avoid this, sorry.)
I'm quite glad to report that upgrading from Sage 4.4.4 (!) worked out
of the box on Ubuntu 9.04 x86_64 (Core2, gcc 4.3.3; MAKE="make -j16" and
SAGE_PARALLEL_SPKG_BUILD=yes set before running the upgrade; directory
renamed before upgrading).
make ptestlong also passed without any errors.
Sage 4.6.rc0pre1 (which I assume is almost identical to the "final" rc0)
built without errors and ptestlong also passed on Ubuntu 10.04 x86_64
(Core2, gcc 4.4.3; built from scratch in parallel with 32 jobs).
-Leif
Mike Witt
> What happens if you build from scratch with
>
> export SAGE_DEBUG=yes
> make
That appears to work.
-Mike
leif
You could also (re)try
unset SAGE_DEBUG
env CFLAGS="-O2 -fno-strict-aliasing -fomit-frame-pointer" ./sage -f
pari-2.4.3.svn-12577.p9
(which just forces reinstallation of the PARI spkg).
-Leif
Mike Witt
If that will yield any information that might improve the release
(or would be otherwise useful to anyone) I'll be happy to try it.
-Mike
leif
It would be nice if you could, and report at #10120.
-Leif
P.S.: Building Sage with SAGE_DEBUG=yes isn't very good for "production"
use, since this (completely) disables optimization in a number of packages.
leif
P.P.S.:
If the above works for you, you can afterwards trigger a rebuild *with*
optimization (of the packages that were built with SAGE_DEBUG set in the
first place) by doing
unset SAGE_DEBUG # if not already done
env SAGE_UPGRADING=yes make # rebuilds all packages that depend on PARI
(assuming you had built Sage in parallel, i.e. all packages that do
*not* depend on PARI were built in the first run of 'make', without
SAGE_DEBUG set).
-Leif
John Cremona
machines using SAGE_SPKG_PARALLEL_BUILD='yes' and MAKE='make -j <n>'
for suitable n; make ptestlong passes everything.
John
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to sage-release...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-release?hl=en.
>
>
Mike Witt
> Mike Witt wrote:
> > On 10/22/2010 03:33:00 AM, leif wrote:
> >> Mike Witt wrote:
> >> > On 10/22/2010 12:15:46 AM, Mitesh Patel wrote:
> >> >
> >> >> What happens if you build from scratch with
> >> >>
> >> >> export SAGE_DEBUG=yes
> >> >> make
> >> >
> >> > That appears to work.
> >>
> >>
> >> You could also (re)try
> >>
> >> unset SAGE_DEBUG
> >>
> >> env CFLAGS="-O2 -fno-strict-aliasing -fomit-frame-pointer" ./sage
> -f
> >> pari-2.4.3.svn-12577.p9
> >>
> >> (which just forces reinstallation of the PARI spkg).
> >
> > If that will yield any information that might improve the release
> > (or would be otherwise useful to anyone) I'll be happy to try it.
>
> It would be nice if you could, and report at #10120.
I'm a little uneasy about getting involved with the bug tracking
system right now, since I don't really have time to learn how it
works. Perhaps down the road a bit.
I realize that makes my reports less useful. Sorry about that.
-Mike
John Cremona
> Built from scratch with no problems on two different 64-bit ubuntu
> machines using SAGE_SPKG_PARALLEL_BUILD='yes' and MAKE='make -j <n>'
> for suitable n; make ptestlong passes everything.
Same again for 32-bit SUSE linux: no build problems, ptestlong all passed.
>
> John
leif
Oh, sorry, I didn't notice you're not (yet) "on trac", Sage's bug
tracking system. (I did not even post a link to the ticket [1], which I
certainly should have done.)
> I realize that makes my reports less useful. Sorry about that.
No, any reports are welcome, on the Sage trac as well as the discussion
groups (sage-release, sage-devel, sage-support).
We usually copy (excerpts from) posts to the tickets, or at least link
to the respective threads. It's just usually more convenient to continue
a discussion at /some/ point on the ticket.
Also, "trac" supports more fancy posts than the Google groups do. ;-)
-Leif
Rob Beezer
mysterious "libpari segfault" - specifically the "a = 10" test.
The message where Jan isolated his discovery is
http://groups.google.com/group/sage-devel/browse_thread/thread/f2644af599f49b1c/7ee58c907458e87b
but the whole thread is interesting. I know Marshall was involved,
but can't recall if he was getting the segfault as well, nor on which
platform. I think Jan would pursue this further if he could get a
PARI specialist to lend a hand.
Rob
leif
Well, that was with the *old* PARI (Sage 4.5.3).
-Leif
leif
> Mitesh Patel wrote:
>> Ave Sage user-developers!
>>
>> We've released Sage 4.6.rc0.
>>
>> Source archive:
>>
>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar
>>
>> Upgrade path:
>>
>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
>
> Amen.
>
> Note that upgrading (the rebuild process, not the downloads) will
> probably now take longer than it used to, because now all packages that
> depend on new ones will get rebuilt.
>
> To reduce the number of (unfortunately unnecessarily) rebuilt packages,
> one could do the following *before* upgrading on any system other than
> SunOS/Solaris, Cygwin and HP-UX:
>
> touch spkg/installed/iconv-1.13.1.p3
>
> (This package is in fact only required/used on the above platforms, but
> "installing" it triggers the rebuild of *many* other packages on *every*
> platform. There's currently no other way to avoid this, sorry.)
I've also successfully upgraded from a copy of Sage 4.5.3 (i.e., a
"moved" installation) with the above (faking the new iconv spkg was
already installed) on Ubuntu 9.04 x86 (Pentium4 Prescott, gcc 4.3.3;
parallel build with 8 jobs).
ptestlong passed without any errors.
-Leif
leif
> leif wrote:
>> Mitesh Patel wrote:
>>> Ave Sage user-developers!
>>>
>>> We've released Sage 4.6.rc0.
>>>
>>> Source archive:
>>>
>>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0.tar
>>>
>>> Upgrade path:
>>>
>>> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
>>
>> Amen.
>>
>> Note that upgrading (the rebuild process, not the downloads) will
>> probably now take longer than it used to, because now all packages that
>> depend on new ones will get rebuilt.
>>
>> To reduce the number of (unfortunately unnecessarily) rebuilt packages,
>> one could do the following *before* upgrading on any system other than
>> SunOS/Solaris, Cygwin and HP-UX:
>>
>> touch spkg/installed/iconv-1.13.1.p3
>>
>> (This package is in fact only required/used on the above platforms, but
>> "installing" it triggers the rebuild of *many* other packages on *every*
>> platform. There's currently no other way to avoid this, sorry.)
Oh, I just noticed that one would have to run "make build" *after*
touching spkg/installed/iconv-1.13.1.p3 and *before* running "sage
-upgrade ..." to make this (fully) work... :/
(Running "make build" just touches all packages that depend on iconv,
with the message "... is already installed", i.e. no [re]compilation
takes place.)
Sorry.
-Leif
Mike Witt
OK, thanks for the encouraging comments. I'm a bit ambivalent
about how far a "non-developer" should get into the development
process. But this isn't the place to get into that :-)
In any event, I do want to make any reports that will be useful.
So ... I went into the directory in which I'd previously done
the make with SAGE_DEBUG=yes. Then I did the two commands above.
It was clearly going to run out of memory again, at this point:
ict-aliasing -fomit-frame-pointer -I. -I../src/headers -fPIC -o
base3.o ../src/basemath/base3.c
It just hung there allocating memory. I killed it before I
ran completely out.
-Mike
John H Palmieri
> Ave Sage user-developers!
>
> We've released Sage 4.6.rc0.
>
> Source archive:
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
machines; all tests passed in all four cases.
--
John
leif
Ok, thanks.
So compiling PARI with "-O2" (instead of "-O3") is still too much for
Fedora's broken gcc 4.4.1. (I didn't expect that, but the GCC developers
tend to put more and more sophisticated optimizations into the usual
default "O2" level.)
In case you have nothing else to do, you could retry the above with
"-O1" instead of "-O2" again... ;-)
-Leif
Mitesh Patel
Justin, are the plotting.rst, desolvers.py, and assumptions.py errors
reproducible?
Mike Witt
No problem. I still have the window open. That one DID work.
-Mike
John H Palmieri
> On 10/22/2010 01:27 AM, Justin C. Walker wrote:
>
> > Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.
> > Five failures during testing (sage -t -long -force_lib):
> > devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed
> > devel/sage/sage/calculus/desolvers.py # 1 doctests failed
> > devel/sage/sage/misc/trace.py # 1 doctests failed
> > devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed
> > devel/sage/sage/symbolic/assumptions.py # 2 doctests failed
> > ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log
>
> http://sage.math.washington.edu/home/justin/logs/4.6.rc0-DQX.log
>
> > Core i7, upgraded from "a3", no problems.
> > One failure during testing (sage -t -long -force_lib):
> > devel/sage/sage/misc/trace.py # 1 doctests failed
> > ptestlong log a sage.math.washington.edu:~justin/logs/4.6.rc0-i7.log
>
> http://sage.math.washington.edu/home/justin/logs/4.6.rc0-i7.log
>
> The base.pyx (#10059) and trace.py (#10138) errors are known. The
> plotting.rst error is
>
> OSError: [Errno 17] File exists:
> '/Users/justin/.sage//matplotlib-1.0.0/tex.cache'
>
> and may stem from the recent matplotlib upgrade (#9221, #6235).
I think the relevant lines in matplotlib/texmanager.py are
if not os.path.exists(texcache):
os.mkdir(texcache)
So my guess is that it's a clash with another doctest trying to create
the same directory at the same time. Should we patch this the way we
did in #8677:
try:
os.mkdir(texcache)
except OSError:
pass
?
(Anyway, I'm not sure, but I don't think this comes from #6235 etc. I
think it could happen anytime you run parallel tests without a
matplotlib config directory, whether it's $HOME/.matplotlib or
$HOME/.sage/matplotlib-1.0.0 or anything else.)
--
John
Justin C. Walker
On Oct 22, 2010, at 15:04 , Mitesh Patel wrote:
> On 10/22/2010 02:00 AM, Mitesh Patel wrote:
>> On 10/22/2010 01:27 AM, Justin C. Walker wrote:
>>> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':
>>>
>>> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.
>>> Five failures during testing (sage -t -long -force_lib):
>>> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed
>>> devel/sage/sage/calculus/desolvers.py # 1 doctests failed
>>> devel/sage/sage/misc/trace.py # 1 doctests failed
>>> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed
>>> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed
>>> ptestlong log at sage.math.washington.edu:~justin/logs/4.6.rc0-DQX.log
[snip]
> Justin, are the plotting.rst, desolvers.py, and assumptions.py errors
> reproducible?
I am trying this on the system where the failures occurred. If I run them individually, all three pass. I am rerunning the full test exactly as I did before now, and I will let you know what transpires.
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
If you're not confused,
You're not paying attention
--------
leif
That's suboptimal; the actual error should be checked, too (everywhere!):
try;
os.mkdir(foo)
except OSError, err:
if err.errno == 17:
pass
else:
raise
(#8677, patch version 4 does similar; I think other instances do not yet?)
2ct,
-Leif
leif
Please forget that post! ;-)
It works as originally stated, by simply touching iconv-1.13.1.p3, the
'make build' isn't necessary (but doesn't hurt either).
Just lack of sleep I hope.
Sorry for the noise.
-Leif
Justin C. Walker
On Oct 22, 2010, at 15:32 , Justin C. Walker wrote:
>
> On Oct 22, 2010, at 15:04 , Mitesh Patel wrote:
>
>> On 10/22/2010 02:00 AM, Mitesh Patel wrote:
>>> On 10/22/2010 01:27 AM, Justin C. Walker wrote:
>>>> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':
>>>>
>>>> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.
>>>> Five failures during testing (sage -t -long -force_lib):
>>>> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed
>>>> devel/sage/sage/calculus/desolvers.py # 1 doctests failed
>>>> devel/sage/sage/misc/trace.py # 1 doctests failed
>>>> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed
>>>> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed
> [snip]
>> Justin, are the plotting.rst, desolvers.py, and assumptions.py errors
>> reproducible?
>
> I am trying this on the system where the failures occurred. If I run them individually, all three pass. I am rerunning the full test exactly as I did before now, and I will let you know what transpires.
Here is the result of rerunning the full 'ptestlong' suite:
devel/sage/sage/misc/trace.py # 1 doctests failed
devel/sage/sage/modules/free_module_element.pyx # 1 doctests failed
devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed
I feel like I'm in a maze of twisty little passages, all subtly different :-}
Let me know if you want the log for this run, or if there is anything else I can provide.
Justin
--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's income
-----------
Question 43:
What if the hokey pokey
really *is* what it’s all about?
--
Jeroen Demeyer
> try;
> os.mkdir(foo)
> except OSError, err:
> if err.errno == 17:
> pass
> else:
> raise
I doubt that these errno numbers are portable. I'm not sure whether we
have access to the symbolic constants like EEXIST from Python.
Mitesh Patel
These are available in the errno module:
http://docs.python.org/library/errno.html#errno.EEXIST
Should we instead report the problem to the matplotlib developers?
koffie
I just did a build from scratch on OS X 10.6.4 using gcc 4.2.1
sage -testall gives two errors which fail if they are run again
individually later on.
Here are the failures
maarten-derickxs-macbook-pro:sage-4.6.rc0 maarten$ sage -t devel/sage/
sage/matrix/matrix2.pyx
sage -t "4.6.rc0/devel/sage/sage/matrix/matrix2.pyx"
Traceback (most recent call last):
File "/Users/maarten/.sage//tmp/matrix2.py", line 18, in <module>
cython(open('devel/sage/sage/matrix/matrix2.pyx').read())
File "cython_c.pyx", line 32, in sage.misc.cython_c.cython (sage/
misc/cython_c.c:656)
File "/Applications/sage/local/lib/python/site-packages/sage/server/
support.py", line 469, in cython_import_all
create_local_c_file=create_local_c_file)
File "/Applications/sage/local/lib/python/site-packages/sage/server/
support.py", line 446, in cython_import
create_local_c_file=create_local_c_file)
File "/Applications/sage/local/lib/python/site-packages/sage/misc/
cython.py", line 367, in cython
raise RuntimeError, "Error converting %s to C:\n%s\n%s"%(filename,
log, err)
RuntimeError: Error converting /Users/maarten/.sage//temp/
maarten_derickxs_macbook_pro.local/52312//tmp_0.spyx to C:
Error converting Pyrex file to C:
------------------------------------------------------------
...
import sage.modules.free_module
import matrix_space
import berlekamp_massey
from sage.modules.free_module_element import is_FreeModuleElement
cdef class Matrix(matrix1.Matrix):
^
------------------------------------------------------------
/Users/maarten/.sage/temp/maarten_derickxs_macbook_pro.local/52312/
spyx/
_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx/
_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx_0.pyx:
57:5: 'matrix1.pxd' not found
Error converting Pyrex file to C:
------------------------------------------------------------
...
import sage.modules.free_module
import matrix_space
import berlekamp_massey
from sage.modules.free_module_element import is_FreeModuleElement
cdef class Matrix(matrix1.Matrix):
^
------------------------------------------------------------
/Users/maarten/.sage/temp/maarten_derickxs_macbook_pro.local/52312/
spyx/
_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx/
_Users_maarten__sage_temp_maarten_derickxs_macbook_pro_local_52312_tmp_0_spyx_0.pyx:
57:5: 'Matrix' is not declared
[5.2 s]
----------------------------------------------------------------------
The following tests failed:
sage -t "4.6.rc0/devel/sage/sage/matrix/matrix2.pyx"
Total time for all tests: 5.2 seconds
maarten-derickxs-macbook-pro:sage-4.6.rc0 maarten$ sage -t "devel/
sage/sage/interfaces/r.py"sage -t "4.6.rc0/devel/sage/sage/interfaces/
r.py"
Traceback (most recent call last):
File "/Users/maarten/.sage//tmp/r.py", line 18, in <module>
from r import *
File "/Users/maarten/.sage/tmp/r.py", line 210, in <module>
from expect import Expect, ExpectElement, ExpectFunction,
FunctionElement
ImportError: No module named expect
[2.8 s]
----------------------------------------------------------------------
The following tests failed:
sage -t "4.6.rc0/devel/sage/sage/interfaces/r.py"
Total time for all tests: 2.8 seconds
Mitesh Patel
> On Oct 22, 2010, at 15:32 , Justin C. Walker wrote:
>> On Oct 22, 2010, at 15:04 , Mitesh Patel wrote:
>>> On 10/22/2010 02:00 AM, Mitesh Patel wrote:
>>>> On 10/22/2010 01:27 AM, Justin C. Walker wrote:
>>>>> Built as upgrade, Mac OS X, 10.6.4, tested using 'ptestlong':
>>>>>
>>>>> Dual Quad Xeon, upgraded from "a0 -> a1 -> a2 -> a3", no problems.
>>>>> Five failures during testing (sage -t -long -force_lib):
>>>>> devel/sage/doc/en/constructions/plotting.rst # 1 doctests failed
>>>>> devel/sage/sage/calculus/desolvers.py # 1 doctests failed
>>>>> devel/sage/sage/misc/trace.py # 1 doctests failed
>>>>> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed
>>>>> devel/sage/sage/symbolic/assumptions.py # 2 doctests failed
>> [snip]
>>> Justin, are the plotting.rst, desolvers.py, and assumptions.py errors
>>> reproducible?
>>
>> I am trying this on the system where the failures occurred. If I run them individually, all three pass. I am rerunning the full test exactly as I did before now, and I will let you know what transpires.
>
> Here is the result of rerunning the full 'ptestlong' suite:
>
> devel/sage/sage/misc/trace.py # 1 doctests failed
> devel/sage/sage/modules/free_module_element.pyx # 1 doctests failed
> devel/sage/sage/plot/plot3d/base.pyx # 4 doctests failed
>
> I feel like I'm in a maze of twisty little passages, all subtly different :-}
>
> Let me know if you want the log for this run, or if there is anything else I can provide.
Thanks, Justin. Could you give us a link to the new log or paste the
error from free_module_element.pyx?
leif
> On 10/23/2010 02:20 AM, Jeroen Demeyer wrote:
>> On 2010-10-23 01:34, leif wrote:
>>> try;
>>> os.mkdir(foo)
>>> except OSError, err:
>>> if err.errno == 17:
>>> pass
>>> else:
>>> raise
>>
>> I doubt that these errno numbers are portable. I'm not sure whether we
>> have access to the symbolic constants like EEXIST from Python.
I doubt that the number differs on the supported platforms, but it's of
course better to use symbolic constants.
The code was just meant to illustrate /what/ to check, not /how/ ;-)
(I sometimes remember the numbers better than the names).
> These are available in the errno module:
>
> http://docs.python.org/library/errno.html#errno.EEXIST
Yep. Cf. #8677.
> Should we instead report the problem to the matplotlib developers?
Not instead, but also I think.
-Leif
Marshall Hampton
> Well, that was with the *old* PARI (Sage 4.5.3).
>
> -Leif
-Marshall
leif
Yep. My comment referred to Jan Groenewald's post about a "mysterious
libpari segfault" Rob mentioned, which he reported for Sage 4.5.3 / PARI
2.3.5, but I see you could reproduce it with Sage 4.6.alpha3 / PARI
2.4.3.svn-12577, too.
-Leif
Justin C. Walker
Here's the location of the new log file:
sage.math.washington.edu:~justin/logs/4.6.rc0-DQX-2.log
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
Men are from Earth.
Women are from Earth.
Deal with it.
--------
John H Palmieri
ticket. I've also reported it upstream.
--
John
Mitesh Patel
This is a Maxima error similar to one of the previous, unreproducible
errors:
sage -t -long -force_lib devel/sage/sage/modules/free_module_element.pyx
**********************************************************************
File
"/Users/Sage/sage-4.6.alpha0/devel/sage-main/sage/modules/free_module_element.pyx",
line 2102:
sage: integrate(r,t)
[...]
TypeError: Error executing code in Maxima
CODE:
sage102 : t$
Maxima ERROR:
sage102 : t$
stdin:44907:Incorrect syntax: Too many )'s
(%i719)
stdin:44960:Incorrect syntax: Illegal use of delimiter )
(%i720)
stdin:45027:Incorrect syntax: Premature termination of input at ;.
(%i721)
**********************************************************************
Please see
http://sage.math.washington.edu/home/justin/logs/4.6.rc0-DQX-2.log
for the full traceback.
Mitesh Patel
> For those who don't want to build the full documentation themselves,
> you can find the generated documentation at
>
> http://sage.math.washington.edu/home/release/sage-4.6.rc0/
>
> Both the HTML and PDF versions are available. You can also download a
> compressed tarball of the full documentation, or view it from the
> above URL.
We've updated alpha.sagenb.org to 4.6.rc0. Let us know if there are
problems.
koffie
reported should be ignored. Everything builds ok.
Dr. David Kirkby
> Sorry, I did something wrong with the testing, the two docest errors I
> reported should be ignored. Everything builds ok.
>
Why should they be ignored? I suspect its probably the usual problem that
parallel testing is unreliable.
Dave
koffie
patches which are work in progress). I did a "make" and then "sage -
testall" instead of a "make ptestlong" and I forgot that the sage
command for which I created a symlink in /usr/local/bin/sage still
pointed to the old install. I tested the right installation last
night. I got 4 doctest failures, which are all related.
sage -t -force_lib "devel/sage/sage/plot/plot3d/base.pyx"
**********************************************************************
File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/
base.pyx", line 1160:
sage: G.save(f)
Exception raised:
1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line
38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_35[4]>", line 1, in <module>
G.save(f)###line 1160:
sage: G.save(f)
File "base.pyx", line 1198, in
sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/Image.py", line 1372, in save
self.load()
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/ImageFile.py", line 155, in load
self.load_prepare()
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/ImageFile.py", line 223, in load_prepare
self.im = Image.core.new(self.mode, self.size)
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/Image.py", line 36, in __getattr__
raise ImportError("The _imaging C module is not installed")
ImportError: The _imaging C module is not installed
**********************************************************************
File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/
base.pyx", line 1165:
sage: G.save(f, zoom=2, figsize=[5, 10])
Exception raised:
1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line
38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_35[5]>", line 1, in <module>
G.save(f, zoom=Integer(2), figsize=[Integer(5),
Integer(10)])###line 1165:
sage: G.save(f, zoom=2, figsize=[5, 10])
File "base.pyx", line 1198, in
sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/Image.py", line 1372, in save
self.load()
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/ImageFile.py", line 155, in load
self.load_prepare()
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/ImageFile.py", line 223, in load_prepare
self.im = Image.core.new(self.mode, self.size)
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/Image.py", line 36, in __getattr__
raise ImportError("The _imaging C module is not installed")
ImportError: The _imaging C module is not installed
**********************************************************************
File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/
base.pyx", line 1170:
sage: G.save(f, viewer='jmol') # Looks the same
Exception raised:
1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line
38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_35[6]>", line 1, in <module>
G.save(f, viewer='jmol') # Looks the same###line 1170:
sage: G.save(f, viewer='jmol') # Looks the same
File "base.pyx", line 1198, in
sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/Image.py", line 1372, in save
self.load()
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/ImageFile.py", line 155, in load
self.load_prepare()
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/ImageFile.py", line 223, in load_prepare
self.im = Image.core.new(self.mode, self.size)
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/Image.py", line 36, in __getattr__
raise ImportError("The _imaging C module is not installed")
ImportError: The _imaging C module is not installed
**********************************************************************
File "/Applications/sage-4.6.rc0/devel/sage/sage/plot/plot3d/
base.pyx", line 1175:
sage: cube().save(tmp_filename() + '.gif')
Exception raised:
1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Applications/sage-4.6.rc0/local/bin/sagedoctest.py", line
38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_35[7]>", line 1, in <module>
cube().save(tmp_filename() + '.gif')###line 1175:
sage: cube().save(tmp_filename() + '.gif')
File "base.pyx", line 1198, in
sage.plot.plot3d.base.Graphics3d.save (sage/plot/plot3d/base.c:11370)
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/Image.py", line 1372, in save
self.load()
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/ImageFile.py", line 155, in load
self.load_prepare()
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/ImageFile.py", line 223, in load_prepare
self.im = Image.core.new(self.mode, self.size)
File "/Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/Image.py", line 36, in __getattr__
raise ImportError("The _imaging C module is not installed")
ImportError: The _imaging C module is not installed
**********************************************************************
1 items had failures:
4 of 8 in __main__.example_35
***Test Failed*** 4 failures.
For whitespace errors, see the file /Users/maarten/.sage//
tmp/.doctest_base.py
[26.7 s]
----------------------------------------------------------------------
The following tests failed:
Total time for all tests: 26.8 seconds
On Oct 25, 9:56 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:
koffie
trying to manually import _imaging from sage I got the error:
sage: import _imaging
---------------------------------------------------------------------------
ImportError Traceback (most recent call
last)
/Applications/sage-4.6.rc0/<ipython console> in <module>()
ImportError: dlopen(/Applications/sage-4.6.rc0/local/lib/python2.6/
site-packages/PIL/_imaging.so, 2): Symbol not found:
_jpeg_resync_to_restart
Referenced from: /Applications/sage-4.6.rc0/local/lib/python2.6/site-
packages/PIL/_imaging.so
Expected in: flat namespace
in /Applications/sage-4.6.rc0/local/lib/python2.6/site-packages/PIL/
_imaging.so
sage:
A google search suggest this is an often experienced problem with
getting pill to work on snow leapard:
http://www.google.nl/search?sourceid=chrome&ie=UTF-8&q=ImportError+Symbol+not+found+_jpeg_resync_to_restart
Mitesh Patel
This is probably #10059. Ticket #9864 may be related.
http://trac.sagemath.org/sage_trac/ticket/10059
http://trac.sagemath.org/sage_trac/ticket/9864
koffie
On Oct 25, 12:23 pm, Mitesh Patel <qed...@gmail.com> wrote:
> On 10/25/2010 05:07 AM, koffie wrote:
>
>
>
>
>
>
>
>
>
> > After reading: "http://www.pythonware.com/products/pil/faq.htm" and
> > trying to manually import _imaging from sage I got the error:
>
> > sage: import _imaging
> > ---------------------------------------------------------------------------
> > ImportError Traceback (most recent call
> > last)
>
> > /Applications/sage-4.6.rc0/<ipython console> in <module>()
>
> > ImportError: dlopen(/Applications/sage-4.6.rc0/local/lib/python2.6/
> > site-packages/PIL/_imaging.so, 2): Symbol not found:
> > _jpeg_resync_to_restart
> > Referenced from: /Applications/sage-4.6.rc0/local/lib/python2.6/site-
> > packages/PIL/_imaging.so
> > Expected in: flat namespace
> > in /Applications/sage-4.6.rc0/local/lib/python2.6/site-packages/PIL/
> > _imaging.so
> > sage:
>
> > A google search suggest this is an often experienced problem with
> > getting pill to work on snow leapard:
David Kirkby
> Amen.
>
> Note that upgrading (the rebuild process, not the downloads) will
> probably now take longer than it used to, because now all packages that
> depend on new ones will get rebuilt.
>
> To reduce the number of (unfortunately unnecessarily) rebuilt packages,
> one could do the following *before* upgrading on any system other than
> SunOS/Solaris, Cygwin and HP-UX:
>
> touch spkg/installed/iconv-1.13.1.p3
>
> (This package is in fact only required/used on the above platforms, but
> "installing" it triggers the rebuild of *many* other packages on *every*
> platform. There's currently no other way to avoid this, sorry.)
> -Leif
That sounds sensible, but it should be relatively easy to integrate
that into the Sage upgrade process, so it is not necessary to manually
do this.
Dave
leif
If it was, I would have done it. ;-)
Of course one could do the "touch" (depending on the platform we build
on) inside the downloaded / newly installed $SAGE_ROOT/spkg/install, but
since such "unnecessary" packages (and their versions) change with every
release, I didn't want to mess up the script with temporary ad-hoc code.
(We're going to put $SAGE_ROOT/spkg/install under revision control, see
#9433.)
Unfortunately the current build process is not very suited to address
platform-specific packages, i.e. the decision to actually install a
package is made inside its spkg-install, so 'make' will assume dependent
packages need to be rebuilt even if the spkg-install does effectively
nothing but "exit 0" (or the changes in a package only affect /some/
architecture, cf. #9530).
The situation is worse with packages like Fortran (and perhaps ATLAS);
the former makes up more than 11% (33 MB) of the "source" tarball
because it contains various Apple Darwin *binaries*, which of course
aren't used on any other platform, while e.g. the ATLAS package is afaik
not built on MacOS X (it uses different BLAS libraries). The Cephes
package is smaller, but also only used on Cygwin.
Note that the necessity to upgrade a package might also depend on the
version currently installed (not just the platform), so implementing a
"smart" upgrade gets even more complicated, and we currently have no
formal package descriptions which would simplify such.
I think in the long run, the "real" Makefile (spkg/standard/deps) should
be *generated*, and we should have platform-specific spkgs in separate
directories (also to be part of a /different/ tarball or separately
downloaded, which could be automated as well, though we currently don't
want downloads / internet access during the "real" build process). Our
current "configure" e.g. checks for prerequisites like gfortran on Linux
(giving instructions to install it if it isn't), so why not handle other
packages that way, too?
5ct
-Leif
koffie
then with SAGE_CHECK=yes, hoping this would give more info. This
caused the check and hence the build to fail as jhpalmieri mentioned
already in the (now closed) ticket where the checking meganism for
python was correctly setup: http://trac.sagemath.org/sage_trac/ticket/9295
There seem to be open tickets for the check failing on Solaris 10:
http://trac.sagemath.org/sage_trac/ticket/9297
And one for Opensolaris:
http://trac.sagemath.org/sage_trac/ticket/9299
but not one for OS X.
Should I ad a similar one for OS X?
Georg Grafendorfer
on AMD X4 Phenom II, Fedora 13,
Georg
Dima Pasechnik
On Oct 22, 8:19 am, Mitesh Patel <qed...@gmail.com> wrote:
> Ave Sage user-developers!
>
> We've released Sage 4.6.rc0.
>
> Source archive:
>
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc0/
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
>
> == Notes ==
>
> * The 4.6 cycle is still in feature freeze.
>
> * We've merged #9896 into this release so it gets more widely tested,
> but it still needs a review.
>
> * Jeroen Demeyer will manage the 4.6.1 cycle.
>
> == Tickets ==
>
> Closed:
>
> #9926: Doctest error in sage/schemes/generic/toric_divisor.py on OS X
> #10081: Another doctest failure in sage/graphs/graphs.py
>
> Merged in sage-4.6.rc0:
>
> #6235: John Palmieri: set MPLCONFIGDIR environment variable when Sage
> starts up [Reviewed by Leif Leonhardy]
> #8677: Volker Braun, William Stein: Race condition creating dirs during
> Sage build [Reviewed by Volker Braun, Mitesh Patel]
> #9210: Jason Grout: pkg-config's prefix statements in
> SAGE_LOCAL/lib/pkgconfig not changed upon Sage move [Reviewed by David
> Kirkby, Karl-Dieter Crisman]
> #9422: Nathann Cohen: Slightly improving is_forest [Reviewed by Leonardo
> Sampaio]
> #9798: Volker Braun: Accelerate Polyhedron constructor and fix cddlib
> output ordering [Reviewed by Dmitrii Pasechnik, Marshall Hampton]
> #9896: Leif Leonhardy: Upgrading from 4.5.3 to 4.6.alpha* can fail (not
> limited to MacOS X) [Reviewed by ???]
> #9959: Jeroen Demeyer: Get PARI/GP to stop starting automatically
> [Reviewed by John Cremona]
> #10041: Joris Vankerschaver: Doctest failure in
> sage/tensor/differential_forms.py [Reviewed by Niles Johnson]
> #10042: Dima Pasechnik: Doctest failure in
> sage/rings/polynomial/polynomial_element.pyx [Reviewed by Leif Leonhardy]
> #10053: Joris Vankerschaver: Equality testing instead of comparisons in
> differential forms code [Reviewed by Niles Johnson]
> #10098: Volker Braun: Flaky doctest in sage/interfaces/expect.py
> [Reviewed by Mitesh Patel]
> #10104: Mike Hansen: #9920 breaks bdisted binaries [Reviewed by Mitesh
> Patel]