From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9178 invoked by alias); 6 Oct 2003 15:34:45 -0000 Mailing-List: contact guile-gtk-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: guile-gtk-owner@sources.redhat.com Received: (qmail 9170 invoked from network); 6 Oct 2003 15:34:43 -0000 Received: from unknown (HELO defaultvalue.org) (66.93.216.237) by sources.redhat.com with SMTP; 6 Oct 2003 15:34:43 -0000 Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 645F63FB2; Mon, 6 Oct 2003 10:34:42 -0500 (CDT) Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 4036481121; Mon, 6 Oct 2003 10:34:42 -0500 (CDT) To: Andreas Rottmann Cc: guile-gtk@sources.redhat.com, guile-gtk-general@gnu.org Subject: Re: guile-gobject/g-wrap status update References: <87y8vy7tey.fsf@alice.rotty.yi.org> From: Rob Browning Date: Mon, 06 Oct 2003 15:34:00 -0000 In-Reply-To: <87y8vy7tey.fsf@alice.rotty.yi.org> (Andreas Rottmann's message of "Mon, 06 Oct 2003 17:13:54 +0200") Message-ID: <87zngez8fh.fsf@raven.i.defaultvalue.org> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-q4/txt/msg00001.txt.bz2 Andreas Rottmann writes: > [BTW: There seem to be two guile-gtk mailing lists ATM - I guess > people should migrate to the one at GNU...] > > I'm ATM working at implementing "glueless" wrapping for g-wrap, > i.e. instead of using a dedicated C wrapper for each wrapped function > creating an applicable smob that invokes a general marshaller which in > turn calls the C function via libffi. Interesting. A couple of questions come to mind. First, how portable is libffi? Will it cover all the existing architectures? Also, do we know what the overhead's likely to be? I suppose the performance argument could go either way when comparing to the existing approach since the existing one-function-per-wrapper approach may well have poorer interactions with the memory hierarchy. In any case, I do want to preserve the ability for people who want to, to be able to have close to minimal ffcall overhead using g-wrap. When calling from interpreted languages, you may have a lot more leeway before you noticably affect performance, but in the long run, I'm hoping guile will also provide some form of compilation. On a related front, I've decided to just use CVS at savannah, so I should be setting that up over the next week (plus or minus -- I have family coming to visit). It also probably makes sense to have a place where those interested can discuss "what should happen next" with g-wrap. I'm happy to have that discussion on an existing list if that would be appropriate, or to create a new one. I've had some ideas I'd like to discuss, and to compare and contrast (to the extent that they overlap) with the above. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4