Hi Sam,
On Wed, Jul 28, 2010 at 3:04 PM, Sam Steingold sds@gnu.org wrote:
Hi, status.text still needs updating:
CLISP 2.49 on x86_64 (64-bit build): TOTAL: 1350 assertions passed, 21 failed, 13 execution errors. which I don't know how to reproduce), but I would appreciate bug reports.
OK, thanks for the information. I think I'm going to shy away from giving test totals for all combinations of platforms/implementations in status.text (or anywhere else) because it changes constantly and is therefore a PITA to maintain even for one platform and implementation. However, the information is useful; I of course would like to see all failures/execution errors down to zero.
Are you using an old GSLL? There should be ~4000 tests now.
I don't know what "execution errors" are (probably things like FUNCALL: undefined function NIL
Yes, stuff like that. I noticed similar errors when I last tested on CLISP. At some point I'll try a new CLISP build and see if it's possible to knock these down a bit. I recommend the following technique for debugging when you see e.g. test FOO failing,
(lisp-unit:use-debugger) ; once only, will give you debugger on error (lisp-unit:run-test foo)
should allow better debugging.
As a side comment, I find lisp-unit's reporting of execution errors to be too subtle; I consider them to be a bigger problem than "failures" yet the erroneous test is merely indented two spaces on the printout, and therefore hard to see. Though I have commit rights to the lisp-unit repo, I haven't had the time/energy to try to fix this.
Some assertion errors should probably not be there: Expected (0.9999999999999997d0 2.0d0 30.0d0) but saw (0.9999999999999999d0 2.0d0 30.0d0) (also, it would be nice to align the expected and actual output).
Yeah, these are all my old-bad tests, incrementally being replaced with GSL's own tests. The virtue of the latter is that, not only do they comprehensively cover all the functions, they also come with specified and independently determined epsilons, so errors like what you see should disappear. But as I said in a previous email, it's tedious and thankless to port tests, so happens quite slowly (on a time scale of months and years, frankly). Contributions welcome :-).
thanks. Sam.
On 8/19/09, Sam Steingold sds@gnu.org wrote:
Hi,
http://common-lisp.net/project/gsll/status.text says:
64-bit CLISP: not tested; bug in CLISP causes crash on loading
I will get a new CLISP going and test again at some point.
I do not have this problem with 64-bit clisp: TOTAL: 1345 assertions passed, 26 failed, 13 execution errors. (BTW, how do I debug those 13 errors? i.e., how do I list them, rerun them, see the code which triggered them?)
See above on debugging ideas.
also, status.text says
CHEBYSHEV: Should have signalled TYPE-ERROR but saw #<SIMPLE-ERROR #x20EB4F1E>
- how do I reproduce that?
See above.
FFI::FOREIGN-CALL-OUT: 3.1415926535897932385L0 cannot be converted to the foreign type DOUBLE-FLOAT
- pi is a long float, you have to convert it to a double explicitly, like (float pi 0d0).
I think this should be fixed for CLISP now.
thanks.
Thanks for the report.
-- Sam Steingold http://sds.podval.org
Liam