* Towards guile-gtk 0.18 @ 1999-10-24 13:14 Ariel Rios 1999-10-25 7:46 ` Miroslav Silovic 1999-11-13 7:42 ` Towards guile-gtk x.xx Daniel Skarda 0 siblings, 2 replies; 11+ messages in thread From: Ariel Rios @ 1999-10-24 13:14 UTC (permalink / raw) To: guile-gtk 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Towards guile-gtk 0.18 1999-10-24 13:14 Towards guile-gtk 0.18 Ariel Rios @ 1999-10-25 7:46 ` Miroslav Silovic 1999-10-25 10:55 ` Marius Vollmer 1999-11-13 7:42 ` Towards guile-gtk x.xx Daniel Skarda 1 sibling, 1 reply; 11+ messages in thread From: Miroslav Silovic @ 1999-10-25 7:46 UTC (permalink / raw) To: Ariel Rios; +Cc: guile-gtk 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Towards guile-gtk 0.18 1999-10-25 7:46 ` Miroslav Silovic @ 1999-10-25 10:55 ` Marius Vollmer 1999-10-25 14:45 ` Miroslav Silovic 1999-10-30 23:05 ` Jim Blandy 0 siblings, 2 replies; 11+ messages in thread From: Marius Vollmer @ 1999-10-25 10:55 UTC (permalink / raw) To: Miroslav Silovic; +Cc: Ariel Rios, guile-gtk 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Towards guile-gtk 0.18 1999-10-25 10:55 ` Marius Vollmer @ 1999-10-25 14:45 ` Miroslav Silovic 1999-10-30 23:05 ` Jim Blandy 1 sibling, 0 replies; 11+ messages in thread From: Miroslav Silovic @ 1999-10-25 14:45 UTC (permalink / raw) To: Marius Vollmer; +Cc: Ariel Rios, guile-gtk 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Towards guile-gtk 0.18 1999-10-25 10:55 ` Marius Vollmer 1999-10-25 14:45 ` Miroslav Silovic @ 1999-10-30 23:05 ` Jim Blandy 1999-10-31 4:34 ` Miroslav Silovic 1999-10-31 5:14 ` Marius Vollmer 1 sibling, 2 replies; 11+ messages in thread From: Jim Blandy @ 1999-10-30 23:05 UTC (permalink / raw) To: Marius Vollmer; +Cc: Miroslav Silovic, Ariel Rios, guile-gtk > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Towards guile-gtk 0.18 1999-10-30 23:05 ` Jim Blandy @ 1999-10-31 4:34 ` Miroslav Silovic 1999-10-31 5:14 ` Marius Vollmer 1 sibling, 0 replies; 11+ messages in thread From: Miroslav Silovic @ 1999-10-31 4:34 UTC (permalink / raw) To: Jim Blandy; +Cc: Marius Vollmer, Ariel Rios, guile-gtk 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Towards guile-gtk 0.18 1999-10-30 23:05 ` Jim Blandy 1999-10-31 4:34 ` Miroslav Silovic @ 1999-10-31 5:14 ` Marius Vollmer 1999-10-31 9:54 ` Keith Wright 1 sibling, 1 reply; 11+ messages in thread From: Marius Vollmer @ 1999-10-31 5:14 UTC (permalink / raw) To: guile-gtk 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Towards guile-gtk 0.18 1999-10-31 5:14 ` Marius Vollmer @ 1999-10-31 9:54 ` Keith Wright 1999-11-01 6:37 ` Jim Blandy 0 siblings, 1 reply; 11+ messages in thread From: Keith Wright @ 1999-10-31 9:54 UTC (permalink / raw) To: guile-gtk > 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. --- ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Towards guile-gtk 0.18 1999-10-31 9:54 ` Keith Wright @ 1999-11-01 6:37 ` Jim Blandy 1999-11-02 21:42 ` Keith Wright 0 siblings, 1 reply; 11+ messages in thread From: Jim Blandy @ 1999-11-01 6:37 UTC (permalink / raw) To: Keith Wright; +Cc: guile-gtk > > > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Towards guile-gtk 0.18 1999-11-01 6:37 ` Jim Blandy @ 1999-11-02 21:42 ` Keith Wright 0 siblings, 0 replies; 11+ messages in thread From: Keith Wright @ 1999-11-02 21:42 UTC (permalink / raw) To: jimb; +Cc: guile-gtk > 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. --- ^ permalink raw reply [flat|nested] 11+ messages in thread
* Towards guile-gtk x.xx 1999-10-24 13:14 Towards guile-gtk 0.18 Ariel Rios 1999-10-25 7:46 ` Miroslav Silovic @ 1999-11-13 7:42 ` Daniel Skarda 1 sibling, 0 replies; 11+ messages in thread From: Daniel Skarda @ 1999-11-13 7:42 UTC (permalink / raw) To: guile-gtk 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~1999-11-13 7:42 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-10-24 13:14 Towards guile-gtk 0.18 Ariel Rios 1999-10-25 7:46 ` Miroslav Silovic 1999-10-25 10:55 ` Marius Vollmer 1999-10-25 14:45 ` Miroslav Silovic 1999-10-30 23:05 ` Jim Blandy 1999-10-31 4:34 ` Miroslav Silovic 1999-10-31 5:14 ` Marius Vollmer 1999-10-31 9:54 ` Keith Wright 1999-11-01 6:37 ` Jim Blandy 1999-11-02 21:42 ` Keith Wright 1999-11-13 7:42 ` Towards guile-gtk x.xx Daniel Skarda
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).