guile-gtk 0.18 Released

guile-gtk 0.18 Released

[Ariel Rios]

(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

Patch to make guile-gtk work with upcoming guile-1.4

[Greg J. Badros]

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 (&gtkobj_marker_hook_smob);
-  tc16_gtkobj = scm_newsmob (&gtkobj_smob);
-  tc16_boxed = scm_newsmob (&boxed_smob);
-  tc16_gtktype = scm_newsmob (&gtktype_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,

Re: Patch to make guile-gtk work with upcoming guile-1.4

[Mikael 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);

Re: Patch to make guile-gtk work with upcoming guile-1.4

[Greg J. Badros]

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

Re: Patch to make guile-gtk work with upcoming guile-1.4

[Marius Vollmer]

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.

Re: Patch to make guile-gtk work with upcoming guile-1.4

[Marius Vollmer]

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

Re: Patch to make guile-gtk work with upcoming guile-1.4

[Greg J. Badros]

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

Re: Patch to make guile-gtk work with upcoming guile-1.4

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

Re: Patch to make guile-gtk work with upcoming guile-1.4

[Jim Blandy]

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

Re: Patch to make guile-gtk work with upcoming guile-1.4

[Greg J. Badros]

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

Re: Patch to make guile-gtk work with upcoming guile-1.4

[Jost Boekemeier]

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

Re: Patch to make guile-gtk work with upcoming guile-1.4

[Brett Viren]

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