[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