Bafflin' Smoke Signal - History

After a period of obscurity, it seems the KDE kdebindings module's time has almost come. So I thought I'd start a series of Bafflin' Smoke Signal blogs about what's going on, and specifically I'd like to try to explain how Ashley Winter's SMOKE library works. In this first blog, I also include a rant about how dysfunctional HR departments in some large organisations just don't understand FOSS developers.

Here's the latest. We have KJSEmbed as a nice easy to use RAD environment; and for the power users the QtRuby/Korundum and QtJava/Koala bindings are both stable, complete and useful. Soon we may have a copy of PyQt/PyKDE maintained in kdebindings, and I believe Germain Garand is progressing well with PerlKDE over on the PerlQt Sourceforge site.

On the downside, as part of the spring clean to make ready for PyKDE, the QtC/KDEC and Objective-C bindings have been retired as they were proving too difficult to maintain. In fact the Objective-C bindings were never released - oops thats about 6 months work down the pan :(

For KDE 3.3, I've recently been working on Qt# v2/Kimono C# bindings which use the SMOKE library via .NET custom RealProxies (rather than the obsolete QtC lib that is used by the Qt# v1 bindings). A new version of the java bindings that use SMOKE and dynamic Proxies is at a similar stage. The proxy based bindings for java and C# may have Aspect Oriented features, and if it works out it should be possible to write advice in ruby or perl as well as the primary language. I hope to co-opt ideas from the AOP java project Nanning http://nanning.codehaus.org/ or DynAOP https://dynaop.dev.java.net/ for KDE.

In version 2 of the Smoke library, Ashley is describing the Qt/KDE api with RDF, where each class or method can be identified with a URI (in SMOKE version 1, a method is identified by a short integer which is less flexible). For instance, RDF services could define the location of wikis or documentation based on these names. Or they can be used to refer to language independent AOP pointcuts. Rather than generating Smoke from the C++ headers, Ashley intends to derive it from a dump of the compiled translation unit for even more complete autogeneration. It will be hot stuff if it all works out!

First, here's how Smoke got started. In early 2002 I had a go at generating ruby bindings, taking an existing unmaintained project 'Ruby/Qt', which used SWIG. I attempted to generate the SWIG interface files using kalyptus (a bindings generator derived from kdoc), and it proved harder than I expected. For instance, in ruby there is no method overloading, and foobar(int), foobar(double) or foobar(QString) in C++ will all map onto a single method in ruby. In the generated ruby 'foobar' method you would need to despatch on the argument type and call the appropriate C++ method. The SWIG code generation didn't handle this very well, and the original Ruby/Qt bindings needed a lot of hand fixing.

A couple of months later I started discussing with Germain Garand how to get the PerlQt bindings updated from Qt 2.0 to Qt 3.0. PerlQt version 2 needed interface files like SWIG, and so we attempted to generate these .pig files via kalyptus. That was working reasonable well, and we were lucky enough to have Dave Faure come along an help out (doesn't he get everywhere?). David was working for Mandrake at the time, and they needed their PerlQt based installer to be updated from Qt 2 to Qt 3. A bonus for me was to have two great perl hackers working on improving kalyptus (my perl is terrible, and never seems to get better).

Then Ashley Winters turned up with his amazing ideas for what would become SMOKE, an autogenerated library that would work with any dynamic language. He had written a perl script to do the basic code generation and parse C++ headers, so David incorporated the code generation into kalyptus, but using that as the header parser. I personally didn't do much other than invent the name; SMOKE stands for 'Scripting Meta Object Kompiler Engine', which is a play on Qt's moc. The easiest way to think of Smoke is a 'moc on steriods'. Although we managed to get PerlQt working, it was hard to see out how SMOKE could be easily extended to the KDE classes, and so that job was left for later..

I ran out of money and time in May 2002, and had to go and do some paid work (the first for a couple of years). Since 1996 I'd been working on and off for a bank maintaining a large global equities trading system with a nice Objective-C/NeXTSTEP front end. I'd already spent about 3 years on the same team, and they wanted me back. You'd think it would be easy? In fact it was really difficult to get past the HR dept (I'd call it an anti-HR dept). They had to have a reference from a 'Line Manager' (does KDE have those?). A photocopy of my degree certificate, when I graduated with a pass degree in Philosphy with Cognitive Studies in 1978! - pretty irrelevant. And I gave them a list of 5 URLs which referred to the interviews and FOSDEM talk I'd given about the language bindings work, but the head of HR told me "we're not on the internet" !!!

Why don't they use the internet to search for skilled programmers by looking at the code they produce, or how they interact on mailing lists? I'm sure somebody who could do that, is going to make a fortune as a FOSS developer head hunter/recruiter. Why look at loads of CV/resumes, which may well be partly a work of fiction and tell you very little about whether the person is any good? I don't know, but that's what they all do. At present in the UK everyone is very keen on cheap people, so low cost trumps everything and skill means nothing anyway. Oh well.

On the day I arrived, I had to take a drug test before I could even get through the door and get a security pass. Fortunately, my bodily fluids were of a high enough standard, but what a weird feeling! My first job, over 25 years ago, was with a software house called 'Dataskil' whose employees were nick named 'rent a drunk'. How times have changed..

Anyhow, after raising some more money, a year later in mid-2003 I started working on a Smoke based ruby binding, QtRuby. In November I finally managed to get the Smoke library working with the KDE classes, and produced the Korundum KDE ruby bindings. While I was doing that I had an idea about how SMOKE could be used with static languages like java and C# via their dynamic proxies feature.

In the next Bafflin' Smoke Signal I'll try and explain more about how dynamic languages like perl and ruby interface with SMOKE, but that's all for now.