Sage on FreeBSD
Peter Jeremy
I've been doing some work on getting Sage-3.4 to work natively on
FreeBSD and I've reached the point where I can compile sage-3.4 on
FreeBSD-8/amd64 (using gcc/g++/gfortran 4.3) and get it to start.
I have a patchset (1131 lines so far) and instructions if anyone else
is interested (or if anyone wants to see my build or test logs).
A full list of failing ports follows. There are a lot of python
errors reporting
ValueError: invalid literal for int() with base 10: '539.621'
(with the same constant each time) - which makes me feel that my
python is busted. I will have to investigate the FreeBSD python
port's patches.
sage -t "devel/sage/doc/en/constructions/plotting.rst"
sage -t "devel/sage/doc/en/constructions/interface_issues.rst"
sage -t "devel/sage/doc/en/constructions/graph_theory.rst"
sage -t "devel/sage/doc/en/a_tour_of_sage/index.rst"
sage -t "devel/sage/doc/en/tutorial/tour_plotting.rst"
sage -t "devel/sage/doc/en/tutorial/tour_functions.rst"
sage -t "devel/sage/doc/en/tutorial/tour_algebra.rst"
sage -t "devel/sage/doc/en/bordeaux_2008/elliptic_curves.rst"
sage -t "devel/sage/doc/en/bordeaux_2008/introduction.rst"
sage -t "devel/sage/doc/en/numerical_sage/scipy.rst"
sage -t "devel/sage/doc/fr/tutorial/tour_plotting.rst"
sage -t "devel/sage/doc/fr/tutorial/tour_algebra.rst"
sage -t "devel/sage/sage/lfunctions/sympow.py"
sage -t "devel/sage/sage/graphs/planarity.pyx"
sage -t "devel/sage/sage/graphs/graph_isom.pyx"
sage -t "devel/sage/sage/graphs/graph_generators.py"
sage -t "devel/sage/sage/graphs/graph_plot.py"
sage -t "devel/sage/sage/graphs/linearextensions.py"
sage -t "devel/sage/sage/graphs/graph_fast.pyx"
sage -t "devel/sage/sage/graphs/graph_database.py"
sage -t "devel/sage/sage/graphs/graph_list.py"
sage -t "devel/sage/sage/graphs/bipartite_graph.py"
sage -t "devel/sage/sage/graphs/base/dense_graph.pyx"
sage -t "devel/sage/sage/graphs/base/graph_backends.py"
sage -t "devel/sage/sage/graphs/base/sparse_graph.pyx"
sage -t "devel/sage/sage/graphs/base/c_graph.pyx"
sage -t "devel/sage/sage/graphs/schnyder.py"
sage -t "devel/sage/sage/graphs/print_graphs.py"
sage -t "devel/sage/sage/graphs/graph_coloring.py"
sage -t "devel/sage/sage/graphs/graph.py"
sage -t "devel/sage/sage/graphs/chrompoly.pyx"
sage -t "devel/sage/sage/graphs/graph_bundle.py"
sage -t "devel/sage/sage/matrix/matrix2.pyx"
sage -t "devel/sage/sage/matrix/constructor.py"
sage -t "devel/sage/sage/parallel/decorate.py"
sage -t "devel/sage/sage/parallel/multiprocessing.py"
sage -t "devel/sage/sage/ext/fast_eval.pyx"
sage -t "devel/sage/sage/server/notebook/cell.py"
sage -t "devel/sage/sage/gsl/dwt.pyx"
sage -t "devel/sage/sage/gsl/fft.pyx"
sage -t "devel/sage/sage/gsl/interpolation.pyx"
sage -t "devel/sage/sage/gsl/ode.pyx"
sage -t "devel/sage/sage/combinat/crystals/tensor_product.py"
sage -t "devel/sage/sage/combinat/crystals/crystals.py"
sage -t "devel/sage/sage/combinat/crystals/spins.py"
sage -t "devel/sage/sage/combinat/crystals/letters.py"
sage -t "devel/sage/sage/combinat/crystals/fast_crystals.py"
sage -t "devel/sage/sage/combinat/permutation.py"
sage -t "devel/sage/sage/combinat/words/suffix_trees.py"
sage -t "devel/sage/sage/combinat/words/word.py"
sage -t "devel/sage/sage/combinat/ribbon.py"
sage -t "devel/sage/sage/combinat/posets/poset_examples.py"
sage -t "devel/sage/sage/combinat/posets/hasse_diagram.py"
sage -t "devel/sage/sage/combinat/posets/elements.py"
sage -t "devel/sage/sage/combinat/posets/posets.py"
sage -t "devel/sage/sage/combinat/root_system/dynkin_diagram.py"
sage -t "devel/sage/sage/combinat/root_system/weight_space.py"
sage -t "devel/sage/sage/combinat/root_system/root_system.py"
sage -t "devel/sage/sage/combinat/root_system/cartan_type.py"
sage -t "devel/sage/sage/combinat/root_system/weight_lattice_realization.py"
sage -t "devel/sage/sage/combinat/root_system/type_reducible.py"
sage -t "devel/sage/sage/combinat/root_system/type_E.py"
sage -t "devel/sage/sage/combinat/root_system/type_dual.py"
sage -t "devel/sage/sage/combinat/root_system/root_lattice_realization.py"
sage -t "devel/sage/sage/combinat/root_system/type_D.py"
sage -t "devel/sage/sage/combinat/root_system/type_F.py"
sage -t "devel/sage/sage/combinat/root_system/type_G.py"
sage -t "devel/sage/sage/combinat/root_system/cartan_matrix.py"
sage -t "devel/sage/sage/combinat/root_system/type_C.py"
sage -t "devel/sage/sage/combinat/root_system/weyl_group.py"
sage -t "devel/sage/sage/combinat/root_system/type_B.py"
sage -t "devel/sage/sage/combinat/root_system/coxeter_matrix.py"
sage -t "devel/sage/sage/combinat/root_system/root_space.py"
sage -t "devel/sage/sage/combinat/root_system/type_A.py"
sage -t "devel/sage/sage/combinat/skew_tableau.py"
sage -t "devel/sage/sage/combinat/graph_path.py"
sage -t "devel/sage/sage/combinat/species/recursive_species.py"
sage -t "devel/sage/sage/combinat/species/species.py"
sage -t "devel/sage/sage/combinat/species/product_species.py"
sage -t "devel/sage/sage/combinat/species/sum_species.py"
sage -t "devel/sage/sage/combinat/partition.py"
sage -t "devel/sage/sage/combinat/skew_partition.py"
sage -t "devel/sage/sage/combinat/partition_algebra.py"
sage -t "devel/sage/sage/combinat/designs/incidence_structures.py"
sage -t "devel/sage/sage/calculus/desolvers.py"
sage -t "devel/sage/sage/calculus/calculus.py"
sage -t "devel/sage/sage/calculus/functional.py"
sage -t "devel/sage/sage/groups/group.pyx"
sage -t "devel/sage/sage/groups/perm_gps/partn_ref/refinement_graphs.pyx"
sage -t "devel/sage/sage/groups/perm_gps/cubegroup.py"
sage -t "devel/sage/sage/misc/getusage.py"
sage -t "devel/sage/sage/misc/classgraph.py"
sage -t "devel/sage/sage/misc/functional.py"
sage -t "devel/sage/sage/numerical/optimize.py"
sage -t "devel/sage/sage/libs/pari/gen.pyx"
sage -t "devel/sage/sage/functions/special.py"
sage -t "devel/sage/sage/functions/piecewise.py"
sage -t "devel/sage/sage/functions/transcendental.py"
sage -t "devel/sage/sage/structure/sage_object.pyx"
sage -t "devel/sage/sage/databases/database.py"
sage -t "devel/sage/sage/tests/book_stein_ent.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_point.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_generic.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_finite_field.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/sha_tate.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/lseries_ell.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_number_field.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/gp_simon.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py"
sage -t "devel/sage/sage/schemes/elliptic_curves/padics.py"
sage -t "devel/sage/sage/rings/integer.pyx"
sage -t "devel/sage/sage/rings/polynomial/polynomial_element.pyx"
sage -t "devel/sage/sage/rings/polynomial/groebner_fan.py"
sage -t "devel/sage/sage/rings/polynomial/polynomial_integer_dense_flint.pyx"
sage -t "devel/sage/sage/rings/polynomial/pbori.pyx"
sage -t "devel/sage/sage/rings/polynomial/polynomial_quotient_ring_element.py"
sage -t "devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py"
sage -t "devel/sage/sage/rings/padics/padic_base_generic.py"
sage -t "devel/sage/sage/rings/tests.py"
sage -t "devel/sage/sage/rings/real_double.pyx"
sage -t "devel/sage/sage/plot/axes.py"
sage -t "devel/sage/sage/plot/bar_chart.py"
sage -t "devel/sage/sage/plot/contour_plot.py"
sage -t "devel/sage/sage/plot/animate.py"
sage -t "devel/sage/sage/plot/text.py"
sage -t "devel/sage/sage/plot/plot.py"
sage -t "devel/sage/sage/plot/plot_field.py"
sage -t "devel/sage/sage/plot/scatter_plot.py"
sage -t "devel/sage/sage/plot/point.py"
sage -t "devel/sage/sage/plot/circle.py"
sage -t "devel/sage/sage/plot/line.py"
sage -t "devel/sage/sage/plot/arrow.py"
sage -t "devel/sage/sage/plot/polygon.py"
sage -t "devel/sage/sage/plot/disk.py"
sage -t "devel/sage/sage/plot/matrix_plot.py"
sage -t "devel/sage/sage/plot/density_plot.py"
sage -t "devel/sage/sage/plot/bezier_path.py"
sage -t "devel/sage/sage/coding/code_bounds.py"
sage -t "devel/sage/sage/symbolic/expression.pyx"
sage -t "devel/sage/sage/modules/free_module_element.pyx"
sage -t "devel/sage/sage/geometry/lattice_polytope.py"
sage -t "devel/sage/sage/geometry/polyhedra.py"
sage -t "devel/sage/sage/finance/time_series.pyx"
--
Peter Jeremy
mabshoff
On Mar 23, 2:50 am, Peter Jeremy <peterjer...@optushome.com.au> wrote:
> Hi,
Hi Peter,
> I've been doing some work on getting Sage-3.4 to work natively on
> FreeBSD and I've reached the point where I can compile sage-3.4 on
> FreeBSD-8/amd64 (using gcc/g++/gfortran 4.3) and get it to start.
> I have a patchset (1131 lines so far) and instructions if anyone else
> is interested (or if anyone wants to see my build or test logs).
(around 15 or so IIRC) tests with 4 small patches.
> A full list of failing ports follows. There are a lot of python
> errors reporting
> ValueError: invalid literal for int() with base 10: '539.621'
> (with the same constant each time) - which makes me feel that my
> python is busted. I will have to investigate the FreeBSD python
> port's patches.
me on FreeBSD.
Cheers,
Michael
Peter Jeremy
>> FreeBSD and I've reached the point where I can compile sage-3.4 on
>> FreeBSD-8/amd64 (using gcc/g++/gfortran 4.3) and get it to start.
>
>Which FreeBSD release are you using?
As I said, 8-current/amd64.
>This is way too much - I get Sage to build and pass all but a few
>(around 15 or so IIRC) tests with 4 small patches.
Ah. Are these patches available? I looked in the FreeBSD entry on
the wiki but whilst it talks about various failures for older versions
of sage, I couldn't find any reference to either sage-3.4 or FreeBSD
patches.
>Why do you apply fixes from ports? Python compiles out of the box for
>me on FreeBSD.
The python embedded in sage compiles for me without patches but a lot
of the failures I am getting point towards a python problem. The
FreeBSD port for python 2.5.4 includes a number of patches that may
be relevant to the problems I am having.
As a general question on sage packaging, the sources are currently
totally self-contained. Whilst this has the advantage that all the
dependencies are in one place, it also has the disadvantage that it
results in multiple copies of some tools (bzip2, gd, libgcrypt,
libgpg_error, libpng, mpfr, python, sqlite3 and zlib in my case) being
installed. Was this done because Linux doesn't have a standard
package management system across all distros or to allow sage to
include sage-specific patches in the tools it uses (I notice this is
done for some tools)? I know that trying to turn sage into a FreeBSD
port in its current form will encounter resistance due to this (there
is pressure on other large ports like OpenOffice.org and the Mozilla
suite to depend on FreeBSD ports rather than embedding equivalent
functionality).
--
Peter Jeremy
Georg S. Weber
some notes on your questions regarding "Sage packaging":
Sage itself is designed in such as way, that it is possible to have
quite different versions of Sage installed at the same time, and
anywhere in your file system. Since different versions of Sage in
general do depend on different versions of some libraries (e.g. gmp/
mpir), the "self-contained-ness" is a necessary ingredient.
Sage is also designed in such a way as to be able to run not only
under Unix descendants (Linux, BSD, Mac OS X, Solaris), but mid-term
under native (!) Windows also, and even so for the average Windows
user out there. So it is essential to bring each and every tool with
it.
Sage as a "distribution" consists of rather inhomogeneous parts, it is
an art to assemble them together in such a way that they play together
rather seamlessly (thinking of Maxima, Pari, ...). So under FreeBSD,
Sage might need some "older" versions of certain "ports" and yes, also
some "newer" versions of the ports available or even special patches
that are very unlikely to find their way "upstream".
Finally, the task to "bring Sage under the hood of one of the big
distributions" has been sucessfully undertaken in the past --- Sage is
available in Debian. See e.g. http://groups.google.com/group/debian-sage/topics.
And this work (mainly by Tim Abbott) included exactly what you
mentioned, moving certain "packages" out of Sage and into Debian (for
some that were not already there), and make Sage-Debian depend on
"official" Debian ports, erm, packages.
Please note that currently (and for the foreseeable future), Sage-
Debian is considered a "branch" of the Sage project that has/is to be
maintained independently. There simply are too few Sage core
developers to ensure that every new version of Sage is "apt-gettable"
under Debian. (Of course it does run as "stand-alone" version out of
the box, however!)
Cheers,
gsw
mabshoff
On Mar 24, 3:20 am, Peter Jeremy <peterjer...@optushome.com.au> wrote:
> On 2009-Mar-23 12:38:45 -0700, mabshoff <mabsh...@googlemail.com> wrote:
Hi,
> >> FreeBSD and I've reached the point where I can compile sage-3.4 on
> >> FreeBSD-8/amd64 (using gcc/g++/gfortran 4.3) and get it to start.
>
> >Which FreeBSD release are you using?
>
> As I said, 8-current/amd64.
> >This is way too much - I get Sage to build and pass all but a few
> >(around 15 or so IIRC) tests with 4 small patches.
>
> Ah. Are these patches available? I looked in the FreeBSD entry on
> the wiki but whilst it talks about various failures for older versions
> of sage, I couldn't find any reference to either sage-3.4 or FreeBSD
> patches.
dig them out :)
> >Why do you apply fixes from ports? Python compiles out of the box for
> >me on FreeBSD.
>
> The python embedded in sage compiles for me without patches but a lot
> of the failures I am getting point towards a python problem. The
> FreeBSD port for python 2.5.4 includes a number of patches that may
> be relevant to the problems I am having.
FreeBSD 7.
> As a general question on sage packaging, the sources are currently
> totally self-contained. Whilst this has the advantage that all the
> dependencies are in one place, it also has the disadvantage that it
> results in multiple copies of some tools (bzip2, gd, libgcrypt,
> libgpg_error, libpng, mpfr, python, sqlite3 and zlib in my case) being
> installed. Was this done because Linux doesn't have a standard
> package management system across all distros or to allow sage to
> include sage-specific patches in the tools it uses (I notice this is
> done for some tools)? I know that trying to turn sage into a FreeBSD
> port in its current form will encounter resistance due to this (there
> is pressure on other large ports like OpenOffice.org and the Mozilla
> suite to depend on FreeBSD ports rather than embedding equivalent
> functionality).
not. I see little evidence that any packager can keep up with Sage
*and* have a Sage library that passes doctests. Not that I want to
discourage you from trying :)
The failures you saw indicate to me that some problem I did not have
was introduced by using the Python from ports. And that is only the
start IMHO. My main two issues with FreeBSD 7 and earlier releases of
Sage were:
* pyprocessing segfaulting on FreeBSD 7 - this is likely something
that has been fixed in the backported pyprocessing from Python 2.6,
but I have not looked into fixing this
* java not working - we currently cannot use IcedTea or anything like
that since jmol does not work with it and each party involved (IcedTea
and jmol) are pointing their finger at the other party and blaming
them. I installed the SunJDK on FreeBSD 7 and the linux compat layer
to make it run and java just segfaulted for me, so no joy :(
> --
> Peter Jeremy
Cheers,
Michael
> application_pgp-signature_part
> < 1KViewDownload
Peter Jeremy
>I've been doing some work on getting Sage-3.4 to work natively on
>FreeBSD and I've reached the point where I can compile sage-3.4 on
>FreeBSD-8/amd64 (using gcc/g++/gfortran 4.3) and get it to start.
I've done some more work and cleaned up most of the problems. Full
details (including the patches I'm using and their rationale) can be
found at http://wiki.sagemath.org/freebsd/sage-3.4
>A full list of failing ports follows. There are a lot of python
>errors reporting
> ValueError: invalid literal for int() with base 10: '539.621'
>(with the same constant each time) - which makes me feel that my
>python is busted.
Turns out this was a bug in matplotlib. It couldn't handle non-integral
character bounding boxes in AFM files and was aborting on the first one
it found - hence the same constant consistently appearing. I'm not sure
why this didn't bite Linux.
The failing tests are now:
sage -t "devel/sage/sage/schemes/elliptic_curves/lseries_ell.py"
Runs out of swap.
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py"
sage -t "devel/sage/sage/modules/free_module_element.pyx"
Numeric noise.
sage -t "devel/sage/sage/libs/pari/gen.pyx"
Runs out of swap.
sage -t "devel/sage/sage/misc/getusage.py"
sage -t "devel/sage/sage/calculus/calculus.py"
Numeric noise.
sage -t "devel/sage/sage/combinat/partition.py"
sage -t "devel/sage/sage/lfunctions/sympow.py"
sage -t "devel/sage/sage/ext/fast_eval.pyx"
Numeric noise.
sage -t "devel/sage/sage/parallel/multiprocessing.py"
sage -t "devel/sage/sage/parallel/decorate.py"
sage -t "devel/sage/sage/rings/real_double.pyx"
Numeric noise.
sage -t "devel/sage/sage/rings/polynomial/polynomial_integer_dense_flint.pyx"
sage -t "devel/sage/sage/rings/polynomial/polynomial_quotient_ring_element.py"
sage -t "devel/sage/sage/rings/polynomial/pbori.pyx"
sage -t "devel/sage/sage/rings/tests.py"
sage -t "devel/sage/sage/rings/integer.pyx"
Numeric noise.
--
Peter Jeremy
William Stein
<peter...@optushome.com.au> wrote:
> On 2009-Mar-23 20:50:05 +1100, Peter Jeremy <peter...@optushome.com.au> wrote:
>>I've been doing some work on getting Sage-3.4 to work natively on
>>FreeBSD and I've reached the point where I can compile sage-3.4 on
>>FreeBSD-8/amd64 (using gcc/g++/gfortran 4.3) and get it to start.
>
> I've done some more work and cleaned up most of the problems. Full
> details (including the patches I'm using and their rationale) can be
> found at http://wiki.sagemath.org/freebsd/sage-3.4
>
>>A full list of failing ports follows. There are a lot of python
>>errors reporting
>> ValueError: invalid literal for int() with base 10: '539.621'
>>(with the same constant each time) - which makes me feel that my
>>python is busted.
>
> Turns out this was a bug in matplotlib. It couldn't handle non-integral
> character bounding boxes in AFM files and was aborting on the first one
> it found - hence the same constant consistently appearing. I'm not sure
> why this didn't bite Linux.
>
> The failing tests are now:
> sage -t "devel/sage/sage/schemes/elliptic_curves/lseries_ell.py"
> Runs out of swap.
How much RAM does this machine have? How much swap does this machine have?
> sage -t "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py"
> sage -t "devel/sage/sage/modules/free_module_element.pyx"
> Numeric noise.
> sage -t "devel/sage/sage/libs/pari/gen.pyx"
> Runs out of swap.
> sage -t "devel/sage/sage/misc/getusage.py"
> sage -t "devel/sage/sage/calculus/calculus.py"
> Numeric noise.
> sage -t "devel/sage/sage/combinat/partition.py"
> sage -t "devel/sage/sage/lfunctions/sympow.py"
> sage -t "devel/sage/sage/ext/fast_eval.pyx"
> Numeric noise.
> sage -t "devel/sage/sage/parallel/multiprocessing.py"
> sage -t "devel/sage/sage/parallel/decorate.py"
> sage -t "devel/sage/sage/rings/real_double.pyx"
> Numeric noise.
> sage -t "devel/sage/sage/rings/polynomial/polynomial_integer_dense_flint.pyx"
> sage -t "devel/sage/sage/rings/polynomial/polynomial_quotient_ring_element.py"
> sage -t "devel/sage/sage/rings/polynomial/pbori.pyx"
> sage -t "devel/sage/sage/rings/tests.py"
> sage -t "devel/sage/sage/rings/integer.pyx"
> Numeric noise.
>
> --
> Peter Jeremy
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Peter Jeremy
>
>On Sat, Mar 28, 2009 at 7:55 PM, Peter Jeremy
><peter...@optushome.com.au> wrote:
>> sage -t "devel/sage/sage/schemes/elliptic_curves/lseries_ell.py"
>> Runs out of swap.
>
>How much RAM does this machine have? How much swap does this machine have?
2GB RAM, 9GB swap.
--
Peter Jeremy
mabshoff
is going off to eat all the RAM+Swap?
I also looked at http://wiki.sagemath.org/freebsd/sage-3.4 and I am
dubious about some of the patches, especially about most of the bits
from ports. I did not need any of those to build Sage 3.2 on FreeBSD 7
(or I did reproduce some of them :)), but I would recommend that those
fixes are pushed upstream. The choice of using shar as an archive
format also seems rather strange to me.
Which java are you using?
Cheers,
Michael
> --
> Peter Jeremy
>
> application_pgp-signature_part
> < 1KViewDownload
William Stein
Just for the record, I claim that java is not used one spec anywhere
in the entire Sage test suite.
The only way Sage uses java is for embedded 3d plotting in the
notebook or popup 3d plotting in the command line. Sage doesn't use
java anywhere else. I think the 3d doctests just generate the code
that would get sent to jmol to draw the image, but jmol itself isn't
actived (since if it were, doctesting any 3d file would take a _long_
time and involve windows popping up all over the place).
-- William
mabshoff
On Mar 28, 9:17 pm, William Stein <wst...@gmail.com> wrote:
> On Sat, Mar 28, 2009 at 9:12 PM, mabshoff <mabsh...@googlemail.com> wrote:
<SNIP>
> > I also looked athttp://wiki.sagemath.org/freebsd/sage-3.4and I am
> > from ports. I did not need any of those to build Sage 3.2 on FreeBSD 7
> > (or I did reproduce some of them :)), but I would recommend that those
> > fixes are pushed upstream. The choice of using shar as an archive
> > format also seems rather strange to me.
>
> > Which java are you using?
>
> Just for the record, I claim that java is not used one spec anywhere
> in the entire Sage test suite.
7 and the SunJDK that ran via the linux emulation layer things went
pretty badly.
> The only way Sage uses java is for embedded 3d plotting in the
> notebook or popup 3d plotting in the command line. Sage doesn't use
> java anywhere else. I think the 3d doctests just generate the code
> that would get sent to jmol to draw the image, but jmol itself isn't
> actived (since if it were, doctesting any 3d file would take a _long_
> time and involve windows popping up all over the place).
>
> -- William
--- pprdrv_tt2.cpp.orig 2009-01-19 06:37:37.373517000 -0500
+++ pprdrv_tt2.cpp 2009-01-19 06:38:26.782530000 -0500
@@ -104,7 +104,8 @@
{ /* have a log of points. */
if(stack_depth == 0)
{
- stream.putchar('{');
+ // Note the below is a hack to make it compile on
Solaris 10 with gcc 4.3.2
+ stream.puts("{");
stack_depth=1;
}
It will likely fix the issue you are seeing on FreeBSD 8 + gcc 4.3,
too. I did take a closer look at the patch set you provided and I want
to make a couple remarks:
* you are patching files like configure scripts and you really should
not do that :)
* most of the fixes should be pushed upstream
* I did the build on a 32 bit FreeBSD 7 box, but I can see how some
of the fixes will only be needed for FreeBSD 8 or FreeBSD on x86-64
I think the first step would be to provide individual patches so that
we can decide what to integrate and what to leave out. Some of the
fixes should certainly go in while I cam quite dubious about others,
but we can do that on a case by case review.
Cheers,
Michael
Peter Jeremy
>On Mar 28, 9:08 pm, Peter Jeremy <peterjer...@optushome.com.au> wrote:
>> On 2009-Mar-28 20:00:12 -0700, William Stein <wst...@gmail.com> wrote:
>> >On Sat, Mar 28, 2009 at 7:55 PM, Peter Jeremy
>> ><peterjer...@optushome.com.au> wrote:
>> >> sage -t "devel/sage/sage/schemes/elliptic_curves/lseries_ell.py"
>> >> Runs out of swap.
>> >How much RAM does this machine have? How much swap does this machine have?
>> 2GB RAM, 9GB swap.
>
>Strange. Can you run the test with -verbose and determine which test
>is going off to eat all the RAM+Swap?
...
Trying:
L(Integer(2))###line 103:_sage_ >>> L(2)
Expecting:
0.381575408260711
ok
Trying:
e = EllipticCurve([Integer(1),Integer(1),Integer(0),-Integer(63900),-Integer(1964465932632)])###line 112:_sage_ >>> e = EllipticCurve([1,1,0,-63900,-1964465932632])
Expecting nothing
ok
Trying:
L = e.lseries().dokchitser(Integer(15))###line 113:_sage_ >>> L = e.lseries().dokchitser(15)
Expecting:
Traceback (most recent call last):
...
RuntimeError: Unable to create L-series, due to precision or other limits in PARI.
*** *** Error: TIMED OUT! PROCESS KILLED! *** ***
*** *** Error: TIMED OUT! *** ***
[362.9 s]
exit code: 1024
There was a 'gp' process that sat thrashing at 2.5GB for a while then
doubled in size to 4.9GB and again doubled to 9.7GB before the parent
timed out and exited - it did not kill the gp process. Interestingly,
it reported the runtime error quite early on and kept going.
I repeated the test with ulimit -v set to 2048000 (ie about 2GB) and
the test "succeeded":
...
Trying:
L(Integer(2))###line 103:_sage_ >>> L(2)
Expecting:
0.381575408260711
ok
Trying:
e = EllipticCurve([Integer(1),Integer(1),Integer(0),-Integer(63900),-Integer(1964465932632)])###line 112:_sage_ >>> e = EllipticCurve([1,1,0,-63900,-1964465932632])
Expecting nothing
ok
Trying:
L = e.lseries().dokchitser(Integer(15))###line 113:_sage_ >>> L = e.lseries().dokchitser(15)
Expecting:
Traceback (most recent call last):
...
RuntimeError: Unable to create L-series, due to precision or other limits in PARI.
ok
Trying:
set_random_seed(0L)
Expecting nothing
ok
...
It looks like this test just falls foul of FreeBSD/amd64's process size
limits (though whatever reports the RuntimeError should stop and not
continue at that point).
>I also looked at http://wiki.sagemath.org/freebsd/sage-3.4 and I am
>dubious about some of the patches, especially about most of the bits
>from ports.
There are only 3 sets of patches that come out of FreeBSD ports.
Of these, only the python fixes may be unnecessary.
gap: These patches were necessary to make gap compile. Note that
posix_openpt() is the recommended way of accessing PTYs since FreeBSD
5.x and, following the re-write of the TTY subsystem in 8.x, the old
BSD PTYs no longer exist by default.
matplotlib: The change from to_int() to to_float() comes from FreeBSD
but is needed to avoid the
ValueError: invalid literal for int() with base 10: '539.621'
that I initially reported.
python: These patches are almost all straight from FreeBSD. They
probably are overkill (though python internally has code to support
FreeBSD only up to 6.x, so there may be some parts that are needed for
7.x and 8.x). (My initial suspicion was that the above problem was
python so I patched it. When that didn't help, I went digging deeper
but did not pull out the python fixes).
>fixes are pushed upstream. The choice of using shar as an archive
>format also seems rather strange to me.
I had hoped that Moin would allow them to be directly viewed - but
it doesn't so I might switch back to using tar.
>Which java are you using?
java version "1.5.0_14-p8"
On 2009-Mar-28 21:38:09 -0700, mabshoff <mabs...@googlemail.com> wrote:
>Yep, we discussed this over lunch. When I was doctesting with FreeBSD
>7 and the SunJDK that ran via the linux emulation layer things went
>pretty badly.
Looking at atimes, something did use java whilst the tests were
running and I don't think anything else would have.
>Re putchar(): I have this patch for gcc 4.3 on Solaris in tree:
>
>--- pprdrv_tt2.cpp.orig 2009-01-19 06:37:37.373517000 -0500
>+++ pprdrv_tt2.cpp 2009-01-19 06:38:26.782530000 -0500
>@@ -104,7 +104,8 @@
> { /* have a log of points. */
> if(stack_depth == 0)
> {
>- stream.putchar('{');
>+ // Note the below is a hack to make it compile on
>Solaris 10 with gcc 4.3.2
>+ stream.puts("{");
> stack_depth=1;
> }
>
>It will likely fix the issue you are seeing on FreeBSD 8 + gcc 4.3,
>too.
In my case, it was the declaration that blew up first:
building 'matplotlib.ttconv' extension
creating build/temp.freebsd-8.0-CURRENT-amd64-2.5/ttconv
gcc -fno-strict-aliasing -DNDEBUG -D__wchar_t=wchar_t -fPIC -I/home/peter/sage/sage-3.4/local/include -I/usr/local/include -I/usr/include -I. -I/home/peter/sage/sage-3.4/local/include/ -I/home/peter/sage/sage-3.4/local/include/python2.5 -c src/_ttconv.cpp -o build/temp.freebsd-8.0-CURRENT-amd64-2.5/src/_ttconv.o
In file included from src/_ttconv.cpp:8:
./ttconv/pprdrv.h:43: error: expected unqualified-id before '!' token
./ttconv/pprdrv.h:43: error: expected `)' before '!' token
error: command 'gcc' failed with exit status 1
> * you are patching files like configure scripts and you really should
>not do that :)
IMO, GNU configure is a massive impediment to portability. I agree I
shouldn't be patching the configure scripts - and if GNU configure
worked as advertised, I wouldn't need to. Where it's only a simple
fix, it's easier to hack the configure script than work out where the
input files are broken and then re-run autoconf.
> * most of the fixes should be pushed upstream
Agreed. I've already pushed the libm4ri fix upstream (and it has been
accepted). I will work through the other fixes and feed the upstream
if appropriate.
>I think the first step would be to provide individual patches so that
>we can decide what to integrate and what to leave out.
I intend to submit each patch to trac as soon as I have an account.
> Some of the
>fixes should certainly go in while I cam quite dubious about others,
>but we can do that on a case by case review.
I'm not sure that what I've done is necessarily either the best or
even most correct approach and see it as a work-in-progress. I
was initially using the base gcc4.2 and installed g95 but ran into
problems and switches to the gcc4.3 toolchain. As a result, some
of my earlier patches may not be relevant any longer.
I will try a FreeBSD-7.1/amd64 environment if I have time during
the week.
--
Peter Jeremy
William Stein
That's *definitely* a bug in your Sage build. gp doubles its stack
when it gets an error that indicates it runs out of memory.
Something must be triggering that error.
It seems like we need a common FreeBSD server somewhere to develop on
together in order to resolve these issues. Please contact Tom Boothby
(<boo...@u.washington.edu>) who will make you an account on the
sage.math devel cluster; I have freebsd 32 and 64-bit (virtual)
servers there and can make you an admin on them. I hope you'll use
ulimit when doctesting :-)
--