Re: new gtk2-perl
- From: muppet <scott asofyet org>
- To: gtk-perl mailing list <gtk-perl-list gnome org>
- Subject: Re: new gtk2-perl
- Date: 09 Apr 2003 21:19:16 -0400
On Wed, 2003-04-09 at 18:28, JÃrn Reder wrote:
muppet wrote:
read the rest, and get the code, at
http://asofyet.org/muppet/software/gtk2-perl/new-gtk2-perl.html
Ok, I read it and I must admit: I'm not expert enough to understand all
the details (in particulary about the depths of the type system). But
what I understood sounds good in my ears ;)
is that because i was too verbose and not clear enough, or because you
don't know the type system very well? i imagine that document will be
the base of developer docs, so if you have any suggestions for making it
clearer then i'm all ears.
I think it's always a good idea to use code generators where possible.
...
Sure, where special handling is needed, it should be done specially.
It's a bad idea to try to build a code generator, which also covers the
special cases. But every generated bit of code saves a lot of work, and
the easy things, which of course can easily be generated, are the
majority here.
pygtk uses a generator to write the vast majority of the methods. they
use a defs file to specify the methods to be bound, with "overrides"
files implementing the functions the stuff that needs special handling,
such as complicated parameter sets or "own" semantics.
in the case of the style of XS i've tried to set up, the XS definitions
pretty much *are* the simple defs, and the non-simple stuff is
implemented right there.
we're using a script to convert the C headers into rough first-pass XS
files, which are intentionally incomplete to force us to look over them
for correctness. ross found a bug in it today that was causing the
omission of some functions; i'll put up another snapshot later tonight
or tomorrow.
Although on my first attempt a "make test" in the Gtk2/ directory of
your tarball reported a lot of errors (beside other things it tries to
allocate 4294967276 bytes of memory ;)
ross added that one because we couldn't figure out at a glance why it
would die for one case but not any others; warranted further
investigation but was not high on the priority list at the time.
i'm very glad you noticed! any ideas?
I hope the new Gtk2-Perl API won't change too much, but I don't see a
reason, why this should happen. From my understanding the Perl side of
the Gtk2 API isn't called into question here.
actually, parts of the perl side will change, mostly for the better.
mainly, no more will the perl developer be required to call ->free or
->unref.
--
muppet <scott asofyet org>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]