de.metacoder:blog

Habe gerade bei Youtube einen Jax-Talk zum Einsatz des Playframeworks bei LinkedIn gesehen. Das Async-Handling von Play ist wirklich absolut genial:

Ich habe seit einiger Zeit Probleme mit Chromium auf Gentoo und der Fontdarstellung.

Die Fonts “Verdana, Helvetica, Arial, sans-serif” (CSS) sahen in normaler Textgröße super aus, sobald aber die Font größer war (z.B. 20px font size), war die Font pixelig und verwaschen.

Um das Problem zu lösen, habe ich mir das Corefonts-Package mit

emerge media-fonts/corefonts

merged. Seit der Installation sehen auch alle Schriften in größerer Version wieder sauber aus.

Ich muss noch mal debuggen, wie der Font-Loading-Mechanismus vom Chrome funktioniert um zu sehen, welche Schriftarten vorher die Übeltäter waren.

Anbei zum Kopieren die minimale pom.xml (+JUnit) mit der man sofort loslegen kann.

Die Scala-Sourcen werden dabei aus “src/main/scala”, die Scala-Testsourcen in “src/test/scala” geladen. Parallel können ganz normal in “src/main/java” / “src/test/java” die entsprechende Java-Sourcen abgelegt werden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelversion>4.0.0</modelversion>
    <groupid>de.metacoder</groupid>
    <artifactid>scalamaven</artifactid>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <dependencies>
        <dependency>
            <groupid>org.scala-lang</groupid>
            <artifactid>scala-library</artifactid>
            <version>2.10.3</version>
        </dependency>
        <dependency>
            <groupid>junit</groupid>
            <artifactid>junit</artifactid>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupid>org.scala-tools</groupid>
                <artifactid>maven-scala-plugin</artifactid>
                <version>2.15.2</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>testCompile</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <jvmargs>
                        <jvmarg>-Xms64m</jvmarg>
                        <jvmarg>-Xmx1024m</jvmarg>
                    </jvmargs>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Der “configuration”-Part, der die JVM-Args steuert und den Heapspace setzt, ist optional. Bei kleineren Projekten reichen die default settings, man kann den Part also weglassen. Bei größeren Scala-Projekten benötigt man die Heapspace-Settings für den Compiler aber wieder, da die Defaults zu knapp werden.

Sowohl unter Fedora als auch unter Gentoo (Stable) hatte ich das Problem, dass ich mit Pavucontrol für das laufende Spiel das Ausgabegerät nicht umschalten konnte. In Pavucontrol konnte ich zwar den entsprechenden Button drücken und mein Wunschausgabegerät wählen, allerdings hat dies keine Auswirkung gehabt und das Ausgabegerät wurde nicht umgestellt.

Der nächste Versuch das Ganze über die command line zu lösen hat mehr Licht ins Dunkle gebracht:

# IDs der Ausgabegeräte rausfinden
pactl list sinks

# Applikationen die über PulseAudio Sound ausgeben auflisten:
pactl list sink-inputs

# Ausgabe von X-Plane (Sink-Input 118) auf Sink 1 (neues Ausgabegerät) umleiten:
pactl move-sink-input 118 1

Der “pactl move-sink-input 118 1"-Befehl terminierte bei mir mit “Failure: Invalid argument”. Beim “pactl list sink-inputs” ist mir beim X-Plane folgende Zeile aufgefallen:

flags: DONT_MOVE START_CORKED FIX_RATE

Das Flag DONT_MOVE hat verhindert, dass man das Ausgabegerät umschalten kann. X-Plane und Steam verwenden OpenAL für die Soundausgabe. Im Steamforum habe ich die Lösung für dieses Problem gefunden. Man muss einfach die Datei .alsoftrc in seinem Home-Verzeichnis mit folgendem Inhalt anlegen:

# ~/.alsoftrc
[pulse]
allow-moves=yes

Ob das irgendwo anders zu Problemen führt / warum OpenAL by default keine Moves erlaubt kann ich aber noch nicht mit Sicherheit sagen. X-Plane funktioniert auf jeden Fall tadellos mit den neuen Settings.

Ich habe gerade einen spannenden und anschaulichen Talk über References in der JVM angesehen. Die verschiedenen Reference-Types (Soft, Weak, Phantom, Hard) werden erklärt, danach folgt noch ein kleiner Ausflug in GUAVA und zum Schluss wird noch einmal kurz der MarkSweep garbage collector (grob) erklärt. Ein sehr schöner Talk, den ich euch nicht vorenthalten möchte: