programmierer-nachrichten.de
Startseite Podcast RSS Impressum

Podcast Folge 5


Wie versprochen der wöchentliche Podcast! Heute nun Folge 5. In dieser Folge unterhalte ich dich mit der Markdown Alternative restructuredText (reST), LLVM 4.0.0, Java 8 Sprachunterstützung bei Googles Android Compiler, Guetzli, um kleinere JPEG Dateien zu erzeugen, Guile 2.2.0, Firefox gibt ALSA auf, Gitea 1.1.0 veröffentlicht, Russen haben Magnetometer basierte Wanzen in IBM Selectric Schreibmaschinen eingebaut, um die Tastenschläge live mitzuschneiden, und Tastaturen mit Hallsensoren.

Viel Spaß mit dieser Folge!


Guetzli erzeugt 20-30% kleinere JPEG Dateien


Google hat einen neuen JPEG Encoder vorgestellt und er nennt sich "Guetzli". Guetzli wurde in Version 1.0 veröffentlicht und verspricht 20 bis 30% kleinere JPEG-Dateien mit Wahrung der Kompatibilität bestehender Software wie Webbrowser, Bildbearbeitungs- oder Darstellungsprogramme.

Ich habe "guetzli" in Version 1.0 aus der Quelle kompiliert und mal ein paar Testbilder angefertig. Ein Bild habe ich mit Gimp als JPEG exportiert, ohne Vorschau, und bei einer Qualität von 100. Das Gimp JPEG ist 121KB groß; dann habe ich es mit "guetzli" verarbeitet und es macht daraus ein JPEG mit 99,6KB (auch 100% Qualität). Das ist bei einer so kleinen Datei schon recht erstaunlich, finde ich. Zumal das "kleinere" JPEG ohne Probleme im Webbrowser dargestellt werden kann. Auch die Vorschauprogramme haben damit kein Problem.

Ich habe außerdem eine PNG-Datei erzeugt, sie mit GIMP zu einem 100% JPEG exportiert und das Resultat sind 121KB; unverändert also. Verarbeite ich die PNG-Datei nun mit "guetzli", so dauert die Verarbeitung schon deutlich länger als von JPEG zu JPEG. Das ist aber logisch, weil das PNG ja auch erst dekodiert werden muss (wobei das JPEG auch dekodiert werden muss; das funktioniert vermutlich nur deutlich schneller). Insgesamt benötigte "guetzli" für das Testbild ca. 14 Sekunden (auf einem Core i7 Desktop PC). Das resultierende JPEG ist dann 107KB groß. Die Verarbeitung von JPEG zu JPEG nahm erheblich weniger Rechenzeit in Anspruch.

An diesem Beispiel sieht man gut, dass JPEG Dateien selbst mit 100% Qualität mehr "Datenverlust" haben als PNG, aber das war ja keine Überraschung.

Ich hatte versucht eine Qualität weniger 84 einzustellen, aber dann gibt es eine Fehlermeldung. Man soll, wenn man eine schlechtere Qualität haben will, doch bitte den Quellcode verändern und neu kompilieren :).

Empfohlen wird außerdem als Quelle immer eine JPEG zu wählen, die von sehr hoher Qualität ist. Und im Optimalfall wählt man als Quelldatei ein PNG Bild, denn PNG ist verlustfrei. So funktioniert "guetzli" laut Google am besten. Ein Nachteil, der nicht unerwähnt bleiben soll: die Verarbeitung der Datei dauert vergleichsweise lange. Aber nicht so lange, dass es stört. Ich finde die Wartezeit ist es wert. Aber das muss man selber entscheiden. Für Fotoalben würde ich es vielleicht nicht verwenden, aber...wenn es nur die Online-Bilder sind, und man die Originalen noch auf seinem NAS liegen hat...dann spricht eigentlich nichts dagegen. Ich konnte auf den ersten Blick keine Unterschiede erkennen. JPEG ist ja eh nicht so der "Knaller", wenn es um Qualität geht. Wenn man verlustfrei abspeichern will, wählt man sowieso kein JPEG.

"guetzli" gibt es bei Github zum Download für verschiedene Plattformen. Für Windows, Linux und macOS kann man ausführbare Dateien runterladen. Das Kompilieren funktioniert aber auch ohne Probleme und ist auch sehr schnell.

Cooles Projekt! Finde ich gut! :)


Google erweitert Android Compiler um Java 8 Sprachunterstützung


Es mag komisch klingen, dass Google erst jetzt ihren Java Compiler für Android um Java 8 Sprachuntertützung erweitert, denn Java 9 steht ja quasi in den Startlöchern und Java 8 gibt es auch schon seit 2014, aber besser spät als nie.

Mit dieser Neuerung gibt Google nun auch die Jack Toolchain auf. Sie hatten versucht Java 8 Unterstützung in Jack zu implementieren, sind dann aber zu dem Entschluss gekommen, dass der Aufwand zu hoch wäre, um relevante Tools so umzubauen, dass sie Jack nutzen. Und auch, wenn Google es nicht geschrieben hat, so dürfte auch Jill nicht mehr weiter entwickelt werden.

Jack ist eine Toolchain von Google, um aus Java Quellcode *.jack-Dateien zu erzeugen. Die meisten Android Programmierer kennen nur *.dex; das wäre an dieser Stelle vergleichbar. *.jack wäre dann eben das neue Bytecode Format. *.jack oder *.dex: das ist bei Android das, was Java Programmierer sonst als *.class-Dateien kennen. Google nutzt ja nicht die Oracle VM, sondern ihre eigene Virtual Machine, die für das mobile Betriebssystem Android optimiert wurde. Zwar nutzt Google mittlerweile die OpenJDK APIs, jedoch nicht die virtuelle Maschine davon, da diese eben kein *.dex oder *.jack versteht. Jill ist ein Tool von Google, um aus bestehenden *.jar-Dateien *.jack Dateien zu erzeugen. Somit sind also Jack & Jill Geschichte, bevor sie überhaupt berühmt werden konnten :)!

Es gibt also kein neues "class file"-Format, sondern "lediglich" Java 8 Sprachunterstützung im Compiler und den bestehenden "DEX"-Tools.

So oder so hat ein Java-Entwickler den Vorteil nun auch die Java 8 APIs nutzen zu können. Das ist unterm Strich eine gute Sache.


LLVM 4.0.0 veröffentlicht


Vor kurzem wurde LLVM 4.0.0 veröffentlicht, eine Low-Level Virtual Machine, mit der man Compiler bauen kann. LLVM ist mittlerweile sehr beliebt. In der Vergangenheit hatte ich das Gefühl, dass jede neue Programmiersprache sich immer darauf konzentrierte C-Code zu erzeugen. Das ist mittlerweile gefühlt nicht mehr so.

Etwas weiter zurück in der Vergangenheit haben Compiler Assembler-Code erzeugt. Dieser Code musste selbstverständlich für eine sehr spezielle Architektur erzeugt werden. Das war sehr aufwendig. Wollte man für x86 Code erzeugen, so musste man es speziell für diese Prozessorarchitektur implementieren. Hatte man nun das Verlangen, dass der Compiler auch Code für ARM basierte CPUs erzeugt, so musste man quasi die komplette Coderzeugung neu programmieren, da sich ARM und x86 sehr deutlich unterscheiden. Der Aufwand für soetwas war und ist sehr hoch. Nicht thematisiert sind bei solchen Projekten die Optimierungen. Diese muss man für jede Architektur entwickeln und erproben. Das ist sehr aufwendig und kostenintensiv.

Aber genau dafür gibt es ja LLVM. Immer, wenn ich über eine neue Programmiersprache lese, so sehe ich, dass, anstatt C-Code, immer häufiger LLVM IR Code erzeugt wird. Das hat natürlich diverse Vorteile. LLVM IR ist eine Zwischensprache. Simpel gesprochen ist LLVM IR ein prozessorunabhängiger Assembler-Dialekt. Das beschreibt es, glaube ich, am besten. Wenn man also heute einen Compiler baut, kann man LLVM IR Code erzeugen und somit, ohne dafür direkt zu entwickeln, diverse Prozessorarchitekturen abdecken. Man bekommt außerdem diverse Optimierungen geschenkt.

LLVM ist sehr verbreitet und Optimierungen auf Basis des LLVM IR Codes sind sehr effektiv. Die Tools sind erprobt und werden gerne angenommen. Eines der bekanntesten Frontends für LLVM ist vermutlich Clang (gesprochen: SSie-Läng :D). Clang ist ein C-Compiler auf Basis von LLVM. Eingesetzt wird er bei Apple, FreeBSD und vielen anderen Projekten. Was dieser C-Compiler heute noch nicht problemlos kompilieren kann ist der Linux-Kernel :). Es gibt Bemühungen und auch erfolgreiche Builds mit C-Lang, aber out of the box geht es nicht. Egal! Dafür kann Clang C, C++ und Objective C/C++. Ha!

Einige interessante Frontends gibt es für LLVM. Darunter Pony, MacRuby, The Pure Programming Language Compiler, LDC - the LLVM-based D Compiler, Emscripten (!!), usw...

Aber der Text wird wieder viel zu lang. Mehr als 7 Minuten kann sich eh keine Sau konzentrieren. Und lesen strengt ja eh voll an ;). Schau dich einfach auf der Website von LLVM um und entdecke die vielen Sprachen, die es bereits unterstützt. Mit "dragonegg" kann man auch die meisten Sprachen der Gnu Compiler Collection (GCC) nutzen; nicht alle aber sinnvoll.

Im nächsten Podcast werde ich vermutlich auch thematisieren, was Richard M. Stallman über LLVM denkt. Das ist auch nicht ganz uninteressant.


Eine Markdown Alternative: reStructuredText


Wir Programmierer lieben es zu dokumentieren! Ok, das ist nur die halbe Wahrheit. Oder auch ganz gelogen :)! So oder so muss man manchmal in den sauren Apfel beißen und eine Dokumentation anfertigen. Sei es ein Pflichtenheft, ein Fachfeinkonzept, eine Betriebsdokumentation oder gar eine Notfalldokumentation. Letzteres natürlich nur, wenn man wirklich überzeugt von seiner Implementation ist.

In vielen Firmen wird vermutlich noch mit Word dokumentiert und so grundsätzlich falsch ist das ja nicht, aber es hat eben auch einige Nachteile. Grundsätzlich ist es schlecht durchsuchbar, wobei man das auch irgendwie hinbekommt. Meistens liegen solche Dokumente aber auf irgendwelchen Netzwerklaufen, die eben sehr langsam zu durchsuchen sind.

In einigen Firmen findet man Dinge wie Confluence von Atlassian oder IBM Connections (wuah!). Aber diese Tools haben WYSIWYG-Editoren, die zwar für den Average-Joe funktionieren, aber echte Programmierer hassen sowas. Nicht nur, dass man die Formatierung mit den teilweise recht fehlerhaften Tools vornehmen muss; auch auf die Versionierung muss man sich verlassen. Diese findet tool-spezifisch statt. Das ist ja gar nicht so toll, da man den Bezug zur Implementation verliert.

Als Programmierer wird man aber sicher schon mit Markdown in Kontakt gekommen sein. Da kann man Dokumente formatieren, ohne sich auf WYSIWYG-Tools zu verlassen. Als weiteren Vorteil erkennt man sofort, dass die Versionierung im eigens gewählten SCM-Tool stattfinden kann. Außerdem kann man die Dokumentation sehr nah an die aktuelle Implementierung koppeln. Was sonst nicht erwünscht ist, ist hier ein Vorteil. Wenn ich Branch XY auschecke, so habe ich auch die damals aktuelle Doku. Sehr gut! Aber das ist nur ein sekundärer Vorteil. Der direkte Vorteil ist die Einfachheit von Markdown. Man muss sich nicht um die Optik kümmern. Und genau das ist das, was Programmierer vermutlich lieben. Man kann da was in reiner Textform schreiben und am Ende kann ein Tool daraus etwas Hübsches generieren.

Ein weiterer Vorteil von Markdown ist, dass es extrem einfach zu erlernen ist. Es ist eben sehr minimal. Markdown wurde von John Gruber und Aaron Swartz entworfen. Es ist so einfach, dass man es innerhalb weniger Minuten erlernen kann. Diese Einfachheit hat aber auch seine Nachteile. So gibt es zum Beispiel keine Tabellen, keine Fußnoten, usw...und was vielleicht verwirrt, aber es gab keinen wirklichen Standard für Markdown. Jeder hat so seine eigene Vorstellung von Markdown gehabt. Aus diesem Grund wurde CommonMark ins Leben gerufen. Das wird auch heute noch aktiv entwickelt. Das ändert aber nichts daran, dass Markdown an sich sehr eingeschränkt ist. Es gibt nur wenige Formatierungsmöglichkeiten.

Nun, so viel Bla und noch kein Wort über reST. reST? Ja, reStructuredText. Das ist, wie Markdown, eine vereinfachte Auszeichnungssprache und relativ einfach zu erlernen. Doch ist reST um Einiges komplexer als Markdown. Das ist aber nicht schlimm, denn du bist ja Programmierer und bevor du HTML schreibst, machst du lieber sowas wie reST, richtig? Richtig! :)

Um aus reST hübsche HTML oder PDF Dokumente zu erzeugen, kann man Sphinx benutzen. Das ist eine Software, die aus dem reST Code HTML und andere Zielformate erzeugt. Interessant ist auch, dass reST erweiterbar ist. So kann man Code Highlighting einbauen, oder gar Graphen, um nur zwei interessante Beispiele zu nennen.

Ist Markdown also für die Tonne? Nein, ganz und gar nicht. Markdown ist so derart simpel, dass es mit Sicherheit lange Verwendung finden wird. reST ist schon so komplex, dass man sich beim Schreiben Gedanken machen muss. Man muss es können. Und genau das entfällt bei Markdown. Das tippt man quasi blind. Und deswegen glaube ich, dass Markdown in vielen Bereichen bestehen bleiben wird. Für komplexe Dokumentationen kann ich mir reST aber sehr gut vorstellen. Der Nachteil ist, dass reST vermutlich nicht so "mal eben" nebenbei gelernt wird wie Markdown. Aber gut, sooo schwer ist reST nun auch nicht.

Einfach mal ausprobieren! :) Sphinx + reST (aka reStructuredText).


Archiv nach Kalenderwochen


2017/KW24, 2017/KW23, 2017/KW22, 2017/KW21, 2017/KW20, 2017/KW19, 2017/KW18, 2017/KW17, 2017/KW16, 2017/KW15, 2017/KW14, 2017/KW13, 2017/KW12, 2017/KW11, 2017/KW10, 2017/KW9, 2017/KW8, 2017/KW7


Startseite Podcast RSS Impressum