Opened 10 years ago
Closed 10 years ago
#12841 closed enhancement (fixed)
update M4RIE to newest upstream release
Reported by: | malb | Owned by: | tbd |
---|---|---|---|
Priority: | major | Milestone: | sage-5.3 |
Component: | packages: standard | Keywords: | |
Cc: | Merged in: | sage-5.3.beta0 | |
Authors: | Martin Albrecht | Reviewers: | Simon King, Jeroen Demeyer, Volker Braun |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #12840 | Stopgaps: |
Description (last modified by )
M4RIE-20120415's main improvement over the version we currently have in Sage is that it is much much faster for degrees 4 <= e <= 8 and bugfixes.
Install: http://sage.math.washington.edu/home/malb/spkgs/libm4rie-20120613.spkg
Attachments (1)
Change History (67)
Changed 10 years ago by
comment:1 Changed 10 years ago by
- Description modified (diff)
comment:2 Changed 10 years ago by
- Dependencies set to #12840
comment:3 Changed 10 years ago by
- Description modified (diff)
comment:4 Changed 10 years ago by
- Status changed from new to needs_review
comment:5 Changed 10 years ago by
comment:6 follow-up: ↓ 7 Changed 10 years ago by
I get an error with SAGE_CHECK on
FAIL: test_ple =================== 5 of 5 tests failed =================== make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src'
This is on Ubuntu 12.04 (32 bit) on vmware in Windows 7. gcc version 4.6.3 (Ubuntu/Linaro? 4.6.3-1ubuntu4)
I got this with the previous package as well.
adam
comment:7 in reply to: ↑ 6 Changed 10 years ago by
Replying to awebb:
I get an error with SAGE_CHECK on
FAIL: test_ple =================== 5 of 5 tests failed =================== make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/math/sage/spkg/build/libm4rie-20120415/src'This is on Ubuntu 12.04 (32 bit) on vmware in Windows 7. gcc version 4.6.3 (Ubuntu/Linaro? 4.6.3-1ubuntu4)
I got this with the previous package as well.
adam
Hi, unfortunately, that error message doesn't say much more than that there were errors.
- The log should contain more detailed information, can you post this?
- Also, by previous package you mean version 20111004?
comment:8 Changed 10 years ago by
Do I just use the spkg above or do I need to apply the patch as well?
I have tried with libm4rie-20111004.p2.spkg and libm4rie-20111004.p3.spkg and got the same error. The log doesn't have any details at all. The error occurs during the make check-TESTS portion of the build. It just lists off a pile of tests and ends each section with things like FAIL: test_trsm. The odd part is that there are no fail messages anywhere else.
The home directories are not yet present on sage.math.washinton.edu but once they are I will upload the log file.
comment:9 Changed 10 years ago by
I fixed the issue in https://bitbucket.org/malb/m4rie/changeset/81d352a8aade and replaced the SPKG with a version with this fix applied.
comment:10 Changed 10 years ago by
I tried again and got the same result. The log is at http://sage.math.washington.edu/home/awebb/libm4rie-20120415.log. I see anything useful in the log however.
comment:11 Changed 10 years ago by
correction: I Don't see anything in the log that is useful. A.
comment:12 Changed 10 years ago by
Argh, that's because I uploaded the wrong file again. I fixed it and replaced the file.
comment:13 Changed 10 years ago by
It looks like it worked. At least it built. I now have a ppl problem but that might have already been reported.
comment:14 follow-up: ↓ 16 Changed 10 years ago by
- Status changed from needs_review to needs_work
The new spkg wants to run autoheader
. This probably means that upstream should run autoreconf
before shipping their sources.
Making install in . make[1]: Entering directory `/usr/local/src/sage-5.0.beta13/spkg/build/libm4rie-20120415/src' (CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /usr/local/src/sage-5.0.beta13/spkg/build/libm4rie-20120415/src/missing --run autoheader) rm -f src/stamp-h1 touch src/config.h.in
comment:15 Changed 10 years ago by
This is exactly the same problem which I already fixed once in #12501.
comment:16 in reply to: ↑ 14 Changed 10 years ago by
Replying to jdemeyer:
The new spkg wants to run
autoheader
. This probably means that upstream should runautoreconf
before shipping their sources.
Upstream does that: https://bitbucket.org/malb/m4ri-scripts/src/tip/release.py#cl-35 but I added a touch configure afterwards. I also touched configure in the SPKG linked above.
comment:17 Changed 10 years ago by
- Work issues set to autoheader
Are you sure you updated the spkg correctly? I still get exactly the same problem as I reported before.
comment:18 Changed 10 years ago by
On which box does this happen, I get on sage.math:
./sage-5.0.beta13-m4rie/sage -f ~/spkgs/libm4rie-20120415.spkg Calling sage-spkg on '/home/malb/spkgs/libm4rie-20120415.spkg' libm4rie-20120415 ==================================================== Extracting package /home/malb/spkgs/libm4rie-20120415.spkg -rw-r--r-- 1 malb malb 401369 2012-04-15 07:03 /home/malb/spkgs/libm4rie-20120415.spkg Finished extraction **************************************************** Host system: Linux sage.math.washington.edu 2.6.24-28-server #1 SMP Fri Feb 11 18:08:32 UTC 2011 x86_64 GNU/Linux **************************************************** C compiler: gcc C compiler version: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/scratch/malb/sage-5.0.beta13-m4rie/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --prefix=/scratch/malb/sage-5.0.beta13/local --with-local-prefix=/scratch/malb/sage-5.0.beta13/local --with-gmp=/scratch/malb/sage-5.0.beta13/local --with-mpfr=/scratch/malb/sage-5.0.beta13/local --with-mpc=/scratch/malb/sage-5.0.beta13/local --with-system-zlib --disable-multilib Thread model: posix gcc version 4.6.3 (GCC) **************************************************** checking build system type... x86_64-unknown-linux-gnu
comment:19 Changed 10 years ago by
This was on boxen.math. Anyway, the relevant file which should be touched is config.h.in
(not configure
)
comment:20 follow-up: ↓ 21 Changed 10 years ago by
I've updated the SPKG accordingly and my release script (for future releases)
comment:21 in reply to: ↑ 20 Changed 10 years ago by
Replying to malb:
I've updated the SPKG accordingly and my release script (for future releases)
Does that mean the ticket needs review? Or still needs work?
comment:22 Changed 10 years ago by
- Status changed from needs_work to needs_review
Thanks, it needs review
comment:23 Changed 10 years ago by
The ticket description mentions bug fixes. What are they?
comment:24 follow-up: ↓ 25 Changed 10 years ago by
The bugfixes mainly concern the testsuite: https://bitbucket.org/malb/m4rie/changesets
- !81d352a8aade reserve enough pointers for finite fields in testsuite
- !8245cd046d86 removed a bit of dead code scan-build reported
- !b81b9649e2d1 use unsigned ints for degrees everywhere
- !ad8e309640e3 make sure the canary does not set bits which are expected to be zero (e.g. in lockup tables)
- !f6f4b011dbe3 fixed a memleak
- !dfacf106f205 bitmasks should be unsigned
- !a3087ea586d7 fixed memleak in test_smallops
- !02f7dfe20ff5 replaced nonstandard STRING(x) with #x
- !9d23a80fa589 remove -lntl, it's not needed
- !f104847ecea0 using less temporary memory for Karatsuba for GF(2^{4) }
- !bd90f880f4a8 saving memory in karatsuba multiplication
- !548023a54d9e use rpath for test_* to make sure the right version of the library is used
- !559610e11d7e unified strassen cutoff
comment:25 in reply to: ↑ 24 ; follow-ups: ↓ 26 ↓ 27 Changed 10 years ago by
Replying to malb:
The bugfixes mainly concern the testsuite:
I didn't install the package with SAGE_CHECK=yes, but I guess I should... Anyway, the Sage test suite (make ptestlong) works.
I tried to verify your claim that it became faster for exponents between 4 and 8. I tested 6. First, in vanilla sage-5.0.rc0:
sage: K.<z> = GF(2^6) sage: %time A = random_matrix(K,10000,10000) CPU times: user 1.63 s, sys: 0.06 s, total: 1.70 s Wall time: 1.70 s sage: %time B = random_matrix(K,10000,10000) CPU times: user 1.53 s, sys: 0.04 s, total: 1.58 s Wall time: 1.58 s sage: %time (A*B).rank() CPU times: user 85.03 s, sys: 0.12 s, total: 85.15 s Wall time: 85.40 s 10000
With the new spkgs in sage-5.0.beta13:
sage: K.<z> = GF(2^6) sage: %time A = random_matrix(K,10000,10000) CPU times: user 1.77 s, sys: 0.07 s, total: 1.84 s Wall time: 1.85 s sage: %time B = random_matrix(K,10000,10000) CPU times: user 1.76 s, sys: 0.03 s, total: 1.79 s Wall time: 1.80 s sage: %time (A*B).rank() CPU times: user 37.38 s, sys: 0.23 s, total: 37.61 s Wall time: 37.74 s 10000
Now, that is faster for the "real" computation, but roughly 10% slower for random matrix creation. Is that a random result within the margin of error?
comment:26 in reply to: ↑ 25 Changed 10 years ago by
comment:27 in reply to: ↑ 25 Changed 10 years ago by
Replying to SimonKing:
Now, that is faster for the "real" computation, but roughly 10% slower for random matrix creation. Is that a random result within the margin of error?
I don't recall that anything changed in random matrix creation, so I'd assume it's down to margin of error.
comment:28 follow-up: ↓ 31 Changed 10 years ago by
I get
king@mpc622:/mnt/local/king/SAGE/stable/sage-5.0.beta13/spkg/optional/libm4rie-20120415$ hg status M spkg-install king@mpc622:/mnt/local/king/SAGE/stable/sage-5.0.beta13/spkg/optional/libm4rie-20120415$ hg diff diff --git a/spkg-install b/spkg-install --- a/spkg-install +++ b/spkg-install @@ -26,7 +26,7 @@ CPPFLAGS="$INCLUDES" if [ "x$SAGE_DEBUG" = "xyes" ]; then - CFLAGS="-O0 $CFLAGS" + CFLAGS="$CFLAGS -O0" ENABLE_DEBUG="--enable-debug" else CFLAGS="-O2 $CFLAGS"
So, please update the package by checking in the changes!
Apart from that, self tests and make ptestlong pass, and we see some speed-up. I only tested on one platform, though. Jeroen, can you confirm that the problem you mentioned is fixed?
comment:29 Changed 10 years ago by
Whoops, yeah, I left those uncommitted because there was a bit of discussion whether we should have this or not, i.e., should SAGE_DEBUG overwrite the optimisation level you specify in in CFLAGS. I'm inclined that it shouldn't so I will revert this change.
comment:30 Changed 10 years ago by
Hi, I updated the SPKG accordingly.
comment:31 in reply to: ↑ 28 Changed 10 years ago by
- Reviewers set to Simon King, Jeroen Demeyer
- Work issues autoheader deleted
Replying to SimonKing:
Apart from that, self tests and make ptestlong pass, and we see some speed-up. I only tested on one platform, though. Jeroen, can you confirm that the problem you mentioned is fixed?
Yes, it does.
I also agree with leaving the -O0
as it is.
comment:32 Changed 10 years ago by
- Description modified (diff)
comment:33 Changed 10 years ago by
- Reviewers changed from Simon King, Jeroen Demeyer to Simon King, Jeroen Demeyer, Volker Braun
- Status changed from needs_review to positive_review
I looked at it with #12840 and looks good to me. Lets get this boat off the ground ;-)
comment:34 Changed 10 years ago by
- Milestone changed from sage-5.1 to sage-5.2
comment:35 Changed 10 years ago by
- Status changed from positive_review to needs_work
- Work issues set to solaris
I tried to compile this on mark (sparc solaris) and it dies at
g++ -DHAVE_CONFIG_H -I. -I./src -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -I/include -I/include -I/include -MT test_trsm-test_trsm.o -MD -MP -MF .deps/test_trsm-test_trsm.Tpo -c -o test_trsm-test_trsm.o `test -f 'tests/test_trsm.cc' || echo './'`tests/test_trsm.cc mv -f .deps/test_trsm-test_trsm.Tpo .deps/test_trsm-test_trsm.Po /bin/bash ./libtool --tag=CXX --mode=link g++ -I/include -I/include -I/include -Wl,-rpath,.libs/ -L/home/vbraun/opt/mark/sage-5.1.beta3/local/lib -o test_trsm test_trsm-test_trsm.o -L/lib -lm4ri -lm4rie -lgivaro -lgmpxx -lgmp -lm -lstdc++ libtool: link: g++ -I/include -I/include -I/include -Wl,-rpath -Wl,.libs/ -o .libs/test_trsm test_trsm-test_trsm.o -L/home/vbraun/opt/mark/sage-5.1.beta3/local/lib -L/lib /home/vbraun/opt/mark/sage-5.1.beta3/spkg/build/libm4rie-20120613/src/.libs/libm4rie.so /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libm4ri.so /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libpng12.so -lz /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libgivaro.so -L/home/vbraun/opt/mark/sage-5.1.beta3/local//lib /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libgmpxx.so /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libgmp.so /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/libstdc++.so -lm -Wl,-R -Wl,/home/vbraun/opt/mark/sage-5.1.beta3/local/lib ld: fatal: option -dn and -P are incompatible ld: fatal: Flags processing errors collect2: ld returned 1 exit status make[2]: *** [test_trsm] Error 1 make[2]: Leaving directory `/home/vbraun/opt/mark/sage-5.1.beta3/spkg/build/libm4rie-20120613/src' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/vbraun/opt/mark/sage-5.1.beta3/spkg/build/libm4rie-20120613/src' make: *** [check-recursive] Error 1
Only more sophisticated linkers understand -rpath
, its better to use -R
. Though you shouldn't have to manually set rpaths in libm4rie-20120613/src/bench/Makefile.am
at all, the whole autotools/libtools machinery should do that for you.
comment:36 Changed 10 years ago by
- Status changed from needs_work to needs_review
Okay, I dropped it from Makefile.am and replaced the SPKG at the same address.
(It is still used in my benchmarking code of M4RIE but that isn't built by Sage.)
comment:37 Changed 10 years ago by
Still dying on mark/skynet, though now at a different place:
/bin/bash ./libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -I/include -O2 -fPIC -Wall -pedantic -g -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT gf2e.lo -MD -MP -MF .deps/gf2e.Tpo -c -o gf2e.lo `test -f 'src/gf2e.c' || echo './'`src/gf2e.c libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -I/include -O2 -fPIC -Wall -pedantic -g -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT gf2e.lo -MD -MP -MF .deps/gf2e.Tpo -c src/gf2e.c -fPIC -DPIC -o .libs/gf2e.o libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -I/include -O2 -fPIC -Wall -pedantic -g -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT gf2e.lo -MD -MP -MF .deps/gf2e.Tpo -c src/gf2e.c -o gf2e.o >/dev/null 2>&1 mv -f .deps/gf2e.Tpo .deps/gf2e.Plo /bin/bash ./libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -I/include -O2 -fPIC -Wall -pedantic -g -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT mzed.lo -MD -MP -MF .deps/mzed.Tpo -c -o mzed.lo `test -f 'src/mzed.c' || echo './'`src/mzed.c libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -I/include -O2 -fPIC -Wall -pedantic -g -I/home/vbraun/opt/mark/sage-5.1.beta3/local/include -MT mzed.lo -MD -MP -MF .deps/mzed.Tpo -c src/mzed.c -fPIC -DPIC -o .libs/mzed.o In file included from src/mzed.c:23:0: src/mzed.h:50:24: fatal error: m4rie/gf2e.h: No such file or directory compilation terminated. make[1]: *** [mzed.lo] Error 1 make[1]: Leaving directory `/home/vbraun/opt/mark/sage-5.1.beta3/spkg/build/libm4rie-20120613/src' make: *** [all-recursive] Error 1 Error building libm4rie
comment:38 Changed 10 years ago by
Updated spkg builds on mark/skynet. Now doctesting...
comment:39 Changed 10 years ago by
I keep getting bus errors (aka segfaults) on mark/skynet with pickling of matrix_modn_dense_double
matrices. The _pickle
method uses mod_int
and not celement
, I'm totally confused about that. Note that on mark/skynet:
sage: cython('def f():\n return (sizeof(double), sizeof(unsigned long))\n') sage: f() (8, 4)
This might not be the fault of your patch, but its hard to un-apply the spkgs.
comment:40 Changed 10 years ago by
The release buildbot shows these bus errors, too:
comment:41 Changed 10 years ago by
This is with only M4RI/M4RIE applied, not the LinBox? update, right?
The elements in Matrix_modn_double
should fit into a mod_int
since they are < 2^{23}. Hence, we simply used the same pickling format as the old Matrix_modn_dense
.
comment:42 Changed 10 years ago by
Yes, just with M4RI/M4RIE. The buildbot failure I linked to is even without the M4RI/M4RIE update.
comment:43 Changed 10 years ago by
From http://docs.oracle.com/cd/E19957-01/806-3568/ncg_math.html about the double bit format:
In the SPARC architecture, the higher address 32-bit word contains the least significant 32 bits of the fraction, while in the x86 architecture the lower address 32-bit word contains the least significant 32 bits of the fraction.
comment:44 follow-up: ↓ 45 Changed 10 years ago by
But we're doing a cast, shouldn't that take care of it?
comment:45 in reply to: ↑ 44 Changed 10 years ago by
Replying to malb:
But we're doing a cast, shouldn't that take care of it?
What lines of code are you talking about? The problem might be alignment, i.e. doubles should be aligned on a multiple of 8 bytes.
comment:46 Changed 10 years ago by
I mean this:
http://hg.sagemath.org/sage-main/file/01e0779db321/sage/matrix/matrix_modn_dense_template.pxi#l650
But perhaps we should wait until we've run this through a gdb before we speculate which lines fail? :)
comment:47 follow-up: ↓ 48 Changed 10 years ago by
comment:48 in reply to: ↑ 47 Changed 10 years ago by
What are the mod_int
and celement
types and where do double
s come in?
comment:49 Changed 10 years ago by
gdb isn't installed on mark. the only debugger is mdb and I have no idea how to use it. But the bus error is at the i=j=0 assignment (using print) in _pickle.
I thought mod_int = long int and celement = double (in matrix_modn_dense_double)
The cast to mod_int is working correctly, though.
comment:50 Changed 10 years ago by
For the record, matrix_modn_dense_template.pxi with some extra prints:
else: print 'word_size != sizeof(char)', word_size, <int><char*>s um = <mod_int*><char *>s for i in range(self._nrows): row_self = self._matrix[i] row_um = &um[i*self._ncols] for j in range(self._ncols): print i, j, row_self[j], <mod_int>row_self[j], self._ncols, self._nrows, <int>row_um row_um[j] = <mod_int>row_self[j] print "crash"
yields
sage: random_matrix(ZZ.quo(123456), 10,10)._pickle() word_size != sizeof(char) 8 68071796 0 0 60348.0 60348 10 10 68071796 --------------------------------------------------------------------------- RuntimeError Traceback (most recent call last) /home/vbraun/opt/mark/sage-5.1.beta3/devel/sage-main/<ipython console> in <module>() /home/vbraun/opt/mark/sage-5.1.beta3/local/lib/python2.7/site-packages/sage/matrix/matrix_modn_dense_double.so in sage.matrix.matrix_modn_dense_double.Matrix_modn_dense_template._pickle (sage/matrix/matrix_modn_dense_double.cpp:6537)() RuntimeError: Bus error
comment:51 Changed 10 years ago by
Jeroen was right, its an alignment thing. The output of PyString_FromStringAndSize
is 4 but not 8-byte aligned. By faking it
um = <mod_int*>((<char *>s)+4)
I avoided the crash.
comment:52 Changed 10 years ago by
But it seems it's not double alignment? By the time it hits unaligned memory it's already a mod_int == long
.
comment:53 Changed 10 years ago by
But note that wordsize
== sizeof(mod_int)
== 8 according to Volker's print
statement.
comment:54 Changed 10 years ago by
The problem is that sage/ext/multi_modular.h
defines
#define mod_int uint_fast64_t
So, mod_int
is actually uint_fast64_t
.
comment:55 follow-up: ↓ 57 Changed 10 years ago by
The file sage/ext/multi_modular.h
seems to be used by LinBox. But matrix_modn_double_*
has a conflicting definition of mod_int
. It is supposed to be the same or did you both use the same name for a type accidentally?
comment:56 Changed 10 years ago by
Note that the conflicting types might not even a problem, as Cython doesn't really care much about types. The definition
ctypedef unsigned long mod_int
mostly just makes Cython aware that mod_int
is some (integer?) type, the actual type doesn't really matter as far as I know.
comment:57 in reply to: ↑ 55 Changed 10 years ago by
Replying to jdemeyer:
The file
sage/ext/multi_modular.h
seems to be used by LinBox. Butmatrix_modn_double_*
has a conflicting definition ofmod_int
. It is supposed to be the same or did you both use the same name for a type accidentally?
FWIW: I made a similar experience on Solaris with my MeatAxe wrapper (and, if I remember correctly, the same problem has shown up a while ago when trying to use Singular options in !libSingular). Namely, MeatAxe uses a function mulmat (or matmul? Doesn't matter...), but apparently a function of the same name is defined in some other spkg as well. And apparently the Solaris linker was confusing the two mulmats, even though they belong to totally different packages! In particular, MeatAxe does not link against the other package.
The simple solution was to rename MeatAxe's mulmat into _mulmat. So, renaming mod_int into something else would be worth a try.
comment:58 Changed 10 years ago by
Perhaps 64-bit integers need to be 8-byte aligned as well? Also, I guess
ctypedef unsigned long mod_int
should be replaced by the correct typedef, to make it less confusing. In any case, I opened a new ticket at #13151 since this is not M4RIE releated.
comment:59 Changed 10 years ago by
The cast is defined at compile-time, not at link-time. To summarize, the problem really is that malloc on Solaris only returns 32-bit aligned memory.
Simon: There is only a single flat namespace on Linux and Solaris, so if any shared library imports conflicting symbols then its just luck to get the right one.
comment:60 Changed 10 years ago by
- Status changed from needs_review to positive_review
Other doctests pass, so lets give this a go.
comment:61 Changed 10 years ago by
- Work issues solaris deleted
comment:62 Changed 10 years ago by
- Milestone changed from sage-5.2 to sage-pending
comment:63 Changed 10 years ago by
- Milestone changed from sage-pending to sage-5.3
comment:64 Changed 10 years ago by
- Milestone changed from sage-5.3 to sage-pending
comment:65 Changed 10 years ago by
- Milestone changed from sage-pending to sage-5.3
comment:66 Changed 10 years ago by
- Merged in set to sage-5.3.beta0
- Resolution set to fixed
- Status changed from positive_review to closed
Note that the SPKG is based on #12821