public inbox for guile-gtk@sourceware.org
 help / color / mirror / Atom feed
From: Andreas Rottmann <a.rottmann@gmx.at>
To: guile-gtk@sources.redhat.com
Subject: Re: Compiling guile-gobject experiences
Date: Sun, 14 Sep 2003 19:47:00 -0000	[thread overview]
Message-ID: <87fziz5exr.fsf@alice.rotty.yi.org> (raw)
In-Reply-To: <871xulk3v7.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 13 Sep 2003 09:02:04 +1000")

Kevin Ryde <user42@zip.com.au> writes:

> Andy Wingo <wingo@pobox.com> writes:
>>
>> But I do agree that it's a problem. I think reducing the size of the
>> generated code is the best solution, personally.
>
> A bit less error inlining might help.  I can see how the cleanup stuff
> ends up needing it, but there's plenty of cases with no cleanups.
> Perhaps building a list of cleanups at runtime would keep it down.
>
I've now made modifications to g-wrap and guile-gobject that make them
use a loop over an array for procedure and method creation,
respectivly. This makes the _init function for large wrapsets
considerably smaller. I'm ATM testing my modifications.

A way to speed the binding creation up a little bit might be to move
the ability to create methods into g-wrap, since that would save us a
few scm_c_lookups for each method. I'll look into this once I'm done
with testing the above mentioned modifictations.

> It'd be nice to call foreign functions just based on a little set of
> argument types, with no actual individual glue code at all.  I've got
> an idea gnu smalltalk has something like that.
>
> I don't think there's any way to portably make a C call from runtime
> arguments, in general, but it wouldn't be hard to setup the right
> thing for each CPU+ABI, with a bit of assembler.  Or maybe gcc could
> help.
>
As Marius already mentioned, there are (at least) two libs that do
this. libffcall seems to be the more featureful one from a first
glance.

Regards, Andy
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!

  parent reply	other threads:[~2003-09-14 19:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-02 17:17 Andreas Rottmann
2003-08-04 16:25 ` Andy Wingo
2003-08-04 16:58   ` Andreas Rottmann
2003-08-07  8:09     ` Andy Wingo
2003-08-07 11:18       ` Andreas Rottmann
2003-09-12 23:02   ` Kevin Ryde
2003-09-13 12:43     ` Marius Vollmer
2003-09-19  0:19       ` Kevin Ryde
2003-09-14 19:47     ` Andreas Rottmann [this message]
2003-09-15 17:59       ` GOOPS slowness [was: Compiling guile-gobject experiences] Andreas Rottmann
2003-09-19  0:18       ` Compiling guile-gobject experiences Kevin Ryde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fziz5exr.fsf@alice.rotty.yi.org \
    --to=a.rottmann@gmx.at \
    --cc=guile-gtk@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).