From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Vollmer To: Rob Browning Cc: guile-gtk@sourceware.cygnus.com, gnucash-devel@gnucash.org Subject: Re: Taking the defs file issue Date: Sun, 12 Nov 2000 16:22:00 -0000 Message-id: <87wve83eoa.fsf@zagadka.ping.de> References: <200011122001.OAA18311@cs.utexas.edu> <878zqoeulm.fsf@raven.localnet> X-SW-Source: 2000-q4/msg00025.html Rob Browning 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.