daskrachen

Adieu

2012-07-15T12:11:00.000+02:00

This blog will be continued at my new domain at bastibe.de.

Sorry that I could not migrate all the comments and links.

How to gem install rlua on OSX/homebrew

2012-02-22T11:43:00.002+01:00

If you want to use rlua, you need to have Lua installed. However, OSX does not come with Lua preinstalled, so you install it using

brew install lua

Oh, would it be nice if everyone agreed on how to install stuff like this. Case in point, homebrew installs liblua (quite reasonable) in /usr/local/lib/liblua.[5.1[.4]].dylib

rlua however expects it to be called liblua5.1.dylib (notice the missing .).

Similarly, the headers are installed plainly into /usr/local/include, whereas rlua expects them to be in a folder called lua5.1.

Hence, here is how you get rlua to install:

ln -s /usr/local/Cellar/lua/5.1.4/lib/liblua.5.1.4.dylib /usr/local/lib/liblua5.1.dylib
ln -s /usr/local/Cellar/lua/5.1.4/include/ /usr/local/include/lua5.1

Not exactly a beautiful solution, but it works.

Text Editors

2012-02-03T18:22:00.001+01:00

Text<sub>Editors</sub>

As far as I can tell, there has been a resurgence of development in the landscape of text editors of late. Only a few years ago, the text editing scene one the Mac seemed to be dominated by

Crazy unix farts using Vim or Emacs
BBEdit users
Textmate users

During a very short period of time though, a raft of new text editors became available. Sublime Text in particular has been getting a lot of attention and rave reviews by many people. To me, this warrants another look at what these new (and old) text editors are offering.

Vim

Vim is very old software. It is a more or less direct descendant of ed from the early 1970s. It grew up in text based terminals without any graphical windows or mouses. Hence, all of its functionality is really meant to be used from the keyboard only, even though mousing is supported these days.

The terminal inheritance limits its graphical capabilities somewhat. There are no graphical drawers or animations or pixel-precise scrolling. Everything is displayed in terms of rectangular characters, hence scrolling can only ever scroll one line at a time and there are no graphical images anywhere. Since Vim predates graphical displays altogether, it does not adhere to its standards much. In fact, in its normal mode it won't even type out the characters you hit on your keyboard.

This is at really Vim's greatest strength and weakness: In its 'normal mode', all key presses are interpreted like keyboard shortcuts in other programs. And what shortcuts there are! Pretty much every key on the keyboard has some special function, most keys even serve multiple functions depending on what mode you are in at the moment. Thus it should come as no surprise that you can do anything with these shortcuts at astounding speed. Watching a seasoned Vimmer do his keyboard dance is something to behold. Moving the cursor is especially powerful. Usually, any place in the current file is reachable using just a few key strokes. But of course, you are not limited to just viewing one file at a time either: Vim supports arbitrary split views and can even be used for efficient diffing or merging. And when it comes to changing that text, Vim is no slouch, either. There are various registers for saving text or locations, there is an increadibly powerful macro system, amazing searching capabilities, command line integration, there are specialized functions for programming… Really, when it comes to pure text editing chops, nothing beats Vim.

Vim is also incredibly customizable. Of course, there is no graphical preferences windows to do the customization in. You customize Vim by editing simple text files. Vim even includes its very own scripting language, VimScript, to enable users to extend it. There is a huge wealth of plugins available. These range from file browsers to support for new languages, or even some limited integration with compilers or source control tools. However, VimScript is not exactly a very pleasant language to code in and Vim does not actually like to interface with external tools much. These two issues limit the scope of what is possible with Vim somewhat–deep compiler integration and graphical debugging are fiddly at best, so you will probably just keep a terminal open and do them there. That said, the plugin ecosystem for Vim is probably still leaps and bounds beyond what is possible with most other text editor out there, but it does not quite reach the same breadth or integration as some IDEs or Emacs do.
All that power comes at a price. Learning Vim is hard. If you start out with Vim, it will probably take at least a week or so until you can approach your old productivity again. Mastering Vim will take years. Even after months and months of diligent learning, you will find some new tricks and features to increase your speed.

At the end of the day though, Vim is an amazingly powerful tool, and it is certainly worth it to at least learn the basics of it. Actually, most people I know who tried it have actually stuck with it. Myself, I have some two years of Vimming under my belt, too, and it has proven to be a very important tool for me.

Emacs 24

The thing you have to realize about Emacs is that… Emacs is powerful. People have called it the thermonuclear text editor, and for a reason. Emacs can edit text, of course, but that is really only the most mundane of its features. Really, Emacs is a little world of its own. You can read and write your mail from within Emacs, you can do spreadsheets, calendaring, it can host terminals, debuggers, compilers, there is Tetris, hell, it even includes its very own psychiatrist! Speaking off the record here, I have a suspicion that Emacs might achieve sentience pretty soon.

Similar to Vim, Emacs is old software. It was invented in the late 1970s at MIT and has been growing ever since. Also like Vim, its terminal inheritance shows its teeth sometimes: mouseweel scrolling can be awkward, especially if you like your inertial scrolling, the menu bar seems to not get much love and keyboard shortcuts are not conformant with what you might be used to from other text editors. On the other hand, Emacs has some very modern features like mixing of proportional fonts and fixed-width fonts or inline image display.

The upside of being old is that Emacs is very mature software. There is a ginormous selection of extensions available for Emacs, most of it actually distributed right with Emacs itself and a lot of it is superbly documented. Besides that, there are several integrated repositories for additional tools that can be downloaded and installed from the internet.

The real power of Emacs is in that it is really not so much a text editor but a virtual machine for a programming language called eLisp. Really anything that can possibly be written in Lisp and remotely involves text editing is possible and probably already available in Emacs. As such, Emacs probably has the most diverse feature set of any text editor out there. Most relevant to programmers will be debugger integration, automatic syntax and spell checking, powerful and context-aware autocompletion, refactoring capabilities and much much more. Emacs is the only program in this list which can actually be used as a full fledged IDE on its own.

But Emacs is not limited to programming at all. As mentioned before, it includes an Email client, a great calendar with an agenda, several IM clients, RSS readers, an astoundingly powerful outliner and spreadsheet editor, it is frequently used for blogging, writing screen plays, books or really anything you can think of.

The only real downside to this is that Emacs is, well, old. There is great power there, but is is only accessible to those willing to learn the myriad key combinations to invoke it. Rellay, mastering Emacs is a task for years, not weeks. But of course, you are not forced to wield all the power Emacs has to offer at once. Getting up to speed with basic text editing in Emacs will only take a few minutes, and the built-in help system and tutorial will guide you further whenever you feel the need to explore.

I have been using Emacs for several months now and I am really enjoying it. It has a few shortcomings, but it is constantly being improved and getting more modern every day. I can see myself giving in to it and just live in Emacs all day long, but for now, I'm happy with it just being my primary text editor. However, I can't quite get beyond the fact that its pure text editing chops are nowhere near Vim. Then again, Emacs does support Vim key bindings, so this might turn out not to bother me in the long run.

At any rate, I would recommend anyone to give Emacs a shot at least for a short while. The power of Emacs can be an exhilarating experience, really.

Textmate (2)

For the longest time, all GUI text editors could generally be classified as either Vim-based, Emacs-based or shortcut-based. The prevalent crop of shortcut-based GUI text editors mapped all its advanced functions to certain modifier-letter combinations and/or menu bar items.

When Textmate was introduced, it introduced a new concept: snippets. Snippets are short pieces of text which, upon activating a certain trigger, would expand to arbitraryly complex constructs.

Thus, to define a class in some programming language, you would type `class`, then hit TAB, and it would expand to a complete class declaration with constructor, destructor and documentation. Further yet, the class name would be highlighted immediately, so you could start editing it to your liking. These edits would even automatically percolate to all the relevant places in the class declaration and thus automatically change all scope declarations and the like.
Or, you could drag some image file into some LaTeX code and it would expand (dragging being the trigger here) to a whole `\begin{figure}` complete with `\caption`, `\label`, the correct path to the image and everything else you need.

This has proven to be such a popular feature that since Textmate's inception, implementations of snippets have been developed for pretty much every IDE or text editor out there.

Textmate also featured a very flexible and easily extensible regex based syntax parser, beautiful color schemes, a very elegant project management system and a vibrant community extending it in many directions. This was even more fascinating in that most of this functionality was implemented using a convenient shell scripting engine that could utilize any programming language your shell supported.

Sadly though, its main developer got stuck somewhere along the way and development all but dried up for five years. This primarily meant that some issues just would not be fixed and thus, got all the more jarring. Most prominently, Textmate lacked split views, regex incremental search and would only do single character undo/redos. Many people left Textmate because of this lack of progress.

While I was in college, I used Textmate extensively and it proved to be a veritable tool for many editing tasks. It is somewhat limited in its integration with programming tools, though, so don't expect any complex compiler or debugger integration. Ultimately, I left it behind for lack of cross platform compatibility and lack of development. There used to be a Windows program called E Text Editor, which wanted to become a fully compatible Textmate alternative for Windows and Linux, but development never even reached production quality.

Recently however, an early alpha version of Textmate 2 has been released that could reinvigorate the community and fix long standing issues. Whether that will actually happen will remain to be seen.

Vico

Vico is a very new application that has spung to live only in 2011 and is not finished yet. It aims to be a modern Vim, combining the virtue of the powerful mode-based editing system of Vim with a modern Cocoa interface. It even merges Vim's editing capabilities with Textmate-derived snippets and syntax highlighting.

Really, it tries to be an organic symbiosis of Vim and Textmate. And for most purposes, it very much succeeds in this. Syntax highlighting is very solid, there is a code browser, a nice file browser and full support for Textmate snippets. Vico even includes a powerful scripting environment that enables you to extend it in a language called Nu, which has the interesting aspect of being able to call into every object or method in the Cocoa libraries, thus opening the doors to a boundless world of wonders. Its Vim integration is well on its way, too. The most notable omission at this point are macros. The developer is working on it though and has promised to implement them in the near future. Some other areas are lacking, too, but if development continues I see no reason why it should not become a very nice text editor.

As it stands though, development of Vico is going slow and its community is not very large yet. Vico is a very nice tool, but at the end of the day, I miss the raw power of an actual Vim just as I miss the vibrant community around Textmate. If you are not spoiled by Vim yet or find Vim just a bit too ugly for your taste, you could give Vico a try though.

Personally, I like it quite a bit and I am hoping very much that it will not be forgotten as a failed attempt to modernize Vim. That said, what with Sublime Text 2 including a limited support for Vim key bindings, I can't really see Vico taking off.

Sublime Text 2

Sublime Text is a fairly recent development. It is a one-man project that has gained a lot of enthusiastic following in the last few months. In many ways, it feels like the next step in text editor development. Much like several other text editors out there, it has adopted Textmate snippets, color themes and syntax definitions as its core feature set. On top of that though, it has built a very powerful and flexible extension system that really sets it apart.

Do you remember CMD-T from Textmate? To open some file, you would hit CMD-T and start typing a file name. The name would be fuzzy matched to select from all available files. Thus, typing `bcc` would select `BeaconController.cpp`. This form of selection is increadibly intuitive and fast. It is also the basis for the extension system of Sublime Text. If there is no keyboard shortcut for a command, hit CMD-Shift-P and start typing to invoke the command.

In very much the same way as M-x in Emacs (though with fuzzy matching), this can invoke arbitrarily complex commands such as `install bundle` or using some refactoring library. Additionally, the same mechanism can be used to jump to method names or opening files. Really, these features are very efficient implementations of a code browser and file browser.

The second big thing about Sublime Text is just the ridiculous amount of polish it received. For example, if you have two files with the same name, it will prefix the tab titles with the folder they reside in. Simple, but so useful! If you jump around in a file, there is always a subtle scrolling animation. Even simple text selections have slightly rounded borders and just look amazingly beautiful.

Also of note is that Sublime Text supports multiple cursors. Want to change then name of all occurrences of a variable? Just select them all (!) and change them all at once. This is another amazingly useful feature.
Its plugin system is based in Python, which is a refreshingly non-awkward choice for a text editor and spawned an astonishing amount of very interesting plugins already. Indeed the plugin system is flexible enough to support things like linters, source control integration and even something akin to Emacs's org-mode.
And it also supports Vim key bindings. Not very complete, but easily enough to be useful. Oh, and it is available cross-platform on Mac, Windows and Linux, too.

I think there are three big families of text editors: Emacs, Vim, and shortcut-based text editors. Since I discovered Textmate however, I started believing that it represents a new branch in the big tree of text editors. Sublime Text seems to be the next step in the evolution of the Textmate branch.

Really, Sublime Text is an amazing achievement. Maybe not quite as hackable as Emacs and not quite as flexible as Vim, but easily beating both in terms of elegance and modernity. If you don't want to learn Emacs or Vim, Sublime Text is what you should use. In fact, it is the first text editor ever that has tempted me to leave Emacs and Vim behind. Nuff said.

What else is out there

Of course, that little list up there is by no means complete. Neither does it list all the amazing features these text editors have to offer, nor does it represent an exhaustive list of them. To the best of my knowledge, this is a short list of other text editors for the Mac platform. Note however, that I have never used any of them extensively and can only tell you stuff from heresay.

BBEdit

BBEdit is the big daddy of Mac text editors. It is currently available in version 10 and has a huge follwing predominantly amongst web developers. As far as I can tell, it includes amazing features for editing HTML. Maybe amongst the best out there.
The remainder of its feature set seems rather standard crop though. There is some support for compilation, source code control, snippets, plugins… Though nothing on the level of Vim or Emacs really. Its most important disadvantage is probably its lack of cross-platform availability and extensibility.

TextWrangler

TextWrangler is the free smaller brother of BBEdit. Its feature set is somewhat pared down in comparison with BBEdit. In particular, it is missing BBEdit's famous HTML magic and some advanced external tool integration.
Even for free, there are probably more capable candidates available, though maybe not at the same level of platform integration. That said, TextWrangler is not a bad choice and probably just fine for some casual text editing.

Jedit

I really don't know much about JEdit other than that it is written in Java, it has a sizeable following and it is available cross-platform. It seems like it could be about as useful as any shortcut based text editor can ever be, which is no small achievement. Also, it features a rich plugin system, of which I only heard good things.
For all I know, this could be a very worthy alternative if you are on a budget (no Sublime Text) and don't want to learn Emacs or Vim.

Chocolat

Chocolat is yet another text editor that came into being in the post-Textmate void. It offers a good range of standard features, though notably missing advanced plugins apparently. Apart from that, it seems to be a solid shortcut based Mac text editor that is relatively cheap and actively developed.

Kod

Kod started out as an open source alternative to Textmate. This is quite uncommon for a post-Textmate text editor and worth supporting. After a good start however, the developer found a new job and development has pretty much stalled.

SubEthaEdit

The great thing about SubEthaEdit is collaborative editing. if you want to edit text collaboratively with several people, SubEthaEdit performs the task seamlessly and elegantly.
Beyond that, it is a capable shortcut-based text editor. If you don't need the collaboration feature, you should probably look elsewhere though.

Smultron

Another venerable veteran on the Mac, Smultron used to be a free open source text editor that had a sizeable following. However, the developer ceased development at some point and later restarted the effort as a paid app in the Mac App Store.
Smultron lost most of its following in that transition.

SlickEdit

SlickEdit is easily the most expensive text editor in this list. A single user license for one platform and one developer costs a scant 300 bucks. That is a lot of money for a text editor and is usually only shelled out only for business critical platform exclusive IDEs. It seems as if SlickEdit tries to be exactly that for general purpose text editing.
It's feature list reads very well and checks all mayor boxes. It is available on pretty much any platform out there and is probably only rivalled by Emacs or Vim in that regard. It also supports emulation for Emacs or Vim key bindings.
That said, 300-600 $ per developer is a pretty hefty price tag. Personally, I doubt that SlickEdit can live up to that price if you compare it to some of the other examples in this list. It is undoubtedly a well-maintained and powerful text editor though.

Komodo Edit

Komodo Edit is the free open source offspring of ActiveState's Komodo IDE. It's feature set is very complete and seems to be very worthy for many editing tasks. Being of IDE ancestry provides it with nice plugin support and very helpful deep language integration like sophisticated autocompletion and syntax checking.
There are also quite good Vim key bindings and it is available on the three major platforms. However, its language support is limited to Perl, Python, Tcl, PHP, Ruby and Javascript. Probably not a bad choice if you can live with the language selection and are on a budget.

TextEdit

The built-in text editor in OSX. No syntax highlighting, project management or any programming support whatsoever make this a rather poor choice. There are plenty of free alternatives out there.
That said, TextEdit does support rich text editing and might be of value for the odd letter to your grandma.

Text editors for web development

Strangely, all the major Mac text editors that cater specifically for web development are not cross platform. If web development is all you are ever doing though, these text editors might be well worth their money.

Coda

Combine the SubEthaEdit text editing engine including its collaborative tools with the great FTP program Transmit and you have CODA, the program for "one-window web development". It even includes a reference book to HTML in the package. For what it is, probably of great value and nice polish. As a general purpose text editor, there are better alternatives.

Espresso
Another text editor gearing specifically for web development. Thus, you get powerful HTML and CSS editing features and good support for typical web development languages such as PHP, Ruby or Markdoen, but no support for other languages. There is an extension system though that could improve language support. This might be a slightly less expensive alternative to Coda.

Taco HTML Editor Another text editor geared exclusively towards web development. This time around though, there is no support for languages other than HTML, CSS and PHP, which makes this program a rather poor choice.

skEdit
skEdit supports a nice array of web development languages and offers a good range of features for a web development text editor. Also, it is pretty inexpensive in comparison to its brethren here. Probably a nice choice for web development if you are on a budget.

List of major text editors on the Mac:


Name	Current version	Price	Availability
Vim	7.3.315	Open Source	cross platform
Emacs	24.0.92 pretest	Open Source	cross platform
Textmate	v2 Alpha	45 EUR	OSX (and E on Win)
Vico	1.3	32 EUR	OSX only
Sublime Text 2	Build 2165	60 USD	Win, OSX, Linux
BBEdit	10.1.1	40 EUR	OSX only
TextWrangler	3.5.3	Free	OSX only
Jedit	4.5pre1	Open Source	cross platform
Chocolat	0.057	50 USD	OSX only
Kod	0.0.3	Open Source	OSX only
SubEthaEdit	3.5.4	30 EUR	OSX only
Smultron	4	5 USD	OSX only
SlickEdit	2011 / 16.1.0	300-600 USD	cross platform
Komodo Edit	7.0.0c2	Free	cross platform
TextEdit	1.7	builtin	OSX only
Coda	1.7.5	100 USD	OSX only
Espresso	2.0.1	80 USD	OSX only
Taco HTML Editor	3.0.2	25 USD	OSX only
skEdit	4.1.5	30 USD	OSX only

How to make Tagbar work with Objective-C

2011-12-04T20:21:00.001+01:00

For the longest time, ctags did not support Objective-C. Without tags, many of the cool programming-related features of Vim simply didn't work. (There are ways to coax other programs to output tags, but this is usually painful)

Recently however, ctags finally gained support for Objective-C! Hurrah!
As of today, Objective-C support is not in the stable branch yet, but thanks to the magic of homebrew, an Obj-C ready ctags is only a brew install ctags --HEAD away!

With that, tag navigation in Vim works for Objective-C. Awesome!
However, Tagbar does not work yet. There used to be a workaround that apparently worked for some people, but it did not work for me.
Things like this drive me nuts. I can see that tags are being generated, but Tagbar won't show them. What is going wrong?

Some investigation proved: There is simply no template in Tagbar for Objective-C! Luckily, that can be fixed quite easily: Simply put this code in your .vimrc:

" add a definition for Objective-C to tagbar
let g:tagbar_type_objc = {
\ 'ctagstype' : 'ObjectiveC',
\ 'kinds' : [
\ 'i:interface',
\ 'I:implementation',
\ 'p:Protocol',
\ 'm:Object_method',
\ 'c:Class_method',
\ 'v:Global_variable',
\ 'F:Object field',
\ 'f:function',
\ 'p:property',
\ 't:type_alias',
\ 's:type_structure',
\ 'e:enumeration',
\ 'M:preprocessor_macro',
\ ],
\ 'sro' : ' ',
\ 'kind2scope' : {
\ 'i' : 'interface',
\ 'I' : 'implementation',
\ 'p' : 'Protocol',
\ 's' : 'type_structure',
\ 'e' : 'enumeration'
\ },
\ 'scope2kind' : {
\ 'interface' : 'i',
\ 'implementation' : 'I',
\ 'Protocol' : 'p',
\ 'type_structure' : 's',
\ 'enumeration' : 'e'
\ }
\ }

With that, Tagbar should work. Admittedly, it won't work perfectly yet. Class definitions will show up in addition to their contents and the contents of all categories will go into the same list. Also, you won't get much more than a flat list of functions with no way to distinguish between class methods and object methods. This can be confusing at times, but by and large, it does the job!

Happy Vimming!

Compiling Scipy and Matplotlib again

2011-10-13T15:27:00.003+02:00

Well, it's compile time again. Once again, I need to install scipy and matplotlib using homebrew and pip on Lion.
It seems things have improved since I tried to compile last time! Well, it still does not work out of the box, but at least now it can be done without compiling by hand:
(remember to brew install pkg-config and gfortran first)
pip install -e git+https://github.com/scipy/scipy#egg=scipy-dev
pip install -e git+https://github.com/matplotlib/matplotlib#egg=matplotlib
I must say, this is still a mess. But at least, it is getting less bad.

Adobe AIR Application Crashes

2011-09-03T13:08:00.001+02:00

Adobe, oh Adobe. Why?

Your updater pops open. Adobe AIR 2.5, if I remember correctly. It runs, and after that, all AIR applications stop working. They boot, then crash and barf up a crash report.

Turns out, this is a problem with case sensitive file systems. If your file system is not case sensitive, you are experiencing some other problem and this fix is not for you.

See, Adobe has this library called WebKit.dylib. However, their code actually looks for Webkit.dylib (note the capitalisation of the K). Well, spelling is hard, I presume.

At least this is an error that can easily be fixed. Fire up your terminal, type

cd /Library/Frameworks/Adobe\ AIR.framework/Version/Current/Resources/

sudo ln -s WebKit.dylib Webkit.dylib

Then enter your password and your AIR applications should work again.

Dear Adobe, is it too much to ask to pretty please make your software work on a case sensitive file system? Spelling is primary school stuff. It is really not that hard!

Compiling Scipy and Matplotlib using pip on Lion

2011-08-01T12:40:00.000+02:00

So I upgraded to Lion. Predictably, some things went wrong. This time, the main thing that bit me was that for some reason, pip stopped working. After a bit of messing around with brew, pip and easy_install, I found out it was almost entirely my own fault. I messed up my PATH.

In the meantime, I had uninstalled all of brew's Python, so I had to reinstall. For me, that entails Python, Numpy, Scipy and Matplotlib. Only this time, Scipy would not build. Some obscure error in some veclib_cabi_c.c would report errors. A quick round of googling reveals:

In order to get Scipy to compile, you need to insert #include <complex.h> in

./scipy/lib/blas/fblaswrap_veclib_c.c.src
./scipy/linalg/src/fblaswrap_veclib_c.c
./scipy/sparse/linalg/eigen/arpack/ARPACK/FWRAPPERS/veclib_cabi_c.c

That done, Scipy compiles perfectly fine.

But, that is not enough yet. As this blogpost outlines, Matplotlib is not currently compatible with libpng 1.5, which ships with Lion. Fortunately, this is already fixed in the most recent source on the Matplotlib repo, so you just have to checkout that:

 pip install -e git+https://github.com/matplotlib/matplotlib.git#egg=matplotlib

By doing that, Matplotlib should install just fine.

Seriously though, these PyPi repos are in a very sorry state. Every time I install one of these packages, I have to jump through hoops and spend hours debugging packages that really should work right out of the box. After all, brew, rvm and gem can do it just fine. Why is pip such a horrible mess?

Installing Pygame using Homebrew

2011-03-04T14:16:00.000+01:00

So I want to do audio development on the Mac without using Matlab. An alternative to Matlab is Python, or rather, Numpy, Scipy and Matplotlib. They are awesome for working with audio data. What they don't do however is playing back audio. There are several packages out there that would afford audio playback. If you are serious about this though, you not only want audio playback, you want asynchronous audio playback. That is, you want to send some audio data to the sound card and continue with your program without waiting for the audio to finish playing. This allows continuous audio playback of computer-generated sound.

Pygame is one package that allows this. (I will submit a patch to Pyaudio soon that will enable it there, too). There are pre-built binaries on the Pygame website that you can install easily. But then there would be no easy way to uninstall them, so what I would rather want is to install Pygame using package managers that allow easy updating and uninstallation. My tool of choice on the Mac is of course Homebrew.

Note that although I am mostly interested in audio playback, this post will detail the installation of all modules of Pygame, not just pygame.mixer.

Homebrew won't install Pygame, but it will install all the prerequisites for Pygame. So, let's do that.

brew install sdl, sdl_mixer, sdl_ttf, libpng, jpeg, sdl_image, portmidi

This will install most packages for you. Note that libpng is also available as a system library, so it is installed keg_only, that is, without linking it in your path. We will need to compile against it though, so the next step is

brew link libpng

Now there is still one package missing, smpeg. Sadly, smpeg does not install its headers, so you can't compile against it. To fix that, type

brew edit smpeg

and add the following line just above the two end at the end of the file

include.install Dir["*.h"]

Then save the file. (I submitted a bug to have this fixed, so you might not need to do this when you read this). Now you can install smpeg with the usual

brew install smpeg

and you will get the headers, too. Isn't Homebrew great?

Now that all the prerequisites are met, lets look at Pygame itself. This is rather more difficult, as it will not build properly against Homebrew libraries on its own. First, download the source package of Pygame from the official website. Unpack it to some directory.

Now open a terminal and navigate to that directory. Me, I like iTerm, but Terminal.app will do just fine, too. In there, run python config.py to create an initial setup file.

At this point, the setup file is mostly useless since config.py failed to find any homebrew-installed library. It is also strangely garbled, so there is some manual labor to do. Open the file Setup (no extension) in your favourite text editor. After the first comment block, you will see a line that looks like this

SDL = -I/NEED_INC_PATH_FIX -L/NEED_LIB_PATH_FIX -lSDL

Obviously, this is lacking the paths to the SDL library. If you installed Homebrew to its default directory, this will be in /usr/local…. Hence, change this line to

SDL = -I/usr/local/include/SDL -L/usr/local/lib -lSDL

The next lines are strangely garbled. They say, for example

FONT = -lS -lD -lL -l_ -lt -lt -lf

Where they actually should say

FONT = -lSDL_ttf

Instead of having one -l and then the library name SDL_ttf, they put -l in front of every single letter of the name. This is strange, and certainly wrong. So, correct it for FONT, IMAGE, MIXER and SMPEG.

Note that I did not tell you to do this for PORTTIME, too. Actually, PORTTIME is already correctly linked in PORTMIDI, so you don't need that at all any more. Just delete or comment the PORTTIME line.

Now that all the dependencies are corrected, lets enable the features. A few lines further down, there will be a block of lines, where most lines begin with a # except for the ones beginning with _numericsurfarray… and _camera…, These are the different features of Pygame: The ones with the # are disabled, the other two are enabled.

With all the stuff we installed earlier, you can now enable all features (remove the # in front of imageext…, font…, mixer…, mixer_music…, _minericsndarray…, movie…, scrap… and pypm…).

Remember we disabled PORTTIME a while ago? Right, so we have to remove that dependency: In the line starting with pypm…, delete the part that says $(PORTTIME). Great. That was easy, right? Now save that file and go back to the Terminal.

We are now going to compile and install Pygame. The nice thing is, even though we are installing it manually, it will go in the right directories and it will be registered with pip or easy_install, so you can just invoke them if you want to uninstall it later by typing pip uninstall pygame. This is something I love about Python!

Alright, now without further ado, install Pygame by typing

python setup.py install

Great! That's it! Everything should work now!

Installing Python/Numpy/Scipy/Matplotlib on OSX

2011-02-03T16:23:00.001+01:00

For numerical analysis and signal processing prototyping, you would use Matlab. However, Matlab has some downsides that might make it unsuitable for your project. It might be too expensive. You might be a snobbish programmer that can't stand less-than-elegant programming languages. I certainly am.

So, you look for alternatives. You could take Octave, which is free, but that would not solve that ugly-code issue. You could take any scripting language you fancy, but Ruby, Perl and Python are too slow to do serious number crunching.

Then, you stumble upon that Python package called Numpy, which seems to be nearly as fast as Matlab when it comes to matrix processing and linear algebra. You then discover SciPy, which would add all that signal processing prowess of Matlab (do quick transformations, random numbers, statistics) to your toolbox. Last but not least, you need plotting. That would be Matplotlib then, which provides quick plotting facilities in Python.

And the best thing is, these three systems work really well together. They seem to be the perfect replacement for Matlab that could even be superiour to it in many regards.

Next up, you need to install all that stuff. If you are like me, you naturally want to do all that on a Mac. Also, you kind of dislike all these installer-thingies, which install stuff to unknown places and are nigh impossible to uninstall or update cleanly. Even though, you could of course just go to the individual websites, download Python, Numpy, SciPy and Matplotlib, run them installers, and be done. You would save yourself a lot of trouble that way.

But since you allegedly are like me, you instead fire up brew and try to install all that stuff using that. Again, you could use MacPorts or Fink instead, but you probably had some bad experiences with them and you generally love the hackishness of Homebrew, so this is your natural first try.

So you set about this, you believe in packet managers and trust them to take care of every obstacle that might be lying in your way. First of all, install the latest developer tools from developer.apple.com. You might need to register (for free) to get them. Also, you need to install Homebrew.

To cut this short, here is what you need to get that Python running:

brew install python

This one should be obvious. At the time of writing, it will install Python 2.7.1. You could take Python 3, but matplotlib is not compatible to it, so you kind of have to stick with 2.7.1 instead.

You also need to put /usr/local/bin and /usr/local/sbin in the beginning of your path to make sure the new Python gets loaded instead of the pre-installed one. You do that by writing

export PATH=/usr/local/bin:/usr/local/sbin:$PATH

in your ~/.bash_profile. (Create it if its not there--it is just a simple text file).

Now, if you type python --version, you should get Python 2.7.1 as a response.

Alright, next up, install the python package manager:

brew install distribute
brew install pip

This will come preconfigured for your newly installed Python. In an ideal world, this should be all. The world being as it is, the pip package of Matplotlib is severely broken and has one other unstated dependency:

brew install pkg-config

Also, SciPy is using some FORTRAN sources, so you need a fortran compiler:

brew install gfortran

Alright. That was enough. Now on to pip. With all these dependencies cleared, pip should be able to download Numpy and Scipy without trouble:

pip install numpy
pip install scipy

Matplotlib, on the other hand, is more difficult to install. You see, pip is looking at the Python package repository PyPi for each package. PyPi then provides a URL. Pip then scans that website for links to suitable package files. But, Sourceforge changed its links a while ago, so pip gets confused and will download an outdated version. Sourceforge says, its new links are way better and no way we will change them back; Pip says, well, if Sourceforge can't provide proper links, that's not our problem. Oh My. Silly children.

So we have to do this manually:

pip install -f http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/matplotlib-1.0.1.tar.gz matplotlib

That URL comes straight from Sourceforge. Look for the latest version of Matplotlib, search for the download link to the source distribution (*.tar.gz), copy that link and strip any trailing '/download'.

UPDATE:

It seems the matplotlib package was updated in the meantime, so you can just run pip install matplotlib now.

This should now download and install matplotlib.

Thank you for reading.

The strangeness of widescreen displays in modern operating systems

2010-07-03T12:08:00.000+02:00

So today, pretty much everyone has widescreen displays. That is, displays that are far more wide than high. This was not always so. In ye olden days, computers were mainly used for displaying text, hence displays tended to have a similar layout as books or magazines. Today, they are more like movies (which might be worrying in itself).

So todays displays are widescreen. To do all that modern stuff, like watch (widesreened) videos or multitask (display two windows side by side). However, this also means that vertical pixels are something of a scarcity. Especially on those small Laptop screens. In fact, the first Netbook screens were so tiny that many of Windows' own windows could not be used at all since the lower parts did not fit on the screen. Raise your hand if Word 2007 leaves barely ten lines of visible text between all its blue-tinted UI-splendour on your laptop screen.

This gets most straining when reading text. On the internet for example. There is practically no website at all that can be displayed in its entirity even on one of those full HD displays. Print-formatted documents are a similar matter. Actually, I find myself craving for pixels regularly. I even disable the bookmark bar in my browser to free those extra two lines of text. And I memorize keyboard shortcuts so I can hide toolbars. And I use Google Chrome instead of Firefox/Safari/Internet Explorer, not least of all since it has the smallest title bar and no bottom bar.

Why, then, do modern operating systems still waste so much vertical space with that Dock/Taskbar? This is something I really don't get. Vertical space is such a scarcity, yet virtually every operating system choses to waste at least three lines of text with something that could easily go on the side of the display. Well, at least on Windows 7 and OSX that is something you can easily change.

So if you are like me and appreciate every added line of text, do yourself a favour and put your Dock/Taskbar on the side. Really, this should be the default.

Gedanken zu User Interfaces

2009-04-25T14:15:00.001+02:00

Jeder kennt dieses Fenster:

Dieses Fenster ist eine ziemlich schlechte Idee, denn jeder geübte Benutzer hat irgendwann gelernt, dass die Aktion "Dateien Löschen" aus drei Gesten besteht: (1) Dateien auswählen, (2) Die Löschaktion einleiten, (3) Den Löschdialog bestätigen. Leider hat man schon vor mehr als zwanzig Jahren nachgewiesen, dass solche zusammengehörigen Gesten von den Benutzern als einzelne "Datei-Löschen" Geste abstrahiert werden. Man kennt das vom Tippen: Man tippt Worte nicht, indem man einzelne Buchstaben aneinander hängt, sondern man tippt Worte fast immer am Stück; Hat man erst einmal angefangen, ein falsches Wort zu tippen, kann man damit nicht aufhören, bis das gesamte Wort getippt ist. Auf ähnliche Weise ist es dem Benutzer auch nicht möglich, auf den Löschdialog sinnvoll zu reagieren, da das Bestätigen der Sicherheitsfrage vollkommen automatisiert ist und daher nicht einmal verhindert werden könnte, wenn man wollte.
Die Alternative ist ein alter Bekannter: Undo. Statt den Benutzer im Vorfeld zu fragen, ob er die Datei wirklich löschen möchte (was er durch Einleiten der Löschaktion bereits bejaht hat) gibt man ihm die Möglichkeit, die Aktion im Nachhinein wieder rückgängig zu machen. Das ist wesentlich effektiver und kommt ohne nerviger Dialogbox aus. Übrigens funktioniert Dateiaktion-Undo bereits heute in allen Betriebssystem außer Linux, jedoch ohne Menüicon und zumeist nur für die letzte Aktion. Wäre es nicht schön, wenn dies noch weiter ausgebaut würde?

Noch ein gefährlicher Dialog:

Das ist ebenfalls ein alter Bekannter, der immer dann erscheint, wenn man ein Programm schließen will, welches noch ungesichte Änderungen enthält: Abgesehen von dem offensichtlichen Problem, dass "Abbrechen" keinen wirklichen Sinn ergibt (Was abbrechen? Das Programm?) erfordert diese Frage jedes Mal das komplette Lesen der Meldung, bis man entschlüsseln kann, was "Ja" und "Nein" in diesem Kontext bedeuten. Um das noch einmal zu verdeutlichen, hier ein besonders schlimmes Beispiel:

Es leuchtet ein, dass hier ein eindeutigerer Dialog wesentlich sinnvoller wäre, bei dem sofort ersichtlich ist, was welcher Button tun wird: (Merke: Auf Buttons gehören immer Verben)

Aber warum eigentlich überhaupt speichern? Warum muss ich mich persönlich darum kümmern, meine Arbeit zu speichern? Ich dachte, ich würde mit einer Datei arbeiten -- aber wenn diese Datei nicht geändert wird, wenn ich nicht zuerst "Speichern" anklicke, habe ich wohl eigentlich doch nicht mit dieser Datei, sondern mit einer heimlichen Kopie gearbeitet. Wäre es nicht viel sinnvoller, immer automatisch zu speichern, und statt des "Speichern"-Buttons eine "auf Urzustand zurücksetzen"-Funktion bereitzustellen? Ich bin mir auf jeden Fall sicher, dass man den "Undo all changes"-Button wesentlich seltener bräuchte als den "Speichern"-Button, denn wenn der Benutzer nicht vorgehabt hätte, neuen Text in eine Datei zu schreiben, dann hätte er keinen neuen Text in die Datei geschrieben. Hat er dennoch "versehentlich" Text eingegeben, ist das ein klarer "Benutzerfehler", also der logische Einsatzzweck für Undo.

Das sind nur zwei Beispiele, wie man intelligente Undo-Mechanismen sinnvoll einsetzen könnte, um das Arbeiten am Computer angenehmer zu gestalten. Ich wünschte, mehr Leute würden sich mit diesen Dingen auseinander setzen...

Tagged File System

2009-04-19T09:41:00.000+02:00

Ein großes Problem bei der Benutzung von Computern ist, dass unerfahrene Benutzer oftmals kein Verständnis für Ordnerstrukturen haben. Das ist im Grunde auch klar, denn die Ordner-Metapher legt nahe, dass sich Ordner auf dem Computer wie echte Aktenordner verhalten, also dass jeder Ordner mehrere Dateien, jedoch nicht andere Ordner enthalten kann. Ganz im Gegenteil dazu basiert aber eine normale Verzeichnisstruktur meist aus vielen, tief ineinander geschachtelten Ordnern. Von einem Usablitity-Standpunkt aus ist daher der Begriff "Ordner" wahrscheinlich schlecht gewählt. Vielleicht würde es schon reichen, den älteren Namen "Verzeichnis" wieder einzuführen. (Dann bräuchten wir nur noch ein passendes Piktogramm für "Verzeichnis"...)

Es wäre daher wünschenswert, eine einfacher zu verstehende Alternative zu Ordnerhierarchien zu haben. Die gibt es auch schon, in Form der bekannten Verzeichnisse "Meine Bilder", "Meine Dokumente", etc.
Diese Ordner wollen den Benutzer mit einfachen Piktogrammen und klaren Namen dazu animieren, einen natürlichen Ort für seine Dateien zu wählen und so ein wenig Ordnung zu schaffen. Tatsächlich ist dieses Konzept einer Tag-Struktur schon relativ ähnlich, da auch hier nicht davon ausgegangen wird, dass sich der Benutzer selbst um eine tief geschachtelte Orderhierarchie kümmert, sondern nur wenige, einfach zu verstehende Markierungsmöglichkeiten ("Bilder", "Dokumente") geboten werden.

Ein echtes Tag-basiertes System könnte vollkommen ohne Verzeichnisse auskommen, wobei man dann eben beim Speichern einer Datei nicht mehr aus einer hierarchischen Liste von Ordnern den Speicherort auswählen würde, sondern von einer flachen Liste von Tags. Die Usability-Kosten davon wären vernachlässigbar.

Ähnlich würde das Finden von Dateien funktionieren: Statt eine hierarchische Liste von Ordnern nacheinander anzuklicken, würde man eine flache Liste von Tags nacheinander anklicken, jedoch mit dem Bonus, dass man die gesuchte Datei nicht erst bei Anklicken aller Tags, sondern mit großer Wahrscheinlichkeit schon nach ein oder zwei Tags gefunden hätte.

Ein Problem würde jedoch mit Projekten entstehen, die aus mehreren Dateien bestehen. Hier müsste man sicher stellen, dass sie im Dateisystem nur als einzelne große Projektdatei auftauchen und nicht jede einzelne Unterdatei gelistet wird. Das ließe sich zum Beispiel durch "Bundles" lösen, wie sie heute schon in OSX vorkommen (Ordner mit definierter Namesendung und Inhalt werden wie Dateien behandelt) oder einfach durch einen speziellen Tag, der die einzelnen Dateien vor der normalen Suche versteckt.
Dieses Konzept wird übrigens heute schon vielfach verwendet, so ist etwa eine aktuelle Word-Datei nur eine ZIP-Datei, die eine definierte Verzeichnisstruktur mit allen Bildern, dem Text (als XML), einer Vorschau-Grafik etc. enthält.

Ich glaube, dass man mit solch einem Tag-basierten Dateisystem deutlich einfacher arbeiten könnte als mit den heute üblichen Verzeichnisstrukturen. Tja, jetzt fehlt nur noch eine innovative Firma, die sich um die Umsetzung kümmert...

Es geht um Tabs

2009-03-31T20:09:00.000+02:00

Tabs sind kaputt. Tabs waren noch nie eine gute Idee. Tabs werden dafür benutzt, um in einem Programm mehrere Fensterflächen voll Inhalt in nur einem Fenster darzustellen. Speziell zu diesem Zweck entwarf man in grauer Vorzeit eine neue Klasse von Programmen namens Fenstermanager. Fenstermanager erlauben es, mehrere Fenster gleichzeitig darzustellen, gerne auch nebeneinander, hintereinander oder übereinander. Kennt jeder. Und Tabs sind eine Krücke, die genau dieses Prinzip unterlaufen, denn sie organisieren Fenster ineinander.

Aber es ist ja nicht nur das. Wir kennen Tabs schon lange in ganz verschiedenen Formen:

All diesen Formen gemein ist, dass sie wenigstens einen Rahmen bilden, der andeutet, welcher Teil des Fensters sich ändern wird, wenn man einen anderen Tab öffnet. Die Ausnahme: Browser.

Wo hat ein Browser seine Tabs? zwischen Adressleiste und Webseiteninhalt. Bei Firefox (besondere Perversion) sind die Tabs sogar so dargestellt, als würden sie nur die Adresszeile ändern (oben befestigte Reiter), ganz im Gegensatz dazu ändern sie aber sowohl die Adresszeile als auch -viel wichtiger- den Webseiteninhalt. Wenn überhaupt, dann sollten sich die Tabs also am oberen Bildschirmrand befinden, so dass man mit ihnen wenigstens konsistent den kompletten Fensterinhalt ändert. Immerhin hier sieht man bereits Licht: Google Chrome und Safari 4 funktionieren bereits so:

Die Lösung von Safari hat noch ein paar Probleme: Wo verschiebt man Tabs? (Ungeschickt: an dem kleinen Handle am rechten Tabgreifer-Rand), Wieso haben die Tabs keine Favicons? Aber nicht verzagen: Noch ist Safari 4 lediglich eine Beta. Gut hingegen fände ich es, wenn dieses Tabbed-Fenster-Interface nicht nur für Safari, sondern für jedes andere Programm auch verwendbar wäre, also als Feature des Fenstermanagers implementiert würde. Man müsste daran noch ein wenig feilen, aber es würde Einiges sehr viel übersichtlicher gestalten. Snow Leopard anyone?

Weitere gute Ideen rund um Tabs, sortiert nach Browser:

Microsoft Internet Explorer 8
- Tabs werden nach Farben sortiert, je nach dem von welchem Tab aus sie geöffnet wurden
- Im neuen Fenstermanager von Windows 7 werden alle Tabs als eigene Fenster aufgeführt
- Jeder Tab läuft in seinem eigenen Prozess. Bringt aber nix, weil wenn einer abstürzt nimmt er trotzdem den ganzen Browser mit. Ist aber auch noch nur Beta!

Firefox 3 Preview
- Tabs sollen über ein neuartiges Interface beim Wechsel als Miniaturen dargestellt werden, so dass man einfacher zwischen ihnen wechseln kann
- Viele andere nette Vorschläge rund um diese Idee gibts hier: Aza Raskins Blog

Safari 4
- Die Tableiste nimmt keinen eigenen Platz auf dem Bildschirm ein
- Tabs sind am richtigen Ort (oben)

Google Chrome
- Tabs sind am richtigen Ort (oben) aber es gibt dennoch eine klassische Titelleiste des Fensters (im Gegensatz zu Safari 4)
- Jeder Tab läuft in einem eigenen Prozess, daher können einzelne Tabs abstürzen ohne den Browser mitzunehmen.
- Jeder Tab läuft in seiner eigenen Sandbox, was es Angreifern wesentlich erschwert, den Browser hochzunehmen.

Fazit: Es gibt noch viel zu tun, aber anscheinend ergibt sich langsam aber sicher ein Konsens, dass etwas mit Tabs getan werden muss. Es bleibt spannend.

Mirror's Edge

2009-03-29T22:22:00.000+02:00

Ich habe am Wochenende, wie in Twitter schon verkündet, Mirror’s Edge (durch-) gespielt. Ganz kurz: Mirror’s Edge ist ein Videospiel für PC/XBOX360/PS3, im Endeffekt ein Platformer aus der Ego-Perspektive, zwar mit der Möglichkeit, Waffen aufzunehmen, aber mit dem klaren Fokus auf Rennen, genauer: Parkours, dem modernen Hindernislauf, hier mit dem Extratwist: auf Hochhausdächern.

Es wurde schon viel gesagt über dieses Spiel. Müde Story, schlechte Charactermodelle, schlechte Shooter-Elemente, unübersichtliche Atmosphäre, kurze Spieldauer, um nur einige der üblichen Kritikpunkte zu nennen.

Ich sage: Alles Popauswurf. Was Mirror’s Edge versucht, ist die Direktheit und Intimität der Egoperspektive mit dem Flow und der Geschwindigkeit eines modernen Platformers zu verbinden. Faith, der Hauptcharakter ist eine kleine “Eurasierin” (Zitat der Entwickler), deren Eltern in einem Widerstandskampf… Bla, bla, bla.
Es geht um Flow, es geht darum, mit blitzschnellen Reflexen und akrobatischem Geschick einen Weg über die Dächer einer Großstadt zu finden. Es geht darum, nicht stehen zu bleiben, nicht zu zögern. Es geht um Geschwindigkeit und Freiheit, über Straßenschluchten zu springen, zwischen Klimaanlagen und Baugerüsten zu sprinten und immer schneller, immer weiter, den Großstadtlärm hinter sich zu lassen. Nur begleitet von Faiths immer wieder ins Bild ragenden Armen und Beinen, ihrem schnellen Atem, dem Rhythmus ihrer Schritte. Und ja, man stirbt häufig, wenn man sich bei einem Sprung verschätzt oder es doch nicht schafft, den Jägern zu entkommen. Aber um so größer ist die Befriedigung einen komplizierten Run endlich zu schaffen und mit einem perfekten Sprung über eine Häuserschlucht die Polizei hinter sich zu lassen.

Mirror’s Edge perfektioniert den Flow, das Gefühl der Freiheit und der Geschwindigkeit. Klar, dass da die Ego-Shooter-Mechanik auf der Strecke bleibt, aber Faith ist auch keine Kämpferin, sondern selbsterklärter Runner. Sicher, die Story ist ein wenig lahm, aber wir reden hier über ein Computerspiel: Die Story hat allein das Ziel, die einzelnen Schauplätze miteinander zu verbinden, und das gelingt ihr. Charakterentwicklung kennt das Spiel nicht, allein der Spieler wird besser. Und auch das ist gut so, denn in den späteren Leveln ist der Schwierigkeitsgrad nicht von schlechten Eltern. Aber Checkpoints sind häufig und fair verteilt, so dass dies selten ein Problem wird.

Ach ja, und der Sound ist genial, selten habe ich mich so sehr in eine Spielfigur hineinversetzt gefühlt wie in Faith. Und die Grafik… Ich könnte hier viel schreiben; Ich glaube schlicht, dass die aktuelle Konsolengeneration im Grunde ein Niveau erreicht hat, auf dem weitere Verbesserungen keine große Rolle mehr spielen. Mirror’s Edge, mit seiner gleißend-Weiß-plus-Farbe Ästhetik zeigt hier eine Welt, wie man sie noch nie gesehen hat, in der Farbe nicht nur als Stilmittel, sondern auch als Wegweiser und tatsächlich Spielhilfe eingesetzt wird: Rot ist, wo es weiter geht. Diese Ästhetik ist schwer in Worte zu fassen und gibt dem Ganzen eine ganz eigene Freiheit, im starken Kontrast zum “realistisch”-Grau-Braun, dem sich so viele andere Spiele verschrieben haben.

Und was bleibt unterm Strich? Ich sage: Das Spiel ist es Wert. Es mag seine Mängel haben, aber allein der Mut, einmal etwas Neues zu machen und nicht dem Einheitsbrei ins Land der Realo-Shooter und der digitalen Nebenjobs zu folgen ist der Beachtung Wert. Einmal nicht schießen zu müssen und stumpfen Missionen zu folgen, sondern in einem Spiel Freiheit zu finden, dass ist eine außergewöhnliche Erfahrung. Wer als Spieler etwas Erfrischung sucht, sollte es probieren. Ich finds geil!

Synchronisieren von Google, Äpfeln, Fenstern und Telefonen

2009-03-28T17:18:00.000+01:00

Ich hatte lange Zeit zwei Computer, einen Desktop und einen Laptop, jeweils mit verschiedenen Betriebssystemen und Datensätzen. Um dennoch immer mit den selben Daten arbeiten zu können, verwendete ich eine externe Festplatte. Obwohl sehr low-tech, funktionierte diese Lösung absolut tadellos: Meine Linux-Kisten mounteten die Festplatte automatisch in ihr jeweiliges home-Verzeichnis und so konnte ich auf verschiedenen Computern arbeiten, ohne mich um die Synchronizität der Daten kümmern zu müssen.

Fast-forward ein Jahr, tausche Linux gegen Apple und finde es jetzt doch sehr anstrengend, immer eine externe Festplatte mit mir herumzuschleppen -- Apple-Snob, der ich bin. Sieht auch unelegant aus, dieses schwarze Kästchen an den hübschen Laptop zu klemmen. Es muss also eine andere Lösung her, um immer auf beiden Rechnern mit aktuellen Dateien arbeiten zu können. Es bietet sich an: MobileMe (damals noch .Mac), genauer, die iDisk, also ein Stück online-Speicher bei Apple, auf dem man von mehreren (Apple-) Rechnern aus arbeiten kann. Das Angebot ist verlockend, aber leider erfüllt MobileMe meine Erwartungen nicht, es gehen Daten verloren und ich ärgere mich, jemals Geld für diesen Dreck ausgegeben zu haben.

Eine Alternative finde ich in Dropbox, welches die Vision des immer synchronen Datenspeichers "in the cloud" endlich erfüllt, wenn auch als Ordner und nicht als Laufwerk. Inzwischen erbringt auch Syncplicity diese Leistung, wenn auch mit einem eigenen Set an Einschränkungen (Es ist aber noch Beta, also kein Grund zur Sorge).

Dennoch: ganz zufrieden bin ich nicht, einfach, weil zwei Rechner immer eine gewisse Menge "mental overhead" bedeuten. Allein, nicht immer am selben Gerät zu sitzen stellt einfach eine Irritation dar, die im Grunde nicht nötig ist. Na gut, und dieses neue "Unibody"-MacBook Pro ist einfach sexy. Also, tausche iMac + MacBook gegen MacBook Pro. Das löst -logisch- auch alle Synchronizitätsprobleme.

Aber ich wäre nicht der Sohn meines Vaters, wenn ich nicht immer noch mehr technischen Schnickschnack haben müsste, enter: the iPhone. Dank Apple und iTunes ist es natürlich kein Problem, Kalender, Email, Kontakte und Musik immer synchronisiert zu halten; Kabel reinstecken, iTunes machen lassen und fertig.
Perfektioniert wird das alles aber erst durch Beihilfe von Google, welches durch ActiveSync (sprich: Exchange) nun auch alle meine Kontakte, Kalendereinträge, Emails und Dokumente auf allen Geräten zur Verfügung stellt. Dieses Setup ist nun endlich wirklich extrem zufriedenstellend. Es ist zwar ein Haufen Kleinkram, den man durcharbeiten muss, bis man das alles richtig konfiguriert hat, aber hat man das einmal getan funktioniert es wirklich tadellos! Und Syncplicity und Dropbox laufen auf dem Rechner einfach nur noch als Backup weiter.

E Text Editor goes Open Source

2009-03-24T15:16:00.000+01:00

Als ich heute von der FH nach Hause kam, lag das hier in meinem Newsreader und ich war, in Ermangelung eines besseren Wortes, geschockt.

Nur, um es noch einmal zu wiederholen: E, der meiner Meinung nach beste Texteditor der Welt wird Open Source. Das kann man nicht oft genug sagen.

Warum ist E so fantastisch?
E ist ein recht neuer, kleiner Texteditor für Windows. Nein, um ihm Genüge zu tun, muss man E in einem Satz mit Emacs, Vim und Textmate nennen, denn wie diese Drei Großen Texteditoren sind auch E keine Grenzen gesetzt, da all seine Funktionalität durch kleine, einfache Skripte entsteht, die von jedem Nutzer beliebig verbessert werden können. Genauer gesagt: E tritt in die direkten Fußstapfen von Textmate, einem Editor für den Mac und ist vollkommen kompatibel mit dessen Erweiterungen, so dass E schon bei seiner Markteinführung auf eine riesige Masse von Sprachen, Snippets und Programmen zurückgreifen konnte, mit der sich jede noch so obskure Textmanipulation bewältigen lässt. Anders als Emacs oder Vim folgt E dabei aber modernen Bedienungs- und Designrichtlinien und fühlt sich genauso flüssig und heimisch an, wie das für eine Windows-Anwendung nur möglich ist.
Seine zweite große, und kaum weniger berauschende Stärke ist sein History-System. Jeder Benutzer eines Texteditors kennt die Undo-Taste (mit Ausnahme von Textmate. What a shame.). Undo macht die zuletzt gemachte Änderung rückgängig und ist damit der beste Freund von notirisch fehleranfälligen Menschen. E bringt Undo auf das nächste Level: Denn neben dem normalen Undo-Befehl gibt es noch eine komplette Übersicht aller jemals an einem Dokument gemachten Änderungen, komplett mit verschiedenen Pfaden, die zu verschiedenen Zeiten genommen wurden kompakt und übersichtlich verpackt in einem fantastischen Baumdiagramm.
Dazu kommen ein riesiger Haufen Features, die eigentlich jedes Programm haben sollte, welche man aber nur viel zu selten findet:

Inkrementielle Suche mit sofortiger Ergebnisvorschau und Unterstützung von Regulären Ausdrücken!
Direkte Unterstützung von Cygwin für alle möglichen Skriptsprachen!
Syntax-Highlighting für so ziemlich jede denkbare Sprache!
Unterstützung für Snippets!
Multiline-Editing!
Kontinuierliche Weiterentwicklung des Editors!
...

Wer mehr wissen will, der surfe nach e-texteditor.com und schaue sich dort den Screencast und den Blog an, lade sich die Demo herunter oder suche im Internet nach Reviews zu E.

Selbst ich, als eingefleischter Textmate-Benutzer halte E als meinen heimlichen Lieblingseditor, denn schließlich kann er alles, was Textmate kann (und das ist schon enorm gut) und dazu noch eine gute Latte mehr. Wer, wie ich, eigentlich seinen Tag nur mit (a) surfen und (b) tippen verbringt, sollte wirklich darüber nachdenken, ein wenig Geld für einen guten Texteditor auszugeben. Es lohnt sich, und E ist ohne Frage einer der Besten. Und jetzt wird er Open Source. Ich bin begeistert!

Western Digital Festplatten-Umtausch mit Überraschungen

2009-03-19T21:17:00.000+01:00

Ich hatte mir vor einer Weile eine externe Festplatte nur für TimeMachine gekauft. Denn TimeMachine ist super, die einzige Backup-Lösung die ganz bewusst nie in Erscheinung tritt es sei denn man braucht sie. TimeMachine läuft leise und unbeachtet im Hintergrund, und gibt mir dieses flauschige Gefühl von Sicherheit, quasi das unsicht- und spürbare Kondom der Computerwelt (bzw. Apple-Welt).

...Bis ich einmal den fatalen Fehler beging, meine externe Festplatte HOCHZUHEBEN. Nicht ruckartig, nicht gewaltsam, sondern tatsächlich sehr sanft, aber wohl gerade zu einem ungünstigen Zeitpunkt, denn die Festplatte gab ein leises Klick von sich und hörte auf zu funktionieren.

Es handelt sich hierbei um eine externe Festplatte der Marke Western Digital MyBook mit 500 Gigabytes, gekauft bei Norskit. Ein Anruf beim Verkäufer ergab, dass dies eine alte Bestellung (weltbewegende 9 Monate) sei und ich daher bei einer anderen Nummer anrufen sollte. Eine sehr freundliche Mitarbeiterin teilte mir dort mit, dass die Firma leider Insolvent sei und ich meine Supportanfrage daher an den Hersteller richten sollte. Und was soll ich sagen? EIN GLÜCK, dass sie das sagte!

Denn auf der Webseite von Western Digital gibt es nicht nur eine Support-Telefonnummer, sondern gleich ein komplettes austausch-Programm für Festplatten, welches vollkommen automatisiert abläuft: Man gibt die Modellnummer seiner Festplatte und -für Notfälle- seine Email-Adresse an und bekommt sofort eine neue Festplatte zugeschickt, mit der einzigen Auflage, die alte, defekte Platte innerhalb von 30 Tagen einzuschicken. Und tatsächlich wurde die neue Platte prompt am nächsten Tag verschickt und kam heute pünktlich per UPS bei mir an.

Faszinierend, so wünsche ich mir Kundenservice. Der einzige Wermutstropfen ist, dass Western Digital offenbar nicht sehr überzeugt von der Ausfallsicherheit seiner Festplatten ist, wenn sie so viel Infrastruktur für den einfachen Austausch bereitstellen... Na egal, ich will mal nicht meckern ;-)

Nachschlag: Es stellt sich heraus, die neue Festplatte unterscheidet sich ein wenig von der alten: Sie ist silber statt schwarz und hat zwei Firewire 800 Anschlüsse anstatt Firewire 400 -- ein Glück, dass auch Kabel mitgeliefert wurden, sonst könnte ich sie jetzt nicht anschließen!

Debugging und GCC auf Windows

2009-03-15T15:10:00.000+01:00

So, jetzt habe ich mein Mex-File zum Einlesen beliebiger Audiodateien endlich lauffähig auf Windows und Mac. Leider werde ich nicht dafür bezahlt, auch noch eine Linux-Version zu bauen, aber falls Interesse besteht, versuche ich mich vielleicht einmal daran.

The State of The Union: Kleine Dateien einlesen, kein Problem. Exotische Formate einlesen, kein Problem. Metadaten auslesen, kein Problem. Dateigröße, Bitrate und Samplerate auslesen, ein kleines Problem, da diese Parameter bei komprimierten Formaten nicht unbedingt fest stehen. Große Dateien einlösen, auf dem Mac kein Problem, auf Windows… nun ja, es dauert. Eine WAV-Datei von 5:30 min einzulesen, dauert mit Windows momentan ca. eine Stunde. Das kann nicht sein, in der Zeit habe ich die Datei dem Programm vorgelesen, wenn es sein muss.

Also, was ist da faul? Jetzt heißt es debuggen: GDB ist mein Freund, aber leider spreche ich seine Sprache nicht, also Oldschool-Debugging mit printf() (bzw. mexPrintf(); Aber da #define printf mexPrintf ist das das selbe). Blöd nur, dass Matlab selbst entscheidet, wann es meine Printfs auf den Bildschirm schreibt und es sich dazu entschlossen hat, dies immer erst nach dem Ausführen der Datei, also erst nachdem es bereits eine Stunde gearbeitet hat, zu tun. Einiges Hirnen später konnte ich Matlab endlich über eine Kombination aus Typecasts, sprintf und mexWarnMsgTxt dazu überreden, wenigstens sporadisch ein paar Informationen herauszugeben.

Das Ergebnis:
(1) Die Datei funktioniert tadellos, ist nur ein wenig langsam (s.o.)
(2) Wer ist schuld? Realloc ist schuld!

Das kam überraschend! Offenbar ist realloc auf dem Mac um mehrere Größenordnungen performanter als auf MinGW/Windows, denn die selbe Anwendung, die auf dem Mac ca. eine Sekunde braucht, braucht auf Windows eine Stunde! Und das allein wegen realloc! (Eigentlich: eine halbe Stunde wegen realloc, der Rest ist der Tatsache geschuldet, dass Windows in einer VM läuft)

Bei WAV-Dateien werden immer 2048 Samples an einem Stück ausgelesen. Danach verwende ich ein realloc, um meinen haupt-Speicherpuffer um diese Größe zu vergrößern und kopiere die neuen Daten dort hinein. Bei meinen 5:30 min macht das bei einer Samplerate von 44100 kHz und zwei Kanälen ca. 15000 Aufrufe von realloc. Komprimierte Datenformate haben üblicherweise kleinere Frames und damit noch einmal wesentlich mehr realloc-Aufrufe.
Der Plan ist also, jetzt statt häufiger, kleiner realloc-Aufrufe, seltenere, größere Aufrufe zu machen. Zeit für ein paar Experimente:

realloc()-Größe   realloc()-Aufrufe   benötigte Zeit
2^11 = 2048       15000               ~1 h
2^16 = 65536      470                 ~2 min
2^17 = 131072     240                 ~1 min
2^18 = 262144     120                 30 s
2^19 = 524288     60                  18 s
2^20 = 1048576    30                  10.5 s
2^21 = 2097152    15                  7.3 s
2^22 = 4194304    7                   5.1 s
2^23 = 8388608    3                   4.2 s

Das Spannende ist: Ich ändere durch meine Methodik praktisch nichts außer der Anzahl und Größe der realloc-Aufrufe, aber man erkennt einen eindeutigen Zusammenhang zwischen Performance und Anzahl der Aufrufe, ergo ist realloc der alleinige Schuldige für mein Performanceproblem auf Windows.

An dieser Stelle fiel mir ein, dass ich bereits an früherer Stelle einmal die gesamte Länge des Audio-Streams anhand der Metadaten geschätzt hatte. Durch eine somit vorgenommene Prä-Allokation des gesamten Speichers lässt sie die Laufzeit weiter auf 2.2 s drücken. Das ist immernoch nicht einmal halb so schnell wie auf OSX (0.9 s), aber das mag auch an der virtuellen Maschine liegen.

Mehr als diesen anecdotal Evidence kann ich nicht anbieten, aber ich bin mir sicher, dass ich ab jetzt die Finger von inkrementiellen Speichervergrößerungen auf MinGW/Windows lassen werde. Ist das in MSVC ähnlich schlimm, oder habe ich da etwa einen Bug entdeckt?

Get a Mac

2009-03-14T10:24:00.000+01:00

Bei meinem üblichen, Samstagmorgendlichen, bettlägrigen Web-Rundgang habe ich heute drei sehr nette Artikel von David Alison gefunden, einem Windows-Programmierer und selbsternanntem Microsoft-Fanboy, der sich einen Mac zulegt und unverhofft glücklich damit wird. So glücklich sogar, dass er inzwischen mehr oder weniger ein Mac-only-User geworden ist.

Ziemlich genau wie ihm ging es mir auch.

Teil 1: A hardcore Windows guy gets a Mac
Teil 2: After two months of Mac, here's why I switched
Teil 3: Switching from Windows to Mac - One Year Later

Wens interessiert: Das ist eine sehr hübsche Einführung darin, warum Macs toll sind. Viel besser als alles, was ich dazu schreiben würde oder bereits getan habe.

Kompilieren auf Windows

2009-03-12T23:24:00.000+01:00

Seit einigen Wochen arbeite ich an einem kleinen Projekt: Eine Matlab-Funktion, die, ähnlich wie die standard-Funktion wavread(), Audiodateien einlesen kann. Aber nicht irgendwelche Audiofiles, sondern ALLE MÖGLICHEN Audiofiles. Wie geht das? Jeder kennt VLC, den Video-Player, der so ziemlich jedes Video öffnen kann, das man ihm vorsetzt, selbst wenn man überhaupt keine Codecs installiert hat. VLC basiert auf FFmpeg, einem Open-Source Programm, welches Funktionen bereit stellt, um eben alle möglichen Mediendaten zu öffnen.

Und da FFmpeg freie Software ist, kann man sie auch für andere Dinge verwenden, etwa, um mit Matlab Audiodateien zu öffnen. Fehlt noch eine Verbindung zwischen Matlab und den FFmpeg-C-Bibliotheken, und die gibt es in Form von Mex, der C-Schnittstelle von Matlab. Feine Sache, zwar hat es eine Weile gedauert, bis ich mich in libavformat und libavcodec eingearbeitet hatte (die beiden wichtigsten FFmpeg-Bibliotheken), aber im Endeffekt lief das alles sehr schmerzfrei -- und das, obwohl ich bisher Mex-Kompilieren mit Matlab immer als eine grausige Beschäftigung in Erinnerung hatte, gespickt von kryptischen Kompiler-Fehlern und hässlichen Notlösungen.

Bumms, Zack, kaum hatte ich mich versehen, hatte ich ein lauffähiges, tadellos funktionierendes Mex-File auf meinem Mac liegen. Damit hatte ich nicht gerechnet. Also sofort die momentane Euphorie ausnutzen und weiter zu Schritt 2, das Ganze nochmal auf Windows. Meine Probleme, Windows so einzurichten, dass ich endlich Kompilieren kann, hatte ich ja schon berichtet. Ich hatte also Visual Studio 2005 installiert, um Matlab zufrieden zu stellen und einen anständigen Kompiler auf dem System zu haben. Aber war ja klar, MSVC macht wieder sein eigenes Ding und nichts ist mit Standardkonformität und Trallalla: Keine C99-Unterstützung, also keine Variablendeklarationen mitten im Code und keine stdint.h oder inttype.h. Ein Glück, es gibt wieder ein wenig mehr Free Software, die wenigstens letztere Lücke schließt. Dennoch; Ich bekomme mein mex-File nicht zum Laufen. Es ist wie verflucht, kaum setze ich mich an eine Windows-Maschine zum Programmieren, fällt meine Produktivität auf das Niveau eines Backsteins.

Enter gnumex, noch ein weiteres Stück FOSS, das es ermöglicht, GCC als Mex-Kompiler zu verwenden, AUF WINDOWS. Um die Dinge zu vereinfachen, verwendete ich die MinGW-Variante und kaum war diese Hürde genommen... lief alles. Einfach so. Wahrscheinlich bin ich ein Dickschädel und habe einfach nicht die Geistesschärfe, mit Windows-Kompilern zu arbeiten, aber mir scheint, alles was ich diesbezüglich anfasse und das nicht GCC heißt ist zum Scheitern verurteilt. Ein Glück, dass es die vielen klugen Jungen und Mädchen gibt, die so wunderbare freie Software schreiben, die mir das Leben so viel einfacher macht!

Eine Fortsetzung kommt noch...

Great Scott!

2009-03-05T13:55:00.000+01:00

Vom Sinn und Unsinn, ein Cross-Platform-Compiling-Matlab-System aufzubauen

Mal wieder: Ich schreibe ein Stück Software für meinen Nebenjob bei meinem Signalverarbeitung-Prof. Diesmal geht es darum, beliebige Audio-Files in Matlab einlesen zu können. Perfekt geeignet ist dafür die selbe Bibliothek, die auch von VLC verwendet wird, libavcodec/libavformat. Das ist eine normale C-Bibliothek, es braucht also nur noch ein kleines mex-File, um ihre Funktionalität für Matlab zur Verfügung zu stellen. Klappt auch wunderbar. Auf dem Mac.

Schritt zwei ist dann, das Ganze auf Windows und Linux zum Laufen zu bringen. Eigentlich kein Problem, denn ich habe keine wilden Dinge getan und die Libraries selbst sind wunderbar Cross-Platform, es gibt sie sogar schon vorkompiliert für praktisch jedes denkbare Betriebssystem.

Also, was brauche ich? Zwei Dinge: Matlab und einen C-Compiler (der mitgelieferte LLC-Compiler macht mein Hirn bluten). Matlab zu installieren ist meiner Erfahrung nach schmerzhaft. Bigtime. Nicht, weil Matlab schwer zu installieren wäre, sondern, weil Mathworks nur zwei Installationen pro Schachtel erlaubt, was für meine drei Betriebssysteme zu gewissen Problemen führt. Außerdem müsste ich meine eine Lizenz erst für die Windows-installation umschreiben lassen, und... ach, Schmerzen. Offenbar habe ich die Jungs dort aber schon derart häufig mit Lizenzanfragen genervt, dass sie mich einfach als hoffnungslos aufgegeben haben, denn dieses Mal musste ich keine neue Lizenz erstellen lassen, sondern einfach installieren, Passwort eingeben, und los. Mein Account meldet jetzt, dass ich fünf gleichzeitige Installationen hätte (von zwei erlaubten). Mir solls Recht sein.

Außerdem: ein aktuelles Linux muss her. VMWare sei Dank, lauert im Linux-Installieren nicht mehr der Schrecken, im Zweifelsfall den kompletten Festplatteninhalt zu verlieren, sondern nur noch, an akuter Progressbar-itis zu ersticken. War ja klar, dass Autoupdate sich diesen Nachmittag aussucht, um meine Ubuntu-VM hoffnungslos zu zerstören. Also, neues Ubuntu heruntergeladen, neu installiert, neu Updates aufgespielt, zwei Stunden Lifetime verloren. Immerhin: es hat fehlerfrei funktioniert, das ist was Neues. Matlab hinterher, VMWare Tools dazu, fertig ist die Development-Kiste. Jetzt fehlt nur noch eine Verbindung zu meinem Development-Verzeichnis, damit ich auf meine Dateien zugreifen kann. Fehlanzeige. Dukommsthiernichrein. Na Toll.

Also weiter zu Windows. Frühere Versuche ergaben bereits, dass ich Matlab nicht dazu bewegen kann, (a) GCC als Compiler zu nehmen oder (b) das bereits installierte Microsoft Visual Studio C++ .Net Professional Directors Cut Special Edition 2008 Ultimate zu verwenden. Nähere Nachforschungen zeigen: Zu neu, Kennternich. Geht nur bis MSVC Jahrgang 2005. Also: Neues MSVC deinstallieren, Altes installieren. ich freue mich immer darauf, MSVC zu deinstallieren, denn es besteht lediglich aus kompakten 12 Programmen, die sich zwar alle auf einem Haufen Installieren- jedoch nicht De-Installieren lassen. Immerhin ist es dank MSDNAA-Membership nicht schwer, an die alten Versionen heranzukommen. Und klar, die Systemsteuerung lässt einen auch immer nur ein Programm auf einmal deinstallieren. Multitasking ist nicht. Dank Syncplicity kann Windows die Zwischenzeit immerhin dazu verwenden, all meine Development-Files auf den Rechner zu laden. Yay!
Das Schöne an Fortschrittsbalken ist ja, sie zeigen Fortschritt. Damit haben sie einen klaren Vorteil gegenüber etwa Dachbalken oder den Bittewartenpunktpunktpunkt-Balken, die die Microsoft SQL Server 2008-Deinstallation stolz herumzeigt. Die fühlt sich wohl sehr wichtig, denn sie rödelt eine starke halbe Stunde im Bitte-Warten-Modus herum. So mag ich Deinstallationen.

To be continued...