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: http://jawnsy.wordpress.com/2009/05/26/i-love-open-source/ 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 now. - 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 files) - 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 without -DPERL_USE_SAFE_PUTENV: http://code.google.com/p/perlqt4/issues/detail?id=6 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 :-) Cheers, Jonathan _______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/soc-coordination
