[Soc-coordination] libdebctrl/PerlQt4 Progress Update (Week 2)

Jonathan Yu jonathan.i.yu at gmail.com
Sat Jun 6 15:19:26 UTC 2009

During the "Community Bonding Period" I was packaging a lot of Perl
modules for Debian, to get a sense of the packaging process. I'm now
proficient at creating Perl packages, which I think will ease the
creation of a Qt package once the bindings are complete. As well, I
was working on the first part of my proposal -- that is, creating a
Debian Control File parser/manipulation library.

About libdebctrl:
- It's now accessible via alioth (libdebctrl) and is using SVN
- The error checking code is all in place now
- Compiles and can read files into a data structure (any files that
match the d/control syntax - RFC822 pseudoheader stuff. This would
seem to include d/copyright, however that file format is not
solidified yet)
- Fixed a bunch of memory leaks in libdebctrl (thanks to valgrind)
- Still a work-in-progress; the code to parse into control structures
needs some work.
- There is still an outstanding bug due to the allocation of
structures, which I wrote on my blog:

Since the official start of the coding period, I've been trying to
figure out the PerlQt codebase.
- This code is on Google Code's repository (the perlqt4 project) in
the branch tagged 'jawnsy' (SVN)
- I installed Debian and tried to install KDE, but ended up giving up
and installing Kubuntu instead. I now have this running both as
dual-boot and under VMware. Getting everything installed on Debian
(prior to switching to Kubuntu) and debugging some issues with GRUB
(with Kubuntu) cost me a few days, but I have that all figured out
- I've branched my own perl bindings, and repackaged it using
Module::Build (Build.PL)
- It now uses pkg-config to determine compile/linker flags; still need
to add something to check qmake as a fallback (this code will later be
moved into its own package, Alien::Qt4/Alien::SmokeQt4 which will be a
subclass of App::Info::Lib)
- There has been lots of discussion on the KDE-Bindings and KDE-Perl
lists discussing changes to the structure of the code. Right now the
big push is to make sure the bindings "work" for the next KDE-Bindings
release cycle (early July as far as I know)
- I spent some time figuring out what errors were, and removing them
- This code does compile and works well -- I ran a couple of the
examples, but now am trying to figure out puic4 (Perl UI Compiler --
it compiles .ui files into .pm files; Qt Designer produces these .ui
- Currently there are test failures due to m_unmap. The bug has been
"fixed" by changing a compile-time option in Perl (in how it frees
memory chunks), but we need to figure out a different way around it to
prevent users from having to recompile their Perl
- I still don't know how Smoke does most of its magic. The XS code for
PerlQt4 is pretty hairy, so I want to rewrite that into SWIG.

Throughout the coding of PerlQt, four people have been tremendously
helpful: the main author of the bindings (Chris Burel), my mentor
(Dominique Dumont), another developer on PerlQt4 (Eric Wilhelm, who is
also primary developer/maintainer of Module::Build) and the primary
author of Ruby's Qt4 bindings (Richard Dale).

Right now the biggest issue is pushing out working bindings and fixing
release-critical bugs (including the memory management issue when
running under a Perl) - It seems to be a memory management sisue in Qt
>= 4.5.0, because it uses putenv and Perl does not properly free the
memory. Chris managed to fix this, but I want to make a fix that works

Another thing is that I need to learn Doxygen soon, so I can properly
document libdebctrl before it gets too hairy. I'd also like to go
through the PerlQt4 code and add some comments explaining what stuff
is doing (meaning I need to figure out what black magic is happening).
Unfortunately PerlQt4 is not really a new project but in fact has lots
of history - it's based largely on code from PerlQt3 and RubyQt4. As a
result, there's a lot of hairy code that "just works" -- and works
well -- but that cannot be explained. In the interest of
maintainability I'd like to clarify the code (there are statements
with a bunch of -> operators and array lookups using another array to
determine the appropriate index...)

That's all for now. If anyone would like more details on my progress
or has any suggestions, please don't hesitate to drop me an e-mail :-)



More information about the Soc-coordination mailing list