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

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

[Andreas Rottmann]

[ 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 <gdt@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.

Re: Thoughts on g-wrap, guile FFI and guile-gnome

[Andy Wingo]

Hello!

Your insights in reverse:

On Sat 21 Feb 2009 03:52, Andreas Rottmann <a.rottmann@gmx.at> writes:

> 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.

I completely agree, this makes sense, and we should do this at some
point this year.

> I wonder how the advent of gobject-introspection will influence the
> future of guile-gnome.

I want to switch to it. But this is like a 200 hour project, and with
less deployment than our existing solution. I don't anticipate working
on this in 2009.

Happy hacking,

Andy
-- 
http://wingolog.org/

Re: Thoughts on g-wrap, guile FFI and guile-gnome

[Andreas Rottmann]

Andy Wingo <wingo@pobox.com> writes:

> Hello!
>
> Your insights in reverse:
>
> On Sat 21 Feb 2009 03:52, Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> 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.
>
> I completely agree, this makes sense, and we should do this at some
> point this year.
>
It should be relatively straightforward, and I'm willing to help with
it.

>> I wonder how the advent of gobject-introspection will influence the
>> future of guile-gnome.
>
> I want to switch to it. But this is like a 200 hour project, and with
> less deployment than our existing solution. I don't anticipate working
> on this in 2009.
>
If Guile would support some releveant parts of R6RS, lets say, by the
end of this year, perhaps sbank could be dropped in, and *voila* you'd
have gobject-introspection support :-) (although I admit that this has a
definitly utopian flair). Of course, there would be have to be some kind
of compat layer that provides the GOOPSy interface that Guile-GNOME
provides on top of the sbank substrate (which maps GObject to a much
simpler objects system, which is implementated in just a few pages of
code [0]).

To get more realistic: it might be the case that sbank's design is not
well suited to the way Guile works; a few notable points about it:

* There's absolutely no C code involved, which means it demands decent
  speed from the implementation's FFI (mostly the part that deals with
  access to C-managed memory). This (no C code, and a not-unreasonable
  speed) is accomplished by circumventing (mostly) the "girepository"
  library, which, for the most part, just makes the raw typelib binary
  data available via C "accessor" functions. If you have to go through
  the FFI layer's function call mechanism for each bit of info in the
  typelib, it's going to be expensive soon. So I've decided not to wrap
  libgirepository, but deal with the typelib data myself.

  The more "traditional" approach (taken by all other
  gobject-introspection bindings I know about), is to use wrap some C
  code around libgirepository, which builds up the procedures, classes,
  etc. for the high-level language, from C.

* Its code uses syntax-case (as specified in R6RS) in quite a few
  places. I hope that Guile's macro problems (which currently interact
  horribly with modules) will be resolved at some point, and that it
  will gain full syntax-case support. Can anybody hint at if/when/how
  that will happen?

[0]
    http://download.gna.org/spells/darcs/r6rs/sbank/gobject/internals.sls
    (mostly the code around send-message)

Regards, Rotty

Re: Thoughts on g-wrap, guile FFI and guile-gnome

[Neil Jerram]

Andreas Rottmann <a.rottmann@gmx.at> writes:

> * Its code uses syntax-case (as specified in R6RS) in quite a few
>   places. I hope that Guile's macro problems (which currently interact
>   horribly with modules) will be resolved at some point, and that it
>   will gain full syntax-case support. Can anybody hint at if/when/how
>   that will happen?

Assuming you mean https://savannah.gnu.org/bugs/?20941 - I hope to get
to this sometime soon.

   Neil