Re: [Chicken-users] A more detailed plea for help with FFI...

[felix winkelmann]

On Wed, 15 Dec 2004 08:11:13 -0500, Ed Watkeys <address@hidden> wrote:
> 
> 17.8 Unsupported features and known problems
>         *       No exception handling.
>         *       No director support.
>         *       No support for c++ standard types like std::vector.
>         *       No support for automatic garbage collection of wrapped 
> classes and
> structures. (Planned on adding in SWIG version 1.3.25)
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         *       Importing multiple SWIG modules not working with TinyCLOS. 
> (Planned
>   on fixing for 1.3.25)
>         *       Problems with complicated function overloading. (Planned on 
> fixing
> for 1.3.25)
> 
> This is not acceptable to me: I do not want resource management to be
> the responsibility of my users i.e. Scheme programmers. I don't know
> when 1.3.25 is coming out and if these fixes are still planned to be in
> it. That said, I'm going to play with SWIG a bit and see how well it
> works.
> 
> For what I'm working on -- a wrapper for Core Graphics under OS X, it
> would definitely be nice to be to be able to use the same code to
> general libraries for Python, Perl, Tcl, Scheme, etc.
> 
> (I know, there's already a wrapper for Python, but Apple hasn't
> released the module definition. And I'd like an interface that is
> pretty much an exact translation of the Core Graphics API, so I can
> read Apple's documentation, mentally translate
> "CGBitmapContextAddLines" to "cg-bitmap-context:add-lines" and write
> working Scheme code. Apple's Core Graphics library for Python is
> different -- and incomplete -- enough to drive you crazy looking for
> functions that may or may not exist.)

Well, sometimes handling memory allocation (or better resource-
management) manually is not as bad as it sounds. The problems here
are that finalizers can run at relatively unpredictable times: especially
when foreign data is finalized, one has to be absolutely sure that the
resource isn't currently in use (in foreign land). Some go even so far
and say that finalization without running it in a separate thread is
inherently unsafe (There is some paper by Hans Boehm about this).
Also, when wrapping libraries that do memory management manually,
and which are designed around manual and controlled de-allocation,
simple bolting a finalizer on the side might not always be the optimal
solution. 
Personally, I try to avoid finalizers, unless there is really no other way
of doing things.


cheers,
felix