Have a nice valentines and free software day!

Now, starting the GUI to start a VM is a bit slow, so VBoxManage startvm "vm" is a huge time- and memorysaver.
Since I work with Openbox, the natural thing for me was to google for a suitable pipemenu. Unfortunately, I couldn’t find one. Long story short: Here is my self-written Openbox pipemenu to control VirtualBox’s VMs. (It can start and stop them, at least.)

Put it somewhere, make it executable and set it as a pipemenu in your menu.xml file.

To set whether VMs should be powered off or if their state should be saved, edit the value of killAction in the script.

Here is my setup on how to work with emacs and use it as an editor for quickly editing files on the command line.

Starting the daemon using systemd

I switched from sysVinit to systemd some time ago, so the most convenient thing to do is to start the emacs daemon using a custom systemd service file. Put the following code into the file /etc/systemd/system/multi-user.target.wants/emacs.service:

Make sure you insert your username in the bottom line. Now, enable the service executing systemctl enable emacs.service and after the next boot the daemon is started automatically.

Shell aliases and sudo-ing

One thing you will quickly notice is that sudo emacsclient ... doesn’t work since the daemon runs under your username. To be able to edit files as root, we need to load the tramp plugin of emacs. Put the following line somewhere in your .emacs or .emacs.d/init.el:

Now, you would use emacsclient -c /sudo::/etc/somefile which is still a bit too long for quick file editing. (As well as the emacsclient command itself). This is why we create shell aliases. I am using zsh which is why I will use its syntax here.

It sets emacs as the default editor and defines the commands ec (emacs in a separate window) and et (emacs in the terminal) as well as its sudo friends for write-protected files, ecs and ets. Simply put the code in your .zshrc or .bashrc (after editing it to fit bash’s syntax) and restart the terminal. Then you can use ec/et/ecs/ets /some/directory/some/file to edit the file. I think tramp uses ssh to connect to your pc as root, so you might need to install ssh to use it.

The reason is that ReMoot only looks for programs that belong to the current user, while the mpd most of the times has it’s own user. (At least that is what’s proposed for example here)

To get ReMoot running with mpd you have to do the following two things:

• ReMoot uses mpc to interface with mpd, so make sure it is installed!
• edit /usr/bin/daemoot (or whereever it may be) and change line 470 (version 0.9 of ReMoot) to my @apps = `ps -L -u $ENV{USER},mpd -o comm,lwp`; where, of course, mpd has to be the user the mpd runs under.

That should be it. Have fun!

• I switched to linux
• I decided to use Pidgin instant messanger
• I hated the big, fat, ugly status bar in pidgin
• I wasn’t able to find a plugin that hides it (and does nothing more)
• So I wrote my own

It is just for Unix (I guess..) and you have to build it yourself. A small README is included in the tarball.

Sourcecode hidestatusbar.tar

I hope it helps anybody.

All the best, Oli

I will presume you know more or less exactly what these software packages do, and how to use them. Also, I assume that you are able to set up a virtual host by yourself. You should be familiar with how to use a command line, too!

Step 1 – Download libraries and set up the project

First of all, we need to download the libraries and set up our project.
Start with the Zend Framework. Go to it’s download page and download (at least) the minimal version. Right now, it is ZF 1.11.3. Unpack the download, go to a command line (whichever your system provides), change to the bin/ folder of the package and type the following lines:

This is what you do on a Unix shell. It is slightly different on Windows machines, there you would have to use the zf.bat file. However, you will have to figure out how to do that on your own, since I don’t work on Windows and am too lazy to google it right now.

Your project should be created now, meaning that the folder /path/to/App should contain several subfolder such as application/, library/ and so on. We create a subfolder with the name bin/ in this folder.

What has to be done next is to move all the libraries into our project. First of all, in the downloaded package of the Zend Framework, there should be a libraries/ folder containing another folder named Zend/. We move that Zend/ folder into the library/ folder of our project.

We then go on by downloading the Doctrine packages. I say packages, because we need the Doctrine ORM as well as the DBAL and the Doctrine Commons project. Luckily, all of them are included in one package, which can be downloaded on the Doctrine ORM’s download page. It is the latest Doctrine package. (As of now, it is version 2.0.1) Unpack it and simply copy the Doctrine/ folder into our project’s library/ folder.

The last step in setting up the project is to move or copy the contents of the bin/ folders of both downloaded packages into the bin/ folder that we just created in our project.

Step 2 – The configuration file

In this tutorial, I will show how to integrate Doctrine using MySQL as database engine. The config settings might be different for other engines or when you use different database interfaces. However, we open the application/configs/application.ini of our project and insert the following lines into the [production] block of the ini file.

At this point, you have to fill in your personal database connection settings. These might be completely different from the ones shown here. You should also adjust the database driver now, when you don’t want to use MySQL.

Step 3 – Bootstrapping

Now comes the fun part. We have to load all the Doctrine libraries and set them up correctly. To do that, we open the application/Bootstrap.php file of our project and fill it with the required functions. I will first post the whole file here and explain it below.

The first two methods don’t have anything to to with Doctrine. We just want to use a registry in our project (later, our EntityManager instance will be stored here!) and we want to register a namespace Default_ for use in our project. These methods are pure Zend Framework-ish, so I assume you know what they do. If not, consult the ZF manual.

Now for the _initDoctrine() method. The first thing we do in line 33 is to include the class loader of Doctrine. Unfortunately, Doctrine already uses the new namespacing of PHP 5 (or 6?). The Zend Framework doesn’t. So we need another class loader with the correct namespacing scheme. We set it up in the following five lines 34-38, telling it that we need the namespace Doctrine and where the include path of the library is.

We then create a Doctrine Configuration instance and configure Doctrine (lines 41-59). Depending on how you want to control the database scheme and stuff like that, you might want to adjust some of the settings here. The ArrayCache can be changed and set to something more performant and if you don’t want to use annotations in the Entities to define the database scheme, you should use a different MetadataDriver. In this tutorial, we use both the ArrayCache and the DefaultAnnotationDriver. When we instantiate the last one, we have to tell it where our classes with the annotations (I will talk about these more, later) are.

I never _really_ understood what the Proxy classes are. They are created at runtime by Doctrine and my guess is, they are to speed up the database interaction by sort of caching joined requests. Anyways, we need to define where these classes should be saved and what namespace that is. This is done in lines 57-59.

After that, we get our connection settings from the application.ini file and can finally create the EntityManager instance by telling it all our configurations and connection information. This EntityManager can be understood as the interface between the Database and our models (called Entities). We are saving it’s instance in the Zend Registry we created earlier.

And that’s it. We can now start creating Entities (models) and trying to do some database interaction!

Step 4 – The Entity

To test everything, we create a small dummy Entity. I will not go into detail on how to create Entites and define the database scheme of their tables. As we defined in the Doctrine config earlier, we want to use annotations (in the Docblock of our Entity) to define the database scheme. We create a file application/models/Test.php and fill it with the following code:

As you see, we want a models with the fields id and name, id being an integer and auto_incremented and name being a string. The table name is set to test123. As you can see, an Entity is nothing more than a PHP class with some members and methods. Only the definitions for how Doctrine should build the table have to be given in the annotations. You could as well use YAML or XML files to define these.

The next step is to adjust the command line tool of Doctrine to fit into our project.

Step 5 – the command line tool

Simply copy the following code into bin/doctrine.php replacing all of the code already in the file.

We do some bootstrapping of our project here to obtain the EntityManager instance. We then create a HelperSet with the EntityManager and run the cli tool.

To create our database table based on the Entity we created earlier, we open a command line, change into the bin/ folder of our project and run

Again, this is for the Unix shell and is different on Windows machines!
Fire up your favourite database administration tool and have a look! The table test123 should have been created properly.

Step 6 – Using the database

I will just post a small example of how to use everything. Replace the content of your application/controllers/IndexController.php with the following:

This is just some quick and dirty dummy code to check if everything works. We get our EntityManager out of the registry and save it as a member of the Controller. We then create a new model (Entity), set the name and by using the EntityManager‘s persist method, we save it. EntityManager->flush() actually invokes the database action and the row should occur in our table.

Test this by simply browse to your project in your favourite webbrowser. If everything worked fine, the table should now have one entry with the name Zaphod Beeblebrox.

If anything did not work, feel free to ask in the comments here! I will be glad to answer any questions.

So I started diving into Android development last autumn and today, just for fun, I tried to use some sensors included in my phone. (HTC Desire running Android 2.3.1)

My idea was to use the accelerometer along with the orientation measurement to measure both the distance the phone was moved and also it’s trajectory. Both values, of course, relative to the starting point of the motion.

So the first difficulty was to transform the measures of acceleration into the coordinate system of the lab (room…). Luckily, Android provides methods that need the acceleration and the magnetic field as input and return the transformation matrix for vectors. (Have a look at SensorManager.getRotationMatrix()).

The next thing I had to take care of was the earth acceleration. Trying to just remove a constant offset from the z-component of my acceleration vector wasn’t really accurate. (Somehow my phone measured the gravity to somewhat around 10.5 m/s^2…) So I just moved to the SDK version 9, which is Android 2.3, and used the sensor type Sensor.TYPE_LINEAR_ACCELERATION. This is the measured acceleration where the gravity was already taken care of.

Now, I took care of everything: I measured the acceleration and transformed it into the room’s coordinate system (before each measurement step, so that I could rotate the phone however I like and it wouldn’t change the measured values). After integrating everything my app was perfect and ready for a tryout.

Walking through my room and trying to measure the distances from wall to wall didn’t work at all. Moving the phone in a circle resulted in a measured distance of about 20+ m, which had to be wrong, too.

I don’t know yet what went wrong or whether it’s just the unprecision of the sensors. However, I will attach the source code of my activity and the layout file. Keep in mind that you need a phone running Android 2.3 to try it. The emulator can’t be moved, so It would be useless to emulate the app.) Please excuse the bad coding style, it was just meant to be an experiment.

Als kleinen Einstand für das artofcode.de Blog möchte ich Euch physikalisch interessierten Lesern heute die Software Bibliothek ESPResSo an einem Beispiel vorstellen. Wir werden eine beliebig lange Kette von Teilchen simulieren (d.h. ihre Bewegungsgleichung numerisch integrieren), die mit Federn untereinander verbunden sind und uns sowohl die Energiebilanz als auch die Bewegung der Teilchen anschauen.

Voraussetzungen

Es werden weder physikalische noch programmiertechnische Vorkenntnisse vorausgesetzt. Eine Unix Shell sollte vorhanden sein. Die Übersetzung und Installation der Bibliothek wird am Beispiel von Mac OS X erklärt, sollte unter Linux Derivaten aber weitaus einfacher sein. Macports wird für Mac OS X bei der Installationsanleitung vorausgesetzt, ist aber nicht unbedingt nötig.

Was ist ESPResSo?

ESPResSo ist eine freie Software Bibliothek für Molekular Dynamik Simulationen. Entwickelt wird es am Max Planck Institut in Mainz. Molekular Dynamik bezeichnet das Verhalten von Atomen und Molekülen unter Einfluss von äußeren Einflüssen und Teilchen-Teilchen Wechselwirkungen. Viele physikalische Probleme können mit steigender Komplexität analytisch (d.h. rechnerisch) nicht gelöst werden, weshalb man auf numerische Methoden wie etwa der Simulation zurückgreifen muss. ESPResSo ist eine sehr umfangreiche Bibliothek, welche eine ganze Reihe von Wechselwirkungen und Einflüssen simulieren kann. Damit ist es möglich, sowohl thermodynamische Größen (wie etwa Druck, Temperatur, Volumen) des physikalischen Systems als auch das Verhalten der einzelnen Teilchen zu untersuchen.

Der harmonische Oszillator

In diesem Artikel werden wir ESPResSo nutzen, um eine Kette von N Teilchen zu simulieren, welche durch Federn mit dem jeweils rechten und linken Nachbarn verbunden sind. Wird ein Teilchen aus seiner Ausgangsposition ausgelenkt, entsteht eine periodische Schwingung (Oszillation). Der harmonische Oszillator ist das wichtigste und allgegenwertigste Problem in nahezu allen Bereichen der Physik. Gelöst wird es durch eine lineare Kombination von Winkelfunktionen, sin() und cos(). In diesem Artikel werden wir den Fall von (nur) zwei Teilchen betrachten, von denen eines im Raum fixiert ist.

Installation von ESPResSo

ESPResSo ist in C geschrieben und nutzt zur Steuerung ein TCL Interface. Für gewisse Funktionen, in denen Fourier Transformationen benötigt werden, ist außerdem die Software FFTW Voraussetzung. TCL und FFTW installieren wir mittels Macports folgendermaßen:

Anschließend laden wir hier die aktuelle ESPResSo Version herunter und entpacken den Quellcode in ein beliebiges Verzeichnis. Nun wechseln wir in das espresso-xx.x.x Verzeichnis und kompilieren die Bibliothek folgendermaßen:

Unter /usr/local/bin finden wir nun unsere ESPResSo binary und können loslegen.

Das Simulationsscript

ESPResSo wird mit einem TCL Script aufgerufen, in welchem anschließend gewisse Befehle der Software verwendet werden können. Ich werde das Script Schritt für Schritt aufbauen und erklären. Am Ende dieses Artikel wird das Script nochmals als Ganzes zum Download bereit stehen.

Randbedingungen und Parameter festlegen

Wir starten mit dem Festlegen von Parametern und Randbedingungen. Die im folgenden Codeschnipsel definierten Variablen sind einfache TCL Variablen, es findet noch keine Interaktion mit ESPResSo statt. Der Ausdruck [expr xxx] wird für Berechnungen genutzt. Funktionsaufrufe funktionieren bei TCL ähnlich.

In Zeile 2 legen wir die Anzahl der Knoten in der Kette fest: In diesem Fall, zwei. Für eine längere Kette reicht es also, allein diesen Wert zu vergrößern. Die Federlänge und -konstante legen wir in den Zeilen 5 und 6 fest: Es gilt zu beachten, dass ESPResSo komplett dimensionslos arbeitet, die angegeben Werte sind also als Vielfache einer charakteristischen physikalischen Einheit zu betrachten. Es folgen Integrationsparameter: int_steps sind die Schritte einer Integration, int_n_times die Anzahl der Integrationen. time_step definiert den Zeitschritt der Integration. In unserem Falle wird die Bewegungsgleichung der Kettenglieder also insgesamt 10000 mal gelöst, und zwar alle 0.005 T, wobei T eine beliebige Zeiteinheit ist. Wir betrachten also gewissermaßen ein Zeitintervall von insgesamt 50 T. Anschließend wird noch die Länge und der Mittelpunkt unseres Testraumes festgelegt, welcher hier keine so große Rolle spielt, jedoch für ESPResSo als Randbedingung wichtig ist.

In diesem Stückchen Code, teilen wir unsere Parameter durch den von ESPResSo definierten Ausdruck setmd der Software mit. Die meisten Einstellungen sind selbsterklärend; periodic x y z legt fest, in welchen Dimensionen sich der Testraum wiederholen soll (in unserem Falle, in keiner), skin beschreibt die Hautdicke der Verlet-Liste unserer Teilchen und mit thermostat off stellen wir das Thermostat aus. (Es ist natürlich möglich, dem System Wärme zuzuführen, was hier aber keine Rolle spielt.) inter 0 harmonic definiert als Wechselwirkung (welcher wir die ID 0 geben) eine harmonische Wechselwirkung, also eine Feder, welche die zuvor definierten Parameter besitzt.

Knoten/Partikel definieren

Im nächsten Schritt, müssen wir die Partikel festlegen, sprich ihre Positionen und Eigenschaften definieren und ESPResSo mitteilen. Da wir ein 1-dimensionales Problem lösen, sollen die y und z Koordinaten bei allen Teilchen gleich liegen, und zwar in der Mitte des Testraumes.

In den ersten Zeilen wird das Partikel mit der ID 0 im Raum positioniert: Es ist der Start unserer Kette. In der darauffolgenden for-Schleife teilen wir mit dem Befehl part ID pos x y z die Partikeleigenschaften der Software mit. Anschließend stellen wir mit part ID bond BONDID PARTNERID die Wechselwirkung BONDID zwischen den Teilchen ID und PARTNERID ein: In unserem Falle unser harmonisches Potential. Die Schleife sollte weiterhin selbsterklärend sein: Die x-Position wird um eine Federlänge erhöht und part_id wird ebenfalls um 1 erhöht, sodass nach und nach eine Kette von $l_chain Teilchen entsteht, welche jeweils mit dem rechten und linken Nachbarn verbunden sind.
In den letzten Zeilen des Schnipsels wird das erste Teilchen mit part 0 fix im Raum befestigt und dem letzten Teilchen (da wir nur zwei Teilchen haben: Dem anderen) ein Stoß in x-Richtung gegeben: Wir stellen seine Anfangsgeschwindigkeit mit part ID v 0.1 0 0 ein. Ohne diesen Kick würden beide Teilchen im Raum ruhen.

Die Integration

Da wir jetzt alle Voraussetzungen für die Simulation geschaffen haben, können wir mit der Integration beginnen. Diese beschränkt sich bei ESPResSo im Prinzip auf den einen Befehl integrate STEPS.

Es werden zwei Dateien zur Auswertung festgelegt: Wir wollen zum Einen eine Energiebilanz machen, und außerdem die Positionen und Geschwindigkeiten der Partikel zu jedem Zeitpunkt festhalten. Wir wiederholen nun mittels der for-Schleife $int_n_times mal die durch integrate STEPS initiierte Integration der Bewegungsgleichungen. [setmd time] gibt uns den Zeitstempel des aktuellen Durchlaufes, mit [analyze energy kinetic/bonded 0] rufen wir die kinetische Energie des Systems order die potentielle Energie unserer Wechselwirkung ab. [part ID print pos v] ergibt einen durch Leerzeichen getrennten String mit der Position im Raum (3 Koordinaten) und der Geschwindigkeit (3 Koordinaten) des Teilchens ID. exit beendet das Script.

Ausführen der Simulation

DMit einem schlichten Aufruf von der ESPResSo binary mit dem TCL Script als Parameter wird dieses ausgeführt.

Die benötigten Daten werden wie erwähnt in den Textdateien gespeichert und wir können mit der Auswertung anfangen.

Auswertung

Die Auswertung ist in diesem Beispiel nicht allzu spannend; ist der eindimensionale, harmonische Oszillator doch zur Genüge bekannt. Trotzdem wollen wir an zwei Beispielen die Richtigkeit der Simulation überprüfen. Zu erst schauen wir uns die Bewegung im Phasenraum an; das heißt wir plotten Position gegen die Geschwindigkeit (bzw. den Impuls) des zweiten Teilchens. (Erinnerung: Unser erstes Teilchen ist ohnehin im Raum fixiert!)
Der charakteristische Kreis ist sehr schön zu erkennen: Ist die Geschwindigkeit maximal, so ist die Position minimal und umgekehrt. Mit anderen Worten: Wenn das Teilchen durch seine Ruhelage schwingt, ist es am schnellsten und die Geschwindigkeit verschwindet, wenn es im Umkehrpunkt bei der maximalen Auslenkung ist. Der Phasenraum scheint also schonmal zu stimmen. Als nächstes schauen wir uns noch die Energiebilanz an:
Auch diese scheint zu stimmen: Die Gesamtenergie bleibt konstant bei 0.25 E (E: charakteristische Energieeinheit), jedoch oszilieren kinetische und potentielle Energie um diesen Wert herum.

Die Simulation scheint also das zu tun, was sie soll. Als nächsten Schritt könnte man die Bewegung verkomplizieren: Mehr Dimensionen einführen, mehr Teilchen oder unterschiedliche Federn. Oder aber man lässt das System Wärme verlieren – oder gewinnen. Man könnte den Teilchen auch weitere Wechselwirkungen geben (magnetische, elektrostatische, …) oder oder oder… Das Experimentieren überlasse ich euch. Die ESPResSo Dokumentation findet ihr hier. Außerdem lohnt es sich, einmal in das samples/ Verzeichnis des ESPResSo Downloads zu schauen!

Hier der Link zu dem kompletten Simulationsscript: oszi.tcl

Sooo. Einige Leser hatten mich gefragt, wann ich meine Zend Framework Integrations-Anleitung denn auf die Beta 1 von Doctrine updaten würde.

Das mache ich in den nächsten Tagen noch, sobald ich Zeit finde. Heute habe ich allerdings schon ein kleines Projekt gestartet: Den zf-doctrine-integrator (Zend Framework Doctrine Integrator).

Prinzipiell besteht das ganze Projekt, welches derzeit auf google code gehostet ist, aus einem Shellscript und den nötigen Dateien zur Integration von Doctrine 2 Beta 1 ins Zend Framework 1.10. Das Shellscript erstellt euch automatisch ein Projekt mit den ZF und Doctrine Bibliotheken, lädt die nötigen Dateien zur Integration aus dem Repository herunter und erstellt automatisch eine vhost Datei.

Das erspart euch bei der Projekterstellung die Arbeit, den Code zur Integration aus alten Projekten oder irgendwelchen Tutorials zu kopieren, außerdem könnt ihr so sicher stellen, immer die aktuellsten ZF und Doctrine Versionen zu nutzen.

Das ganze ist mehr oder weniger überhaupt nicht getestet. Ich würde mich sehr freuen, wenn ihr einfach mal ausprobiert, ob das tool bei euch läuft. Issues könnt ihr auf der Projektseite direkt posten. Die Systemvoraussetzungen und eine (in Zukunft) ausführliche Dokumentation findet ihr im Wiki.

• zum Projekt
• zum Download des Shell Scripts
• Systemvoraussetzungen
• Bedienungsanleitung

Das klingt nach einer interessanten Aufgabe, derer ich mich eben mal gewidmet habe.

Größe derzeit: 165 Byte (unix: 148 Byte) grauenvoller Code!

Auseinanderwurschteln könnt ihr das selbst, in schön gibts nur die endgültige Version.

ohne unix befehle (165 Byte)

mit unix befehlen (148 Byte)