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.
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.
Dave
--
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
