It’s been a while since I had to use Eclipse, and last time I did I was really disappointed at the lack of a real text editor embedded in it. There were a few Vim plugins for Eclipse back then, but all of them where paid. Luckly now there seems to be a decent open alternative: http://vrapper.sourceforge.net/documentation/
Vrapper provides pretty decent text editing capabilities for Eclipse, I’d almost say it makes it usable. And, as a beneficial side effect, now your coworkers wont’ be able to touch your Eclipse anymore!
We all more or less know the list of operators that C++ provides for “normal code” but not everyone is aware that the preprocessor also has special operators we can use. Small difference: an operator like ‘+’ will usually operate on numbers, but the preprocessor operates only on a single concept: source code tokens. What kind of operators could a preprocessor have, then? Two, actually. Let’s start with the simpler one:
The ‘#’ operator is the simplest operator of the preprocessor: it converts the next token to string. Something like this, for example:
#define f(x) to_str(x) == #x f(123)
to_str(123) == "123"
A restriction applies to the stringify operator: it can only be applied to a macro param, not just any token. So this, for example, is an illegal macro:
#define f(x) #123 == #x
There’s another operator, which is a bit more “esoteric”. We’ll talk about token pasting next time.
Have you ever run into this error message on git before?
fatal: example.com/repo.git/info/refs not found: did you run git update-server-info on the server?
It can be very baffling, because it may happen even if you change absolutely nothing in your git’s configuration. I’ve read most people attribute this to a typo, and that seems to be the most common case, but I found yet another thing that might trigger this error: if you have set a proxy server, for example for wget, using an environment variable like http_proxy, https_proxy or ftp_proxy then git might be tripping up on your proxy and producing this error message.
Lately, out of curiosity, I spent some time to better understand how the C preprocessor works. I admit it, I thought it was a very dumb copy-paste based replace mechanism, only capable of doing the simpler keyword matching and replacement. Boy, was I wrong. Turns out the preprocessor is actually an organically grown pseudo language (as opposed to a properly designed language feature) inside C, which later got standardized through an incredibly complex set of rules and definitions. Rules for recursion, expansion, pattern matching and crazy operators like # and ## are some of the things that I never before knew existed in the preprocessor.
During my time toying with the preprocessor I learned a few things about recursion, the different operators supported by it and some crazy things about the order of conditional evaluation. I’ll summarize some of the things I learned in the next few posts: you might want to check 16.3 in the C++ standard, since the next few articles will be only explanations about different paragraphs on this section.
Disclaimer: if you find any real-world utility to these bits of preprocessor trivia, you are probably doing something horribly wrong or horribly evil!
So, your code is ferpect. It compiles cleanly with all warning options maxed out. You have already added -ansi, -pedantic, -Wall, -Wc++0x-compat, -Wextra and it all works. Even -Weffc++ emits no warning. And then, a wild third party library appears; your beautiful compile log is now littered with “initialization out of order” and “should declare a virtual destructor” warnings. What to do?
When including a third party library (like, for example, boost) you will almost never have the option to fix any of the diagnostics that your compiler helpfully provides you. If there’s nothing you can do about them, there’s no point in getting the warnings either. Disabling -Weffc++ is also not a good idea. If you already took the effort of cleaning your code to such a high standard, you shouldn’t now relax it.
There’s a third option: When compiling don’t include those libs as “-I /path/to/lib”, do it as “-isystem /path/to/lib”. Gcc will now know those warnings are not your fault and it will stop nagging you.
On any your .git/hooks folder; add this script in .git/hooks/post-merge (and don’t forget to chmod +x it):
ctags -R -f .ctags .
Now every time you do a git pull your ctags file will automagically update. You might also want to copy or ln -s this script for the post-commit hook, if you want to run a ctags update on each git commit. Be aware that this will make your commits slower, if generating your tags file takes a long time.
Extra tip: “-f .ctags” will make ctags write into a hidden file, .ctags, which you can then add to .gitignore. Now ctags magically works in Vim and you won’t even need to see your tags file (just don’t forget to “set tags=./.ctags;/” on vim).
TL;DR: Link to a mostly working hacked version of Pictag, on my Github repo.
Since Google decided not to support Picasa for Linux anymore (yes, a long time ago) I’ve been looking for a decent photo management alternative. Lately I’ve settled with Digikam, it does everything Picasa used to do (and much better, I may add) except for providing a way to geotag your pictures on a map.
Most geotagging solutions involve having an already created waypoints map from a GPS device, which then gets processed and magically added to the images’ exif data. That didn’t cut it for me, I don’t have, nor want, a GPS I can take on holidays, plus I really only want to drag and drop pictures on a map. That’s where pictag comes in.
At the moment pictag seems to be a bit abandoned, as there are no more packages for Ubuntu 13.04. Luckily with some hacking it’s possible to get it running.
First, since there’s no package for Pictag you’ll need to take care of the dependencies yourself. On a more or less vanilla 13.04 install, this should do the trick:
sudo apt-get install python-setuptools \ python-distutils-extra \ geoclue-ubuntu-geoip \ liblaunchpad-integration-common \ libchamplain-0.12-0 \ libchamplain-0.12-dev \ libchamplain-gtk-0.12-0 \ libchamplain-gtk-0.12-dev \ python-pyexiv2 \ libclutter-gtk-1.0-0 \ libclutter-gtk-1.0-dev
After you’ve taken care of that you can download the latest version from Launchpad (while writing this article that should be 12.07.17) and run ./bin/pictag, only to watch it fail miserably.
Pictag seems to be using GSettings, a very annoying Gnome settings manager which won’t work unless you actually install whatever program you’re trying to run. Luckily we can just hack it out of Pictag simply by commenting out all references to self.settings in PictagWindow.py and Window.py. Either that or get my hacked version of Pictag, on my Github repo.
With some luck, my hacked version of Pictag should run pretty much OK on Ubuntu 13.04 or newer. There seems to be a few issues with libchamplain (the mapping library) on earlier versions of Ubuntu that may cause the map to display only broken images. If you can’t load any maps you’ll have to get a newer Ubuntu. Or fork my repo and get hacking 🙂