[Gsll-devel] status.text & clisp

[Liam Healy]

Hi Sam,

On Wed, Jul 28, 2010 at 3:04 PM, Sam Steingold <sds at 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 at 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