Andy Wingo wi...@pobox.com writes:
Hello!
Your insights in reverse:
On Sat 21 Feb 2009 03:52, Andreas Rottmann a.rottm...@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
