Hi Michael, There's a memory leak in _fmpz_poly_reverse, which is used in all the newton division functions. So machines with small quantities of RAM might abort because of that. It's also possible they might get stuck on fmpz_poly_div_newton or earlier because of this. But these issues are fixed in the latest revision and I'd appreciate any test feedback people can give me with the current version you've packaged despite these known faults. On many systems the memory leaks won't be severe enough to cause any problems. If you do want to fix it you can just take the current version of the function _fmpz_poly_reverse in the file fmpz_poly.c from HEAD in SVN and put it into the rev 1075 code that you have.
In the latest revision (HEAD) I've completely redone the FLINT build system, so you will need to move the new makefile up into SAGE as the old one won't work any more. Before running the makefile, you now have to source flint_env (or replace it with a SAGE specific thing which does the same thing). Basically what I've done is take the existing SAGE lib_makefile and rewritten it to automate some things, distributing bits of it into the FLINT makefile and the rest into flint_env. But I've also removed some SAGE specific stuff that isn't needed in FLINT itself. Naturally you can still override all that as you were doing before, but there should be much less to do now in lib_makefile. One of the concerning things is that making FLINT into a shared library with -fPIC incurs upto a 20% speed penalty. Ouch!! As we'll be adding more tuning information and platform specific stuff soon, it might be worth letting the FLINT build system do as much work as possible otherwise you'll be continuously rewriting lib_makefile for FLINT. At present all I've done is add some tuning details for the G5 but there'll be more soon enough. BTW, I've ripped off some stuff directly from lib_makefile, but I didn't know who to credit it to. If you let me know I'll add the appropriate copyright notices to the new FLINT build files. Basically some of that stuff has now been moved upstream into FLINT. Many thanks to whoever wrote that. By the way, as of the most recent revision of FLINT, the SAGE trac ticket related to u_int32_t etc, should be able to be closed. However I haven't fixed this in the old FLINT-QS, since I plan to replace it with the new FLINT-QS, which is part of FLINT instead of being distributed separately. I'm not 100% sure that the new sieve actually works on all systems yet, but it's going to work very soon if it doesn't already, meaning we can replace the old FLINT-QS in SAGE with the new one. By the way, I added a function for cleaning up after the stack based memory manager in FLINT after SAGE is done with it. It also audits the stack and complains if a problem was found. This is how I discovered the hitherto unnoticed memory leak! Bill. On 24 Nov, 03:46, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > Hello folks, > > Bill has fixed a couple of bugs in flint since r1072 that were corner > cases that only happened on Core Duos, so I have updated the spkg to > r1075. It is available at > > http://sage.math.washington.edu/home/mabshoff/flint-0.9-r1075.spkg > > It runs the spkg-check script per default - this will be deactivated > in the final 2.8.14 release. We do this because Bill Hart needs > feedback and extended testing for FLINT that the Sage doctests cannot > provide. The tests take about 15-30 minutes to run (15 on sage.math, > 30 in my laptop). Please report back whether the tests failed or > succeeded, together with info about CPU, operating system and > compiler. Bill: is there a standard format you would like? > > Cheers, > > Michael > > One more thing: Bill, when I checked out trunk, i.e. r1086 compilation > fails with: > > gcc -std=c99 -I/tmp/Work-mabshoff/release-cycles-2.8.14/ > sage-2.8.14.rc0/local/include/ -I/tmp/Work-mabshoff/release- > cycles-2.8.14/sage-2.8.14.rc0/local/include -I/tmp/Work-mabshoff/ > release-cycles-2.8.14/sage-2.8.14.rc0/local/include -funroll-loops - > fexpensive-optimizations -mtune=opteron -march=opteron -fPIC -funroll- > loops -O3 -o delta_qexp delta_qexp.o mpn_extras.o mpz_extras.o memory- > manager.o ZmodF.o ZmodF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o > mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o long_extras.o -L/tmp/Work- > mabshoff/release-cycles-2.8.14/sage-2.8.14.rc0/local/lib/ -L/tmp/Work- > mabshoff/release-cycles-2.8.14/sage-2.8.14.rc0/local/lib/ -L/tmp/Work- > mabshoff/release-cycles-2.8.14/sage-2.8.14.rc0/local/include -lgmp - > lpthread -lm -lntl > make: *** No rule to make target `BLTcubes.c', needed by `BLTcubes'. > Stop. > Error building flint shared library. > > Since there are some modifications to the makefiles in the spkg (it > seems that we add targets for OSX) we might want to merge those > changes back into trunk. I will check and ping the person who wrote > the makefile. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
