[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Thoughts on g-wrap, guile FFI and guile-gnome [was: 1.9.11 ffi reference

From: Andreas Rottmann
Subject: Thoughts on g-wrap, guile FFI and guile-gnome [was: 1.9.11 ffi reference bug]
Date: Sat, 21 Feb 2009 03:52:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux)

[ Sorry for the crossposting, but I think (a part of) the message is
  relevant for all mailing lists I'm sending this to ]

Greg Troxel <address@hidden> writes:

[ Regarding the need for a G-Wrap release, due to a bug ]

>   It is. I've a release tarball ready, will upload this weekend (along
>   with guile-gnome-platform packages for Debian).
> Great - glad you are still out there and g-wrapping.
Well, I'm still out there, but my involvment in G-Wrap has degraded into
maintainance mode; I'll probably not evolve the codebase
further. However, it seems that G-Wrap is kind of feature-complete as
far as guile-gnome is concerned -- an that's its only client ATM AFAIK,
as gnucash has transitioned to SWIG.

For a different, but related topic: I wonder how the advent of
gobject-introspection will influence the future of guile-gnome. With the
VM branch landing in Guile soonish (and hence improved performance), it
might make sense to provide a pure-Scheme FFI inside Guile core (perhaps
just molding the current G-Wrap runtime library into shape). Once you
have that, you can create bindings without the need for any "binding
generation" step, hence doing away (in principle) the need for G-Wrap

For an example how such an FFI would look like, take a look at the PLT

However, I like the Ikarus FFI better, which is more minimalist (and
more in line with both Scheme and UNIX philosophy, IMHO), see [2],
chapter 5.

Note however, that either FFI provides the primitives to emulate the
other (I've built a very Ikarus-like, portable FFI on PLT, Ikarus and
Ypsilon) [3]

Using such an FFI, it is possible to use the typelib data provided by
gobject-introspection to build bindings for e.g. GTK+ almost
automagically (nearly no customization needed for GObject-based APIs). I
have started an attempt to do so for R6RS Schemes (namely Ikarus, PLT
and Ypsilon) [0]. The amount of porting work to another (R6RS)
implementation that provides the necessary FFI building blocks is
trivial[1]. Code written towards the bindings created by this approach
completly portable.

Regards, Rotty

[0] See

[1] Namely errecting a thin portability layer upon the host
    implementations FFI. The code that does the actual work of handling
    the typelib data and creating the bindings is completely


[3] See,
    files foreign.sls and the compatibility layer inside the foreign/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]