[plt-scheme] Re: image manipulation

On Mar 25, 2004, at 11:29 AM, Scott Owens wrote:

>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> The SRFI 4 implementation is actually based on an older version of the 
> SGL implementation.  However, I can't think of a sensible way to unify 
> them.  The SGL vectors have to be based on the GL typedefs such as 
> GLint, GLushort and so on.  The size of these types may vary between 
> different GL implementations, but SGL code should not have to worry 
> about it.  On the other hand, SRFI 4 arrays have to deal with specific 
> sizes to meet the specification.
>
> So what would unifying them mean?  From a PLT maintainer's 
> perspective, it would be nice if they shared the same back-end C code. 
>  But at the Scheme level, there is a need for the different interfaces 
> they provide.

Just to take this to its logical end: one way to unify them would be to 
have the scheme code for sgl "aware of" what underlying representations 
the gl C code uses for its named types.  Then, the Scheme code could 
use SRFI 4 vectors as inputs to and outputs from the sgl library.

This has one benefit--less duplicated C code--but two problems:

1) To make the scheme code "aware of" the representation mappings 
involves either parsing GL header files or duplicating this information 
manually.
2) Scheme code that wanted to use the GL library portably would then 
_also_ have to be "aware of" these mappings.  Bleah!

To summarize, I agree with Scott's assessment that this would be a bad 
idea.

In fact, what we _really_ need is a nice FFI-builder.  The SRFI-4 C 
code would then presumably be generated automatically from an interface 
specification.

john



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2379 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20040325/6b7b93ff/attachment.p7s>