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