Niels’ Homepage

I recently started to have a look at the LibreOffice code to see if I could contribute to it. On their developers web page there is a nice tutorial on how to install all the build dependencies for it using Debian based Linux distributions like Ubuntu. If you want to get rid of all these dependencies after a while, for example because you are no longer interested or you need the disk space, it is very hard to delete them. Fortunately I found a working solution here.
To make things a bit easier I built a script to for command line use that can be downloaded here:

1
2
3
4
5

#!/bin/bash
 
sudo aptitude markauto $(apt-cache showsrc "$1" \
    | grep Build-Depends \
    | perl -p -e 's/(?:[\[(].+?[\])]|Build-Depends:|,|\|)//g')

It can be invoked as follows (assuming it is in your PATH):

build-dep-rm openoffice.org

I want to emphasize that I did not invent this method, the credits should have to go to the persons that posted the solution on Launchpad.

In the previous installment a skeleton Autotools project was created. In this installment the usage of libraries for the application code will be added. I like putting my application data into libraries as it makes it more convenient to reuse the code, e.g. when doing unit testing (which will be shown in a later installment).

In this installment a skeleton setup for handling libraries using Libtool will be presented. At the end the methods to link against the static or dynamic libraries will be shown. The created library will be a very trivial one but the created skeleton should be enough to expand on this.
Continue Reading »

For most software projects that go past the trivial state a build environment can assist in helping with finding dependencies, providing alternatives, documentation creation, unit testing, etc. One of the most flexible environments are provided by the GNU Autotools, but setting up a new Autotools project can be a bit cumbersome. It always seem to give me the feeling that I have to rediscover everything about the GNU Autotools and to avoid making the same mistakes over and over again I kept a lot of notes. The disadvantage of personal notes are of course:

• They get disorganized
• They are hard to keep up-to-date
• They are not always available
• It is difficult to transfer the knowledge contained in them to another person

So therefore I decided to do what I always do to solve these issues: I publish the knowledge on a subject that I obtained so far on my homepage. It will be series of installments, each building on the knowledge from the previous installments. In this first installment a trivial ‘Hello, World!’ project will be created. Later installments will provide information on:

• Creating and using libraries
• Creating and using unit tests
• Creating documentation with Doxygen
• Creating documentation with Docbook

But more subjects might be added in the future. It is also most likely that new insights will be added to already published parts and I will try to indicate the new additions as good as possible.

Since I consider these my personal notes they are not a replacement for the full GNU Autotools documentation and other resources. For more in-depth information the following on- and off-line resources are recommended:

• The Autotools tutorial by Alexandre Duret-Lutz. It not only provides a nice tutorial in the form of a presentation but also provides a lot of links to other resources.
• Autotools: a practitioner’s guide to Autoconf, Automake and Libtool by John Calcote. based on these he published a book with the same name. Highly recommended.
• One of the first books published on the GNU Autotools was the so-called ‘Goat Book‘ by Gary V. Vaughan, Ben Elliston, Tom Tromey and Ian Lance Taylor. It has since been published on-line and, although it is not the most accessible text on the subject, it still contains a lot of good information.

Although I consider these my notes, complete with rough-edges and warts and all, and by no means a complete tutorial on the subject I do still appreciate any remarks or comments. Nowhere will a setup guide for the used tools be given. These differ to much from system to system and with the use of Google resources with better information than I can provide should be available.

Continue Reading »

Since a few days I am using the Pathogen plug-in together with the scripts from GitHub as described here. I think it is a wonderful way to maintain my personal ViM installation. However, after installing and trying OmniCppComplete I got the following error messages when attempting to complete something:

-- Omni completion (^O^N^P) Pattern not found

After a while I found out that the used complete-function ‘omnifunc’ was set to:

ccomplete#Complete

This is the generic completion function for C-based programs and does not work well with C++-programs. To fix this add the following line to .vimrc:

au BufNewFile,BufRead,BufEnter *.cpp,*.hpp set omnifunc=omni#cpp#complete#Main

This should leave you with a working OmniCppComplete plug-in managed from the vim-scripts repositories at GitHub.

Ik heb me net heerlijk zitten ergeren aan een artikel op de Computable website. De stelling is dat het introduceren (het gebruik wordt niet eens genoemd), van Linux in een bedrijfsomgeving verborgen kosten met zich mee brengt. Dat zou helemaal waar kunnen zijn, maar de auteurs Johan Zwiekhorst en Jozef Schildermans van Data TestLab slaan volgens mij op een aantal punten behoorlijk door. De argumenten op een rijtje:

• Bovendien is opensourcesoftware minder populair dan Windows, zodat vandalen het vooralsnog grotendeels met rust laten…Echt waar? Zouden de onderzoekers wel eens een gekeken hebben naar de echte getallen over Open Source? Apache, iemand? PHP? Java? Bovendien gaat het begrip Open Source veel verder dan alleen het operating system, dus het begint al door appels met peren te vergelijken.

• Zoals je waarschijnlijk wel weet, bestaan er honderden Linux-distributies. De toon lijkt nu wel gezet. Feitelijk en tendentieus.

• De basis van die bundel is de linux kernel: die is hetzelfde voor iedereen. Daarbovenop komt het GNU/Linux platform. Kennis van GNU/Linux ontbreekt blijkbaar bij de auteurs: de kernel is niet bij alle distributies hetzelfde. Ze zijn wel gebaseerd op dezelfde broncode, maar vaak aangepast door de maker van de distributie om zo goed mogelijk aan te sluiten bij de doelgroep van de distributie. De opmerking dat het GNU/Linux platform erbovenop komt is natuurlijk onzin. Het heet GNU/Linux omdat een Linux kernel wordt gecombineerd met de GNU applicaties om een operating system te maken. Richard Stallman zal het niet waarderen dat de GNU applicaties GNU/Linux worden genoemd.

• Als je een Windows-gebaseerde server draait, dan moet je die clientlicenties betalen ongeacht het gebruikte desktopsysteem. Wat een raar argument. Als het een homogene Windows-omgeving is, moet er ook voor zowel de client als de server licenties betaald worden. Bij Linux ben je in ieder geval nog het bedrag voor het desktop operating system kwijt.

• Zo blijkt het erg moeilijk om computers van A-merken te kopen zonder Windows erop. Dat is alleen Microsoft aan te rekenen. Dus feitelijk weer juist, maar het lijkt mij eerder een argument om zo snel mogelijk te stoppen met het gebruik van Microsoft producten, want daardoor wordt blijkbaar de prijs van apparatuur onnodig opgejaagd.

Afgezien van de hierboven beschreven argumenten, staat het artikel bovendien vol met taal- en/of typefouten. Ik ben benieuwd naar het vervolg op dit artikel op 12 april, maar gezien de argumentaties in dit artikel vrees ik het ergste.

If PHP ever gives you the following error (I just encountered it while developing with the Yii Framework):

Cannot modify header information - headers already sent by

Then you probably injected some whitespace somewhere in your output. The easiest way to avoid that is by not using the PHP closing tag ‘?>‘ at the end of PHP source files. Some people are against that but if I look into the sources for Yii and read the Zend Framework Programmer’s Reference Guide then it is obviously a well established method of avoiding the mentioned error.

As a passionate and seasoned user of the best editor in the world I always look around for ways to improve the editing experience. One way to improve that is by selecting a good color scheme. The ViM website offer a ton of color schemes but no way to sample them other then look at the user ratings, install them and then judge for yourself. And even then the color schemes on the ViM site are not all schemes that are available.

Fortunately someone wrote a page where, as far as I know, all color schemes are shown and downloadable. Even my two favorite ones: here and here. The only minor annoyance is the fact that the color schemes are not all alphabetically ordered.

I know, I know, old news, but I still like to use this web site as my own long term memory…

There is a new release of the NanoBlogger Gallery plugin. The previous version had a problem when run in Bash versions below 3.1. There are some differences when initializing arrays from a ‘string’ using $IFS.

In Bash 3.1 you can do this:

1
2
3
4
5
6
7
8

#!/bin/bash
 
a="1.2.3"
IFS='.'
declare -a arr=( $a )
echo "${#arr[@]}"
 
# Outputs 3 in version 3.1 and 1 in version 3.0

But if you instead do this then it works in both versions:

1
2
3
4
5
6
7
8
9

#!/bin/bash
 
a="1.2.3"
IFS='.'
declare -a arr
eval "arr=( $a )"
echo "${#arr[@]}"
 
# Outputs 3 in version 3.1 and 3.0

So hopefully the Gallery plug-in is better prepared for the real world :). Thanks to Chris Gratham for helping me out with this.

The new version can be downloaded here.

NanoBlogger is a minimalistic approach to blogging as vi (or ViM) is a minimalistic approach to editing. Okay, not as minimalistic as ed or ex, but you get the idea.

Using ViM as the default editor for NanoBlogger is as simple as setting the variable $EDITOR in .bashrc, $BLOG_DIR/blog.conf or, if you want control of NanoBlogger settings for each machine that you work on, $HOME/.nb.conf.

But the default settings for editing entries or articles are not particularly nice. Fortunately ViM can have settings on a per-file basis using modelines (if you don’t know what they are just type :h auto-setting on the ViM command line). To make editing with ViM a bit nicer, just edit the following files:

• $BLOG_DIR/templates/entry.metadata
• $BLOG_DIR/templates/file.metadata

and add the following line at the end of the file:

vim: set ts=4 sw=4 ff=unix fo+=t et:

This should provide you with some decent ViM settings across all machines that you are working on.

WARNING:
NanoBlogger versions <=3.3-RC5 have a bug that will overwrite the template files with the default template files and undo your modeline setting. This can be fixed by either using a later version (not available at the time of this writing), using the CVS version or editing the file lib/tools.sh in the same directory where your NanoBlogger binary is. Search for a line that has the following:

$NB_TEMPLATE_DI/

and change that to:

$NB_TEMPLATE_DIR/

I use this weblog as a brain dump. Not only to be able to remember long forgotten stuff, to make sure knowledge is not forgotten but also to share knowledge with others.

If you do a lot of C++ programming it is almost unavoidable to use the STL and at some point you probably will end up defining your own templates. This is not a bad thing since you then make use of the strengths of the C++ language.

The problem starts when you make a programming error using a (STL) template. The error messages from the compiler are cluttered with so much noise that it is often very hard to spot where the error has been made. Fortunately someone has written a filter (STLFilt) to parse these cryptic messages and make them more readable. It works with most compilers although support for GCC is a bit behind. Support for version 3.4.x and up is worked on. My experience, however, is that it is still very usable for GCC version 3.4.x and up.

You can find a distribution of STLFilt for your compiler here.