Re: new gtk2-perl

XS build system (hey - I voted for XS already last year -  check the
archives ;) and the usage of code generators.
I think it's always a good idea to use code generators where possible.
Gtk1-Perl used this technology and the result was a feature rich and  stable
Gtk Perl binding (beside this nasty MakeMaker incompatibility  which never
got fixed officially and thus became Top#1 FAQ here ;).

the only things auto-generated when a user downloads and compiles
new-gtk2-perl are some of the typemap stuff. the actual bindings are written
once as XS and then run through the normal XS->C pipeline. things like gtk2
version compatibility would be handled with #ifdef's etc.

muppet did mention a script he wrote (and i just updated
today, that isn't on the site yet) that will take a gtk2 header file and
generate a partially working XS mapping. using this i created (almost
complete) mappings for ~65 modules and muppet did several others. after
running a gtk2 header through this script you can spend about 10 mins or so
getting 90 percent of the modules 100% done, and the probably 9 of the other
10, 75% there. i.e. you only have to change a few things and make sure that
what was generated was sane. and then there's a little bit of style clean up
to do.

Ok, a lot of "untested" code is produced by a generator. But in my  opinion
most generated code need no in-depth testing (presuming the code generator
itself is more or less error free), *because* it is generated.

the somewhat confusing, and error prone, auto-generation at compile time of
gtk-perl function mappings aren't in new-gtk2-perl.  muppet does auto-generate
things that could be more safely done like typemaps, where the same code is
created for each of the appropriate types. this is much safer, in my opinion

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.

this is essentially the process that's been implemented here
creates what can be easily created and a human goes back over it and fixes the
more complicated cases (i.e. stack manip when multiple values or complicated
objects are returned, the whatever_new functions, etc.)

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 ;) : I think this is the right way  (I'll do some
in-depth debugging on what's going wrong here later).

the memory thing is a known error, on all systems thus far, i put that test in
there to specifically exercise it so that we'll have a reliable what to check
that it's fixed when it is. everything else (at least on the systems i've had
access to) is just debugging information rather than errors, if you are
getting actual error's please send a copy of them to myself and/or muppet and
we'll look at them.

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.

from the developing an app stand point almost nothing would change, and if
anything should get simpler, you won't have to worry about the lifetimes of
your widgets and such, they'll behave how you expect perl var's to behave.
(this is perhaps what needs the most testing in new-gtk2-perl code as well as
in gtk-perl)

developing extensions of new-gtk2-perl should be orders of magnitude easier
than gtk2-perl and should for the most part follow the normal XS development
process, most of the differences are explained in various doc's muppet has/is

Just my 2 cents...

appreicaite you opinion.

i spent about 5 or so hours a couple of weekends ago trying to get started
working on gtk2-perl and didn't even begin to scratch the surface. it wasn't
like xs and it wasn't like inline. it was it's own special thing that took a
lot of digging to figure out (and i never really did.) this new stuff of
muppet's is almost completely familiar to anyone who's done XS. if they
haven't done xs then there's no shortage of doc's and books on how to do
it. there's just no way someone can just pick up and work on or extend
gtk2-perl as it currently stands. that's not really an opinion, that's just
the case.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]