[plt-scheme] Re: image manipulation

From: Eli Barzilay (eli at barzilay.org)
Date: Thu Mar 25 13:04:01 EST 2004

On Mar 25, John Kozak wrote:
> 
> > FWIW, SRFI 4 provides unboxed arrays of numbers, including 32-bit
> > & 64-bit floating point representations.
> 
> To sneak in a pet moan of mine, the sgl collect has its own,
> parallel implementation of this - it would be nice if they got
> unified.

And to sneak in a semi-dead pet of mine, I worked on an FFI interface,
and part of that is allowing sort-of-free access to C-level stuff,
which means that it's some form of superset of the mentioned
functionality of srfi/4 and sgl.  (Not a complete superset because
you're completely unprotected, so you can malloc a C vector of 10
integer, then reference th 20th float of that pointer...)

This works like charm on Linux, and should probably have no problems
running on Windows and OSX -- but I used ffcall to interface functions
and callbacks.  The problem with that, which is why the thing is
semi-dead, is a license problem -- ffcall is GPL, so it cannot be used
as an integral part of MzScheme.  Sad.  There's probably a good amount
of C glue that would not be needed of this thing would work.  (If
anyone has any ideas, email me.)


On Mar 25, John Clements wrote:
> 
> To be more concrete: the C code for the GL library uses the name
> gl_foobar_number, say, to refer to a 64-bit float on some platforms
> and a 128-bit float on other platforms.

I believe that the srfi/4 approach is better, since it puts more
weight on the Scheme -- to make this work with the opengl binding,
something like Joe's parser for C header files could be used so the
opengl code knows what C types to use...

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!


Posted on the users mailing list.