* guile-gtk 0.18 Released @ 2000-06-01 21:05 Ariel Rios 2000-06-18 19:06 ` Patch to make guile-gtk work with upcoming guile-1.4 Greg J. Badros 0 siblings, 1 reply; 12+ messages in thread From: Ariel Rios @ 2000-06-01 21:05 UTC (permalink / raw) To: gnome-announce-list, guile, guile-gtk (Hello happy schemers, (Due to popular demand, the most functional and beautiful guile-gtk version 0.18 is now available for your lambda downloading pleasure.) (Guile-gtk provides glue code to make Gtk accessible from Guile so it provides a convenient interface for Scheme programmers to develop visual applications. (It can optionally integrate with GNOME via the Gnome-guile package.)) (Guile-gtk is free software licensed under the GPL.) (Guile-gtk was started by Marius Vollmer <mvo@zagadka.ping.de> and is currently mantained by Ariel Rios <ariel@arcavia.com> and other intrepid Guile hackers around the world.) (New in this version: * Guile-gtk now calls gtk_set_locale during initialization. * Support for type conversions with composites due to libltdl support from libguile. * Lots of improvements with the build-guile-gtk script. * Functions for getting the Gtk+ and guile-gtk version. * Lots of additions and corrections to the *.defs files. * The usual, uncountable number of minor and major bug fixes. * Please note that this version only supports Gtk+1.2.x.) (Homepage: http://www.ping.de/sites/zagadka/guile-gtk/ Availability: http://www.ping.de.sites/zagadka/guile-gtk/download/guile-gtk-0.18.tar.gz Mailing List: To subscribe to the list send mail to: <guile-gtk-subscribe@sourceware.cygnus.com> To post messages please write to: <guile-gtk@sourceware.cygnus.com>) (The following people contributed to this release of guile-gtk: Ariel Rios <ariel@arcavia.com> Marius Vollmer <mvo@zagadka.ping.de> Martin Baulig <martin@home-of-linux.org> Miroslav Silovic <silovic@zesoi.fer.hr> Mikael Djurfeldt <mdj@mdj.nada.kth.se> Alexandre Muniz <munizao@xprt.net>)) =>Enjoy, Ariel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Patch to make guile-gtk work with upcoming guile-1.4 2000-06-01 21:05 guile-gtk 0.18 Released Ariel Rios @ 2000-06-18 19:06 ` Greg J. Badros 2000-06-19 2:06 ` Mikael Djurfeldt 2000-06-19 14:49 ` Marius Vollmer 0 siblings, 2 replies; 12+ messages in thread From: Greg J. Badros @ 2000-06-18 19:06 UTC (permalink / raw) To: Ariel Rios, Marius Vollmer; +Cc: gnome-announce-list, guile, guile-gtk The below patch makes guile-gtk compile and run the calc.scm test program when building against guile-1.3.5pre2 (the upcoming guile-1.4). The patch is relative to current CVS guile-gtk. I suggest folding it into guile-gtk after guile-1.4 is released. (It should be tested more thoroughly, too, of course.) Thanks, Greg Sun Jun 18 18:59:41 2000 Greg J. Badros <gjb@cs.washington.edu> * guile-gtk.c: Updated for guile-1.4 which is about to be released. Change scm_newsmob(..) to scm_make_smob_type_mfpe(..) calls. Index: guile-gtk.c =================================================================== RCS file: /cvs/gnome/gnome-guile/guile-gtk/guile-gtk.c,v retrieving revision 1.48 diff -u -p -r1.48 guile-gtk.c --- guile-gtk.c 2000/05/16 20:18:53 1.48 +++ guile-gtk.c 2000/06/19 02:02:55 @@ -558,13 +558,6 @@ gtkobj_free (SCM obj) return sizeof (sgtk_object_proxy); } -struct scm_smobfuns gtkobj_smob = { - gtkobj_mark, - gtkobj_free, - gtkobj_print, - NULL -}; - /* Treating GtkObject proxies right during GC. We need to run custom code during the mark phase of the Scheme GC. We do this by creating a new smob type and allocating one actual smob of it. @@ -648,13 +641,6 @@ gtkobj_marker_hook_print (SCM obj, SCM p return 1; } -struct scm_smobfuns gtkobj_marker_hook_smob = { - gtkobj_marker_hook, - NULL, - gtkobj_marker_hook_print, - NULL -}; - static void install_marker_hook () { @@ -1033,13 +1019,6 @@ boxed_print (SCM exp, SCM port, scm_prin return 1; } -struct scm_smobfuns boxed_smob = { - scm_mark0, - boxed_free, - boxed_print, - NULL -}; - SCM sgtk_boxed2scm (gpointer ptr, sgtk_boxed_info *info, int copyp) { @@ -1275,13 +1254,6 @@ gtktype_equalp (SCM obj1, SCM obj2) return GTKTYPE (obj1) == GTKTYPE (obj2)? SCM_BOOL_T : SCM_BOOL_F; } -struct scm_smobfuns gtktype_smob = { - scm_mark0, - scm_free0, - gtktype_print, - gtktype_equalp -}; - GtkType sgtk_type_from_name (char *name) { @@ -1351,13 +1323,6 @@ illobj_print (SCM obj, SCM port, scm_pri return 1; } -struct scm_smobfuns illobj_smob = { - scm_mark0, - scm_free0, - illobj_print, - NULL -}; - static SCM sgtk_make_illegal_type_object (GtkType type) { @@ -2652,11 +2617,40 @@ SCM_SYMBOL (sym_gtk_version, "gtk-1.3"); static void sgtk_init_substrate (void) { - tc16_gtkobj_marker_hook = scm_newsmob (>kobj_marker_hook_smob); - tc16_gtkobj = scm_newsmob (>kobj_smob); - tc16_boxed = scm_newsmob (&boxed_smob); - tc16_gtktype = scm_newsmob (>ktype_smob); - tc16_illobj = scm_newsmob (&illobj_smob); + tc16_gtkobj_marker_hook = scm_make_smob_type_mfpe("gtkobj_marker_hook", + sizeof(sgtk_object_proxy), + gtkobj_marker_hook, + NULL, + gtkobj_marker_hook_print, + NULL); + + tc16_gtkobj = scm_make_smob_type_mfpe("gtkobj", + sizeof(sgtk_object_proxy), + gtkobj_mark, + gtkobj_free, + gtkobj_print, + NULL); + + tc16_boxed = scm_make_smob_type_mfpe("gtkboxed", + sizeof(sgtk_boxed_info), + scm_mark0, + boxed_free, + boxed_print, + NULL); + + tc16_gtktype = scm_make_smob_type_mfpe("gtktype", + sizeof(sgtk_type_info), + scm_mark0, + scm_free0, + gtktype_print, + gtktype_equalp); + + tc16_illobj = scm_make_smob_type_mfpe("gtkillobj", + sizeof(GtkType), + scm_mark0, + scm_free0, + illobj_print, + NULL); global_protects = NULL; sgtk_protshell_chunk = g_mem_chunk_create (sgtk_protshell, 128, ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-18 19:06 ` Patch to make guile-gtk work with upcoming guile-1.4 Greg J. Badros @ 2000-06-19 2:06 ` Mikael Djurfeldt 2000-06-19 14:11 ` Greg J. Badros 2000-06-19 14:49 ` Marius Vollmer 2000-06-19 14:49 ` Marius Vollmer 1 sibling, 2 replies; 12+ messages in thread From: Mikael Djurfeldt @ 2000-06-19 2:06 UTC (permalink / raw) To: Ariel Rios; +Cc: djurfeldt "Greg J. Badros" <gjb@cs.washington.edu> writes: > + tc16_gtkobj_marker_hook = scm_make_smob_type_mfpe("gtkobj_marker_hook", > + sizeof(sgtk_object_proxy), > + gtkobj_marker_hook, > + NULL, > + gtkobj_marker_hook_print, > + NULL); (Thanks to Greg for the patch.) Just a small comment: The `scm_make_smob_type_mfpe' function has not been mentioned in the NEWS file because it might become deprecated in next release of Guile. Please instead use the standard interface: tc16_gtkobj_marker_hook = scm_make_smob_type ("gtkobj_marker_hook", sizeof (sgtk_object_proxy)); scm_set_smob_mark (tc16_gtkobj_marker_hook, gtkobj_marker_hook); scm_set_smob_print (tc16_gtkobj_marker_hook, gtkobj_marker_hook_print); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-19 2:06 ` Mikael Djurfeldt @ 2000-06-19 14:11 ` Greg J. Badros 2000-06-19 15:47 ` Mikael Djurfeldt 2000-06-19 14:49 ` Marius Vollmer 1 sibling, 1 reply; 12+ messages in thread From: Greg J. Badros @ 2000-06-19 14:11 UTC (permalink / raw) To: Mikael Djurfeldt; +Cc: Ariel Rios, Marius Vollmer, guile, guile-gtk, djurfeldt Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes: > "Greg J. Badros" <gjb@cs.washington.edu> writes: > > > + tc16_gtkobj_marker_hook = scm_make_smob_type_mfpe("gtkobj_marker_hook", > > + sizeof(sgtk_object_proxy), > > + gtkobj_marker_hook, > > + NULL, > > + gtkobj_marker_hook_print, > > + NULL); > > (Thanks to Greg for the patch.) > > Just a small comment: > > The `scm_make_smob_type_mfpe' function has not been mentioned in the > NEWS file because it might become deprecated in next release of Guile. I'd much prefer that this function not be depracated... notice all of the redundancies and potential maintenance headaches below. People *will* cut and paste from one section to another, change the *_hook in the first line, and forget to change it in later lines, resulting in a hard-to-find and nasty bug. Greg > > Please instead use the standard interface: > > tc16_gtkobj_marker_hook = scm_make_smob_type ("gtkobj_marker_hook", > sizeof (sgtk_object_proxy)); > scm_set_smob_mark (tc16_gtkobj_marker_hook, gtkobj_marker_hook); > scm_set_smob_print (tc16_gtkobj_marker_hook, gtkobj_marker_hook_print); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-19 14:11 ` Greg J. Badros @ 2000-06-19 15:47 ` Mikael Djurfeldt 0 siblings, 0 replies; 12+ messages in thread From: Mikael Djurfeldt @ 2000-06-19 15:47 UTC (permalink / raw) To: Greg J. Badros; +Cc: djurfeldt "Greg J. Badros" <gjb@cs.washington.edu> writes: > I'd much prefer that this function not be depracated... notice all of > the redundancies and potential maintenance headaches below. People > *will* cut and paste from one section to another, change the *_hook in > the first line, and forget to change it in later lines, resulting in a > hard-to-find and nasty bug. I don't think this will cause much problems, and, actually, I think the standard interface (scm_make_smob_type/scm_set_smob_xxx) is easier to read and intuitively understand. But we'll not let that debate delay release. Instead we prepare for the eventuality that it will be removed, and don't bring it forward as a suggested way to code in this release. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-19 2:06 ` Mikael Djurfeldt 2000-06-19 14:11 ` Greg J. Badros @ 2000-06-19 14:49 ` Marius Vollmer 2000-06-19 15:01 ` Greg J. Badros 1 sibling, 1 reply; 12+ messages in thread From: Marius Vollmer @ 2000-06-19 14:49 UTC (permalink / raw) To: Mikael Djurfeldt; +Cc: Ariel Rios, Greg J. Badros, guile, guile-gtk, djurfeldt Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes: > The `scm_make_smob_type_mfpe' function has not been mentioned in the > NEWS file because it might become deprecated in next release of Guile. But smob.h says: /* These next two functions are the supported way to create new SMOB types. scm_make_smob_type is useful if there are no special smob functions and the defaults work for mark,free,print,equal_p, or you want to use scm_set_smob_{mark,free,print,equalp}, below. scm_make_smob_type_mfpe is ideal if you need to set one or more of the special smob functions-- use NULL for when the default function is fine */ The comment should be updated, probably. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-19 14:49 ` Marius Vollmer @ 2000-06-19 15:01 ` Greg J. Badros 2000-06-19 21:54 ` Jim Blandy 0 siblings, 1 reply; 12+ messages in thread From: Greg J. Badros @ 2000-06-19 15:01 UTC (permalink / raw) To: Marius Vollmer; +Cc: Mikael Djurfeldt, Ariel Rios, guile, guile-gtk, djurfeldt Marius Vollmer <mvo@zagadka.ping.de> writes: > Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes: > > > The `scm_make_smob_type_mfpe' function has not been mentioned in the > > NEWS file because it might become deprecated in next release of Guile. > > But smob.h says: > > /* These next two functions are the supported way to create new SMOB types. > > scm_make_smob_type is useful if there are no special smob functions > and the defaults work for mark,free,print,equal_p, or you want to use > scm_set_smob_{mark,free,print,equalp}, below. > > scm_make_smob_type_mfpe is ideal if you need to set one or more of > the special smob functions-- use NULL for when the default function > is fine > */ > > The comment should be updated, probably. Or we should just decide not to depracate the _mfpe piece. I think it's imprudent to require the separate and redundant calls to scm_set_smob_ when the common usage suggests the _mfpe interface that permits eliminating those redundancies. Greg ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-19 15:01 ` Greg J. Badros @ 2000-06-19 21:54 ` Jim Blandy 2000-06-20 8:41 ` Greg J. Badros 0 siblings, 1 reply; 12+ messages in thread From: Jim Blandy @ 2000-06-19 21:54 UTC (permalink / raw) To: Greg J. Badros Cc: Marius Vollmer, Mikael Djurfeldt, Ariel Rios, guile, guile-gtk, djurfeldt > Or we should just decide not to depracate the _mfpe piece. I think it's > imprudent to require the separate and redundant calls to scm_set_smob_ > when the common usage suggests the _mfpe interface that permits > eliminating those redundancies. The original smob interface had one provide a structure of function pointers and other info; this structure had to live for as long as any objects of that type did. In my experience, interfaces like that don't age gracefully. Over time, the set of relevant functions changes. Usually it's just that functions get added, but sometimes functions are superceded in favor of newer ones with better interfaces, with the older function kept around for compatibility. Having one setter function for each smob function allows the smob definition interface to remain regular as these kinds of changes take place. If you look at GDB and Apache, both of them have traded old-style structure interfaces for ones that resemble Guile's newer functions. The brevity of code that defines smob types simply isn't of interest to me, within reason. It's run only once, and the time consumed by those functions is negligible. I also think that the scm_set_smob_xxx interface is more readable. People like Greg Badros may have no trouble remembering what "mfpe" means, but in general I think such naming schemes lack gentility. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-19 21:54 ` Jim Blandy @ 2000-06-20 8:41 ` Greg J. Badros 2000-06-20 9:15 ` Jost Boekemeier 0 siblings, 1 reply; 12+ messages in thread From: Greg J. Badros @ 2000-06-20 8:41 UTC (permalink / raw) To: Jim Blandy Cc: Marius Vollmer, Mikael Djurfeldt, Ariel Rios, guile, guile-gtk, djurfeldt Jim Blandy <jimb@savonarola.red-bean.com> writes: > > Or we should just decide not to depracate the _mfpe piece. I think it's > > imprudent to require the separate and redundant calls to scm_set_smob_ > > when the common usage suggests the _mfpe interface that permits > > eliminating those redundancies. > > The original smob interface had one provide a structure of function > pointers and other info; this structure had to live for as long as any > objects of that type did. > > In my experience, interfaces like that don't age gracefully. Over > time, the set of relevant functions changes. Usually it's just that > functions get added, but sometimes functions are superceded in favor > of newer ones with better interfaces, with the older function kept > around for compatibility. Having one setter function for each smob > function allows the smob definition interface to remain regular as > these kinds of changes take place. I'm not arguing for the structure-style interface. I'm just arguing about what the front end to client applications should be. I'll try to make my argument once more (and then quit repeating myself, I promise): * the setter-style requires repeating the smob name. Registering smobs is typically cut and pasted, thus resulting in a maintenance issue, and hard to find bugs. * the setter-style also doesn't make obvious the fact that the special functions are set exactly once, when the smob is registered, and not changed. I believe my varargs style suggestion addresses the extensibility concerns, avoids redundancy, and encourages proper use at intialization time (trading them for giving up static correctness checks). > If you look at GDB and Apache, both of them have traded old-style > structure interfaces for ones that resemble Guile's newer functions. > > The brevity of code that defines smob types simply isn't of interest > to me, within reason. It's run only once, and the time consumed by > those functions is negligible. Which is why varargs should be an option. And since we know it's run exactly once, the dynamic argument checking we can include suffices. > I also think that the scm_set_smob_xxx interface is more readable. > People like Greg Badros may have no trouble remembering what "mfpe" > means, but in general I think such naming schemes lack gentility. It was better than the alternative, which was requiring people to remember the order of the arguments. It has the additional benefit of permitting new extensions to choose whether to require people to revisit every smob registration call (by changing the name of the exported function to _mfpek (where k = mnemonic for the new function required by the smob interface) or by allowing a default for the new function, by introducing a new _mfpek (leaving the _mfpe intact) that call the _mfpe and then do the extra setting for the "k" function. The setter based interface is misleading because it suggests that the functions can be set at an arbitrary time and repeatedly (instead of coupling the selection of the special functions with the initialization, as it should); the setter based interface is error-prone because it requires redundantly specifying the smob ID in a place that is cut & pasted regularly. Greg ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-20 8:41 ` Greg J. Badros @ 2000-06-20 9:15 ` Jost Boekemeier 2000-06-20 9:22 ` Brett Viren 0 siblings, 1 reply; 12+ messages in thread From: Jost Boekemeier @ 2000-06-20 9:15 UTC (permalink / raw) To: Greg J. Badros; +Cc: guile-gtk [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 279 bytes --] > when the common usage suggests the _mfpe interface that permits What does "mfpe" mean and what does the function do that others don´t? Just curious, I don´t have access to the guile sources from here and I can´t deduce the meaning from the discussion so far. Jost ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-20 9:15 ` Jost Boekemeier @ 2000-06-20 9:22 ` Brett Viren 0 siblings, 0 replies; 12+ messages in thread From: Brett Viren @ 2000-06-20 9:22 UTC (permalink / raw) To: Jost Boekemeier; +Cc: guile-gtk [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 586 bytes --] Jost Boekemeier writes: > > > when the common usage suggests the _mfpe interface that permits > > What does "mfpe" mean and what does the function do that others don´t? > Just curious, I don´t have access to the guile sources from here and > I can´t deduce the meaning from the discussion so far. Mark Free Print Equalp You use the _mfpe function to tell guile what 4 functions it must call in order to garbage collect your smob. See the ``data-rep.info'' page in guile-core/doc for details (get the CVS version as there has been some changes from 1.3.4). -Brett. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Patch to make guile-gtk work with upcoming guile-1.4 2000-06-18 19:06 ` Patch to make guile-gtk work with upcoming guile-1.4 Greg J. Badros 2000-06-19 2:06 ` Mikael Djurfeldt @ 2000-06-19 14:49 ` Marius Vollmer 1 sibling, 0 replies; 12+ messages in thread From: Marius Vollmer @ 2000-06-19 14:49 UTC (permalink / raw) To: Greg J. Badros; +Cc: Ariel Rios, guile, guile-gtk "Greg J. Badros" <gjb@cs.washington.edu> writes: > The below patch makes guile-gtk compile and run the calc.scm test > program when building against guile-1.3.5pre2 (the upcoming > guile-1.4). The patch is relative to current CVS guile-gtk. I > suggest folding it into guile-gtk after guile-1.4 is released. (It > should be tested more thoroughly, too, of course.) Thanks! We can it apply right now, I think, because 1.3.4 already includes the new interface for creating smobs. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2000-06-20 9:22 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-06-01 21:05 guile-gtk 0.18 Released Ariel Rios 2000-06-18 19:06 ` Patch to make guile-gtk work with upcoming guile-1.4 Greg J. Badros 2000-06-19 2:06 ` Mikael Djurfeldt 2000-06-19 14:11 ` Greg J. Badros 2000-06-19 15:47 ` Mikael Djurfeldt 2000-06-19 14:49 ` Marius Vollmer 2000-06-19 15:01 ` Greg J. Badros 2000-06-19 21:54 ` Jim Blandy 2000-06-20 8:41 ` Greg J. Badros 2000-06-20 9:15 ` Jost Boekemeier 2000-06-20 9:22 ` Brett Viren 2000-06-19 14:49 ` Marius Vollmer
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).