[ 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 <g...@ir.bbn.com> 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 altogether. For an example how such an FFI would look like, take a look at the PLT FFI: http://docs.plt-scheme.org/foreign/index.html 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 http://live.gnome.org/sbank [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 implementation-independent. [2] http://bazaar.launchpad.net/%7Eaghuloum/ikarus/ikarus.dev/download/head%3A/ikarusschemeusersgui-20081023124504-qudot9ri5pcmiao8-1/ikarus-scheme-users-guide.pdf [3] See http://download.gna.org/spells/darcs/r6rs/spells/libraries/, files foreign.sls and the compatibility layer inside the foreign/ subdirectory.
