Sage 4.6.rc0 released

4 views
Skip to first unread message

Mitesh Patel

unread,
Oct 21, 2010, 8:19:56 PM10/21/10
to sage-r...@googlegroups.com
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/

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

unread,
Oct 22, 2010, 12:06:46 AM10/22/10
to sage-release
I got three test failures (with "sage -tp 4") on OS X 10.6:

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

unread,
Oct 22, 2010, 12:31:44 AM10/22/10
to sage-release
All tests passed on an Ubuntu 9.10 (64-bit), intel i7 860 machine.

-Marshall

Mike Witt

unread,
Oct 22, 2010, 12:58:52 AM10/22/10
to sage-r...@googlegroups.com
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

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

unread,
Oct 22, 2010, 1:31:24 AM10/22/10
to sage-r...@googlegroups.com


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

unread,
Oct 22, 2010, 2:27:37 AM10/22/10
to sage-r...@googlegroups.com

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

unread,
Oct 22, 2010, 3:00:51 AM10/22/10
to sage-r...@googlegroups.com
On 10/22/2010 01:27 AM, Justin C. Walker wrote:
> 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

unread,
Oct 22, 2010, 3:15:46 AM10/22/10
to sage-r...@googlegroups.com
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.

leif

unread,
Oct 22, 2010, 4:13:03 AM10/22/10
to sage-r...@googlegroups.com
Mitesh Patel wrote:
> 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

unread,
Oct 22, 2010, 5:53:04 AM10/22/10
to sage-r...@googlegroups.com
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'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

unread,
Oct 22, 2010, 6:21:09 AM10/22/10
to sage-r...@googlegroups.com
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.

-Mike

leif

unread,
Oct 22, 2010, 6:33:00 AM10/22/10
to sage-r...@googlegroups.com


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

unread,
Oct 22, 2010, 6:51:41 AM10/22/10
to sage-r...@googlegroups.com

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

unread,
Oct 22, 2010, 6:56:57 AM10/22/10
to sage-r...@googlegroups.com

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

unread,
Oct 22, 2010, 7:14:30 AM10/22/10
to sage-r...@googlegroups.com

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

unread,
Oct 22, 2010, 8:07:43 AM10/22/10
to sage-r...@googlegroups.com
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.

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

unread,
Oct 22, 2010, 11:57:31 AM10/22/10
to sage-r...@googlegroups.com
On 10/22/2010 03:56:57 AM, leif wrote:
> 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

unread,
Oct 22, 2010, 12:23:03 PM10/22/10
to sage-r...@googlegroups.com
On Fri, Oct 22, 2010 at 1:07 PM, John Cremona <john.c...@gmail.com> wrote:
> 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

unread,
Oct 22, 2010, 12:30:35 PM10/22/10
to sage-r...@googlegroups.com

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


[1] http://trac.sagemath.org/sage_trac/ticket/10120

Rob Beezer

unread,
Oct 22, 2010, 3:54:00 PM10/22/10
to sage-release
This looks to me like exactly the doctest causing Jan Groenewald's
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

unread,
Oct 22, 2010, 4:02:56 PM10/22/10
to sage-r...@googlegroups.com

Well, that was with the *old* PARI (Sage 4.5.3).

-Leif

leif

unread,
Oct 22, 2010, 4:12:19 PM10/22/10
to sage-r...@googlegroups.com
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.)

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

unread,
Oct 22, 2010, 4:27:00 PM10/22/10
to sage-r...@googlegroups.com
leif wrote:
> 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

unread,
Oct 22, 2010, 4:46:27 PM10/22/10
to sage-r...@googlegroups.com

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

unread,
Oct 22, 2010, 5:31:42 PM10/22/10
to sage-release
On Oct 21, 5:19 pm, Mitesh Patel <qed...@gmail.com> 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.rc...
>
> 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.

Built from scratch and upgraded from 4.5.3 on two Mac OS X 10.6
machines; all tests passed in all four cases.

--
John

leif

unread,
Oct 22, 2010, 5:38:12 PM10/22/10
to sage-r...@googlegroups.com

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

unread,
Oct 22, 2010, 6:04:33 PM10/22/10
to sage-r...@googlegroups.com

Justin, are the plotting.rst, desolvers.py, and assumptions.py errors
reproducible?

Mike Witt

unread,
Oct 22, 2010, 6:05:32 PM10/22/10
to sage-r...@googlegroups.com

No problem. I still have the window open. That one DID work.
-Mike

John H Palmieri

unread,
Oct 22, 2010, 6:10:33 PM10/22/10
to sage-release
On Oct 22, 12:00 am, Mitesh Patel <qed...@gmail.com> wrote:
> 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 bet the plotting.rst error is not repeatable.

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

unread,
Oct 22, 2010, 6:32:22 PM10/22/10
to sage-r...@googlegroups.com

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

unread,
Oct 22, 2010, 7:34:26 PM10/22/10
to sage-r...@googlegroups.com

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

unread,
Oct 22, 2010, 8:39:13 PM10/22/10
to sage-r...@googlegroups.com

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

unread,
Oct 22, 2010, 9:37:05 PM10/22/10
to sage-r...@googlegroups.com

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?
--

Message has been deleted

Jeroen Demeyer

unread,
Oct 23, 2010, 3:20:32 AM10/23/10
to sage-r...@googlegroups.com
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.

Mitesh Patel

unread,
Oct 23, 2010, 4:01:29 AM10/23/10
to sage-r...@googlegroups.com

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

unread,
Oct 23, 2010, 5:33:15 AM10/23/10
to sage-release
Hej All,

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

unread,
Oct 23, 2010, 6:09:39 AM10/23/10
to sage-r...@googlegroups.com
On 10/22/2010 08:37 PM, Justin C. Walker wrote:
> 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

unread,
Oct 23, 2010, 8:12:05 AM10/23/10
to sage-r...@googlegroups.com
Mitesh Patel wrote:
> 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

unread,
Oct 23, 2010, 8:45:23 AM10/23/10
to sage-release

> Well, that was with the *old* PARI (Sage 4.5.3).
>
> -Leif

No, it wasn't, it happened with sage-4.6.alpha3 as well.

-Marshall

leif

unread,
Oct 23, 2010, 10:05:35 AM10/23/10
to sage-r...@googlegroups.com

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

unread,
Oct 23, 2010, 12:20:41 PM10/23/10
to sage-r...@googlegroups.com

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

unread,
Oct 23, 2010, 3:01:56 PM10/23/10
to sage-release
See <http://trac.sagemath.org/sage_trac/ticket/10159> for a Sage trac
ticket. I've also reported it upstream.

--
John

Mitesh Patel

unread,
Oct 23, 2010, 5:58:56 PM10/23/10
to sage-r...@googlegroups.com

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

unread,
Oct 24, 2010, 5:17:59 AM10/24/10
to sage-r...@googlegroups.com
On 10/22/2010 11:45 PM, Minh Nguyen wrote:
> 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

unread,
Oct 24, 2010, 7:06:02 PM10/24/10
to sage-release
Sorry, I did something wrong with the testing, the two docest errors I
reported should be ignored. Everything builds ok.

Dr. David Kirkby

unread,
Oct 25, 2010, 3:56:30 AM10/25/10
to sage-r...@googlegroups.com
On 10/25/10 12:06 AM, koffie wrote:
> 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

unread,
Oct 25, 2010, 5:55:32 AM10/25/10
to sage-release
Since I accidentally tested the wrong version of sage (4.4.4 with some
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:
Traceback (most recent call last):
File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
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:
Traceback (most recent call last):
File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
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:
Traceback (most recent call last):
File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
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:
Traceback (most recent call last):
File "/Applications/sage-4.6.rc0/local/bin/ncadoctest.py", line
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:


sage -t -force_lib "devel/sage/sage/plot/plot3d/base.pyx"
Total time for all tests: 26.8 seconds


On Oct 25, 9:56 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:

koffie

unread,
Oct 25, 2010, 6:07:37 AM10/25/10
to sage-release
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:
http://www.google.nl/search?sourceid=chrome&ie=UTF-8&q=ImportError+Symbol+not+found+_jpeg_resync_to_restart

Mitesh Patel

unread,
Oct 25, 2010, 6:23:57 AM10/25/10
to sage-r...@googlegroups.com

koffie

unread,
Oct 25, 2010, 6:31:37 AM10/25/10
to sage-release
yeah that is exactly the same problem

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:
> >http://www.google.nl/search?sourceid=chrome&ie=UTF-8&q=ImportError+Sy...

David Kirkby

unread,
Oct 25, 2010, 9:37:40 AM10/25/10
to sage-r...@googlegroups.com
On 22 October 2010 10:53, leif <not.r...@online.de> wrote:

> 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

unread,
Oct 25, 2010, 11:20:08 AM10/25/10
to sage-r...@googlegroups.com

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

unread,
Oct 25, 2010, 1:57:07 PM10/25/10
to sage-release
I did a new "make ptestlong" on my mac (os x 10.6.4 gcc 4.2.1) but
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

unread,
Oct 26, 2010, 5:18:02 AM10/26/10
to sage-release
Sage 4.6.rc0 built from scratch, all ptestlong passed,

on AMD X4 Phenom II, Fedora 13,

Georg

Dima Pasechnik

unread,
Oct 30, 2010, 1:45:26 PM10/30/10
to sage-release
builds from scratch and passes testlong on Debian Squeeze x64.

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:
>
> http://sage.math.washington.edu/home/release/sage-4.6.rc0/sage-4.6.rc...
>
> 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]
Reply all
Reply to author
Forward
0 new messages