Hi, status.text still needs updating:
CLISP 2.49 on x86_64 (64-bit build): TOTAL: 1350 assertions passed, 21 failed, 13 execution errors.
I don't know what "execution errors" are (probably things like FUNCALL: undefined function NIL which I don't know how to reproduce), but I would appreciate bug reports.
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).
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 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?)
also, status.text says
CHEBYSHEV: Should have signalled TYPE-ERROR but saw #<SIMPLE-ERROR #x20EB4F1E>
- how do I reproduce that?
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).
thanks.
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
Hi Liam,
On 8/7/10, Liam Healy lhealy@common-lisp.net wrote:
Are you using an old GSLL? There should be ~4000 tests now.
it should be relatively recent. I can no longer update because I have modified files and I don't know what to do next. $ git pull Updating 7591d6d..7aa0111 calculus/monte-carlo.lisp: needs update histogram/ntuple-example.dat: needs update error: Entry 'calculus/monte-carlo.lisp' not uptodate. Cannot merge.
what is the git analogue of "cvs up -C" or "hg revert"? i.e., how do I remove all my local changes?
If you did not commit your changes and you wish to remove them
git reset --hard
If you want to save/restore them on top of the new version,
git stash git pull git stash pop
It could be that the missing tests are all in those execution errors; if one of the forms in a test gets an execution error, I think none are counted in the passes. So that may be where most of the 4000 tests went.
Liam
On Mon, Aug 9, 2010 at 1:12 PM, Sam Steingold sds@gnu.org wrote:
Hi Liam,
On 8/7/10, Liam Healy lhealy@common-lisp.net wrote:
Are you using an old GSLL? There should be ~4000 tests now.
it should be relatively recent. I can no longer update because I have modified files and I don't know what to do next. $ git pull Updating 7591d6d..7aa0111 calculus/monte-carlo.lisp: needs update histogram/ntuple-example.dat: needs update error: Entry 'calculus/monte-carlo.lisp' not uptodate. Cannot merge.
what is the git analogue of "cvs up -C" or "hg revert"? i.e., how do I remove all my local changes?
-- Sam Steingold http://sds.podval.org
Hi Liam,
On 8/7/10, Liam Healy lhealy@common-lisp.net wrote:
On Wed, Jul 28, 2010 at 3:04 PM, Sam Steingold sds@gnu.org wrote:
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)
MATRIX-PRODUCT: FUNCALL: undefined function NIL MATRIX-PRODUCT-HERMITIAN: FUNCALL: undefined function NIL MATRIX-PRODUCT-NONSQUARE: FUNCALL: undefined function NIL MATRIX-PRODUCT-TRIANGULAR: FUNCALL: undefined function NIL MATRIX-SET-ALL: FUNCALL: undefined function NIL SCALE: FUNCALL: undefined function NIL TDIST: FFI::FOREIGN-CALL-OUT: floating point overflow VECTOR-SET-ALL: FUNCALL: undefined function NIL TOTAL: 3501 assertions passed, 15 failed, 14 execution errors.
1. VECTOR-SET-ALL: FUNCALL: undefined function NIL
*** - FUNCALL: undefined function NIL Break 1 GSL[3]> :w [197] EVAL frame for form (SET-ALL V1 #C(-34.5 8.24)) Break 1 GSL[3]> :bt <13/200> #<COMPILED-FUNCTION #:|49 60 (DEFMFUN SET-ALL (# VALUE) ...)-4-1-3|> <14/200> #<STANDARD-GENERIC-FUNCTION SET-ALL> [197] EVAL frame for form (SET-ALL V1 #C(-34.5 8.24)) Break 1 GSL[3]> v1 #4m(#C(0.0 0.0) #C(0.0 0.0) #C(0.0 0.0)) Break 1 GSL[3]> (type-of *) GRID:VECTOR-COMPLEX-SINGLE-FLOAT
(disassemble (slot-value (nth 20 (CLOS:GENERIC-FUNCTION-METHODS #'SET-ALL)) 'CLOS::$FAST-FUNCTION))
Disassembly of function #:|49 60 (DEFMFUN SET-ALL (# VALUE) ...)-4-1-4| (CONST 0) = #:|gsl_vector_complex_set_all| (CONST 1) = FOREIGN-STRUCTURES-BY-VALUE::PREPARED (CONST 2) = MPOINTER 2 required arguments 0 optional arguments No rest parameter No keyword parameters 10 byte-code instructions: 0 (CONST&PUSH 0) ; #:|gsl_vector_complex_set_all| 1 (CONST&PUSH 1) ; FOREIGN-STRUCTURES-BY-VALUE::PREPARED 2 (PUSH-UNBOUND 1) 4 (CALLS2&PUSH 158) ; GET 6 (LOAD&PUSH 3) 7 (CALL1&PUSH 2) ; MPOINTER 9 (LOAD&PUSH 3) 10 (FUNCALL 2) 12 (LOAD 2) 13 (SKIP&RET 3) NIL
(symbol-plist (sys::closure-const (slot-value (nth 20 (CLOS:GENERIC-FUNCTION-METHODS #'SET-ALL)) 'CLOS::$FAST-FUNCTION) 0)) NIL
i.e., the method FUNCALLs the property of the uninterned symbol which is NIL.
(dolist (m (CLOS:GENERIC-FUNCTION-METHODS #'SET-ALL)) (let ((c (sys::closure-consts (slot-value m 'CLOS::$FAST-FUNCTION)))) (unless (symbol-package (car c)) (print (list m c)))))
(#<STANDARD-METHOD (#<STANDARD-CLASS GRID:MATRIX-COMPLEX-DOUBLE-FLOAT> #<BUILT-IN-CLASS T>)> (#:|gsl_matrix_complex_set_all| FOREIGN-STRUCTURES-BY-VALUE::PREPARED MPOINTER)) (#<STANDARD-METHOD (#<STANDARD-CLASS GRID:MATRIX-COMPLEX-SINGLE-FLOAT> #<BUILT-IN-CLASS T>)> (#:|gsl_matrix_complex_float_set_all| FOREIGN-STRUCTURES-BY-VALUE::PREPARED MPOINTER)) (#<STANDARD-METHOD (#<STANDARD-CLASS GRID:VECTOR-COMPLEX-DOUBLE-FLOAT> #<BUILT-IN-CLASS T>)> (#:|gsl_vector_complex_set_all| FOREIGN-STRUCTURES-BY-VALUE::PREPARED MPOINTER)) (#<STANDARD-METHOD (#<STANDARD-CLASS GRID:VECTOR-COMPLEX-SINGLE-FLOAT> #<BUILT-IN-CLASS T>)> (#:|gsl_vector_complex_float_set_all| FOREIGN-STRUCTURES-BY-VALUE::PREPARED MPOINTER))
i.e., the complex vectors and matrices do not work.
why?
2. MATRIX-SET-ALL same story [399] EVAL frame for form (SET-ALL M1 #C(-34.5 8.24)) Break 2 GSL[4]> (type-of m1) GRID:MATRIX-COMPLEX-SINGLE-FLOAT
3. matrix-product: (disassemble (slot-value (first (CLOS:GENERIC-FUNCTION-METHODS #'matrix-product)) 'CLOS::$FAST-FUNCTION)) Disassembly of function #:|32 53 (DEFMFUN MATRIX-PRODUCT (# # &OPTIONAL ...) ...)-3-4-1-1| ==> (funcall (get '#:|gsl_blas_zgemm| 'FOREIGN-STRUCTURES-BY-VALUE::PREPARED))
4. (lisp-unit:run-tests scale) SCALE: FUNCALL: undefined function NIL
*** - FUNCALL: undefined function NIL Break 4 GSL[7]> :w [825] EVAL frame for form (SCALE SCALAR V1) Break 4 GSL[7]> scalar #C(32.5 42.73) Break 4 GSL[7]> v1 #4m(#C(-34.5 8.24) #C(3.29 -8.93) #C(34.12 -6.15) #C(49.27 -13.49) #C(32.5 42.73) #C(-17.24 43.31) #C(-16.12 -8.25) #C(21.44 -49.08)) Break 4 GSL[7]> (type-of *) GRID:VECTOR-COMPLEX-SINGLE-FLOAT Break 4 GSL[7]> (describe #'scale)
#<STANDARD-GENERIC-FUNCTION SCALE> is a generic function. Argument list: (ALPHA X) Methods: (FLOAT GRID:VECTOR-COMPLEX-DOUBLE-FLOAT) (FLOAT GRID:VECTOR-COMPLEX-SINGLE-FLOAT) (COMPLEX GRID:VECTOR-COMPLEX-DOUBLE-FLOAT) (COMPLEX GRID:VECTOR-COMPLEX-SINGLE-FLOAT) (FLOAT GRID:VECTOR-DOUBLE-FLOAT) (FLOAT GRID:VECTOR-SINGLE-FLOAT)
Break 4 GSL[7]> (disassemble (slot-value (third (CLOS:GENERIC-FUNCTION-METHODS #'scale)) 'CLOS::$FAST-FUNCTION))
Disassembly of function #:|127 138 (DEFMFUN SCALE (# #) ...)-11-1-4| (CONST 0) = #:|gsl_blas_zscal| (CONST 1) = FOREIGN-STRUCTURES-BY-VALUE::PREPARED (CONST 2) = MPOINTER 2 required arguments 0 optional arguments No rest parameter No keyword parameters 10 byte-code instructions: 0 (CONST&PUSH 0) ; #:|gsl_blas_zscal| 1 (CONST&PUSH 1) ; FOREIGN-STRUCTURES-BY-VALUE::PREPARED 2 (PUSH-UNBOUND 1) 4 (CALLS2&PUSH 158) ; GET 6 (LOAD&PUSH 3) 7 (LOAD&PUSH 3) 8 (CALL1&PUSH 2) ; MPOINTER 10 (FUNCALL 2) 12 (LOAD 1) 13 (SKIP&RET 3) NIL Break 4 GSL[7]>
i.e., again (funcall (get '#:|gsl_blas_zscal| 'FOREIGN-STRUCTURES-BY-VALUE::PREPARED)...)
5. (lisp-unit:run-tests tdist) TDIST: FFI::FOREIGN-CALL-OUT: floating point overflow
*** - FFI::FOREIGN-CALL-OUT: floating point overflow Break 5 GSL[8]> :w [1019] EVAL frame for form (TDIST-PINV 1.0d0 300.0d0) Break 5 GSL[8]> (describe #'TDIST-PINV)
#<COMPILED-FUNCTION TDIST-PINV> is a compiled function. Argument list: (P NU) Documentation: The inverse cumulative distribution functions P(x) for the tdist distribution with nu degrees of freedom. For more information, evaluate (DISASSEMBLE #'TDIST-PINV).
Break 5 GSL[8]> (DISASSEMBLE #'TDIST-PINV)
Disassembly of function TDIST-PINV (CONST 0) = #<FOREIGN-FUNCTION "gsl_cdf_tdist_Pinv" #x00002B6F431FECC0> 2 required arguments 0 optional arguments No rest parameter No keyword parameters 6 byte-code instructions: 0 (CONST&PUSH 0) ; # 1 (LOAD&PUSH 3) 2 (LOAD&PUSH 3) 3 (FUNCALL 2) 5 (VALUES1) 6 (SKIP&RET 3) NIL
running under gdb indicates that the machine double being converted to lisp is an "inf", so the overflow is expected...
Hi Sam,
Just focusing in on one class of errors, vector-set-all on complex vectors:
On Tue, Aug 10, 2010 at 1:36 PM, Sam Steingold sds@gnu.org wrote:
(symbol-plist (sys::closure-const (slot-value (nth 20 (CLOS:GENERIC-FUNCTION-METHODS #'SET-ALL)) 'CLOS::$FAST-FUNCTION) 0)) NIL
i.e., the method FUNCALLs the property of the uninterned symbol which is NIL.
If I make a small modification to GSLL (attached) so that function names like #:|gsl_vector_complex_float_set_all| are instead interned, e.g. '|gsl_vector_complex_float_set_all|, then I get all tests to pass in my (old) version of CLISP: (lisp-unit:run-tests vector-set-all) VECTOR-SET-ALL: 12 assertions passed, 0 failed.
Now it seems to me that what FSBV is doing with symbols (set/get properties) should work equally well on uninterned or interned symbols, so the original should work fine. Is that correct? Why does CLISP lose the property list binding when the symbol is uninterned?
Liam
Hi Liam,
On 8/10/10, Liam Healy lhealy@common-lisp.net wrote:
On Tue, Aug 10, 2010 at 1:36 PM, Sam Steingold sds@gnu.org wrote:
(symbol-plist (sys::closure-const (slot-value (nth 20 (CLOS:GENERIC-FUNCTION-METHODS #'SET-ALL)) 'CLOS::$FAST-FUNCTION) 0)) NIL
i.e., the method FUNCALLs the property of the uninterned symbol which is NIL.
If I make a small modification to GSLL (attached) so that function names like #:|gsl_vector_complex_float_set_all| are instead interned, e.g. '|gsl_vector_complex_float_set_all|, then I get all tests to pass in my (old) version of CLISP: (lisp-unit:run-tests vector-set-all) VECTOR-SET-ALL: 12 assertions passed, 0 failed.
Now it seems to me that what FSBV is doing with symbols (set/get properties) should work equally well on uninterned or interned symbols, so the original should work fine. Is that correct? Why does CLISP lose the property list binding when the symbol is uninterned?
because it is not the same symbol. :-( this is a very old bug: https://sourceforge.net/tracker/?func=detail&aid=836838&group_id=135... the workaround is to use `let' or `locally' instead of `progn',
On Tue, Aug 10, 2010 at 11:48 PM, Sam Steingold sds@gnu.org wrote:
Hi Liam,
On 8/10/10, Liam Healy lhealy@common-lisp.net wrote:
On Tue, Aug 10, 2010 at 1:36 PM, Sam Steingold sds@gnu.org wrote: > (symbol-plist (sys::closure-const (slot-value (nth 20 > (CLOS:GENERIC-FUNCTION-METHODS #'SET-ALL)) 'CLOS::$FAST-FUNCTION) 0)) > NIL > > i.e., the method FUNCALLs the property of the uninterned symbol which is NIL.
If I make a small modification to GSLL (attached) so that function names like #:|gsl_vector_complex_float_set_all| are instead interned, e.g. '|gsl_vector_complex_float_set_all|, then I get all tests to pass in my (old) version of CLISP: (lisp-unit:run-tests vector-set-all) VECTOR-SET-ALL: 12 assertions passed, 0 failed.
Now it seems to me that what FSBV is doing with symbols (set/get properties) should work equally well on uninterned or interned symbols, so the original should work fine. Is that correct? Why does CLISP lose the property list binding when the symbol is uninterned?
because it is not the same symbol. :-( this is a very old bug: https://sourceforge.net/tracker/?func=detail&aid=836838&group_id=135... the workaround is to use `let' or `locally' instead of `progn',
Wow, "very old", you're not kidding; it was old already in 2003. I guess that one has tenure now, so I've changed the definition in GSLL to use let.
I can't get the new CLISP to build as it doesn't see libsigsegv and libreadline are there no matter what I try. So on my old Debian stable CLISP 2.44.1, I can run the individual tests vector-set-all and matrix-set-all, but I can't run the comprehensive test suite as it crashes out of CLISP a few tests in.
Liam
-
Liam Healy -
Sam Steingold