"Diogo F. S. Ramos" <diogo...@gmail.com> writes: > Noah Lavine <noah.b.lav...@gmail.com> 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/>