Re: Taking the defs file issue

[Marius Vollmer <mvo@zagadka.ping.de>]

Rob Browning <rlb@cs.utexas.edu> writes:

> This is because in general, I tend to favor this approach to one
> that tries to hide the allocation semantics.  Like it or not, when
> you're wrapping a C API, I think you generally *do* have to know
> (and care) about the allocation semantics, and I tend to feel that
> trying to automate them too much (beyond the "'cleanup 'no-cleanup"
> stuff we already have in g-wrap) is just going to hurt more than
> help.

I quite strongly disagree with this.  In my view, the functions
exported to the Scheme side must not be not be `dangerous' in the
sense that a pilot error can not lead to memory corruption, memory
leaks or similar.

This goal might not be always possible to reach, but one should try
very hard before giving up.  I would even go so far as to require that
the C API be changed so that it can be safely wrapped.  (I did this
with Gtk+, incidentally.)

Guile-gtk is not just the automatic generation of glue code.  This is
actually the easy part.  The hard part is to know what code to
generate and how to make sure that it behaves in a sane way.

[ When I say that generating glue is easy I only meant that in the
  context of guile-gtk.  Designing something more ambitious like
  g-wrap is quite challenging. ]

For example, when you have a pointer-token object in Scheme land, how
do you make sure that the pointer in the token stays valid as long as
it can be used from Scheme?  If you can't guarantee this, you should
not export the pointer to Scheme at all.  It must not be possible to
use a invalid pointer-token in Scheme code, even in buggy Scheme code.
A bug in Scheme should never have uncontrollable consequences like
memory corruption.

Taking you GtkWindow* example, how to you propose to handle the
life-time of GtkWindow structures?  Do you also export gtk_object_ref
and gtk_object_unref to Scheme and expect Scheme programmers to use
them?  I don't think that this would be very welcome.

Anyway, the guts and most of the smarts of guile-gtk are actually in
guile-gtk.c (and in Gtk+ itself), not in build-guile-gtk.  We pretty
much know what glue code we want to generate and it would be nice if
we could use a external tool to do so, but the generated code glue
itself and the `feel' of the resulting Scheme API should pretty much
stay the same.  There is room for improvement, of course, especially
when it comes to composite types and multiple return values, but the
quality of the Scheme API must not decrease.  For example, it is
important that guile-gtk knows about the type hierarchy of the
GtkObject types in Gtk+ so that it can do proper type checking.

> How do you handle varargs from guile?  Robert and I tried to figure
> out a way to do that last week and came to the conclusion that it
> wasn't possible without some non-portable assembly nonsense (or
> similar) since C doesn't have anything remotely like "apply" for
> va_lists; ISTR Robert actually found something in the C FAQ about
> this.

You could try libffi or libffcall (I think).  I once did bindings for
libffi but they have rotten away I'm afraid.

> Overall, as I somewhat suggested above, and bearing in mind that I
> haven't yet *fully* grokked what you're proposing since I don't have
> as much familiarity with gtk, gnome, and the current state of
> guile-{gnome,gtk} as you do, it sounds like your current .defs
> proposal goes far beyond what g-wrap was intended to do, covering
> quite a bit more ground.

[small voice] Lest there be a misunderstanding, I don't know fully
what to think of the defs proposal.  The last time I read it, I found
it to be quite superficial and vague.  I'm not pushing for anything in
this department.  In fact, I'm quite happy sitting on an island with
guile-gtk, knowing that it works quite well as it is, and waiting for
whatever ransom might come... ;)

> On the issue of "wrapping C structures in more detail" -- right now
> g-wrap presumes the C API is "function rich".  By that I mean that it
> presumes that you can do everything you need with a structure or other
> C datatype via the functional API.

Yes, and trivial accessor functions could be generated by g-wrap.
Structure members should be exported as functions to Scheme (there is
pretty much no choice anyway), but the needed accessors functions need
not be written by hand.  An interesting thing would be to merge this
with GOOPS, somehow.