Dinge, Zeugs und Sachen - Computer

Richtige Verwendung von select()

nospam@example.com (namenlos) — Tue, 29 Nov 2011 15:17:33 +0100

Merke: manchmal hilft Doku lesen erheblich. Ich habe gerade einen halben Tag danach gesucht, wieso eine pipe() zwischen zwei Threads eines Programms nicht funktioniert. Ich habe eine pipe, an deren lesendem Ende ein Thread mittels select() auf Befehle wartet. Dummerweise wollte bei folgendem Code select nicht zurückkehren:

select(1, &fdset, 0, 0, 0)

Irgendwie wollte das partout nicht zurückkehren, obwohl ich das Schreib-Ende des File-Descriptors beschrieben habe… Hm… Nach einigem Suchen habe ich die Doku nochmal genauer gelesen:

nfds is the highest-numbered file descriptor in any of the three sets, plus 1.

Tja, richtig lesen. nfds (der erste Parameter von select) ist nicht die Anzahl der Descriptoren im fd_set, sondern die Nummer des höchsten Descriptors plus eins. Dummerweise ist das Beispiel in der Doku mit fd=0 gemacht, so dass der höchste plus 1 gleich 1 ist (und damit gleich der Anzahl), was mich natürlich auf die völlig falsche Fährte gelockt hat. Naja, ein halber Tag versemmelt, aber wenigstens was bei gelernt. Fast wie Goethe…

Neuer Release des Logging-Templates

nospam@example.com (namenlos) — Fri, 22 Apr 2011 09:41:00 +0200

Irgendwann vor langer, langer Zeit (laut Versionshistory mittlerweile 5 Jahre her) hatte ich mal als Fingerübung ein Logging-Template in C++ geschrieben, was sich anfühlen sollte wie std::cout. Ziel war den geneigten Programmierer vom Denken zu entlasten und ihm quasi std::cout-Debugging mit etwas mehr Möglichkeiten zu erlauben. Hat offenbar damals schon gut gepasst, kurz darauf kam nämlich die Fähigkeit zur Anpassung an verschiedene Multithread-Umgebungen via Policy-Klasse dazu. Dann lag das ganze erstmal 5 Jahre im Dornröschenschlaf, in denen ich es zwar hin und wieder genutzt habe, aber eigentlich keine neuen Fähigkeiten brauchte. Bis vor kurzem...

Daher jetzt: tada! ein komplett neues Release, in dem sich so einiges geändert hat. Das Frontend an sich bleibt gleich (sprich: existierender Code sollte problemlos weiter kompilieren, es sei denn er macht was total dämliches und verwendet zweimal einen Log-Level in einer Nachricht). Im Hintergrund hat sich allerdings einiges getan. Erstmal wurde der Code etwas aufgeräumt, da sich dort von verschiedenen Experimenten Reste angesammelt hatten. Dann wurde das Handling der Loglevel komplett umgebaut um eine flexiblere Ausgabe nach unten zu ermöglichen. Hintergrund: ich brauche für ein Projekt gerade die Möglichkeit Daten ins Syslog auszugeben. Dazu muss der zugrundeliegende Ausgabestream aber das Log-Level wissen. Außerdem muss er zuverlässig wissen, wann eine Nachricht beendet ist. Beides stellt das Frontend jetzt sicher. Weil's so schön war habe ich gleich noch den passenden SyslogStream beigelegt, der das Loggingfrontend an syslog() anklemmt. Benutzung ist wie üblich relativ einfach:

#include <syslogstream.hxx>

use namespace Logging;

int main(int argc, char *argv[]) {
    SyslogStream slog("TestLogger");
    Syslogger logger(slog, LEVEL_INFO);

    logger << LEVEL_INFO << "This an INFO message which has a number attached: " << 12345 << std::endl;
    logger << LEVEL_WARNING << "This is a warning message." << std::endl;

    return 0;
}

Dieser Code schreibt zwei Nachrichten unter dem Präfix TestLogger ins Syslog. Die Doku der Klassen gibt noch einige Informationen her, welche Eigenschaften man zusätzlich konfigurieren kann. Das Logging-Frontend kann dank std::ostream-Kompatibilität natürlich jedes Element ausgeben, welches auf einem ostream ausgegeben werden könnte.

Der Code ist weiterhin header-only, braucht also keine Installation irgendwelcher Bibliotheken, sondern kann dan public-domain-Lizenz einfach ins eigene Projekt mit übernommen werden. Wer nett sein will: mich interessiert immer, wo der Code verwendet wird. Kurze Mail an mich wäre nett (hm... sollte ich vielleicht mal in die Lizenz schreiben...)

Der Code ist mittlerweile umgezogen und liegt bei Bitbucket: https://bitbucket.org/namenlos/logging/

screen für X-Programme

nospam@example.com (namenlos) — Sun, 30 Jan 2011 18:11:54 +0100

Kennt wahrscheinlich eh schon wieder jeder außer mir, aber wer schonmal das Problem hatte, dass er gern ein X-Programm laufen lassen will und dann vielleicht noch auf einem anderen Rechner wieder drauf zugreifen, der sollte sich mal xpra anschauen. Wie screen das für die Konsole macht kann man mit xpra grafische Programme laufen lassen und später wieder an einen laufenden X-Server anklemmen. Geht (natürlich) auch von einem anderen Rechner aus via ssh. Macht sich sogar ganz bequem mit xpra attach ssh:user@host:display. Wieder was gelernt...

Wenn NVidia einen Monitorwechsel nicht erkennen will…

nospam@example.com (namenlos) — Thu, 03 Jun 2010 09:02:20 +0200

Manchmal regt mich meine NVidia-Karte im Notebook echt auf. Nicht nur, dass ich nur mit dem Binary-Treiber unter Linux Features wie 3D-Beschleunigung oder Suspend-to-RAM nutzen kann, nein, leider ist der auch noch nicht kompatibel mit der Standardarchitektur zum Setzen von Bildschirmauflösungen etc. Dafür braucht man ein spezielles Tool von NVidia, welches nur im Klicki-Bunti-Modus bedienbar ist. Nix mit Skripten und so (zumindest zum großen Teil). Macht alles nix, kann ich mich gerade noch dran gewöhnen. Was aber wirklich nervig ist, ist die Weigerung des Tools einen Wechsel des externen Monitors zu erkennen. Wenn man nach dem Booten einmal einen Monitor erkannt hat, dann lässt es sich durch nichts und niemanden davon überzeugen einen Wechsel desselben zur Kenntnis zu nehmen. Das ist normalerweise kein Problem: ich arbeite mit einem 1680x1050-Monitor, welche üblicherweise als erster erkannt wird und wenn ich dann mal zu einem Beamer wechsele, dann muss die Auflösung eben von Hand runtergestellt werden (sowieso sinnvoll, da viele Beamer interessanterweise eine höhere Auflösung melden, als sie nativ darstellen). Wenn ich jetzt allerdings mal ausnahmsweise einen Beamer nach dem Booten ranhänge und dann später zum großen Monitor wechseln will, dann hängt man mit der niedrigeren Auflösung fest. Nach einiger Rumprobiererei hab ich jetzt eine Methode, die das ohne X-Server-Neustart zu beheben scheint:

nvidia-settings starten ohne externen Monitor dran. Das Programm wird unter "X Server Display Configuration" das bereits früher erkannte Gerät (bspw. den Beamer) zeigen. Dort auf "Detect Displays" klicken. Das Programm wird sich beschweren, dass der externe Monitor entfernt wurde und fragen ob der auch aus der Liste der verfügbaren Displays entfernt werden soll. Soll er. Auf "Apply" klicken, bestätigen und das Programm beenden.
Monitor anstecken und nvidia-settings wieder starten. Wenn man jetzt unter "X Server Display Configuration" (wo definitiv nur ein Display zu sehen sein sollte, nämlich das interne!) auf "Detect Displays" klickt, dann sollte der richtige externe Monitor sichtbar werden (und damit auch die passenden Auflösungen zur Auswahl vorliegen).

Warum das so kompliziert ist fehlt mir im Moment jegliche Idee. Evtl. sitzt hier das Problem auch einfach mal wieder vor dem Monitor.

Neues yeanpypa-Release

nospam@example.com (namenlos) — Sat, 01 May 2010 13:43:16 +0200

Nach über drei Jahren hab ich's dank der Anregung eines Kollegen doch mal geschafft, meinen kleinen Parser-Generator in Python aufzuarbeiten und eine neue Version zu veröffentlichen. Diese bringt endlich rekursive Regeln und die Möglichkeit Regeln zu gruppieren. Außerdem sollte sie jetzt auch Python 3 kompatibel sein. Geblieben ist natürlich die einfache Definition von Parsern in Form einer (leicht abgewandelten) EBNF direkt in Python.

Weil Gelaber über Software ohne Beispiel immer doof ist hier ein Beispiel für das Parsen einer einfachen XML-ähnlichen Sprache:

#! /usr/bin/env python
# -*- coding: utf-8 -*-

from yeanpypa import *

test = '<tag><inner attr="Just a test">plah</inner></tag>'

text = Word(alpha)
name = Combine(alpha + ZeroOrMore(alpha | digit))
value = Literal("\"").hide() + Word(alpha | AnyOf(" \t.,!?+-") | digit) + Literal("\"").hide()
attribute = name + Literal('=').hide() + value
opening_tag = Group(Literal('<').hide() + Word(alpha) + ZeroOrMore(attribute) + Literal('>').hide())
closing_tag = Group(Literal('').hide())
tag = Recursive()
tag.set(text | opening_tag + tag + closing_tag)

result = parse(tag, test)
print result.getTokens()

Die Ausgabe ist hierarchische Liste von Token sein (wobei alle, die mit .hide() markiert werden nicht enthalten sind):

[['tag'], [['inner', [['attr', ['Just a test']]]], 'plah', ['inner']], ['tag']]

Mittels semantischer Aktionen die an Teile der Regeln gehängt werden kann man komplexere Datenstrukturen on the fly aufbauen statt erst auf der endgültigen Tokenliste zu arbeiten. Bspw. könnte die Regel tag mittels einer semantischen Aktion ein Objekt einer Klasse Tag anlegen, welches strukturierten Zugriff auf die Bestandteile des Tags gibt. Semantische Aktionen sind Funktionen, die die Tokenliste, welche durch die Regel gematcht wurde als Parameter erhalten und darauf beliebige Aktionen ausführen können. Yeanpypa ist so konstruiert, dass der Rückgabewert einer semantischen Aktion anstelle der Token in das Ergebnis übernommen wird. So kann man hier also statt einer Liste von Token mittels einer semantischen Aktion gleich eine Liste von Tag-Objekten erhalten.

Die Software findet sich mit dem neuen Release auf bitbucket.org. Doku und Beispiele (auf Englisch) finden sich auf meiner snippets-Webseite. Wenn ich Zeit finde werde ich noch ein paar mehr Beispiele implementieren um die Fähigkeiten von yeanpypa umfassender zu demonstrieren.