sage-5.8.rc0 released

[Jeroen Demeyer]

Dear Sage lovers,

We're releasing Sage 5.8.rc0.

Source archive:

http://boxen.math.washington.edu/home/release/sage-5.8.rc0/sage-5.8.rc0.tar

Upgrade path:

http://boxen.math.washington.edu/home/release/sage-5.8.rc0/sage-5.8.rc0/

The source and upgrade path can also be found on the mirror network
(you might need to wait a while before the mirrors are synchronized):

http://www.sagemath.org/download-latest.html


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

== Tickets ==

* We closed 144 tickets in this release. For details, see

http://boxen.math.washington.edu/home/release/sage-5.8.rc0/tickets.html

Merged in sage-5.8.rc0:

#14121: Chris Berg: Fixing bug in shuffle product [Reviewed by Franco
Saliola, Frédéric Chapoton, Nathann Cohen]
#14245: John Palmieri: Cloning doesn't properly copy the _static doc
directory [Reviewed by Florent Hivert]
#14254: Jeroen Demeyer: OverflowErrors in TripleDictEraser [Reviewed by
Simon King]

[Nathann Cohen]

Hellooooooooooooooooo !!!

I get an error when I compile this release. That's where it seems to come from :

[...]

checking for setpgrp... (cached) yes

checking for gettimeofday... yes

checking for major... yes

checking for getaddrinfo... yes

checking getaddrinfo bug... yes

Fatal: You must get working getaddrinfo() function.

       or you can specify "--disable-ipv6".

Error configuring Python.

real    0m15.329s

user    0m5.964s

sys     0m3.096s

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

Error installing package python-2.7.3.p5

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

Please email sage-devel (http://groups.google.com/group/sage-devel)

[...]

By the way, we usually email sage-release in such situations and not sage-devel :-)

Here is my install.log file if it can help :

http://steinertriples.fr/install.log

Nathann

[leif]

Nathann Cohen wrote:
> Hellooooooooooooooooo !!!
>
> I get an error when I compile this release. That's where it seems to
> come from :
>
> [...]
> checking for setpgrp... (cached) yes
> checking for gettimeofday... yes
> checking for major... yes
> checking for getaddrinfo... yes
> checking getaddrinfo bug... yes
> Fatal: You must get working getaddrinfo() function.
> or you can specify "--disable-ipv6".
> Error configuring Python.
>
> real 0m15.329s
> user 0m5.964s
> sys 0m3.096s
> ************************************************************************
> Error installing package python-2.7.3.p5
> ************************************************************************
> Please email sage-devel (http://groups.google.com/group/sage-devel)
> [...]

You can

$ env PYTHON_CONFIGURE=--disable-ipv6 ./sage -i
http://sage.math.washington.edu/home/jdemeyer/spkg/python-2.7.3.p6.spkg

:-)

(Better first copy the spkg into spkg/standard/, then export
PYTHON_CONFIGURE=..., then run 'make' again.)

>
> By the way, we usually email sage-release in such situations and not
> sage-devel :-)

Yes. I've complained a couple of times that we should mention
sage-release first there.


-leif


P.S.: Details on the OS?

>
> Here is my install.log file if it can help :
> http://steinertriples.fr/install.log
>
> Nathann

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Jeroen Demeyer]

On 2013-03-14 11:05, Nathann Cohen wrote:
> Hellooooooooooooooooo !!!
>
> I get an error when I compile this release.

Since Python hasn't changed recently, either
1) this is just some random unexplained failure ("cosmic ray") which
should go away when rebuilding.
or
2) previous versions of Sage also failed to compiled on this machine.
or
3) there is some very weird interaction between packages I am overlooking.

[leif]

Jeroen Demeyer wrote:
> On 2013-03-14 11:05, Nathann Cohen wrote:
>> Hellooooooooooooooooo !!!
>>
>> I get an error when I compile this release.
> Since Python hasn't changed recently, either
> 1) this is just some random unexplained failure ("cosmic ray") which
> should go away when rebuilding.

http://www.swpc.noaa.gov/forecast.html

> or
> 2) previous versions of Sage also failed to compiled on this machine.
> or
> 3) there is some very weird interaction between packages I am overlooking.
>

[Nathann Cohen]

Hellooooooo !!

> $ env PYTHON_CONFIGURE=--disable-ipv6 ./sage -i
> http://sage.math.washington.edu/home/jdemeyer/spkg/python-2.7.3.p6.spkg

I will try that !

> P.S.:  Details on the OS?

Debian unstable !

Nathann

[Nathann Cohen]

Helloooooooooooo !!

> Since Python hasn't changed recently, either
> 1) this is just some random unexplained failure ("cosmic ray") which
> should go away when rebuilding.
> or
> 2) previous versions of Sage also failed to compiled on this machine.
> or
> 3) there is some very weird interaction between packages I am overlooking.

I cannot tell fo cosmic rays, as for previous versions of Sage I beleve the first to fail was 5.8.beta4. I was runnning beta3 a couple of days ago without any problem, though.

Buttttttt I may also have upgrade my distribution in the meantime :-)

Nathann

[leif]

Jeroen Demeyer wrote:
> Dear Sage lovers,
>
> We're releasing Sage 5.8.rc0.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.rc0/sage-5.8.rc0.tar
>
> Upgrade path:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.rc0/sage-5.8.rc0/
>
> The source and upgrade path can also be found on the mirror network
> (you might need to wait a while before the mirrors are synchronized):
>
> http://www.sagemath.org/download-latest.html
>
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.

Rather unrelated to *this* (devel) release (as Singular hasn't been
updated recently), but on mark (Solaris SPARC, with GCC 4.7.0) I get:

...
make PIPE= install-nolns in kernel
make[4]: Entering directory
`/home/leif/Sage/release/build/mark/sage-5.8.rc0-gcc-4.7.0/spkg/build/singular-3-1-5.p4/src/kernel'
g++ -O2 -g -fPIC -fno-implicit-templates -I. -I..
-I/home/leif/Sage/release/build/mark/sage-5.8.rc0-gcc-4.7.0/local
-I/usr/xpg4/include
-I/home/leif/Sage/release/build/mark/sage-5.8.rc0-gcc-4.7.0/local/include -I/home/leif/Sage/release/build/mark/sage-5.8.rc0-gcc-4.7.0/local/include
-I/usr/local/include -DNDEBUG -DOM_NDEBUG -DSunOS_5 -DHAVE_CONFIG_H
-c bigintmat.cc
bigintmat.cc: In function 'int getShorter(int*, int, int, int, int)':
bigintmat.cc:347:33: error: call of overloaded 'log10(int&)' is ambiguous
bigintmat.cc:347:33: note: candidates are:
In file included from
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/math.h:26:0,
from bigintmat.cc:14:
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:201:21:
note: long double std::log10(long double)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:169:15:
note: float std::log10(float)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:69:15:
note: double std::log10(double)
bigintmat.cc:347:52: error: call of overloaded 'log10(int&)' is ambiguous
bigintmat.cc:347:52: note: candidates are:
In file included from
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/math.h:26:0,
from bigintmat.cc:14:
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:201:21:
note: long double std::log10(long double)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:169:15:
note: float std::log10(float)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:69:15:
note: double std::log10(double)
bigintmat.cc:356:31: error: call of overloaded 'log10(int&)' is ambiguous
bigintmat.cc:356:31: note: candidates are:
In file included from
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/math.h:26:0,
from bigintmat.cc:14:
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:201:21:
note: long double std::log10(long double)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:169:15:
note: float std::log10(float)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:69:15:
note: double std::log10(double)
bigintmat.cc:356:50: error: call of overloaded 'log10(int&)' is ambiguous
bigintmat.cc:356:50: note: candidates are:
In file included from
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/math.h:26:0,
from bigintmat.cc:14:
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:201:21:
note: long double std::log10(long double)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:169:15:
note: float std::log10(float)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:69:15:
note: double std::log10(double)
bigintmat.cc: In member function 'void bigintmat::pprint(int)':
bigintmat.cc:427:29: error: call of overloaded 'floor(int)' is ambiguous
bigintmat.cc:427:29: note: candidates are:
In file included from
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/math.h:26:0,
from bigintmat.cc:14:
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:193:21:
note: long double std::floor(long double)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:164:15:
note: float std::floor(float)
/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/gcc/sparc-sun-solaris2.10/4.7.0/include-fixed/iso/math_iso.h:77:15:
note: double std::floor(double)
make[4]: *** [bigintmat.o] Error 1
make[4]: Leaving directory
`/home/leif/Sage/release/build/mark/sage-5.8.rc0-gcc-4.7.0/spkg/build/singular-3-1-5.p4/src/kernel'
make[3]: *** [install-nolns] Error 1
make[3]: Leaving directory
`/home/leif/Sage/release/build/mark/sage-5.8.rc0-gcc-4.7.0/spkg/build/singular-3-1-5.p4/src'
Unable to build and install Singular
Error building Singular (error in build_singular).

real 29m2.921s
user 9m32.393s
sys 1m3.429s
************************************************************************
Error installing package singular-3-1-5.p4
************************************************************************


These errors are similar (same reason) to those we had with FLINTQS [1]
and a few other packages.

Does nobody at all build on Solaris with GCC 4.7.x?

(We probably have to fix these before upgrading the standard GCC spkg to
4.7.2.)


-leif

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

[leif]

Adding a few casts on three lines of kernel/bigintmat.cc solves this,
i.e., Singular afterwards installs successfully.

I'll open a ticket for that later (in case I remember to).


-leif

[Jeroen Demeyer]

On 2013-03-14 12:55, leif wrote:

> Rather unrelated to *this* (devel) release (as Singular hasn't been
> updated recently), but on mark (Solaris SPARC, with GCC 4.7.0) I get:

That's strange, because the buildbot does actually use GCC-4.7.0 on mark
and it succeeds.

[Jean-Pierre Flori]

Thanks a lot, I was trying to build Sage on Solaris and Singular indeed failed.
Now I don't have to worry about that!

I also have troubles with polybori, I'll have a look later, it seems it cannot detect M4RI correctly.

[Jean-Pierre Flori]

Except that my Singular build fails with GCC 4.6.3, so the problem might be different.
I had trouble with a system readline interfering with mercurial before, so this might be it in fact.

[Jean-Pierre Flori]

Or not.
The errors I get look like:

In file included from /usr/include/stdlib.h:18:0,
                 from feResource.cc:8:
/usr/include/iso/stdlib_iso.h:131:61: error: conflicting declaration 'const char
* restrict'
/usr/include/iso/stdlib_iso.h:131:33: error: 'restrict' has a previous declarati
on as 'wchar_t* restrict'
/usr/include/iso/stdlib_iso.h:133:56: error: conflicting declaration 'const char
* restrict'
/usr/include/iso/stdlib_iso.h:133:28: error: 'restrict' has a previous declarati
on as 'wchar_t* restrict'
/usr/include/iso/stdlib_iso.h:143:57: error: conflicting declaration 'char** res
trict'
/usr/include/iso/stdlib_iso.h:143:34: error: 'restrict' has a previous declarati
on as 'const char* restrict'
/usr/include/iso/stdlib_iso.h:144:59: error: conflicting declaration 'char** res
trict'
/usr/include/iso/stdlib_iso.h:144:36: error: 'restrict' has a previous declarati
on as 'const char* restrict'
/usr/include/iso/stdlib_iso.h:146:9: error: conflicting declaration 'char** rest
rict'
/usr/include/iso/stdlib_iso.h:145:46: error: 'restrict' has a previous declarati
on as 'const char* restrict'
/usr/include/iso/stdlib_iso.h:149:61: error: conflicting declaration 'const wcha
r_t* restrict'
/usr/include/iso/stdlib_iso.h:149:30: error: 'restrict' has a previous declarati
on as 'char* restrict'

[leif]

I thought it would SAGE_INSTALL_GCC.


-leif

[Jeroen Demeyer]

On 2013-03-14 14:45, leif wrote:
> I thought it would SAGE_INSTALL_GCC.

Ah yes indeed. Sorry about that.

[leif]

ROFL. Probably include [just?] <cstdlib> instead when compiling C++?
('restrict' is a C99 keyword.)

We had trouble with stdlib.h as well, but of the same kind as with
math.h. (IIRC overloaded versions of e.g. div() go into the global
namespace on Solaris.)


-leif

[Alexander Dreyer]

Hi Jean-Pierre,

> I also have troubles with polybori, I'll have a look later, it seems it
> cannot detect M4RI correctly.

The spkg from
http://trac.sagemath.org/sage_trac/ticket/13989
considerably improves polybori's build system.
Perhaps it already fixes the issue for you.

Best regards,
Alexander
--
Dr. rer. nat. Dipl.-Math. Alexander Dreyer

Abteilung "Systemanalyse, Prognose und Regelung"
Fraunhofer Institut f�r Techno- und Wirtschaftsmathematik (ITWM)
Fraunhofer-Platz 1
67663 Kaiserslautern

Telefon +49 (0) 631-31600-4318
Fax +49 (0) 631-31600-5318
E-Mail alexande...@itwm.fraunhofer.de
Internet http://www.itwm.fraunhofer.de/sys/dreyer.html

[leif]

The stdlib.h headers* on {mark,mark2} (SunOS 5.10) look sane; they btw
use _RESTRICT_KYWD rather than a hardcoded 'restrict', and can safely
(modulo pulling a few overloaded functions into the global namespace) be
included by C++ sources.


-leif

_____
* All (C) 2004 Sun Microsystems, FWIW.

[Jean-Pierre Flori]

Hi,

On Thursday, March 14, 2013 3:10:49 PM UTC+1, Alexander Dreyer wrote:

Hi Jean-Pierre,
> I also have troubles with polybori, I'll have a look later, it seems it
> cannot detect M4RI correctly.
The spkg from
http://trac.sagemath.org/sage_trac/ticket/13989
considerably improves polybori's build system.
Perhaps it already fixes the issue for you.

I'll give it a shot, but it seems its not because of Polybori, but of some symbol versioning hell of libpng.
I'll report here later.

Best regards,
  Alexander
--
Dr. rer. nat. Dipl.-Math. Alexander Dreyer

Abteilung "Systemanalyse, Prognose und Regelung"

Fraunhofer Institut f�r Techno- und Wirtschaftsmathematik (ITWM)

[leif]

Jean-Pierre Flori wrote:
> Hi,
>
> On Thursday, March 14, 2013 3:10:49 PM UTC+1, Alexander Dreyer wrote:
>
> Hi Jean-Pierre,
> > I also have troubles with polybori, I'll have a look later, it
> seems it
> > cannot detect M4RI correctly.
> The spkg from
> http://trac.sagemath.org/sage_trac/ticket/13989
> <http://trac.sagemath.org/sage_trac/ticket/13989>
> considerably improves polybori's build system.
> Perhaps it already fixes the issue for you.
>
> I'll give it a shot, but it seems its not because of Polybori, but of
> some symbol versioning hell of libpng.

libpng fails to build if GCC was configured to use the GNU linker but
the first ld in your PATH is the Sun linker. (Presumably vice versa as
well.)

Work-around: export LD=/path/to/gnu-linker, or change your PATH


(IIRC there are more packages needing this, don't recall right now, and
didn't get that far yet.)


-leif

[Jean-Pierre Flori]

I got LD set to the sun linker (and I think the GNU linker comes first in PATH).
Note that libpng did "correctly" build.
It's when trying to link a dumb object file to libm4ri which links to libpng that the polybori spkg thinks m4ri is not available because of undefined symbols of the form png_...@@PNG12.0 (or smtg like that).

Then it seems polybori tries to build its own m4ri but it fails as well, but if we fix the first m4ri detection  which should point to the Sage installed one, this is not really a problem.

[Jean-Pierre Flori]

And the new polybori directly fails when it cannot find m4ri.

Here is the relevant part of config.log:

  |
  |
  |int
  |main() {
  | 
  |return 0;
  |}
  |
gcc -o .sconf_temp/conftest_41.o -c -std=c99 -O3 -Wreturn-type -DPBORI_NDEBUG -DSIZEOF_VOID_P=4 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DPBORI_HAVE_TR1_UNORDERED_MAP -DPBORI_HAVE_M4RI -Ilibpolybori/include -Igroebner/include -I/infres/post/flori/sage-5.7-infres2/local/include -I/infres/post/flori/sage-5.7-infres2/local/include/python2.7 .sconf_temp/conftest_41.c
gcc -o .sconf_temp/conftest_41 -Wl,-rpath=\$ORIGIN/../build/usr/local/lib -z origin .sconf_temp/conftest_41.o -L/infres/post/flori/sage-5.7-infres2/local/lib -L/infres/post/flori/sage-5.7-infres2/local/lib -L/infres/post/flori/sage-5.7-infres2/local/lib/python2.7/config -lm4ri
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_destroy_read_struct@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_create_info_struct@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_set_compression_level@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_get_image_width@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_write_end@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_get_image_height@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_write_row@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_read_info@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_init_io@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_write_info@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_get_bit_depth@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_set_user_limits@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_get_channels@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_sig_cmp@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_read_row@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_set_sig_bytes@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_read_end@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_set_IHDR@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_destroy_write_struct@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_get_interlace_type@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_create_write_struct@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_set_invert_mono@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_set_text@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_create_read_struct@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_set_packswap@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_get_compression_type@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to `png_get_color_type@PNG12_0'
collect2: ld returned 1 exit status

[Alexander Dreyer]

Hi!

> Then it seems polybori tries to build its own m4ri but it fails as well,
> but if we fix the first m4ri detection which should point to the Sage
> installed one, this is not really a problem.

Right, the polbori spkg does not contain a duplicate of the libm4ri
source. This is intended, to avoid that the first issue is overlooked.

Best regards,
Alexander


--
Dr. rer. nat. Dipl.-Math. Alexander Dreyer

Abteilung "Systemanalyse, Prognose und Regelung"

Fraunhofer Institut f�r Techno- und Wirtschaftsmathematik (ITWM)

[Jean-Pierre Flori]

Passing -lpng or -lpng12 after -lm4ri solves the issue...
Not sure why Solaris is so picky, even Cygwin is not in my souvenir.

[Jean-Pierre Flori]

I mean it let gcc build the config test executable.

[Alexander Dreyer]

Hi!

> collect2: ld returned 1 exit status
>
>
> Passing -lpng or -lpng12 after -lm4ri solves the issue...
> Not sure why Solaris is so picky, even Cygwin is not in my souvenir.

Oh, that's fummy, this is also included in a patch of the ticket a
mentioned above. So maybe we can just finalize the ticket?

Best regards,
Alexander
--
Dr. rer. nat. Dipl.-Math. Alexander Dreyer

Abteilung "Systemanalyse, Prognose und Regelung"

Fraunhofer Institut f�r Techno- und Wirtschaftsmathematik (ITWM)

[Jean-Pierre Flori]

If that may be of any help:

readelf -d local/lib/libm4ri-0.0.20120613.so

Dynamic section at offset 0x48100 contains 24 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libpng12.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.1]
 0x0000000e (SONAME)                     Library soname: [libm4ri-0.0.20120613.so]
 0x0000000f (RPATH)                      Library rpath: [xxxxxxxxxx/local/lib]

[leif]

Jeroen Demeyer wrote:
> Dear Sage lovers,
>
> We're releasing Sage 5.8.rc0.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.rc0/sage-5.8.rc0.tar
>
> Upgrade path:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.rc0/sage-5.8.rc0/
>
> The source and upgrade path can also be found on the mirror network
> (you might need to wait a while before the mirrors are synchronized):
>
> http://www.sagemath.org/download-latest.html

Ubuntu 10.04.4 LTS x86 (with FSF GCC 4.7.2):

Built from scratch w/o problems (modulo the known R "-O3" issue, "-O3
-fno-ipa-cp-clone" works), and all tests (ptestlong) passed.


FWIW, here Tachyon did not segfault during tests, but testing
sage/interfaces/tachyon.py verbosely showed one instance of

Tachyon Parallel/Multiprocessor Ray Tracer Version 0.98.9
Copyright 1994-2010, John E. Stone <john....@gmail.com>
------------------------------------------------------------
Scene Parsing Time: 0.0002 seconds
Scene contains 1 objects.
Preprocessing Time: 0.0000 seconds
Rendering Progress: 100% complete
Ray Tracing Time: 0.0523 seconds
writetgaregion: file ptr out of range!!!

Image I/O Time: 0.0036 seconds

(The log actually contains a couple of lines with '\r', updating the
progress.)


-leif

[William Stein]

Hi,

Using a $250 Samsung ARM Chromebook running using an Ubuntu
12.04.02LTS changeroot, I built Sage-5.8.rc0 no problem, though I used
the systemwide ATLAS since I didn't want to wait forever. Thanks to
the porting-Sage-to-ARM-Linux team!!!!

I really wish I had built Sage this way for the joint mathematics
meetings in January, since then I used the public notebook servers via
the chromebooks (tethered via my cell phone), when using Sage directly
on them would have been better.

Anyway, in case anybody is interested, having a very usable Ubuntu
chroot + Sage, while still using the GUI of Chrome, works surprisingly
well on the Samsung ARM Chromebook.

William

> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-release?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Alexander Dreyer]

Hi William,

> Using a $250 Samsung ARM Chromebook running using an Ubuntu
> 12.04.02LTS changeroot, I built Sage-5.8.rc0 no problem, though I used
> the systemwide ATLAS since I didn't want to wait forever. Thanks to
> the porting-Sage-to-ARM-Linux team!!!!

So maybe it's time to oppose Steve Wildstrom:
http://techpinions.com/the-trouble-with-open-source-my-sage-saga/8654

[Jean-Pierre Flori]

On Thursday, March 14, 2013 4:32:34 PM UTC+1, Alexander Dreyer wrote:

Hi!
>         collect2: ld returned 1 exit status
>
>
>     Passing -lpng or -lpng12 after -lm4ri solves the issue...
>     Not sure why Solaris is so picky, even Cygwin is not in my souvenir.
Oh, that's fummy, this is also included in a patch of the ticket a
mentioned above. So maybe we can just finalize the ticket?

There is indeed a fix there at the level of the Sage library.

The problem I encountered is that libm4ri is not even correctly detected by polybori configure system.
Indeed the scons CheckLib function tests the availability of m4ri by compiling a dumb C file with -lm4ri but this fails at the linking stage because of undefined symbols on the Solaris I have access to as below:

{{{
scons: Configure: Checking for C library m4ri...
.sconf_temp/conftest_41.c <-

  |
  |
  |
  |int
  |main() {
  | 
  |return 0;
  |}
  |
gcc -o .sconf_temp/conftest_41.o -c -std=c99 -O3 -Wreturn-type -DPBORI_NDEBUG -D
SIZEOF_VOID_P=4 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DPBORI_HAVE_TR1_UNORDERED_MAP -D
PBORI_HAVE_M4RI -Ilibpolybori/include -Igroebner/include -I/infres/post/flori/sa
ge-5.7-infres2/local/include -I/infres/post/flori/sage-5.7-infres2/local/include
/python2.7 .sconf_temp/conftest_41.c
gcc -o .sconf_temp/conftest_41 -Wl,-rpath=\$ORIGIN/../build/usr/local/lib -z ori
gin .sconf_temp/conftest_41.o -L/infres/post/flori/sage-5.7-infres2/local/lib -L
/infres/post/flori/sage-5.7-infres2/local/lib -L/infres/post/flori/sage-5.7-infr
es2/local/lib/python2.7/config -lm4ri
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to
 `png_destroy_read_struct@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to
 `png_create_info_struct@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to
 `png_set_compression_level@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to
 `png_get_image_width@PNG12_0'
/infres/post/flori/sage-5.7-infres2/local/lib/libm4ri.so: undefined reference to
 `png_write_end@PNG12_0'

...
}}}
 
What I meant is that if you add -lpng[12] on the compile line above:
{{{

gcc -o .sconf_temp/conftest_41.o -c -std=c99 -O3 -Wreturn-type -DPBORI_NDEBUG -D
SIZEOF_VOID_P=4 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DPBORI_HAVE_TR1_UNORDERED_MAP -D
PBORI_HAVE_M4RI -Ilibpolybori/include -Igroebner/include -I/infres/post/flori/sa
ge-5.7-infres2/local/include -I/infres/post/flori/sage-5.7-infres2/local/include
/python2.7 .sconf_temp/conftest_41.c
gcc -o .sconf_temp/conftest_41 -Wl,-rpath=\$ORIGIN/../build/usr/local/lib -z ori
gin .sconf_temp/conftest_41.o -L/infres/post/flori/sage-5.7-infres2/local/lib -L
/infres/post/flori/sage-5.7-infres2/local/lib -L/infres/post/flori/sage-5.7-infr

es2/local/lib/python2.7/config -lm4ri -lpng[12]
}}}
Then m4ri is correctly detected.

What could solve this is first to check for m4ri headers, then whether m4ri needs libpng from these headers and only test linking against libm4ri (with or without libpng) depending on the previous test.
But I'm not sure it's so trivial to do "properly" with scons and just CheckLib.

Best,
Jp

[William Stein]

On Fri, Mar 15, 2013 at 8:08 AM, Alexander Dreyer
<alexande...@itwm.fraunhofer.de> wrote:
> Hi William,
>> Using a $250 Samsung ARM Chromebook running using an Ubuntu
>> 12.04.02LTS changeroot, I built Sage-5.8.rc0 no problem, though I used
>> the systemwide ATLAS since I didn't want to wait forever. Thanks to
>> the porting-Sage-to-ARM-Linux team!!!!
> So maybe it's time to oppose Steve Wildstrom:
> http://techpinions.com/the-trouble-with-open-source-my-sage-saga/8654

I find the first comment pretty funny: "Real men do use the command
line!" Command lines are awesome. I've been putting a lot of work
into an "xterm for the web browser" lately... :-)

Every user of Sage is either using the command line or writing
programs in (basically) Python, so the users of Sage are typically
advanced computer users, by definition.

William

>
> Best regards,
> Alexander
>
> --
> Dr. rer. nat. Dipl.-Math. Alexander Dreyer
>
> Abteilung "Systemanalyse, Prognose und Regelung"

> Fraunhofer Institut für Techno- und Wirtschaftsmathematik (ITWM)

> Fraunhofer-Platz 1
> 67663 Kaiserslautern
>
> Telefon +49 (0) 631-31600-4318
> Fax +49 (0) 631-31600-5318
> E-Mail alexande...@itwm.fraunhofer.de
> Internet http://www.itwm.fraunhofer.de/sys/dreyer.html

[kcrisman]

> So maybe it's time to oppose Steve Wildstrom:
> http://techpinions.com/the-trouble-with-open-source-my-sage-saga/8654

Thanks for pointing this out.

 

I find the first comment pretty funny: "Real men do use the command
line!"  Command lines are awesome.  I've been putting a lot of work
into an "xterm for the web browser" lately... :-)

Quote:

The point of all this is that the folks behind Sage, like  they participants in many other open source projects, have failed to tackle the critical issues of usability. They have not transcended the “real men use command line interfaces” mentality and show little interest in the hard, but to most hackers, unrewarding, work of providing a great, or even a satisfactory, user experience. As a result they end up writing code mostly for themselves and each other. 

I think this is really unfair, and neglects the awesome work people (including William et al. with the notebook, of course, but also more recently Ivan and Volker with the apps) have done to make it work.  Maybe he should have just used sagenb.org to start!  We could do better on usability, but it's clear the author didn't do his homework on this.  

That said, we can always do better - the Mac one should have "just worked", for instance.  Also, bizarrely, why didn't he download the app bundle on Mac?  No command line needed to install that.

 

Every user of Sage is either using the command line or writing
programs in (basically) Python, so the users of Sage are typically
advanced computer users, by definition.

???  Including people just changing sliders on an embedded Sage cell instance, or our P-Chem students who just use it to calculate integrals all day long?   I would say that a lot of people are not writing programs, they just use commands on a one-off basis.  That may make them advanced globally in terms of computers, but not advanced in the sense you mean, I guess.

[William Stein]

>> Every user of Sage is either using the command line or writing
>> programs in (basically) Python, so the users of Sage are typically
>> advanced computer users, by definition.
>>
>>
>
> ??? Including people just changing sliders on an embedded Sage cell
> instance,

No. But such a person is unlikely to actually *install* Sage. I
should have said "every user of Sage that will install it themselves".

> or our P-Chem students who just use it to calculate integrals all
> day long?

Well that is definitely "using a command line", even if the command
line is in the notebook.

> I would say that a lot of people are not writing programs, they
> just use commands on a one-off basis.

That's still "a command line".

> That may make them advanced globally
> in terms of computers, but not advanced in the sense you mean, I guess.

I really should have emphasized that I meant people installing Sage on
their own computers.

>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-release?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[leif]

What is

-Wl,-rpath=\$ORIGIN/../build/usr/local/lib -z origin

supposed to mean? B)

(To me, this looks quite messed up.)


-leif

[kcrisman]

On Friday, March 15, 2013 1:40:04 PM UTC-4, William Stein wrote:

>> Every user of Sage is either using the command line or writing
>> programs in (basically) Python, so the users of Sage are typically
>> advanced computer users, by definition.
>>
>>
>
> ???  Including people just changing sliders on an embedded Sage cell
> instance,

No.  But such a person is unlikely to actually *install* Sage.   I
should have said "every user of Sage that will install it themselves".

Fair enough, though see below.

 

> or our P-Chem students who just use it to calculate integrals all
> day long?

Well that is definitely "using a command line", even if the command
line is in the notebook.

I'm not sure I'd call "typing integral(x^2,x) and clicking evaluate" the same thing as "using the command line".   But it's not worth quibbling over; the point is that even in this case the author has rather overstated things, though of course it definitely could be more polished.

[Justin C. Walker]

On Mar 13, 2013, at 08:42 , Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

> Dear Sage lovers,
>
> We're releasing Sage 5.8.rc0.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.8.rc0/sage-5.8.rc0.tar

Built w/o problems on two Mac OS X systems (10.6.8/Dual 6-core Xeons, 10.8.2/Quad-core Core i7), and all tests ('ptestlong') passed on each system!

Justin

--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
When LuteFisk is outlawed,
Only outlaws will have LuteFisk
--------

[Alexander Dreyer]

Sorry,
I didn't think about the CheckLib part. I'll have a look at that later.
Best regards, Alexander

[Ivan Andrus]

On Mar 15, 2013, at 11:27 AM, kcrisman <kcri...@gmail.com> wrote:

> So maybe it's time to oppose Steve Wildstrom:
> http://techpinions.com/the-trouble-with-open-source-my-sage-saga/8654

Thanks for pointing this out.

 

I find the first comment pretty funny: "Real men do use the command
line!"  Command lines are awesome.  I've been putting a lot of work
into an "xterm for the web browser" lately... :-)

Quote:

The point of all this is that the folks behind Sage, like  they participants in many other open source projects, have failed to tackle the critical issues of usability. They have not transcended the “real men use command line interfaces” mentality and show little interest in the hard, but to most hackers, unrewarding, work of providing a great, or even a satisfactory, user experience. As a result they end up writing code mostly for themselves and each other. 

I think it's also partly that mathematicians don't get funding for making things pretty and easy to use, but rather for pushing the boundaries of mathematics.  I'm sure there are exceptions.

I think this is really unfair, and neglects the awesome work people (including William et al. with the notebook, of course, but also more recently Ivan and Volker with the apps) have done to make it work.  Maybe he should have just used sagenb.org to start!  We could do better on usability, but it's clear the author didn't do his homework on this.  

I think it's somewhat fair (as a critique of open source in general).  Mathematicians and programmers often don't have much experience or skills in interface design.  That's why companies hire a different set of people to do that.  But that's just the way it is.  It would be great if there were more graphic designers and such who contributed to open source.  I've thought about that a lot in the past.

That said, we can always do better - the Mac one should have "just worked", for instance.  Also, bizarrely, why didn't he download the app bundle on Mac?  No command line needed to install that.

I wondered the same thing.  I just checked the download site and the following warning may have been the reason:

It has come to our attention recently that on MacOSX computers, where Sage has never been installed before, the `-app` version of Sage might fail to start. We apologize for the inconvenience. While we are working on a fix for this problem, please use the non-"-app" version of Sage.

I'm pretty sure that particular problem has been resolved.  Wasn't it #12161?

-Ivan

[Volker Braun]

Builds fine on the Chromebook Pixel (in a crouton Ubuntu chroot)

[William Stein]

On Sat, Mar 16, 2013 at 6:57 AM, Volker Braun <vbrau...@gmail.com> wrote:
> Builds fine on the Chromebook Pixel (in a crouton Ubuntu chroot)

... and, how do you like the Chromebook Pixe? Can I ask how fast Sage
runs on it, e.g., for large integer arithmetic -- e.g., "%time
n=factorial(10^7)" then "%time m=n*n"?

William

[Volker Braun]

I really like the Pixel. Having said that, I'll still replace my thinkpad W520 that died an untimely death two days ago since a subnotebook just doesn't satisfy my computational needs on longer travels. I need a quad-core i7, up to 32 gb ram, 3 drives (mSATA + internal + ultrabay), 15" screen. Its still ridiculous that the top-of-the-line workstation replacement thinkpad has such a crappy screen in comparison. 

I'm somewhat tempted by the retina macbook pro but non-user serviceable RAM that maxes out at 16gb for ridiculous amounts of money? And at most one drive (after chucking the DVD drive) plus some proprietary ssd? And native Linux support seems to be not as good either. Hence: no thanks ;-) 

Pixel benchmark (dual-core i5 1.8GHz)

sage: %time n=factorial(10^7)

CPU times: user 3.97 s, sys: 0.09 s, total: 4.06 s

Wall time: 4.06 s

sage: %time m = n*n                                                                                                                        

CPU times: user 1.86 s, sys: 0.06 s, total: 1.92 s

Wall time: 1.92 s

[kcrisman]

I wondered the same thing.  I just checked the download site and the following warning may have been the reason:

It has come to our attention recently that on MacOSX computers, where Sage has never been installed before, the `-app` version of Sage might fail to start. We apologize for the inconvenience. While we are working on a fix for this problem, please use the non-"-app" version of Sage.

I'm pretty sure that particular problem has been resolved.  Wasn't it #12161?

Is that still there?  Yeah, I think we should probably remove it.

[P Purkayastha]

On Friday, March 15, 2013 11:08:25 PM UTC+8, Alexander Dreyer wrote:

Hi William,
> Using a $250 Samsung ARM Chromebook running using an Ubuntu
> 12.04.02LTS changeroot, I built Sage-5.8.rc0 no problem, though I used
> the systemwide ATLAS since I didn't want to wait forever.  Thanks to
> the porting-Sage-to-ARM-Linux team!!!!
So maybe it's time to oppose Steve Wildstrom:
http://techpinions.com/the-trouble-with-open-source-my-sage-saga/8654

The blog post is quite strange.

First,  over the past year I don't remember seeing posts here about problems with running the Ubuntu version.

Secondly, the guy is installing it system wide instead of following the instructions in the README. Is this page [ http://sagemath.org/download-linux.html ] up to date? Is the ubuntu ppa up to date? If not, all those instructions should be replaced by just the first one called "Usage". Also, "Usage" is incorrect. Without the sage directory in the PATH, simply running "sage" won't work. So, it should be something like

"Change directory to the extracted sage folder"

"Open a terminal in this directory and run ./sage"

Thirdly, the blog post mentions a command like "chmod -R 755 sage-3.1....". That's a recipe for disaster. Not all files should be made executable.