Im Oktober 2013 war das Entwickler-Magazin auf der Suche nach einem Autor mit Expertise in Sachen IronPython. Für 2014 ist nämlich eine neue Artikelserie geplant, bei der in jeder Ausgabe eine „exotische“ Sprache vorgestellt werden soll — sozusagen ein Blick über den Tellerrand der herkömmlichen Programmiersprachen. In diesem Zusammenhang sollte auch IronPython ein kleiner Artikel gewidmet werden.

Sucht man nach einem deutschsprachigen Artikel über IronPython, landet man sehr schnell bei Nicht nur für Zombies: Einstieg in IronPython, den ich für das freiesMagazin geschrieben hatte. Da es zu IronPython nur wenig auf deutsch gibt, lag es wohl nahe, mich anzufragen. Daraufhin habe ich einen neuen Artikel geschrieben. Das Schwierigste war noch, sich eine irgendwie passende Anspielung auf Monty Python zu überlegen. Der Schwerpunkt dieses Artikels liegt besonders auf der Geschichte von IronPython, warum die Sprache entwickelt wurde, welche Anwendungsfälle es gibt — inklusive einer kleinen Beispielanwendung. Zu meiner Überraschung machte mein Artikel den Anfang der Serie in der Ausgabe Januar/Februar. Er wurde auch relativ unverändert abgedruckt, bis auf die Überschrift, die ist nicht von mir.

Alte Hardware wegzuwerfen ist meist sehr schade, weil sie häufig noch gut funktioniert. Zum Beispiel das Business-Notebook Thinkpad R51. Vor 10 Jahren war das ein Spitzenmodell mit Windows XP, 512 MB Arbeitsspeicher, 30 Gigabyte IDE-Festplatte und einem Intel Celeron M mit 1,3 GHz. Heute ist der Arbeitsspeicher zu wenig, das vorinstallierte Betriebssystem ein Sicherheitsrisiko und der Festplatte kann man nicht mehr trauen. Der Prozessor ist aber noch schnell genug, um damit im Internet zu surfen, oder E-Mails zu schreiben. Wenn man sich für alte Hardware interessiert, sollte man eine Sammelleidenschaft für Komponenten aus defekten Rechnern, besonders Laptops entwickeln und wenigstens Arbeitsspeicher und PCI-Geräte wie WLAN-Karten retten, bevor man einen Laptop verschrottet. Für manche WLAN-Karten gibt es keine Firmware unter Linux, dann ist es gut, wenn man sie gegen eine austauschen kann, die problemlos erkannt wird. Arbeitsspeicher kann man immer gebrauchen, außerdem muss man kein Geld ausgeben, um den Arbeitsspeicher eines älteren Notebooks zu erweitern, und wenn es nur ein weiterer 512 MB Riegel für den R51 ist. Speichermedien wie SD- oder CompactFlash-Karten hat man meist auch mehr als man braucht, zum Beispiel weil man sich für den Fotoapparat mal eine Karte mit noch mehr Speicherplatz gekauft hat. Haben die alten Karten mindesten 4 GB oder mehr Speicher und liegen ungenutzt in der Schreibtischschublade rum und wenn die Karte bootfähig ist, braucht man nur noch einen IDE-Adapter für etwa 10 Euro und die Festplatte kann ausgetauscht werden.

Den restlichen Eintrag lesen »

Auf der Arbeit benutze ich fast auschließlich Windows 7 und arbeite viel mit dem Startmenü und dem Suchfeld, um Dateien zu suchen, oder um Programme auszuführen. So ein Suchfeld hat das Whisker-Menü für die Desktopumgebung XFCE genialer Weise auch. Auf das Whisker-Menü bin ich übrigens über den Artikel „Optimale Oberfläche für Gnome und XFCE“ bei Pro-Linux gestoßen. Wenn ich aber, wie normalerweise unter Windows üblich, die Windows-Taste an meinem privatem Notebook mit Debian Wheezy drücke, um das Whisker-Menü zu starten, passiert nichts. Jetzt kann man in den Einstellungen von XFCE unter Tastatur im Reiter Tastenkürzel für Anwendungen einer Anwendungen ein Tastenkürzel zuweisen. In diesem Fall wäre das die Anwendung „xfce4-popup-whiskermenu“. Das klappt allerdings nicht mit der Windows- bzw. Super-Taste, da man sie nicht als einzelne Taste auswählen kann, sondern nur in Kombination mit einer anderen. Um das zu ändern, muss man die Super-Taste an eine andere Taste binden, die es eigentlich nicht gibt, auf meinem Notebook z.B. die Taste F13. Diese Taste wird dann zum Aufruf des Whisker-Menüs benutzen.

Den restlichen Eintrag lesen »

Mit Shell-Skripten sind kleine Helfer schnell selbst geschrieben. Sie haben den Vorteil, dass man sich keine langen Befehlszeilen auswendig merken muss. Es reicht dann, einfach das eigene Shell-Skript aufzurufen.

Redaktioneller Hinweis: Dieser Artikel von mir ist erstmals in der Februarausgabe 02/2014 von freiesMagazin erschienen.

Den restlichen Eintrag lesen »

Ich habe es in diesem Jahr doch noch geschafft, mein HTC One X zu bricken flashen. Meine Entscheidung fiel auf die aktuell letzte stable Version von CyanogenMod (CM) 10.2 und ich bin einer Anleitung für Ubuntu und für CM 10.1 gefolgt. Es hat mit Debian 8.0 Jessie und der neueren CM-Version auch sehr gut funktioniert. Daher ist dieser Artikel eher eine Übersetzung inklusive eigener Erfahrung des Blog-Posts von James. Es ist trotzdem keine Gewähr dafür, dass es bei eurem HTC One X auch klappt. Falls ihr es versuchen wollt, ist es immer auf eigene Gefahr. Aber es lohnt sich, wenn es klappt, auch wenn die Garantie dann weg ist. Letzteres ist auch mit ein Grund, warum ich über ein Jahr mit dem Flashen gewartet habe.

Den restlichen Eintrag lesen »

Es gibt sicherlich bessere Wipe-Programme für Windows, als das mitgelieferte diskpart. Dafür ist es seit Windows 2000 immer mit an Bord und man kann schnell alle Daten wenigstens einmal überschreiben, bevor man einen USB-Stick aus der Hand gibt, oder den PC inklusive Festplatte verkauft. Um einen USB-Stick zu „schreddern“ steckt man ihn in den PC, ruft die Microsoft Shell cmd.exe mit erhöhten Rechten auf und gibt diskpart ein.

Den restlichen Eintrag lesen »

Ein C-Programm unter Windows zu kompilieren ist leider nicht ganz so einfach, wie einen C-Compiler unter Gnu/Linux anzuwerfen. Das Ganze soll natürlich auf der Konsole stattfinden. Mit dem kostenlosen Visual Studio C++ 2010 Express geht das aber recht fix, solange es sich zumindest um kleine Projekte in C handelt.

Den restlichen Eintrag lesen »

Bei meiner Debian Installation von „Jessie“, also aktuell Testing, nervt mich gerade diese unerträgliche Langsamkeit von apt-get. Der Grund für das langsame Apt ist PDiff, das für ein inkrementelles Update der Paket-Liste sorgt. Im Prinzip ist das ja keine schlechte Idee, da nur die Differenz zwischen der aktuellen Liste und ihrer vorherigen Version heruntergeladen werden muss. Man muss also insgesamt weniger Daten herunterladen.

Der Nachteil ist, dass jedes inkrementelle Update einer Paket-Liste eine Anfrage an den Server benötigt. Wenn man nicht so häufig ein Update macht, sind das sehr viele Anfragen an den Server. Das Abarbeiten jeder dieser Anfragen dauert dabei länger, als alle Paket-Listen nochmal erneut herunterzuladen.

PDiff kann man auf zwei Wegen ausschalten. Einmal kann man PDiff einfach während eines einzelnen Updates deaktivieren:

apt-get update -o Acquire::Pdiffs=false

Oder man trägt das Verhalten dauerhaft in die Datei /etc/apt/apt.conf ein:

Acquire::PDiffs "false";

Ich bin durch zwei Artikel auf dem Debian Planeten darauf gekommen, das Verhalten von Apt zu ändern. Beide Artikel fordern, dass das Standardverhalten mit dem inkrementellen Update in Debian geändert, bzw. deaktiviert werden soll.

Die PowerShell ist bekanntlich eine mächtige Kommandozeile unter Windows und ideal um administrative Skripte zu schreiben. Bei größeren Projekten, bei denen die Programme auch noch auf verschiedenen Plattformen laufen sollen, ist aber eine Programmiersprache wie zum Beispiel Python die bessere Wahl. In anderen Kommandozeilen, wie der Bash unter Gnu/Linux, kann man Python-Skripte aufrufen, indem man einfach den Namen des Skripts in die Kommandozeile eingibt, oder den Befehl python davor schreibt, eventuell noch mit dem Pfad. Das geht in der PowerShell im Prinzip auch:

PS> python .\HalloWelt.py
Hallo Welt!

Dazu muss allerdings der Pfad zur Python-Installation in die Umgebungsvariable PATH eingetragen werden, die man entweder unter Systemsteuerung -> System -> Erweiterte Systemeinstellungen bzw. Windows-Taste + Pause und danach unter Umgebungsvariablen… ändert. Oder man führt den folgenden Befehl in der PowerShell aus:

$env:Path = $env:Path + ";C:\Program Files (x86)\Python27\"

Der Pfad zur Python-Installation kann auch anders sein, das hängt von der Installation ab. Wenn man den Pfad dauerhaft nur für den jeweiligen Benutzer in der PowerShell haben möchte und sich den Umweg über die Erweiterten Systemeinstellungen sparen will, kann man die Zeile in das PowerShell-Profil eintragen. Das Profil öffnet man innerhalb der PowerShell mit notepad $profile. Um sich auch noch das Tippen des Befehls python zu sparen und Python-Skripte direkt zu starten, kann man auch noch die Dateinamenerweiterung „.PY“ an die Umgebungsvariable PATHEXT anhängen:

$env:PATHEXT += ";.PY"

Die Zeile kann ebenfalls in das PowerShell-Profil gepackt werden. Hat man das alles erledigt, kann man Python-Programme aus der PowerShell heraus genauso starten,

PS> .\HalloWelt.py
Hallo Welt!

wie eine ein VBSkript oder eine Batch-Datei.

Mein Artikel Nicht nur für Zombies: Einstieg in IronPython aus freiesMagazin Ausgabe 07/2012 ist mittlerweile ein gutes Jahr alt, und es hat sich seit dem bei IronPython ein bisschen was getan.

Am 07. September 2013 erschien Version 2.7.4 der Sprache, mit der man sich weiter an die in C geschriebene Referenz von Python, CPython, annähert. Wer die neue Version einmal ausprobieren möchte, findet einen Link zum Installer für Windows auf der Homepage — ironpython.net. Unter Linux oder MacOS X ist die Installation ein wenig aufwendiger, da IronPython den .Net-Klon Mono benötigt. Während unter Ubuntu ein

sudo apt-get install ironpython

reichen sollte, benötigt man unter Debian zuerst das Mono-Framework,

apt-get install mono-complete

das es für MacOS X als Installationspaket gibt. Anschließend lädt man bei beiden Betriebssystemen das aktuelle IronPython von GitHub herunter und installiert es unter Mono:

git clone https://github.com/IronLanguages/main.git IronLanguages
cd IronLanguages/
xbuild Solutions/IronPython.sln /p:Configuration=Release

Ich habe allerdings eine Fehlermeldung beim Importieren des OS-Moduls unter Mono bekommen, in der IronPython-Konsole war es

>>> import os
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named os

und beim Aufrufen eines Skripts mit ipyw.exe war es:

~/IronLanguages/bin/Release$ mono ipyw.exe ~/bin/ipyHelloWorlp.py
Traceback (most recent call last):
  File "/home/christian/IronLanguages/bin/Release/Lib/site.py", line 62, in <module>
ImportError: No module named osTraceback (most recent call last)

Da ich nicht der einzige bin, konnte ich den Fehler durch folgenden Eintrag in meiner ~/.bashrc beheben:

# IronPython on Mono:
export IRONPYTHONPATH=~/IronLanguages/External.LCA_RESTRICTED/Languages/IronPython/27/Lib:$IRONPYTHONPATH
alias ipy="mono ~/IronLanguages/bin/Release/ipy.exe"

Der Installationspfad von IronPython liegt in meinem Home-Verzeichnis unter ~/IronLanguages. Das ist vermutlich suboptimal, aber zum Testen geht es. Darunter habe ich noch einen Alias ipy auf den Aufruf mono ~/IronLanguages/bin/Release/ipy.exe gesetzt, um mir Tipparbeit zu sparen.

Im August diesen Jahres hat Scott Hanselman im The Hanselminuts Podcast mit Dino Viehland einen Gast, der mehrere Jahre bei Microsoft mit Python gearbeitet hat. Mit seinem Team entwickelte er die Python Tools for Visual Studio. Die Frage ist, warum sollte Microsoft etwas mit Python machen wollen? Weil man mit Python Django-Webseiten erstellen kann, die unter Azure gehostet werden können.