XmlPatterns 101

Just this month Qt4.4 was released. Amongst the hot new stuff is QtXmlPatterns, which packs a C++ XQuery API. XQuery is a full blown typed XML query language based on XPath combined with so called FLOWR expressions [for-let-where-orderby-return]. While it's main goal is XML transformation one can abuse it as an ultra concise parser. Let's see a small example.

<?xml version="1.0" encoding="ISO-8859-1"?>
<root>
   <suite name="suite1" dir="/a/b">
   <case name="test1" exe="t.sh">
       <command name="cmd11" />
       <command name="cmd12" />
   </case>
   <case name="test2" exe="t2.sh">
       <command name="cmd21" />
   </case>
   </suite>
</root>

Say we want to extract dir, exe and name for each command in the listing above. This can be done in just four lines of XQuery, quite economic compared to your average dom-traversal code.

    QXmlQuery query;
   query.setQuery(
       "for $suite in doc(\"test.xml\")//suite\n"
       "for $case  in $suite/case\n"
       "for $cmd   in $case/command\n"
       "return concat($suite/@dir, '/', $case/@exe, ' ', $cmd/@name)\n");
   QStringList cmds;
   query.evaluateTo(&cmds);

At this point the 'cmds' QStringList contains:

("/a/b/t.sh cmd11", "/a/b/t.sh cmd12", "/a/b/t2.sh cmd21")

WASDeTT 2008

The other day I got confirmation on participation in WASDeTT. A Cyprus-based workshop on tool-building cohosted with ECOOP08 . Exciting to say the least! I'm really looking forward to this, especially since it'll be totally funded by my uni - subscription cost partly recuperated :)

I'll be presenting TestQ a prototype tool built as undergraduate project under the guidance of members from the LORE research group. Maybe I'll pick up some ingenious ideas for the GSOC [while enjoying the superb weather]

Acunote

Yesterday apaku suggested to use acunote.com, a project management and planning tool which streamlines progress communication. Next to extensive milestone scheduling it has direct integration with subversion. This allows for interesting features such as source annotations based on the commit diffs. It's implemented as a webservice in full 2.0 glory. All of this drenched in Agile Scrum terminology, yummy!

Apparently the authors are OSS enthusiasts themselves, as a result this service is gratuite for GSOC projects (and OSS in general). Though they haven't gone as far as opening it all up, yet. Evgeniy Ivanov is using it as well for his Kdevelop4 DVCS integration GSOC, which might have something to do with their git support :)

Milestone 2

I plugged QxRunner into Kdevelop4, as planned. While still far from fully functional it's nice to see some progress anyway. The screenshot below shows a small CppUnit suite. It's not dynamic at all though, just compiled in the hard way. I'm, however, quite happy with how it turned out visually. Might have to remove the result view (widget in the lower left corner) with something more flexible though, maybe based on the filesystem-plugin scroll thingy.

g++ linkage on 64 bit

/usr/bin/ld: /home/nix/KdeDev/kdevelop/build/lib/libqxcppunit.a(testrunner.o):
relocation R_X86_64_32S against `vtable for QxCppUnit::TestRunner' can not be
used when making a shared object; recompile with -fPIC
/home/nix/KdeDev/kdevelop/build/lib/libqxcppunit.a: could not read symbols:
Bad value
collect2: ld returned 1 exit status
make[2]: *** [lib/kdevxtest.so] Error 1

A cookie for those that decipher this g++ gibberish. And yes, "-fPIC" was present. Apaku, who's mentoring me, told me this happens when you try to link a static library into a shared one. Apparently this is not supported in the 64bit gcc implementation and hence forbidden in KDE. Funnily enough the same construct runs without a hitch on x86.

Related to this I learned about gcc's DSO visibility concept. Marking symbols as visible in a shared library is typically done with an export macro. In the original QxRunner this macro was activated externally by the buildsystem, which I overlooked when converting to CMake. This resulted in totally mangled shared libs ... not good.

QxRunner test suite

While coding hasn't officialy started yet I just finished the first milestone. The base for the test runner is going to be QxRunner, however this didnt have a test suite of it's own, yet. By coding this I achieved a double purpose (i) get to know the internals inside out and (ii) create a safety net for comming changes.

The initial goal was 90% coverage, although it never got specificied what kind of coverage, be it class, method, block, statement, branch ... In the end I achieved 70% line coverage which is a whole lot indeed. The remaining bits werent really worth exercising imo, view report. I measured this with gcc's gcov and visualized it with lcov.