On 5/5/07, mabshoff <Michael.Abshoff@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > Regarding Linbox: The svn snapshot in 2.5.0alpha2 is about 6 weeks old
> > > and juding from the svn log it seems to be a good idea to update.
> >
> > The last two times I tried the svn version was broken. The version
> > included in SAGE was the result of Clement Pernet being at SAGE Days 3 and
> > spending several days fixing bugs and build issues. As soon as linbox
> > development
> > moved forward past then, it became broken in various way fairly
> > quickly. I reported
> > all the issues I had, so maybe they are fixed now.
>
> Ok, I tried 1.1.3r2701 on three different platforms and all tests
> passed, Clement fixed a bug in 1.1.3r2699 that caused problems in test-
> rank. Do you use your own testcases or how do you determine that there
> were issues?
My test case is to build the SAGE linbox package, then run the SAGE
test suite. I also have a lot of randomized testing of linear algebra
via my modular symbols package.
> If you have your own code you can send them to me and I
> can take a look.
I'll try the latest svn and take a look myself. It's very easy to build
the new linbox package, and it has some great things I really want
to include in SAGE, e.g., Clement's new super-fast charpoly routine.
If anything doesn't work I'll email both you and Clement.
> I have been getting more and more familiar with the
> code and I am currently testing 1.1.3r2701 with valgrind. My goal is
Excellent!
> > > Another taks I would suggest is also adding "make check" to the build
> > > script because that would obviously greatly expand the testing base
> > > for the Linbox code. This would increase the build time of that spkg
> > > very much, but at least we can catch build issues and/or bugs much
> >
> > ^^^^^^^^^^^^^^
> >
> > Running make check will not be the *default* for builds, but I have been
> > planning to introduce some form of this for a while. However, I intend
> > to have optional scripts spkg-check in each sage package, that would
> > be run after spkg-install succeeds and before the temp build directory
> > is deleted. Then if one builds using
> > "make buildcheck"
> > SAGE would build each package and run spkg-check. If one builds
> > with just plan "make" then none of the spkg-check's get run.
> >
>
> Great. Can we also add something that builds the packages without
> optimizations and with debug info so that debugging would get easier?
How about a script
spkg-debug
which is run instead of spkg-install if present and if one builds
SAGE using "make sagedebug".
This could be very complicated to maintain in general. E.g., when new
versions of packages come out, instead of just updating spkg-install (which
can already be incredibly complicated -- the spkg-install for singular), one
also would have to do the same with spkg-debug. It also means that I have
to run "make sagedebug" and make sure everything works on a whole
bunch of different architectures after every package update before any
new release of SAGE. Adding spkg-debug's and properly maintaining
them would significantly increase the workload for making new SAGE
releases, so it won't happen unless someone volunteers to help with it.
> Is there also a way to finish the compilation and installation of a
> spkg that had a build failure? I am currently stuck on cygwin with
> libsingular and I can build it manually and run spkg-install, but when
> I restart the build process with "make" it starts rebuild singular
> from scratch :(. If I get it installed manually I can move forward
> while waiting on somebody else to fix the build.
The simplest answer is that if the package is called, e.g., foo-2.4.5,
then if you just do (from SAGE_ROOT)
touch spkg/installed/foo-2.4.5
SAGE will henceforth assume that package was successfully installed.
So, after doing
. local/bin/sage-env
and getting your package installed, just do touch as above, and you're
good to go.
> > Best would be for you to send me an spkg-check script for each.
> >
>
> Will do. I am still working on an updated gdmodule that no longer uses
> different Setup.py[.cygwin]
Thanks.
--
William Stein
Associate Professor of Mathematics
University of Washington
http://www.williamstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to
sage-devel-unsubscribe@xxxxxxxxxxxxxxxx
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/
-~----------~----~----~----~------~----~------~--~---
|
