boost::python in Glom

General, , , ,

I recently took another look at boost::python. It was a much better experience than when I first tried boost::python for Glom in 2005, probably because my use of the Python C API in the meantime has helped me understand what boost::python is doing. I have a mostly-done patch to use it in Glom 1.12 (Glom 1.10 will be released soon). This should make the code simpler and much more robust, allowing me to add more Python API to Glom, allowing people to drive more of the Glom UI via scripts.

As a side-effect this will force us to enable C++ exceptions in the Maemo build for Glom 1.12, increasing code size, but that might be less of an issue by then.

I do find the boost::python documentation fragmented and unfocused, spending too much time congratulating itself about its use of various design patterns and generic programming techniques in the implementation, instead of just telling me how to achieve common tasks. It often assumes knowledge of the Python C API, as if it is based on original proposals or internal documentation. Many companies are using boost::python so I’m surprised that none have arranged for more useful documentation to be written. I’d be happy to do it if someone wants to pay for my time.

In fact, boost::python’s API maps closely to the C API, so you probably need to know both, though I hoped that boost::python would make it clearer and more explicit.

However, the people on the boost::python mailing list have been very helpful when the documentation has not been clear or where I have made silly mistakes.

Boost should install pkg-config .pc files

Getting the CFLAGS and LIBS for boost python in your configure.ac is insanely difficult and fragile. There are some .m4 scripts out there, but I can’t get any of them to work. Why on earth don’t they install a .pc file? They can’t all be Windows programmers.

And despite using unstable APIs, they don’t seem to allow parallel installs. For instance, on my Ubuntu Linux system, the headers are directly under /usr/include/ rather than /usr/include/boost-python-1.0/. GNOME gets this stuff right.

The need for parallel installs is even greater for boost::python because there are various possible incompatible configurations, any of which you are likely to find on your system. At the moment you will just get compiler or linker errors (which distro packagers don’t understand) instead of being able to explicitly depend on a specific version with a specific build (which distro packagers could understand).

This will make life difficult for Glom distro packagers, but I think it’s still worth it.

planet.openismus.com and Trainees

General, , , ,

Over the last month or so our two trainees, David King and Michael (not Mathias) Hasselmann have made good progress getting familiar with GTK+ and associated tools on Linux. They are on an intensive schedule, but they have the time to learn how things really work, so they don’t have to feel that any part is a mystery. For instance, they know now how to create custom GObjects and GTK+ widgets rather than just how to put widgets together in Glade. Now they will move on to C++, moving through gtkmm and then to Qt, with detours through Maemo and Scratchbox.

We hope to offer training to customers in the near future and this is giving us a good idea of what to cover and how.

Beyond just coding, Daniel and I are helping them to form good open source habits, creating developers in our image, so they can be creators of quality and fighters against entropy. I’ve encouraged them to blog about the experience and generally get involved in the community as an important part of their training, so don’t hesitate to give your advice.

It’s also interesting to see how the move to Germany has been for David, registering for various things and finding an apartment. It seems easier in Berlin than in Munich, and easier now than when I moved to Germany 10 years ago. Daniel‘s help has been a big time-saver, I guess.

I set up planet.openismus.com to show their blogs and all our others too.

Glom 1.8 bug fixes. Ubuntu packages

General, ,

Over the last few months we (Openismus) fixed several nasty regressions in Glom 1.8 compared to 1.6. The latest release is fairly usable. We really must set up some LDTP testing scripts or suchlike to catch these regressions before our .0 releases.

The Openismus PPA has updated packages for Ubuntu Intrepid, based on Iain Lane’s packages. The official Glom packages for Ubuntu Intrepid are 1.6, which was finally updated to a bug-fixed release, thanks again to Iain Lane.

Work on Glom 1.10 is going well, though it’s largely a port to libgda-4.0.

Inefficient Crèche/Kindergarten Allocation in Munich

Uncategorized, ,

It’s hard to find a place in a Crèche (Kinderkrippe) or Kindergarten in Munich. As far as I can tell, this is how it works:

  • Every family puts their child on the waiting list at 50 Crèches. That’s 50 separate waiting lists. Each family needs different hours – such as half-day or full-day.
  • Every Crèche therefore has a huge waiting list, probably 50 times bigger than their capacity.
  • A Crèche fills the next available place by calling people on the waiting list. Many people they call already have a place elsewhere, because they registered at all the other places, because they have no confidence in any one waiting list, because the waiting lists are huge. Families have to take the first place that is offered regardless of suitability because they have no clue about their chances on the other waiting lists.

This is incredibly inefficient and ineffective. I am surprised that nobody has created an online system to match children to Crèche and Kindergarten places. It wouldn’t have to be specific to Munich or even Germany.

Flumotion Documentation

General,

Writing the Flumotion Manual

I’m blogging about this a little late because I waited for some (internal) Flumotion Incorporated releases before mentioning it.

Between July and September 2008 I did about a man-month of work for Openismus on Flumotion‘s user manual (HTML, or PDF, or DocBook in the GNOME help browser), the first major piece of user documentation I’ve done. I usually write developer documentation. Flumotion is an audio/video streaming system. From the introduction:

Flumotion can broadcast your content live or on-demand in a range of popular audio and video formats. It supports a wide range of input hardware thanks to its use of Linux, GStreamer and other open source software. You can get started quickly with Flumotion’s simple user interface then just place a link to the streamed content on your website.

Flumotion allows processing to be spread across multiple machines, so your platform can scale to handle more viewers of more streams in more formats. Its open source architecture makes it more efficient and more flexible than competing systems, making better use of your hardware.

I worked from a table-of-contents that I agreed with Thomas Vander Stichele over a couple of days in person. There was a previous version but it was very developer-focused, immediately talking about the internal architecture of the software. Lots of that existing content was reused, updated, and expanded as sysadmin information, but the first few chapters are new, actually making the manual user-focused.

We wanted  an immediate introduction to Flumotion while providing a path to its full functionality and clearly offering the necessary information for later deployment, configuration, and security. I think we succeeded. We also added a reference section that’s generated from the Flumotion components themselves. These and other sections are heavily interlinked so it’s easy to get more information regardless of where you jump into the manual, because it’s natural for different people to focus on their area of concern.

I needed to ask lots of questions and do follow-up interrogation to get the raw information before writing content. Along the way I found myself acting as a tester, filing several Flumotion bugs that were then fixed, so Flumotion now works better as well as being better documented. The Flumotion/Fluendo developers were incredibly helpful and never lost patience with me, making the work a real pleasure.

Note that neither the HTML or PDF at flumotion.net have yet had any Flumotion-specific style or layout applied to them.

DocBook to PDF with fop

I’ve been writing DocBook documentation for a long time, starting with the gtkmm manual, so I’m generally familiar with the tools. (Though I had to learn lots of new markup and correct terminology for documenting an application instead of an API). Applications can just install their DocBook XML directly and leave the rendering to the GNOME Help browser (yelp), but you often need the document in HTML or PDF format to show on a website.

The DocBook XSL stylesheets for XHTML are still the correct way to generate HTML and work well. In the past I used docbook2pdf  (a simple way to use jade) to generate PDF , as you can see in the gtkmm-documentation Makefile.am. But it quickly became obvious that docbook2pdf wasn’t good enough. For instance, it did not include our index in the PDF and didn’t offer any way to customize the PDF output.

So I tried fop again and actually got it working, at least on Fedora Linux 9. fop uses Java so it had not really been packaged on Linux distributions before Java was open-sourced. I was pleasantly surprised at how much progress has been made since my last attempts. In the past it was frustrating to hear that we should be using fop because that was the only system being maintained, but never finding anyone who had managed to get it working.

Using fop means generating a .fo (XML) file from your DocBook XML, by processing it with the official fop XSL stylesheet from the DocBook people. fop then processes this .fo file to create a .pdf file. You can influence the end result by setting some XSL parameters when generating the .fo file.

Even on Fedora 9 there were various bugs to work around, such as:

As the flumotion-doc Makefile.am shows, we also chose a useful set of DocBook XSL Stylesheet parameters, which are surprisingly well documented. These avoid some problems (maybe bugs, though its debatable) and add some attractive admonition icons.

That Makefile.am is the result of much work so I hope it’s useful to other people trying the same thing. Note that it has a little extra complication because we bring in some XML examples inline, just like we bring C++ examples in to the gtkmm book.

fop broken again on Fedora 10 and Ubuntu Intrepid

Unfortunately I can’t confirm yet that these bugs are really fixed in Fedora 10 because Fedora 10 has some even more serious bugs that prevent me from getting that far:

And Ubuntu Intrepid (the first Ubuntu to package fop) has the same problem: fop crashes with SEVERE: Couldn’t find hyphenation pattern en. Plus the workaround  for the FOP PNG problem (and the scaling)  doesn’t work due to an apparently totally-broken Imagemagick  on Ubuntu.

This is rather disappointing. I was looking forward to using fop for the gtkmm book, for both HTML and PDF, hoping that the syntax highlighting stuff would work on our inline example code. Note to self: This might be useful help for that.

Liam at one year, standing

General, , , ,

Liam is now one year old. The months have passed quickly but the progress is obvious. He can now stand easily though he only bothers when distracted by something shiny. He walks sometimes holding our hand and I’m sure that any moment now he’ll stop needing to hold on. Even without walking he gets around incredibly quickly, indulging his need to take things out of their proper place, take them apart, and then jam them all back together again.

Peek-a-boo and pretending to be chased are his other main interests.

For the last six months, I’ve been working part-time, spending two and a half days at work and two and a half days at home taking care of Liam, with not much time in between for other things. I am very lucky to spend so much time with him – if really helps you create a strong bond.

Hopefully in March there will be a place for him in a Kinderkrippe/Kindergarten for a few hours a day. He’ll need that to get enough time with other kids, and it will take some stress off my work routine, though I’m unlikely to be working totally full-time for the forseeable future.

Documenting Telepathy: Examples

General, , ,

I’m gradually working on documenting Telepathy, the IM/real-time-communications toolkit, though I am currently still exploring the API rather than writing text, and I am only using occasional hours here and there for even that. The delay is more due to me than Telepathy. With the help of the Telepathy developers, I have  completed some simple telepathy-glib examples, giving me a feel for the API. I can now start to write up some of the text.

Telepathy actually works and is full featured, and has many people working on it. That makes it very useful to many people.

But to be honest, the API feels frustrating so far and I think you’ll see what I mean when you look at those examples. I’ll continue trying to document it so people at least know what to do, even if what they have to do doesn’t seem very nice.

Apart from the many little annoyances, I think the API suffers greatly from extreme use of asynchronicity, instead of fighting to protect application developers from that. I think that’s partly due to the choice of D-Bus for the implementation, instead of just using a C library, forcing every method call to be asynchronous. There’s also a tendency for high-level actions to consist of  multiple small (asynchronous) low-level steps, though that’s partly due to the awkwardness of simulating an object-orientated class hierarchy in a D-Bus API where even (the equivalent of) a cast is asynchronous, and a consequence of needing to discover interfaces at runtime, due to inconsistent interface coverage by the various plugins (connection managers). There’s also a tendency to expose the (naturally asynchronous) client-server network behavior of the protocols directly in the API instead of combining and hiding multiple network back and forth behind simpler API, though the new TpContact class does a lot of work in the background.

However,  I have not yet explored the whole API and don’t yet have a full sense of the common ways that the API is used, so my judgement could conceivably be wrong. I also suspect that it could be much worse.

Meeting the new Openismus Trainees

Uncategorized, , , ,

I was at the Berlin office on Friday meeting our trainer (Daniel Elstner) and two new trainees: David King and Michael Hasselmann (not Mathias). They should all blog more, at least when they start in January.

I am very positive about these guys. I stressed how we want them to develop good habits based on empathic consideration for the users and developers who will use their code and real understanding of the languages and APIs they use. We want to build excellent developers who are an example to others. Character and communication was a major issue when choosing these trainees via email and they show that in person.

This is an important step for the company. It makes it easier to predict when we will have new developers available and helps us to merge those developers into a cohesive culture. It also means that we’ll have more full-time people to help out with unexpected extra work. I’m proud that we’ve stuck to our 35 (productive) hours-per-week rule instead of pushing our people to be stressed and unproductive, and now that will be easier.

The Berlin office is coming to life too, with 5 people there. Overall we’ll now have 11 employees (3 part-time), which feels substantial to me.

Scanner for Linux?

General, ,

Can anyone recommend a fairly recent model of scanner that is absolutely sure to work with Ubuntu Linux. I guess that means that it will work with the “XSane Image Scanner”, from inside Gimp, and with the gnomescan project’s “flegita” GUI. By recent I mean widely available to buy now.

I have too many paper-only documents so I want to back them up electronically.

As usual, the information about supported hardware out there is rather vague, with wildly differing interpretations of “works ouf of the box”. If you need to compile a driver or edit a text configuration file then it didn’t work out of the box.

Update: I don’t really want to buy an all-in-one device just to get a scanner. I already have a printer.

Trainees Chosen

General, , , ,

The response to my call for Openismus trainees was excellent. I have now selected two trainees who will start in January 2009 and I really wish we could afford to take a couple more. I’ll announce the names soon. Furthermore, Daniel Elstner will return to Openismus to train them in the Berlin office, starting in December.

I think I’ve replied to everyone personally. If I’ve missed anyone, please do email me again so I can give you a more specific response.