[plt-scheme] Announce: mzgtk2 release 2 version 2.6.10.002

On Jan  6, Hans Oesterholt-Dijkema wrote:
> 
> > Have you tried using Eli's FFI in addition?
> >
> For SQLID, that would be an option for the drivers, I think even a
> good option. For MzGtk2 *see your earlier comments on integration*,
> the memory management and thread support (I myself am not using
> continuations yet), need C code to support them. I've looked at the
> FFI, but I see problems coming up there.

I can't see why you'd need C.  The foreign interface provides you with
access to various allocation routines, including the raw malloc() (and
therefore free()), and it gives you the ability to register handlers
for collecting objects.  What else would you need?


> MzGtk2 is doing quite a good job on the mem mgt already, although,
> the OO system also does a part on that. See e.g.
> 
> http://www.elemental-programming.org/mzgtk2-mzgtk2-memory-management.html
> 
> *And*, I definitely would need SWIG support for the FFI.  The number
> of C header files and lines of code to parse for Gtk+ is just
> enormous. You don't want to do that by hand.

Yes, this is an issue -- but they only thing you want out of SWIG is
parse the headers and spit out some readable description of functions
and types.  My guess is that this would be almost trivial.

But: the problem is that header files don't tell you the whole story
-- you need to know more details like:

* Is this function a Foo constructor, or does it return a reference to
  an existing Foo?

* Is this pointer argument intended as an input or as an output value?

* How are arguments related?  (e.g, a pointer to a vector, and the
  number of items in that vector).

SWIG will not help you with these things.  Actually, nothing can help
except for some format that is better than C header files.  This is
where the various IDLs are coming in, and the sad fact is that there
is nothing that is as popular as header files.

IIRC, the mzgnome project used some IDL-like files that were part of
Gnome -- which were conveniently in sexpr format.


On Jan  6, Hans Oesterholt-Dijkema wrote:
> 
> > Yes -- my guess is that using the dynamic foreign interface would have
> > made things *much* easier.  (But I think the same about creating yet
> > another object system just for that.)
>   
> You can always join in on schematics.sf.net ;-) and try out an FFI
> implementation yourself.  When I developed the OO system I was new
> to the scheme world. I wanted an OO system as simple as perl's OO
> system.

(I don't know about Perl's OO system, and I doubt that it's "simple".
Last I heard, it had some, uh, "features" that were anything bug
simple.)


> Well, maybe, it's not that difficult to let the ROOS macros map on
> e.g. swindle?

Why map?  Why not use an existing object system instead of mapping
macros?  (And I wouldn't advocate Swindle for that either, I'd use the
mzlib object system.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!