[Openmcl-devel] Erroneous results if function is untraced

Gary Byers gb at clozure.com
Wed Dec 31 02:26:34 UTC 2008



On Tue, 30 Dec 2008, Liam Healy wrote:

> (lisp-implementation-version)
> "Version 1.2-r10552  (LinuxX8664)"
>
> In testing my system GSLL, an interface to the GNU Scientific Library
> (GSL), I have found a few failures under CCL.  These tests will run
> correctly if the function is traced, or if the values are defined with
> a defparameter.  In this example, #(0 0 0 0) is the wrong answer, #(3
> 2 1 0) is the correct answer:
>
> Welcome to Clozure Common Lisp Version 1.2-r10552  (LinuxX8664)!
> ? (clc:clc-require :gsll-tests)
> T
> ? (in-package :gsl)
> #<Package "GSLL">
>
> ;; Call inside let, fails
> ? (let ((perm (make-permutation 4 T))) (permutation-reverse perm))
> #<PERMUTATION #(0 0 0 0)>
>
> ;; Trace the function and repeat, suceeds:
> ? (trace permutation-reverse)
> NIL
> ? (let ((perm (make-permutation 4 T))) (permutation-reverse perm))
> 0> Calling (PERMUTATION-REVERSE #<PERMUTATION #(0 1 2 3)>)
> <0 PERMUTATION-REVERSE returned #<PERMUTATION #(3 2 1 0)>
> #<PERMUTATION #(3 2 1 0)>
>
> ;; No tracing, use defparameter, succeeds:
> ? (defparameter *perm* (make-permutation 4 t))
> *PERM*
> ? *perm*
> #<PERMUTATION #(0 1 2 3)>
> ? (permutation-reverse *perm*)
> #<PERMUTATION #(3 2 1 0)>
>
> ;; Direct call fails:
> ? (permutation-reverse (make-permutation 4 t))
> #<PERMUTATION #(0 0 0 0)>
>
> ;; Tracing, direct call fails
> ? (permutation-reverse (make-permutation 4 t))
> 0> Calling (PERMUTATION-REVERSE #<PERMUTATION #(0 1 2 3)>)
> <0 PERMUTATION-REVERSE returned #<PERMUTATION #(3 2 1 0)>
> #<PERMUTATION #(3 2 1 0)>
>
> All the calls that exhibit the problem are FFI calls via CFFI.  For example,
> (DEFUN PERMUTATION-REVERSE (P)
>    (DECLARE)
>    "Reverse the order of the elements of the permutation p."
>    (LET NIL
>      (COPY-CL-TO-C P)
>      (LET ((#:CRETURN (FOREIGN-FUNCALL "gsl_permutation_reverse"
> :POINTER (MPOINTER P) :VOID)))
> 	(DECLARE (IGNORE #:CRETURN))
> 	(SETF (CL-INVALID P) T)
> 	(VALUES P))))
> (from a macro expansion)
>
> The repository web site for GSLL is http://repo.or.cz/w/gsll.git
>
> Is this a known problem?
>

I can't tell from the above what the problem is, so I don't
know whether you're seeing a symptom of a known problem or
something else.

What does COPY-CL-TO-C do ?  (A reasonable guess is that it copies
a CL object's contents to foreign memory somewhere/somehow, but
that's just a guess and it's not clear where that somewhere would
be.)

Likewise, what does MPOINTER do ?

There shouldn't be too much that TRACE does (except for some
extra printing and consing) that directly affects a function's
result.   Is there a PRINT-OBJECT method (or structure print-function)
defined on PERMUTATION ? If so, does that method have side-effects
that might interact with whatever it is that COPY-CL-TO-C and 
MPOINTER do ?


> Thanks,
> Liam
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>



More information about the Openmcl-devel mailing list