[Openmcl-devel] Erroneous results if function is untraced

[Gary Byers]

On Tue, 30 Dec 2008, Liam Healy wrote:

>
> Since I'm calling foreign functions with arrays, I need to copy them
> over.  You are right about COPY-CL-TO-C, it copies the contents of the
> CL array over to the C side, then MPOINTER returns a pointer to the C
> structure that holds the array for the foreign function to use.
> There is in fact a print-object method defined, and I thought that
> might be the key because it has potential side effects, but it doesn't
> make any difference if I print the object with tracing off,
>
>  (untrace)
> NIL
> ? (let ((perm (make-permutation 4 T))) (permutation-reverse perm))
> #<PERMUTATION #(0 0 0 0)>
> ? (let ((perm (make-permutation 4 T))) (print (permutation-reverse perm)))
>
> #<PERMUTATION #(0 0 0 0)>
> #<PERMUTATION #(0 0 0 0)>

Those 0s are clearly in the same order that they were in before the
call to PERMUTATION-REVERSE.  No, wait ... maybe they've been reversed.
I confess that I can't tell ...

So, a PERMUTATION object has at least three attributes a CL array, a
foreign pointer, and a flag indicating whether or not the CL array is
in synch with the foreign pointer.  PERMUTATION-REVERSE copies the CL
array to the foreign pointer, does a foreign function call that reverses
the foreign pointers elements, and sets the flag indicating that the CL
array is out-of-date.

Is one of the side-effects of the PRINT-OBJECT method to ensure that
the CL array is back in synch with the foreign pointer (by copying
the foreign pointer's contents back to the CL array and clearing the
flag, if the flag was set ?)  If so, are these side-effects always
performed by the PRINT-OBJECT method, or does this happen conditionally
(under control of some printer-control variables, perhaps) ?

Presumably, part of generating the correct answer involves copying
from the foreign pointer back to the CL array at some point.   Again,
I can't think of anything that TRACE would do that would affect this
other than calling the PRINT-OBJECT method, so it would seem that
you're either seeing an unexpected interaction between that method
and other code that causes the correct answer to be generated when
it wouldn't be otherwise, or ... well, I don't know what else you'd
be seeing; I'd be more inclined to believe that some things don't
work when traced (because, e.g., they're tail-recursive and run
out of stack space when TRACE defeats tail-call optimization) than
I would to believe that "not tracing causes correct code to misbehave."


>
> Thanks.
>
> Liam
>
>