[gambit-list] passing an f64vector
Eduardo Cavazos
wayo.cavazos at gmail.com
Mon Mar 23 08:14:48 EDT 2009
Eduardo Cavazos wrote:
>> 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...
Marc Feeley wrote:
> 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).
Thanks for the help Marc; it worked perfectly.
One of my stress tests for Scheme/OpenGL is an implementation of
ContextFreeArt. A few moments ago Gambit completed it's first rendering:
http://proteus.freeshell.org/spirales-gambit-2009-03-23.png
I'm having a good time with Gambit! Very interesting system.
Ed
More information about the Gambit-list
mailing list