On 2009-Mar-28 21:12:09 -0700, mabshoff <mabsh...@googlemail.com> wrote: >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 <mabsh...@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
pgpZbjSqs88jl.pgp
Description: PGP signature
