From mboxrd@z Thu Jan  1 00:00:00 1970
From: Miroslav Silovic <silovic@zesoi.fer.hr>
To: Marius Vollmer <mvo@zagadka.ping.de>
Cc: Ariel Rios <jarios@usa.net>, guile-gtk@sourceware.cygnus.com
Subject: Re: Towards guile-gtk 0.18
Date: Mon, 25 Oct 1999 14:45:00 -0000
Message-id: <7e7lkbceqy.fsf@zesoi.fer.hr>
References: <19991024202010.8425.qmail@nwcst287.netaddress.usa.net> <7eu2nfikc3.fsf@zesoi.fer.hr> <87iu3v49vx.fsf@zagadka.ping.de>
X-SW-Source: 1999-q4/msg00031.html

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Miroslav Silovic <silovic@zesoi.fer.hr> writes:
> 
> > This could be solved by splitting gtk.defs (and modifying
> > build-guile-gtk to allow it to export the glue generated by
> > define-object and define-enum declarations between multiple files).
> 
> I think build-guile-gtk already does this.  You have to have the right
> `import' statements, tho.
> 

> I'm a bit worried about the size of gtk-glue.c, too.  Does it need to
> be that big?  Is the compiled code too bloated, too?  Maybe it would
> be acceptable to just generate some table for each function and then
> have one generic glue function that peruses this information.  Maybe
> this wouldn't work for all of them, but for the majority.

-rwxr-xr-x   1 silovic  lss  388024 Oct 25 22:48 libguilegtk-1.2.so.0.0.0*

(-g -O2, stripped, 1.7 MB unstripped)

I'd say this isn't too bad. This also means that most of that 400kb of
C is... well, compiled into nothing. With most identifiers ranging
from 20 to 40 characters in length, this is not surprising. My main
gripe is not the total code size, it's the fact that it's all in a
single file that gets recompiled each time I modify some interface -
this slows down development cycle.

For total code size, some functions could be replaced by C closures
(some C code, with guile vector containing extra data). Something like
this pseudo-C?

typedef struct {
  void *wrapper;
  void *function;
} GlueSmob;


/*
...
handle smob registration somewhere else; also, since we'll be using
static tables, they shouldn't be freed from GC
...
*/

/*
this should take 1 rest argument
*/
static SCM
exec_function_wrapper (SCM the_glue_smob, SCM args)
{
  GlueSmob *s = (GlueSmob*)SCM_CDR(the_glue_smob);
  return s->wrapper(s->function, args);
}

static SCM
make_function_wrapper (SCM the_glue_smob)
{
  SCM cclo = scm_makcclo (exec_function_wrapper, 2);
  SCM_VELTS(cclo)[1] = the_glue_smob;
}

/* autogenerated table */
GlueSmob gs[N_GLUE] = {
 {wrapper1, whatever},
 {wrapper2, whatever},
 ...};

/* another autogenerated table */
char *symbols[N_GLUE] = {"gtk_button_new", .....};

/* end of autogenerated code */

static void
init_glue (void)
{
  int i;
  for (i = 0; i < N_GLUE; i++) {
    SCM s = scm_cons((SCM)tc16_glue_smob, (SCM)&gs[i]);
    SCM symbol = scm_sysintern0 (symbols[i]);
    SCM_SETCDR(symbol, make_function_wrapper (s));
  }
}

Then just instantiate a new wrapper for every possible combination of
parameter and return types - the worst case (unique combination) means
you only waste 8 bytes on the table entry and an extra indirection in
calling.

-- 
How to eff the ineffable?