Re: GSoC 2011

[Andreas Rottmann]

"Diogo F. S. Ramos" <address@hidden> writes:

> Noah Lavine <address@hidden> writes:
>
>>> I've started trying to port librepository to guile from the ground up,
>>> using just C. While doing so people at #introspection point me to the
>>> great port of zeenix (guile-gir), as yourself.
>>
>> What does librepository do?
>
> Sorry, the correct name is 'libgirepository'.
>
> The library reads typelib files, which describes gobjects, and offers an
> API to the user, so one doesn't need to create a parser.
>
Yep.  This is the recommended (at least by upstream) way to access
.typelib files.  However, for sbank I decided not make use of its
parser.  In the following, I'd like to outline some of the fundamental
design decisions in sbank in the hope that this information is useful
for work on object-introspection bindings for Guile.

- sbank is pure Scheme code.  This means I can use only the
  implementation's dynamic FFI, and can not rely on C glue code.  This
  has the advantage of greatly improving portability between
  implementations.  sbank makes use of a small FFI abstraction in the
  `(spells foreign)' library, and does not contain any
  implementation-specific code at all.  Portability across
  implementations is obviously not a concern for a Guile-specific
  binding, but if it is decided that the binding should make use of the
  dynamic FFI (only), I think the following points are valid for a
  Guile-specific implementation as well.

- Using a dynamic FFI to access libgirepository's parser would have
  entailed replicating its API on the Scheme.  At that point, my
  intuition was that doing the parsing in Scheme would be of similiar
  complexity, and can even be done in a more easily automatable manner
  (see below).  Another upside is that you don't have to use
  (potentially relatively costly) FFI calls to access every single bit
  of information in the typelib; that information is *already* available
  in RAM, you just need to be able to make sense of it.

- To get the information about memory layout of the typelib data, sbank
  employs a script that uses gobject-introspection's tools
  (g-ir-scanner) to get an XML description (in GIR format) of
  gtypelib-internal.h (thus it doesn't need to do any C header parsing
  itself).  That XML is the converted to an S-expression based format
  containing the relevant information (data/typelib.scm).  At
  macro-expansion time, this information is used to generate accessors
  for the typelib data available in memory.  

  The only downside of this approach that I can see is that sbank does
  not rely on libgirepository's ABI, but on the typelib format, and
  needs to be updated (regenerating data/typelib.scm) if that format
  changes.  However, it seems that this format has stabilized pretty
  much; the last change to gitypelib-internal.h has been in October
  2010, and it was backward-compatible.  There's much incentive to only
  make backward-compatible changes as changing the format incompatibly
  requires rebuilding of all typelibs, involving a multitude of source
  packages (GTK+, libsoup, ... -- everything that ships with
  gobject-introspection support).

FWIW, I'm slowly working on porting `(spells foreign)' to Guile, which
should make sbank run out-of-the box.  That will be a good stress test
on Guile's dynamic FFI, besides offering an alternative to guile-gnome.

If there emerges a Guile-specific gobject-introspection binding project,
it would IMHO make sense (if it's a pure Scheme project) to reuse some
of sbank's infrastructure, specifically the typelib accessor stuff.
Additionally, it would be nice to cooperate on offering a compatible
Scheme API; you can find some information on the Scheme<->C mapping used
in sbank in its tutorial [0].  Of course, a Guile-specific project will
also want to offer some compatibility with guile-gnome, but I don't
think these goals do necessarily conflict.

[0] http://rotty.yi.org/software/sbank/tutorial.html

>> According to some Gnome webpage Google found, GLib introspection is
>> intended to make it easy to wrap GObject objects in higher-level
>> languages. If I understand correctly, you wish to do this for Guile?
>> That sounds like a good thing to do, if so.
>
> It is the trend that I'm seeing at the GObject based world with the
> Gnome 3.0 release.
>
> Apparently it is possible to drop whole bindings with it [0], leaving
> less code to maintain and debug.
>
> [0] 
> http://www.johnstowers.co.nz/blog/index.php/2011/04/03/end-of-an-era-pygtk/
>
Indeed, that's the major advantage of gobject-introspection; quoting
from sbank's tutorial:

  To stress that: if a C library provides gobject-introspection
  metadata, you should be able to use it via sbank without further ado.

  However, while the metadata provided in the .typelib file is complete
  enough to yield good and "schemely" bindings, there might still be
  some corners in the API that profit from some glossing over, and sbank
  provides such glossing where and when such cases are identified.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>