sage-4.6.1.alpha3 released

[Jeroen Demeyer]

Dear Sage lovers,

We're releasing Sage 4.6.1.alpha3.

Source archive:

http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3.tar

Upgrade path:

http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3/

Please build, test, and report! We'd love to hear about your
experiences with this release.

== Notes ==

There are 2 tickets which need review:
* Upgrade the Readline spkg to 6.1: #9523
* cmdline.py doctest failures on fulvia (SunOS): #10431

The 4.6.1 release cycle is now in feature freeze.

== Known issues ==

* The doctest sage/interfaces/expect.py fails on bsd.math
(OS X 10.6 i386), both compiled as 32-bit and as 64-bit, see #9163.
This error has been reported before, but for a Cygwin build.
* Upgrading on bsd.math (OS X 10.6 i386) is completely broken.
* On iras (ia64-Linux-suse), a doctest in sage/graphs/genus.pyx fails
by giving a negative value for get_memory_usage(), see #9863.

== Tickets ==

* For a more detailed overview of all tickets and patches which are
merged in this version, see

http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/tickets.html

Closed tickets:

#4782: construction of some relative quadratic extensions is SERIOUSLY
FRICKIN's FOO-bar'd [Reviewed by Robert Bradshaw]
#5006: the hg script installed by install_script() does not pass
parameters correctly [Reviewed by Robert Bradshaw]
#8483: Multiplication faster than squaring? [Reviewed by Martin Albrecht]

Merged in sage-4.6.1.alpha3:

#6094: David Joyner, William Stein, Johan S. R. Nielsen: Change all
occurrences of "method" to "algorithm" [Reviewed by Rob Beezer, Robert
Miller]
#9434: John Palmieri: Stop greping for a non-existent sage-banner
[Reviewed by Jeroen Demeyer, David Kirkby]
#9618: Nathann Cohen: Slight improvement to vertex_coloring [Reviewed by
Robert Miller]
#9864: Leif Leonhardy, Mitesh Patel: Error building PIL on RHEL Server
5.5 [Reviewed by Jeroen Demeyer]
#9933: Martin Albrecht: BooleanPolynomialRing not recognizing leading
term of elements [Reviewed by Mariah Lenox]
#9940: John Palmieri: Fix equality/inequality for AdditiveAbelianGroup
[Reviewed by Rob Beezer]
#10183: Damek Davis, Benjamin Jones: long doctests wrongly tagged "#
long" instead of "#long time" [Reviewed by John Cremona, Minh Van Nguyen]
#10187: Volker Braun, David Kirkby: Update ECL to 10.4.1 and Maxima to
5.22.1 - currently the latest releases. [Reviewed by Karl-Dieter
Crisman, David Kirkby, Volker Braun, Leif Leonhardy]
#10188: Volker Braun: mpir spkg needs update for Fedora 14 [Reviewed by
Leif Leonhardy]
#10220: Jason Grout: Unnecessary imports cause slower sage startup
[Reviewed by Jeroen Demeyer]
#10236: Chris Wuthrich: bug in modular symbols for elliptic curves
[Reviewed by John Cremona]
#10287: Minh Van Nguyen: memleak in bitset_realloc() [Reviewed by Robert
Miller]
#10288: John Palmieri: Experimental package 'CHomP' fails to install on
OpenSolaris x86 [Reviewed by David Kirkby]
#10291: Mike Hansen: Plots are changing if showed multiple times
[Reviewed by Andrey Novoseltsev]
#10300: Jeroen Demeyer: Test some command line options [Reviewed by
André Apitzsch]
#10302: John Palmieri: sage -sh should pass exitcode [Reviewed by Jeroen
Demeyer]
#10303: John Palmieri: clean up sage-check-64 and use of SAGE64
[Reviewed by David Kirkby, Leif Leonhardy]
#10304: Mathieu Guay-Paquet: PolynomialRing_field.lagrange_polynomial
doesn't always return a polynomial [Reviewed by Minh Van Nguyen]
#10306: Jeroen Demeyer: Redirect stdout and stderr of sage-cleaner to
/dev/null in sage-sage [Reviewed by Mike Hansen]
#10309: Jeroen Demeyer: Fix doctest error in
doc/en/numerical_sage/cvxopt.rst [Reviewed by Dima Pasechnik]
#10324: Jeroen Demeyer: Cython syntax highlighting for Cython code in
sage/gsl/ode.pyx [Reviewed by Mike Hansen]
#10326: Jeroen Demeyer: Various clean-up in local/bin/sage-sage
[Reviewed by Rob Beezer, Leif Leonhardy]
#10350: Jeroen Demeyer: Fix some remaining issues with
sphinx-1.0.4.p3.spkg [Reviewed by Minh Van Nguyen]
#10359: Leif Leonhardy: Let PIL search '.../lib64' directories for
optional libraries if appropriate [Reviewed by Volker Braun]
#10362: Rob Beezer: Improve vector constructor documentation [Reviewed
by Andrey Novoseltsev]
#10422: Rob Beezer: new_matrix constructor documentation fix [Reviewed
by Benjamin Jones]
#10423: Leif Leonhardy: Upgrade Jinja2 to version 2.5.5 (latest
upstream) [Reviewed by Jeroen Demeyer]
#10431: Jeroen Demeyer: cmdline.py doctest failures on fulvia (SunOS)
[needs review]

[leif]

Jeroen Demeyer wrote:
> Dear Sage lovers,
>
> We're releasing Sage 4.6.1.alpha3.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3.tar
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3/

Why have gotten downloads from sagemath that slow (again, but worse than
ever / even significantly slower than before Harald sped it up)?

> Please build, test, and report! We'd love to hear about your
> experiences with this release.
>
> == Notes ==
>
> There are 2 tickets which need review:
> * Upgrade the Readline spkg to 6.1: #9523
> * cmdline.py doctest failures on fulvia (SunOS): #10431
>
> The 4.6.1 release cycle is now in feature freeze.
>
> == Known issues ==
>
> * The doctest sage/interfaces/expect.py fails on bsd.math
> (OS X 10.6 i386), both compiled as 32-bit and as 64-bit, see #9163.
> This error has been reported before, but for a Cygwin build.

There are no 32-bit builds on bsd / MacOS X 10.6, since it defaults to
64-bit builds. (Setting SAGE64 is not necessary.)

> * Upgrading on bsd.math (OS X 10.6 i386) is completely broken.

Can you give more details? Ticket?

-Leif

> Andr� Apitzsch]

[Jeroen Demeyer]

On 2010-12-06 10:29, leif wrote:
>> * Upgrading on bsd.math (OS X 10.6 i386) is completely broken.
>
> Can you give more details? Ticket?

I have not yet opened a ticket for this.
You can look at the buildbot page
http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29
For a test log with failures, see
http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29/builds/8/steps/shell_4/logs/stdio

[leif]

At first glance, most of these doctest failures look like as if the Sage
library patches for the Maxima upgrade hadn't been applied, so I guess
there are once again missing dependencies in module_list.py.

You could try "sage -ba-force" (if the broken installation is still
there), and rerun the tests.

-Leif

[Jeroen Demeyer]

On 2010-12-06 10:52, leif wrote:
>> I have not yet opened a ticket for this.
>> You can look at the buildbot page
>> http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29
>> For a test log with failures, see
>> http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29/builds/8/steps/shell_4/logs/stdio
>
> At first glance, most of these doctest failures look like as if the Sage
> library patches for the Maxima upgrade hadn't been applied, so I guess
> there are once again missing dependencies in module_list.py.

Could be, but it does not explain why the upgrades do work on other
machines.

> You could try "sage -ba-force" (if the broken installation is still
> there), and rerun the tests.

Mitesh, can you try that on the buildbot OSX 10.6-64 up?

[leif]

Jeroen Demeyer wrote:
> On 2010-12-06 10:52, leif wrote:
>>> I have not yet opened a ticket for this.
>>> You can look at the buildbot page
>>> http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29
>>> For a test log with failures, see
>>> http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29/builds/8/steps/shell_4/logs/stdio
>>
>> At first glance, most of these doctest failures look like as if the Sage
>> library patches for the Maxima upgrade hadn't been applied, so I guess
>> there are once again missing dependencies in module_list.py.
> Could be, but it does not explain why the upgrades do work on other
> machines.

It's not at all clear to me how / when this test was performed, as the
upgrade failed due to the new SAGE64 flag file semantics (#10303).

Cf.
http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29/builds/8/steps/shell_2/logs/stdio
(which is in the *green* area of the weird "waterfall". I don't know
what the order of packages there means, certainly not the order in which
these were built. The missing package version numbers are also bad, and
the logfile aliases have to be made *after* (or actually in theory
within) "sage -upgrade ...", since after downloading we have new spkg
versions.)

Can anyone try a *manual* upgrade on bsd.math or some other MacOS X 10.6
machine, with

*either* setting SAGE64=yes and echoing "yes" into
SAGE_ROOT/local/lib/sage-64.txt

*or* unsetting SAGE64 and deleting that file

prior to upgrading?

Even this /might/ not work immediately, but the user eventually will be
prompted to change a "conflicting" setting. The latter choice, unsetting
SAGE64, is perhaps the better.

Note that MacOS X 10.6 defaults to 64-bit builds anyway, so there's no
point in setting SAGE64=yes, and even setting it to "no" would - at
least until now - not lead to a 32-bit build if one wanted that.

-Leif

[kcrisman]

>   *or* unsetting SAGE64 and deleting that file
>
> prior to upgrading?
>
> Even this /might/ not work immediately, but the user eventually will be
> prompted to change a "conflicting" setting. The latter choice, unsetting
> SAGE64, is perhaps the better.

If the file doesn't already exist, should there be a problem on the
upgrade? I'm trying this currently, having unset SAGE64 (which I
never set anyway)...


Also, I want to point out that sage-README-osx.txt is STILL in
$SAGE_ROOT instead of just in $SAGE_ROOT/local/bin/.

- kcrisman

[Mitesh Patel]

On 12/06/2010 05:04 AM, leif wrote:
> Jeroen Demeyer wrote:
>> On 2010-12-06 10:52, leif wrote:
>>>> I have not yet opened a ticket for this.
>>>> You can look at the buildbot page
>>>> http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29
>>>> For a test log with failures, see
>>>> http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29/builds/8/steps/shell_4/logs/stdio
>>>
>>> At first glance, most of these doctest failures look like as if the Sage
>>> library patches for the Maxima upgrade hadn't been applied, so I guess
>>> there are once again missing dependencies in module_list.py.
>> Could be, but it does not explain why the upgrades do work on other
>> machines.
>
> It's not at all clear to me how / when this test was performed, as the
> upgrade failed due to the new SAGE64 flag file semantics (#10303).
>
> Cf.
> http://build.sagemath.org/sage/builders/OSX%2010.6-64%20up%20%28bsd%29/builds/8/steps/shell_2/logs/stdio
> (which is in the *green* area of the weird "waterfall". I don't know
> what the order of packages there means, certainly not the order in which
> these were built. The missing package version numbers are also bad, and
> the logfile aliases have to be made *after* (or actually in theory
> within) "sage -upgrade ...", since after downloading we have new spkg
> versions.)

Fixing this is on the TODO list. I think one way to do it is to
download the new packages with sage-update, make the log links, and then
run sage-upgrade.

> Can anyone try a *manual* upgrade on bsd.math or some other MacOS X 10.6
> machine, with
>
> *either* setting SAGE64=yes and echoing "yes" into
> SAGE_ROOT/local/lib/sage-64.txt
>
> *or* unsetting SAGE64 and deleting that file
>
> prior to upgrading?
>
> Even this /might/ not work immediately, but the user eventually will be
> prompted to change a "conflicting" setting. The latter choice, unsetting
> SAGE64, is perhaps the better.

I built 4.6 on bsd with SAGE64 unset. The upgrade to 4.6.1.alpha3
succeeded and the long doctests passed, except for the known expect.py
failure (#9163) and

sage -t -long -force_lib "devel/sagenb-main/sagenb/misc/sphinxify.py"
**********************************************************************
File
"/Users/buildbot/mpatel/sage-4.6-4.6.1.alpha3/devel/sagenb-main/sagenb/misc/sphinxify.py",
line 69:
sage: sphinxify('A test')
Expected:
'<div class="docstring">\n \n <p>A test</p>\n\n\n</div>'
Got:
'\n<div class="docstring">\n \n <p>A test</p>\n\n\n</div>'
**********************************************************************
File
"/Users/buildbot/mpatel/sage-4.6-4.6.1.alpha3/devel/sagenb-main/sagenb/misc/sphinxify.py",
line 71:
sage: sphinxify('**Testing**\n`monospace`')
Expected:
'<div class="docstring"...<strong>Testing</strong>\n<span
class="math"...</p>\n\n\n</div>'
Got:
'\n<div class="docstring">\n \n
<p><strong>Testing</strong>\n<span
class="math">monospace</span></p>\n\n\n</div>'
**********************************************************************
File
"/Users/buildbot/mpatel/sage-4.6-4.6.1.alpha3/devel/sagenb-main/sagenb/misc/sphinxify.py",
line 73:
sage: sphinxify('`x=y`')
Expected:
'<div class="docstring">\n \n <p><span
class="math">x=y</span></p>\n\n\n</div>'
Got:
'\n<div class="docstring">\n \n <p><span
class="math">x=y</span></p>\n\n\n</div>'
**********************************************************************

Has anyone else seen this?

> Note that MacOS X 10.6 defaults to 64-bit builds anyway, so there's no
> point in setting SAGE64=yes, and even setting it to "no" would - at
> least until now - not lead to a 32-bit build if one wanted that.

Are there any objections to removing the redundant OS X 10.6 builder and
keeping the regular, binary, and upgrade builders, all of which do not
set SAGE64 but default implicitly to 64-bit builds?

[Mitesh Patel]

On 12/06/2010 02:22 AM, Jeroen Demeyer wrote:
> Dear Sage lovers,
>
> We're releasing Sage 4.6.1.alpha3.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3.tar
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3/
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.

There are some binaries in

http://sage.math.washington.edu/home/buildbot/binaries/sage/4.6.1.alpha3

[kcrisman]

> I built 4.6 on bsd with SAGE64 unset.  The upgrade to 4.6.1.alpha3

My upgrade from alpha2 succeeded as well.

> succeeded and the long doctests passed, except for the known expect.py
> failure (#9163) and
>
> sage -t -long -force_lib "devel/sagenb-main/sagenb/misc/sphinxify.py"
> **********************************************************************
> File

> "/Users/buildbot/mpatel/sage-4.6-4.6.1.alpha3/devel/sagenb-main/sagenb/misc /sphinxify.py",

> line 69:
>     sage: sphinxify('A test')
> Expected:
>     '<div class="docstring">\n    \n  <p>A test</p>\n\n\n</div>'
> Got:
>     '\n<div class="docstring">\n    \n  <p>A test</p>\n\n\n</div>'
> **********************************************************************
> File

> "/Users/buildbot/mpatel/sage-4.6-4.6.1.alpha3/devel/sagenb-main/sagenb/misc /sphinxify.py",

> line 71:
>     sage: sphinxify('**Testing**\n`monospace`')
> Expected:
>     '<div class="docstring"...<strong>Testing</strong>\n<span
> class="math"...</p>\n\n\n</div>'
> Got:
>     '\n<div class="docstring">\n    \n
> <p><strong>Testing</strong>\n<span
> class="math">monospace</span></p>\n\n\n</div>'
> **********************************************************************
> File

> "/Users/buildbot/mpatel/sage-4.6-4.6.1.alpha3/devel/sagenb-main/sagenb/misc /sphinxify.py",

> line 73:
>     sage: sphinxify('`x=y`')
> Expected:
>     '<div class="docstring">\n    \n  <p><span
> class="math">x=y</span></p>\n\n\n</div>'
> Got:
>     '\n<div class="docstring">\n    \n  <p><span
> class="math">x=y</span></p>\n\n\n</div>'
> **********************************************************************
>
> Has anyone else seen this?

sage -t -long -force_lib "devel/sagenb-main/sagenb/misc/sphinxify.py"

[19.8 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 19.8 seconds

Sorry I couldn't duplicate this. Or maybe I'm not?

Also, with respect to #9163:

sage -t -long "devel/sage/sage/interfaces/expect.py"
[19.1 s]

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 19.1 seconds

Did I do something wrong? This is an OS X 10.6 box.

- kcrisman

[Jeroen Demeyer]

On 2010-12-07 03:29, Mitesh Patel wrote:
> sage -t -long -force_lib "devel/sagenb-main/sagenb/misc/sphinxify.py"

> Has anyone else seen this?

YES, see my thread "Is sage -f sagenb-VERSION supposed to update
devel/sagenb-main?" on sage-devel.

[David Kirkby]

On 6 December 2010 08:22, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Dear Sage lovers,
>
> We're releasing Sage 4.6.1.alpha3.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3.tar

I get a strange problem on my laptop running Solaris 11 express with
Pari. I'm surprised this did not show up in the earlier releases The
error message is a bit confusing too.

Basically it looks like two options are being passed to the linker.
One is -a, which is only used for static libraries. The other is -dy,
which is only used for dynamic libraries.

This is a bit odd, as:

* 4.6.1.alpha2,built ok on the same machine.
* The error message looks like two incomatible linker options are
bing passed, but it's not obvious to me where those link options get
passed.

gcc -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -O3 -g
-I. -I../src/headers -fPIC -o part.o ../src/modules/part.c
gcc -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -O3 -g
-I. -I../src/headers -fPIC -o stark.o ../src/modules/stark.c
gcc -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -O3 -g
-I. -I../src/headers -fPIC -o subfield.o ../src/modules/subfield.c
gcc -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -O3 -g
-I. -I../src/headers -fPIC -o thue.o ../src/modules/thue.c
rm -f libpari-gmp-2.4.so.24.3
gcc -o "/export/home/drkirkby/sage-4.6.1.alpha3/spkg/build/pari-2.4.3.alpha.p0/src/Osunos-none"/libpari-gmp-2.4.so.24.3
-shared -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -O3 -g
-fPIC -Wl,-assert,nodefinitions mp.o mpinl.o F2x.o FF.o Flx.o FpE.o
FpV.o FpX.o Qfb.o RgV.o RgX.o ZV.o ZX.o alglin1.o alglin2.o arith1.o
arith2.o base1.o base2.o base3.o base4.o base5.o bb_group.o bibli1.o
bibli2.o bit.o buch1.o buch2.o buch3.o buch4.o concat.o ellanal.o
elliptic.o galconj.o gen1.o gen2.o gen3.o hnf_snf.o ifactor1.o lll.o
perm.o polarit1.o polarit2.o polarit3.o prime.o random.o rootpol.o
subcyclo.o subgroup.o trans1.o trans2.o trans3.o anal.o compat.o
compile.o default.o errmsg.o es.o eval.o hash.o init.o intnum.o
members.o pariinl.o parse.o sumiter.o DedekZeta.o Hensel.o QX_factor.o
aprcl.o elldata.o ellsea.o galois.o galpol.o groupid.o krasner.o
kummer.o mpqs.o nffactor.o part.o stark.o subfield.o thue.o -lc -lm
-L/export/home/drkirkby/sage-4.6.1.alpha3/local/lib -lgmp
ld: fatal: option -dy and -a are incompatible
ld: fatal: flags processing errors
collect2: ld returned 1 exit status
make[3]: *** [libpari-gmp-2.4.so.24.3] Error 1

Dave

[Willem Jan Palenstijn]

On Tue, Dec 07, 2010 at 12:31:10PM +0000, David Kirkby wrote:
> On 6 December 2010 08:22, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> > Dear Sage lovers,
> >
> > We're releasing Sage 4.6.1.alpha3.
> >
> > Source archive:
> >
> > http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3.tar
>
> I get a strange problem on my laptop running Solaris 11 express with
> Pari. I'm surprised this did not show up in the earlier releases The
> error message is a bit confusing too.
>
> Basically it looks like two options are being passed to the linker.
> One is -a, which is only used for static libraries. The other is -dy,
> which is only used for dynamic libraries.
>
> This is a bit odd, as:
>
> * 4.6.1.alpha2,built ok on the same machine.
> * The error message looks like two incomatible linker options are
> bing passed, but it's not obvious to me where those link options get
> passed.
>
>

<snip>

> gcc -o "/export/home/drkirkby/sage-4.6.1.alpha3/spkg/build/pari-2.4.3.alpha.p0/src/Osunos-none"/libpari-gmp-2.4.so.24.3
> -shared -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -O3 -g
> -fPIC -Wl,-assert,nodefinitions mp.o mpinl.o F2x.o FF.o Flx.o FpE.o

<snip more object files>

> kummer.o mpqs.o nffactor.o part.o stark.o subfield.o thue.o -lc -lm
> -L/export/home/drkirkby/sage-4.6.1.alpha3/local/lib -lgmp
> ld: fatal: option -dy and -a are incompatible

The -Wl,-assert,nodefinitions is triggering that error. It looks like some
linkers support that, but some don't. For example, GNU ld ignores the -assert
option entirely, /usr/ccs/bin/ld on t2 doesn't support it, but apparently some
Sun linkers do support it.

The option is set by pari's config/get_dlld.

I hope this helps you in figuring out what changed for you since alpha2.

-Willem Jan

[Jeroen Demeyer]

On 2010-12-07 13:31, David Kirkby wrote:
> * 4.6.1.alpha2,built ok on the same machine.

That is very strange, because pari did not get updated since
sage-4.6.1.alpha1 (md5sum of the pari spkgs in alpha1, alpha2 and alpha3
is 7fca0be69aaa2ebcdf08d312dabfa643).

[Rob Beezer]

Build from source, make testlong (all single-threaded) went fine on 64-
bit KUbuntu 10.04.

Upgrade from a previously upgraded 4.6.1.alpha2 failed with complaints
about the extcode package and its Mercurial merges and unresolved
conflicts. Which looks identical to part of a recent discussion about
extcode from Volker Braun:

http://groups.google.com/group/sage-release/msg/029ed6f35f558efc
http://groups.google.com/group/sage-release/msg/2635bee6b0c92b01

1. I can stuff install.log somewhere or provide console output if it
is needed. Just say so.

2. This is my development copy of Sage, so who knows what else might
be nonstandard. I did unapply all patches and rebuild before starting
the upgrade.

3. Can I just forcibly install the remaining updated packages (and
rebuild) to get my upgrade back on course? Or if there is a really
quick explanation of how to get back on track, a pointer or two would
be appreciated. Nothing lost, I can always start fresh. Thanks.

Rob

[David Kirkby]

Ignore my report. Something must have got screwed up on this machine,
as 4.6.1.alpha2 now fails at the same point, whereas it built fine
before.

I've been messing around with a few things. Though I can't possibly
think what would have caused it. I think it was me.

Dave

[Justin C. Walker]

On Dec 6, 2010, at 00:22 , Jeroen Demeyer wrote:

> Dear Sage lovers,
>
> We're releasing Sage 4.6.1.alpha3.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3.tar
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3/

Built from scratch on Mac OS X (10.6.5; Dual Quad Xeon). All tests passed ("ptestlong")!

Great work!

Upgrade from 4.6.1-a2 underway.

Justin

--
Justin C. Walker
Curmudgeon at Large
Director
Institute for the Enhancement of the Director's Income
--
Build a man a fire and he'll be warm
for a night.
Set a man on fire and he'll be warm
for the rest of his life.

[Rob Beezer]

On Dec 7, 10:34 am, Rob Beezer <goo...@beezer.cotse.net> wrote:
> Upgrade from a previously upgraded 4.6.1.alpha2 failed with complaints
> about the extcode package and its Mercurial merges and unresolved
> conflicts.  Which looks identical to part of a recent discussion about
> extcode from Volker Braun:

Replying to myself: nevermind. I had some testing debris in local/
bin that I'd forgotten about, which caused further failures too.

Rob

[kcrisman]

> #10187: Volker Braun, David Kirkby: Update ECL to 10.4.1 and Maxima to
> 5.22.1 - currently the latest releases. [Reviewed by Karl-Dieter
> Crisman, David Kirkby, Volker Braun, Leif Leonhardy]

Did we not update the banner to alpha3? Clearly I have alpha3, since
Maxima is upgraded... and I have the correct Jinja... what gives?

----------------------------------------------------------------------
| Sage Version 4.6.1.alpha2, Release Date: 2010-11-21 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
sage: maxima_console()
<snip>
Maxima 5.22.1 http://maxima.sourceforge.net
using Lisp ECL 10.4.1
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.

[François]

On Dec 9, 9:55 am, kcrisman <kcris...@gmail.com> wrote:
> > #10187: Volker Braun, David Kirkby: Update ECL to 10.4.1 and Maxima to
> > 5.22.1 - currently the latest releases. [Reviewed by Karl-Dieter
> > Crisman, David Kirkby, Volker Braun, Leif Leonhardy]
>
> Did we not update the banner to alpha3?  Clearly I have alpha3, since
> Maxima is upgraded... and I have the correct Jinja... what gives?
>
> ----------------------------------------------------------------------
> | Sage Version 4.6.1.alpha2, Release Date: 2010-11-21                |
> | Type notebook() for the GUI, and license() for information.        |
> ----------------------------------------------------------------------
> **********************************************************************
> *                                                                    *
> * Warning: this is a prerelease version, and it may be unstable.     *
> *                                                                    *
> **********************************************************************
> sage: maxima_console()
> <snip>

> Maxima 5.22.1http://maxima.sourceforge.net

> using Lisp ECL 10.4.1
> Distributed under the GNU Public License. See the file COPYING.
> Dedicated to the memory of William Schelter.
> The function bug_report() provides bug reporting information.

I got the correct banner. On a build from the source tarball.

[François]

On Dec 6, 9:22 pm, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> Dear Sage lovers,
>
> We're releasing Sage 4.6.1.alpha3.
>
> Source archive:
>

> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4...
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4...

>
> Please build, test, and report!  We'd love to hear about your
> experiences with this release.
>

Built from scratch on a rather vanilla intel iMac running 10.5.8
(gcc-4.0.1)
and I got 2 doctest failures:

/sage -t -long -force_lib "devel/sage/sage/plot/plot3d/base.pyx"
sage -t -long -force_lib "devel/sage/sage/plot/plot3d/base.pyx"
**********************************************************************
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/devel/sage/sage/plot/
plot3d/base.pyx", line 1160:
sage: G.save(f)
Exception raised:
Traceback (most recent call last):
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/bin/
ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/bin/
sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/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:11358)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/lib/python2.6/
site-packages/PIL/Image.py", line 1888, in open
fp = __builtin__.open(fp, "rb")
IOError: [Errno 2] No such file or directory: '/Users/frb15/.sage//
temp/BlueFerniMac1.canterbury.ac.nz/58267//tmp_132'
**********************************************************************
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/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 "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/bin/
ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/bin/
sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/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:11358)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/lib/python2.6/
site-packages/PIL/Image.py", line 1888, in open
fp = __builtin__.open(fp, "rb")
IOError: [Errno 2] No such file or directory: '/Users/frb15/.sage//
temp/BlueFerniMac1.canterbury.ac.nz/58267//tmp_135'
**********************************************************************
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/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 "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/bin/
ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/bin/
sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/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:11358)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/lib/python2.6/
site-packages/PIL/Image.py", line 1888, in open
fp = __builtin__.open(fp, "rb")
IOError: [Errno 2] No such file or directory: '/Users/frb15/.sage//
temp/BlueFerniMac1.canterbury.ac.nz/58267//tmp_138'
**********************************************************************
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/devel/sage/sage/plot/
plot3d/base.pyx", line 1175:
sage: cube().save(tmp_filename() + '.gif')
Exception raised:
Traceback (most recent call last):
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/bin/
ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/bin/
sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/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:11358)
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/local/lib/python2.6/
site-packages/PIL/Image.py", line 1888, in open
fp = __builtin__.open(fp, "rb")
IOError: [Errno 2] No such file or directory: '/Users/frb15/.sage//
temp/BlueFerniMac1.canterbury.ac.nz/58267//tmp_142'
**********************************************************************
1 items had failures:
4 of 8 in __main__.example_35
***Test Failed*** 4 failures.
For whitespace errors, see the file /Users/frb15/.sage//
tmp/.doctest_base.py
[11.7 s]

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


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


and:

./sage -t -long -force_lib "devel/sage/sage/plot/plot3d/tachyon.py"
sage -t -long -force_lib "devel/sage/sage/plot/plot3d/tachyon.py"
rm: /Users/frb15/.sage//temp/BlueFerniMac1.canterbury.ac.nz/58884//
tmp_16: No such file or directory
**********************************************************************
File "/Users/frb15/Desktop/sage-4.6.1.alpha3/devel/sage/sage/plot/
plot3d/tachyon.py", line 297:
sage: os.system('rm ' + tempname)
Expected:
0
Got:
256
**********************************************************************
1 items had failures:
1 of 9 in __main__.example_4
***Test Failed*** 1 failures.
For whitespace errors, see the file /Users/frb15/.sage//
tmp/.doctest_tachyon.py
[5.3 s]

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


sage -t -long -force_lib "devel/sage/sage/plot/plot3d/tachyon.py"
Total time for all tests: 5.3 seconds


Francois

[kcrisman]

Ah, but I upgraded. Hmm.

[Justin C. Walker]

On Dec 6, 2010, at 00:22 , Jeroen Demeyer wrote:

> Dear Sage lovers,
>
> We're releasing Sage 4.6.1.alpha3.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3.tar
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3/

Upgrade from 4.6.1-a2 completed (Mac OS X, 10.6.5, Dual Quad Xeon) w/o problems and all tests passed!

Full build on 10.4.11 underway.

Justin

--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
If you're not confused,
You're not paying attention
--------

[Johan S. R. Nielsen]

My upgrade from 4.6.1.-a2 failed but that may very well be because of
local changes I forgot to pop. I had messed around with that install
quite a bit.

Anyway: after downloading and clean building, all tests passed! And my
banner is correct.

System: Ubuntu 10.4 w. kernel 2.6.32-26

Johan

[John H Palmieri]

On Dec 8, 12:55 pm, kcrisman <kcris...@gmail.com> wrote:
> > #10187: Volker Braun, David Kirkby: Update ECL to 10.4.1 and Maxima to
> > 5.22.1 - currently the latest releases. [Reviewed by Karl-Dieter
> > Crisman, David Kirkby, Volker Braun, Leif Leonhardy]
>
> Did we not update the banner to alpha3?  Clearly I have alpha3, since
> Maxima is upgraded... and I have the correct Jinja... what gives?

When I try upgrading, I get the message


pulling from /Applications/sage_builds/sage-4.6.1.alpha3-upgrade/spkg/
build/sage_scripts-4.6.1.alpha3
searching for changes
adding changesets
adding manifests
adding file changes
added 19 changesets with 26 changes to 18 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

...

merging .hgtags
warning: conflicts during merge.
merging .hgtags failed!
merging sage-banner
warning: conflicts during merge.
merging sage-banner failed!


This is in an attempt to upgrade a clean copy of 4.6.1.alpha0.


By the way, is the script "hgmerge" still needed on OS X these days?
It was added to the mercurial spkg 2 years ago...

--
John

[kcrisman]

On Dec 9, 10:57 am, John H Palmieri <jhpalmier...@gmail.com> wrote:
> On Dec 8, 12:55 pm, kcrisman <kcris...@gmail.com> wrote:
>
> > > #10187: Volker Braun, David Kirkby: Update ECL to 10.4.1 and Maxima to
> > > 5.22.1 - currently the latest releases. [Reviewed by Karl-Dieter
> > > Crisman, David Kirkby, Volker Braun, Leif Leonhardy]
>
> > Did we not update the banner to alpha3?  Clearly I have alpha3, since
> > Maxima is upgraded... and I have the correct Jinja... what gives?
>
> When I try upgrading, I get the message
>
> pulling from /Applications/sage_builds/sage-4.6.1.alpha3-upgrade/spkg/
> build/sage_scripts-4.6.1.alpha3
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 19 changesets with 26 changes to 18 files (+1 heads)
> (run 'hg heads' to see heads, 'hg merge' to merge)
>
> ...
>
> merging .hgtags
> warning: conflicts during merge.
> merging .hgtags failed!
> merging sage-banner
> warning: conflicts during merge.
> merging sage-banner failed!
>

Oh, and that explains why, when I upgrade, the program FileMerge
automatically pops up with a few random things like that. It never
seems to cause problems, but perhaps in certain instances it does have
side effects like this.

- kcrisman

[Justin C. Walker]

On Dec 6, 2010, at 00:22 , Jeroen Demeyer wrote:

> Dear Sage lovers,
>
> We're releasing Sage 4.6.1.alpha3.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3.tar
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.1.alpha3/sage-4.6.1.alpha3/

Full build on Mac OS X, 10.4.11 (Core 2 Duo) completed w/o problems.

Testing (ptestlong) showed two failures. Tried both individually. The first failed as before. The second passed. Both failures are below. Full test log is at
sage.math.washington.edu:~justin/logs/ptestlong-4.6.1-10.4.11.log

Justin

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

sage -t -long -force_lib "devel/sage/sage/tests/cmdline.py"
**********************************************************************
File "/SandBox/Justin/sb/sage-4.6.1.alpha3/devel/sage/sage/tests/cmdline.py", line 198:
sage: err
Expected:
''
Got:
'ERROR: history is not a magic function\n'

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

1 of 119 in __main__.example_1

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

sage -t -long -force_lib devel/sage/sage/tests/book_stein_ent.py
**********************************************************************
File "/SandBox/Justin/sb/sage-4.6.1.alpha3/devel/sage-main/sage/tests/book_stein_ent.py", line 289:
sage: qsieve(n)
Expected:
([6340271405786663791648052309,
46102313108592180286398757159], '')
Got:
([], '')

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

1 of 267 in __main__.example_1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

--
Justin C. Walker, Curmudgeon at Large

Institute for the Absorption of Federal Funds
--

Democracy is two wolves and a lamb
voting on what to have for lunch.
Liberty is a well-armed lamb contesting
the vote.

[kcrisman]

Just wanted to let folks know that I tried compiling Sage with the new
XCode update on Snow Leopard, and it built fine. MAN that
SAGE_SPKG_PARALLEL_BUILD="yes" is great!

Incidentally, I thought that ./sage -tp -long directory/ would pick 2
times the number of cores (default, IIRC), but apparently you have to
give it ./sage -tp 4 -long in that case. Did I miss something about
that default?

- kcrisman

[Jeroen Demeyer]

I believe the default in min(8, number_of_cores). I don't know about a
factor 2 (and I don't think there should be a factor 2).

Jeroen.

[kcrisman]

Sorry, I must have been confused... but on this machine that would
still lend TWO cores (Intel Core 2 Duo, do I interpret this
correctly?), and when I do ./sage -tp -long directory/, it says
testing 1500-odd files with 1 thread - not 2 threads. Can someone
else confirm this?

- kcrisman

[John H Palmieri]

Running "sage -tp ..." calls the script sage-ptest. If you omit the
numeric argument, then it defaults to 1 thread. Is that reasonable
behavior? If you give it the argument 0, on the other hand, then it
uses numthreads=min(8, number of cpus).

This should be documented somewhere...

--
John

[kcrisman]

Ah, I see, it's no argument gives 1 thread, but argument 0 gives
min(...). Should we also use min(...) for no argument? I think
that half of this is documented, but maybe not the other half... ?
Though I don't see it at http://www.sagemath.org/doc/developer/doctesting.html
...

[Jeroen Demeyer]

On 2010-12-09 23:34, Justin C. Walker wrote:
> sage -t -long -force_lib "devel/sage/sage/tests/cmdline.py"
> **********************************************************************
> File "/SandBox/Justin/sb/sage-4.6.1.alpha3/devel/sage/sage/tests/cmdline.py", line 198:
> sage: err
> Expected:
> ''
> Got:
> 'ERROR: history is not a magic function\n'
> **********************************************************************
> 1 items had failures:
> 1 of 119 in __main__.example_1

This is related to IPython. What happens when you type ./sage --ipython ?

[Justin C. Walker]

Yup. The result is

$ ./sage --ipython

ERROR: history is not a magic function

sage:

Does this mean that IPython is trying to execute "%history"?

I don't see it in any of my "rc" files, and this is new behavior (although 4.5.2 is the previous version that I've built on my 10.4 system, so bit rot could easily settle in).

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

[Jeroen Demeyer]

On 2010-12-11 22:40, Justin C. Walker wrote:
> $ ./sage --ipython
> ERROR: history is not a magic function
> sage:

That's so wrong (why is there a "sage" prompt?). I get something
totally different:
$ ./sage --ipython
Python 2.6.4 (r264:75706, Dec 5 2010, 10:29:33)
Type "copyright", "credits" or "license" for more information.

IPython 0.9.1 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]:

[Justin C. Walker]

On Dec 11, 2010, at 13:49 , Jeroen Demeyer wrote:

> On 2010-12-11 22:40, Justin C. Walker wrote:
>> $ ./sage --ipython
>> ERROR: history is not a magic function
>> sage:
>
> That's so wrong (why is there a "sage" prompt?).

Hey, I just report what I see :-}

> I get something
> totally different:
> $ ./sage --ipython
> Python 2.6.4 (r264:75706, Dec 5 2010, 10:29:33)
> Type "copyright", "credits" or "license" for more information.

Perhaps because ipython errored out, sage took over. Looking over 'sage-sage', this doesn't seem likely, but it's shell programming, after all.

I don't see any local files being modified, nor any "rc" files with apparently bogus entries (nothing in the various history files I've checked so far).

I'll keep looking.

Justin

--
Justin C. Walker, Curmudgeon at Large

Director
Institute for the Enhancement of the Director's Income

-----------
Nobody knows the trouble I've been
-----------

[leif]

kcrisman wrote:
> Ah, I see, it's no argument gives 1 thread, but argument 0 gives
> min(...). Should we also use min(...) for no argument? I think
> that half of this is documented, but maybe not the other half... ?
> Though I don't see it at http://www.sagemath.org/doc/developer/doctesting.html
> ...

The documentation is certainly not up-to-date (especially w.r.t.
*M*akefile and the targets for testing; there are e.g. more of them.
Also it doesn't mention how to override the default "NUM_THREADS" in the
Makefile without editing it.)

IMHO sage-ptest (or "sage -tp ...") should exit with an error if no "N"
(number of threads) argument was given, since this parameter is *not*
(and as far as I know never has been) optional.

The Python script sage-ptest tries to be "smart":

argv = sys.argv
opts = ' '.join([X for X in argv if X[0] == '-'])
argv = [X for X in argv if X[0] != '-']

try:
numthreads = int(argv[1])
infiles = argv[2:]
except ValueError: # can't convert first arg to an integer: arg was
probably omitted
numthreads = 1
infiles = argv[1:]

I think we should raise an error there instead; all help messages tell
"-tp" and alike should be (immediately btw.) followed by <num_threads>.

I don't recall when interpreting "0" as min(8, num_cpus) was introduced
/there/; it's "always" been in the Makefile, but I think it's relatively
new in sage-ptest.

Note that a (more or less unintentional) "doubling" of the number of
threads (or cores) usually happens on CPUs with hyperthreading (but only
if you specify "0" threads), since Python reports the number of hardware
threads, not cores. (Intel dropped hyperthreading in the Core and Core2
processors, but the newer ones - including AMD CPUs - again have it.)

The only intentional doubling I'm aware of happens when building the
Sage library in parallel, where the number of "CPUs" Python reports is
doubled, which makes sense (to me ;-) ).

-Leif

[leif]

leif wrote:
> I don't recall when interpreting "0" as min(8, num_cpus) was introduced
> /there/; it's "always" been in the Makefile, but I think it's relatively
> new in sage-ptest.

That's of course BU**SH**, since the Makefile doesn't "compute" the
number of threads, but simply passes "-tp 0" by default when running
e.g. "make ptestlong", which indirectly calls sage-ptest. :-)

-Leif

[Jeroen Demeyer]

On 2010-12-11 23:12, Justin C. Walker wrote:
> Perhaps because ipython errored out, sage took over.

Sage is getting sentient and trying to take over the universe :-)

[David Kirkby]

I don't believe there's a factor of two there either. There might be
some advantage in having a factor of 1.5 though, as the build process
is often not CPU bound, and so having more threds is generally a good
thing. But I still think a limit of 8 is right as a default, to stop
people accidentally taking over large servers.

Dave

[Volker Braun]

For the record, the alpha3 compiles on Fedora 14 :-)

Jmol still does not work on the Sage command line on F14 x86_64 because Sage mistakenly launches it via "sage-native-execute". It would be nice if someone could review this simple ticket:

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

Volker

[koffie]

On Dec 7, 9:08 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> On 2010-12-07 03:29, Mitesh Patel wrote:
>
> > sage -t -long -force_lib "devel/sagenb-main/sagenb/misc/sphinxify.py"
> > Has anyone else seen this?
>
> YES, see my thread "Is sage -f sagenb-VERSION supposed to update
> devel/sagenb-main?" on sage-devel.

Upgrade succeeded on os x 10.6.5.

During a sage -testall I got the same sphinxify error also together
with the already known http://trac.sagemath.org/sage_trac/ticket/10059

All other tests succeded

[Volker Braun]

http://trac.sagemath.org/sage_trac/ticket/10185 can be closed (fixed by ECL/Maxima update)

[kcrisman]

Can anyone verify the following from a scratch-built alpha3? This is
on Mac OS X 10.6.


sage: G = plot(sin)+circle((3,2),2)+arrow((5,6),(3,2))
sage: G
dyld: Library not loaded: /usr/X11/lib/libfreetype.6.dylib
Referenced from: /usr/X11/bin/fc-list
Reason: Incompatible library version: fc-list requires version
13.0.0 or later, but libfreetype.6.dylib provides version 10.0.0
dyld: Library not loaded: /usr/X11/lib/libfreetype.6.dylib
Referenced from: /usr/X11/bin/fc-list
Reason: Incompatible library version: fc-list requires version
13.0.0 or later, but libfreetype.6.dylib provides version 10.0.0

The plot still shows up, incidentally. And certainly I don't think
that we should be using the Mac X11 libraries for stuff, since it is
highly likely that many users on Mac won't have that installed! Maybe
it's just picking them up when matplotlib is compiled? This is not
really my expertise, though, so that may make no sense.

Thanks,
- kcrisman

[Volker Braun]

Do your coordinate axes have numbers besides the tick marks? The freetype library is there to render truetype fonts. Sage includes a freetype spkg but apparently matplotlib picked up the wrong one.

[kcrisman]

On Dec 22, 11:09 am, Volker Braun <vbraun.n...@gmail.com> wrote:
> Do your coordinate axes have numbers besides the tick marks? The freetype
> library is there to render truetype fonts.

This time, yes; I didn't pay attention last time, and I had already
closed that session.

> Sage includes a freetype spkg but
> apparently matplotlib picked up the wrong one.

Yes, that is what I was referring to. Weirdly, no error this time,
tried restarting Sage four times and doing it again, always worked.
Well, let's be on the lookout, but for now a false alarm.

- kcrisman

[Volker Braun]

Looks like you managed to unset LD_LIBRARY_PATH somehow before invoking the plot command.

[koffie]

On Dec 22, 4:51 pm, kcrisman <kcris...@gmail.com> wrote:
> Can anyone verify the following from a scratch-built alpha3?  This is
> on Mac OS X 10.6.
>

I don't have a from scratch build one, but I do have one which has
been upgraded from a 4.6.rc0 schratch build one on my OS X 10.6.5
machine. There it just works as it should.