From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.user Subject: Re: Questions about guile-gtk Date: 19 Oct 2002 16:07:32 +0200 Sender: guile-user-admin@gnu.org Message-ID: <877kgezfmj.fsf@zagadka.ping.de> References: <20021016114848.GB6292@www> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035036530 16966 80.91.224.249 (19 Oct 2002 14:08:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 19 Oct 2002 14:08:50 +0000 (UTC) Cc: guile-user@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 182uHY-0004PU-00 for ; Sat, 19 Oct 2002 16:08:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 182uH5-0001dx-00; Sat, 19 Oct 2002 10:08:19 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 182uGQ-0000cN-00 for guile-user@gnu.org; Sat, 19 Oct 2002 10:07:38 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 182uGN-0000Vn-00 for guile-user@gnu.org; Sat, 19 Oct 2002 10:07:37 -0400 Original-Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.10) id 182uGN-0000Vj-00 for guile-user@gnu.org; Sat, 19 Oct 2002 10:07:35 -0400 Original-Received: from dialin.speedway42.dip160.dokom.de ([195.138.42.160] helo=zagadka.ping.de ident=qmailr) by mail.dokom.net with smtp (Exim 3.32 #2) id 182uGt-0007ak-00 for guile-user@gnu.org; Sat, 19 Oct 2002 16:08:07 +0200 Original-Received: (qmail 23712 invoked by uid 1000); 19 Oct 2002 14:07:32 -0000 Original-To: tomas@fabula.de In-Reply-To: <20021016114848.GB6292@www> Original-Lines: 78 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:1225 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:1225 tomas@fabula.de writes: > - I use the function sgtk_build_args(), which, as I understand, > tries to convert an SCM keyword list into a GtkArg array to > set the properties of a Gtk object. > The third argument to it is a `protector', I don't understand > exactly its use (but it's usually passed the object, which is > annoying if it's the object just being created ;-) > What I'm supposed to do with this? The 'protector' is used to combine the mark/sweep collector of Guile with the refcounting collector of Gtk+. Here is a shortish explanation: /* GtkObjects. GtkObjects are wrapped with a smob. The smob of a GtkObject is called its proxy. The proxy and its GtkObject are strongly connected; that is, the GtkObject will stay around as long as the proxy is referenced from Scheme, and the proxy will not be collected as long as the GtkObject is used from outside of Scheme. The lifetime of GtkObjects is controlled by a reference count, while Scheme objects are managed by a tracing garbage collector (mark/sweep). These two techniques are made to cooperate like this: the pointer from the proxy to the GtkObject is reflected in the reference count of the GtkObject. All proxies are kept in a list and those that point to GtkObjects with a reference count greater than the number of `internal' references are marked during the marking phase of the tracing collector. An internal reference is one that goes from a GtkObject with a proxy to another GtkObject with a proxy. We can only find a subset of the true internal references (because Gtk does not yet cooperate), but this should be good enough. By using this combination of tracing and reference counting it is possible to break the cycle that is formed by the proxy pointing to the GtkObject and the GtkObject pointing back. It is straightforward to extend this to other kind of cycles that might occur. For example, when connecting a Scheme procedure as a signal handler, the procedure is very likely to have the GtkObject that it is connected to in its environment. This cycle can be broken by including the procedure in the set of Scheme objects that get marked when we are tracing GtkObjects with a reference count greater than the number of internal references. Therefore, each proxy contains a list of `protects' that are marked when the proxy itself is marked. In addition to this, there is also a global list of `protects' that is used for Scheme objects that are somewhere in Gtk land but not clearly associated with a particular GtkObject (like timeout callbacks). */ Does this help? Not specifying a protector will not put the SCM objects on the global list. This is not optimal, but it is still safe in the sense that they might be freed too late, but not too early. > - How do I handle C functions with in/out parameters, that is, > pointers, like: > > gtk_canvas_get_scroll_region(GtcCanvas c, > double *x1, double *y1, > double *x2, double *y2) > > Again: is there something in guile-gtk to cope with it and didn't > I see it, or is it ``roll your own''? There is a section in the README named "Composite Types and `call-by-reference'". > In the mid-term I think it's important to have an ``official'' bindings > generator tool, just to attract good bindings... Yes! -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user