On Fri, Jul 16, 2010 at 8:00 AM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > On 07/16/10 03:03 PM, Sergey Bochkanov wrote: >> >> Hello, Dr.. >> >> You wrote 16 июля 2010 г., 17:37:25: >>>> >>>> So if spkg-check is executed, I can be sure that spkg was successfully >>>> installed into system? >>> >>> Not exactly, as some packages unfortunately ignore errors, so if the >>> package >>> fails to install, you will not know it. >> >> I am talking about my own package, so I know that its author at least >> tried to handle all errors during install :) > > Yes, I had not realised you were talking of your own package. If you recall, > I looked at that, and found it was ok. The tests passed on a system or two I > checked it on. You did have some self-tests, though I remarked the output > was only shown at the end, not after each test. You said it was a problem > with flusing stdout and it behaved differently on Linux to Solaris. > >>> Not all packages have spkg-check files - in fact, the majority do >>> not. A list of the packages which have them missing can be found on >>> this ticket. http://trac.sagemath.org/sage_trac/ticket/9281 >> >> Looks like that spkg-check is not very popular way of testing >> packages.
Perhaps running all spkg-check should be added to the -testall runs? (This may not be very practical however...given we don't leave all the old builds around.) > That's true, though there is an interest in improving that situation by a > few people at least. > > If you look at the ticket I created listing the packages which don't have > spkg-check files, you will see several others have added their usernames to > 'cc' field. John Palmieri has done some work on this > > http://trac.sagemath.org/sage_trac/ticket/9352 > > I fixed a couple recently > > http://trac.sagemath.org/sage_trac/ticket/9277 > http://trac.sagemath.org/sage_trac/ticket/9286 > http://trac.sagemath.org/sage_trac/ticket/9309 > http://trac.sagemath.org/sage_trac/ticket/9308 > > and have created tickets for fixing a couple more > > http://trac.sagemath.org/sage_trac/ticket/9311 > >> Many packages rely on doctests. > > >> It leads me to the next >> question. >> >> I work on test suite for ALGLIB spkg. Previous release contained only >> computational core tests, now I want to add Python-C integration >> tests. These tests will be integrated into spkg-check. So testing will >> be done as follows: >> 1) spkg-check is called >> 2) computational core (external shared library) is tested >> 3) if failed, testing is stopped >> 4) communication between core and Python is tested >> >> Step (4) is just execution of very large Python script which tries to >> call different ALGLIB functions and to check their result. This script >> is automatically generated from formal description - it will allow me >> to use these tests later in other programming languages. >> >> It is also possible to automatically generate doctests from formal >> description used to generate spkg-check. > > I'm impressed. Sage needs more people like you, who take testing a bit more > seriously. > >> So I have three options: >> a) to test ALGLIB from spkg-check only >> b) to generate doctests and to test ALGLIB using doctests only >> c) to use BOTH spkg-check and doctests >> >> But what should I choose in this situation? > > Many packages are checked by both spkg-check and doctests. If you take a > package like R for instance, the spkg-check will run R's testsuite, whereas > the doctests will only confirm that R can be called from Sage - there is > very little actual testing done of R. And then there are other packages like pari where the sage doctests do way more testing than any existing upstream tests. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
