Towards guile-gtk 0.18

Towards guile-gtk 0.18

[Ariel Rios]

Hi all--

Since the release of 0.17 I've been working towards having more Gtk+ functions
wrapped. Also, I've already included the changes required by guileGL to work.
I would like to know if any of you want a specific problem to be corrected for
inclusion in the new version.

Ariel

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

Re: Towards guile-gtk 0.18

[Miroslav Silovic]

Ariel Rios <jarios@usa.net> writes:

> Hi all--
> 
> Since the release of 0.17 I've been working towards having more Gtk+
> functions wrapped. Also, I've already included the changes required
> by guileGL to work.  I would like to know if any of you want a
> specific problem to be corrected for inclusion in the new version.

I've updated from CVS and compiled the new tree. The compilation is
taking forever, because of this:

-rw-r--r--   1 silovic  lss        469083 Oct 25 15:08 gtk-glue.c

I think that C file of this size is becoming an issue - adding
anything to gtk*.defs causes this to be recompiled - with another very
long wait.

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).

-- 
How to eff the ineffable?

Re: Towards guile-gtk 0.18

[Marius Vollmer]

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.

Just a thought.

- Marius

Re: Towards guile-gtk 0.18

[Miroslav Silovic]

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?

Re: Towards guile-gtk 0.18

[Jim Blandy]

> 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.

Some historical perspective: people used to make fun of the Mach
microkernel because it wasn't very "micro" --- it was bigger than a
BSD kernel on the same machine.  And it didn't even have filesystems,
networking stacks, and so on.

It turns out that a full half of the executable was due to
automatically generated RPC stubs.  The whole thing was based on
message-passing; even system calls were done by having the process
send a message to the kernel.  They used MiG (the Mach Interface
Generator) to describe the interfaces and generate client and server
messaging stubs; the kernel had lots of server stubs linked into it.
And the stubs were really big.

I'm not sure if this helps you solve your present problem, but I guess
it's worth noticing that this "Gosh, our automatically generated
interface adapter stubs are kind of big!" scene has been played out
before.  Many more times than once, I'd guess.  So some genuinely
clever thinking is required here.

Re: Towards guile-gtk 0.18

[Miroslav Silovic]

Jim Blandy <jimb@red-bean.com> writes:

> I'm not sure if this helps you solve your present problem, but I guess
> it's worth noticing that this "Gosh, our automatically generated
> interface adapter stubs are kind of big!" scene has been played out
> before.  Many more times than once, I'd guess.  So some genuinely
> clever thinking is required here.

*grin* Actually there are two problems: size of the automatically
generated stubs (which is not *really* big, 300kb is managable... and
I posted a possible method to reduce this size by a significant
factor), and the fact that all these stubs end up in the same file -
making building cycle astonishingly long. The former is not too much
of a problem, while the latter is - and it's also much easier to
solve, simply split defs file in a clever way.

-- 
How to eff the ineffable?

Re: Towards guile-gtk 0.18

[Marius Vollmer]

Jim Blandy <jimb@red-bean.com> writes:

> > I'm a bit worried about the size of gtk-glue.c, too.
>
> Some historical perspective: people used to make fun of the Mach
> microkernel because it wasn't very "micro" --- it was bigger than a
> BSD kernel on the same machine.  And it didn't even have filesystems,
> networking stacks, and so on.

[ Yeah, I know.  I'm just about to assess how difficult it would be to
  port GNU Mach to Linux, that is, to use unmodified Linux code for
  the machine specific parts of Mach.  I want to run the Hurd on my
  iMac. ]

> It turns out that a full half of the executable was due to
> automatically generated RPC stubs.

Yes.  I have done some minimal survey and it turnes out that a
libguilegtk without any actual stubs in it has this size

    % size .libs/libguilegtk-1.3.so.0.0.0 
       text    data     bss     dec     hex filename
      36719    1324      84   38127    94ef .libs/libguilegtk-1.3.so.0.0.0

while the regular one has

    % size /usr/local/lib/libguilegtk-1.3.so.0.0.0 
       text    data     bss     dec     hex filename
     295734   36180      84  331998   510de libguilegtk-1.3.so.0.0.0

This might not be very relevant because a glue library is supposed to
contain mostly glue, but it shows that reducing the glue portion of
libguilegtk would have siginificant effects.

- Marius

Re: Towards guile-gtk 0.18

[Keith Wright]

> From: Marius Vollmer <mvo@zagadka.ping.de>
> 
> Jim Blandy <jimb@red-bean.com> writes:
> 
> > Some historical perspective: people used to make fun of the Mach
> > microkernel because it wasn't very "micro"
> 
> > It turns out that a full half of the executable was due to
> > automatically generated RPC stubs.

Ouch!  That hurts.  I wrote that RPC stub generator.  It seemed
like a good idea at the time.

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop < http://www.free-comp-shop.com >
         ---  Food, Shelter, Source code.  ---

Re: Towards guile-gtk 0.18

[Jim Blandy]

> > > Some historical perspective: people used to make fun of the Mach
> > > microkernel because it wasn't very "micro"
> > 
> > > It turns out that a full half of the executable was due to
> > > automatically generated RPC stubs.
> 
> Ouch!  That hurts.  I wrote that RPC stub generator.  It seemed
> like a good idea at the time.

Sorry!  I forget who it was who told me this.  It was someone on the
Mach project at CMU, way back in 1990-92 or something.

Re: Towards guile-gtk 0.18

[Keith Wright]

> From: Jim Blandy <jimb@red-bean.com>
> > > 
> > > > It turns out that a full half of the executable was due to
> > > > automatically generated RPC stubs.
> > 
> > Ouch!  That hurts.  I wrote that RPC stub generator.  It seemed
> > like a good idea at the time.
> 
> Sorry!  I forget who it was who told me this.  It was someone on the
> Mach project at CMU, way back in 1990-92 or something.

I'm not offended, ey was probably right.  I don't know what
they might have done later, but at the time (about 1985)
it was just a quick thing to translate Pascal procedure
declarations into stubs to assign the parameters to
a record, call the message send, receive the reply, and
assign the record fields back to the parameters.  One procedure,
one stub.  It was better than writing it by hand, but
since every kernel call is done this way it deserved more
attention than it ever got.  Unfortunately, optimising
this was not seen as the fast-track to tenure.  As long
as it worked nobody was eager to make it top priority.

A few weeks ago I started looking through the OMG definition
of IDL and translating it to S-expressions and Scheme data
types.  The idea was that the Scheme IDL compiler would just
translate to data which a Scheme procedure could interpret
at run time to marshall arguments for a CORBA call, keeping
the code compact.  In view of the discussion on this list of
GOOPS vs Pure Scheme, YASOS, ILU, etc. that project is
canceled for lack of interest.

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop < http://www.free-comp-shop.com >
         ---  Food, Shelter, Source code.  ---

Towards guile-gtk x.xx

[Daniel Skarda]

Hello,

  few days ago I talked with my friend about programming languages. His
  favourite language is (currently :) Python and during debate he frequently
  mentioned that "Python comes with batteries included". This means that
  you install single Python package and get standard modules for nearly
  everything. 

  I think that at this point he is quite right - just imagine you base your
  project on goops, guile-gtk and guileGL. Than users of such project have to
  download and install guile, goops, guile-gtk, guileGL - and possibly other
  guile packages you use. Fortunately nowadays all "serious" packages use
  autoconf - but there is serious labyrinth of version dependencies.

  I am not sure that instant merge of all available packages would be clever - but
  some sort of convergence would be nice. In my opinion following issues should
  be solved to make guile (not only guile-gtk) more useful:

   * Guile should ship with standard way of storage and accessing of C modules
     (shared libraries loading). Today I found try-module-dynamic-link in 
     (ice-9 boot-9) module, but guile-gtk does dynamic linking on its own. I
     would prefer something like (ice-9 libltdl) - guile bindings for libltdl
     library which ships with libtool package.

   * Sometime ago I had to create bindings by hand I have to say that writing
     all these asserts by hand is really painful (and its easy to make mistake -
     ... == 0, ... == SCM_BOOL_F). 

     After some experience with guileGL bindings I am sure that it is not easy
     to create bindings directly from header files - or it is possible just for
     basic types (ints etc) - but when there are arrays and pointers things get
     more complicated.

     I now that there are at least two programs for creating bindings. To be
     honest - I have not tried them. Because I hacked some things in guile-gtk,
     I got used to build-guile-gtk script. I do not know whether all schemers
     would nominate it for best solution but I am sure that Guile should ship
     with such script. So I would like to propose:

        - instead of adding new features to build-guile-gtk we should make it
          more general and separate gtk specific features to special module
          (GuileGL already do this)

        - it would be nice to separate generic functions (enum2scm, scm2enum..)
          from guile-gtk library, thus other bindings do not depend on gtk

	  Also functions for creating new smob types would be useful. As I saw
	  the current define-struct code it depends on gtk library :(

        - To simplify writing and maintaining glue (.defs) files we should
	  provide some mechanism to specify function definitions inside .c
	  files (like SCM_PROC and SCM_MAGIC_SNARFER mechanism):

            SCM_GLUE((define-enum FooType
		       (foo1	MY_FOO_1)
		       (foo2	MY_FOO_2)))

            typedef enum {
              MY_FOO_1,
	      MY_FOO_2
	    } FooType;

  	    SCM_GLUE((define-func foo
  		       int
  		       ((string	  bar)
			(FooType  foot))
  		       (scm-name    "my-foo")))
  	    
  	    int foo(char* bar, FooType foot)
  	    {
  	    .... /* C code */

What do you thing about proposed changes?
Dan Skarda