[gambit-list] passing an f64vector

Marc Feeley feeley at iro.umontreal.ca
Sun Mar 22 21:00:48 EDT 2009


On 22-Mar-09, at 1:21 PM, Eduardo Cavazos wrote:

> Hello,
>
> The type of the second parameter of gl function glGetDoublev is
> GLdouble*. So, I'd like to be able to pass an f64vector as that  
> argument.
>
> The declaration of glGetDoublev is:
>
>     void glGetDoublev( GLenum pname, GLdouble *params )
>
> So something along these lines I guess:
>
> (define glGetDoublev
>   (c-lambda (GLenum scheme-object)
>             void
>             " glGetDoublev ( ___arg1 , UNPACKTHEVEC( ___arg2 ) ) ; "))
>
> Except with the proper unpacking of ___arg2. Any suggestions as to  
> what
> macro to use there? I'm looking through gambit.h...

There is no builtin Scheme to C converter for homogeneous vectors  
(u8vector, f64vector, ...).  A converter for these types is  
conceivable but a couple of issues makes it non-trivial:

1) A Scheme vector has a length, and often the length of the vector  
may vary from one call to another (i.e. the length is a dynamic  
property).  How is the length of the vector passed to C?  When a C  
array is passed to Scheme, how does the converter determine how long  
the array is?

2) To avoid GC problems (and in keeping with the other Scheme to C  
converters) a copy of the vector would have to be made in a C array.   
Unfortunately, for some functionality, the extra cost of doing the  
copy may cancel the benefit of performing the computation in C.

3) Sometimes the vector is supposed to be mutated by the C function,  
and the result of the mutations must be available to the Scheme code.   
If the vector is copied the C function's mutations aren't preserved.

I have given some thought about various solutions to these problems,  
but nothing definite yet.

In the meantime you can use the ___BODY(vect) macro in your code, it  
returns a pointer to the first element of the vector:

(define glGetDoublev
   (c-lambda (GLenum scheme-object)
             void
             " glGetDoublev ( ___arg1 ,  
___CAST(___F64*,___BODY(___arg2)) ); "))

But beware... this assumes that the GC doesn't get invoked during the  
call glGetDoublev (because a GC might move the vector).  Even if the  
GC isn't called explicitly, it is conceivable a GC could be invoked  
asynchronously in a (real) multithreaded implementation of Gambit  
(impossible in the current runtime system, but who knows... maybe a  
multithreaded GC will be added in the future).

Marc




More information about the Gambit-list mailing list