Am 07.05.2010 wurde die Versionsnummer vom Ruby Head auf 1.9.3 aktualisiert. Gleichzeitig wurde der aktuelle Trunk in den Branch 1_9_2 verschoben. Damit beginnt nun wohl die Stabilisierungsphase des 1.9.2er Releases. Bis zum 15.06.2010 werde nebenbei noch die “Supported Plattforms” für Ruby 1.9.2 ausgelotet. Im Moment gehört dazu ausschließlich GNU/Linux auf i386. Um Mac OS X etwas zu stärken habe ich mit Yugui gesprochen und eine Continuous Integration Environment für Mac OS X 10.6 aufgesetzt, welche ich in den nächsten Tagen noch stabilisieren möchte. Vielleicht wird 1.9.2 dann mit Unterstützung für Mac veröffentlicht.!
Fünfzig:
Übersetzt von yugui.
Erste große Neuigkeit vor dem kompletten Konferenzbericht.
Matz hat auf der RubyConf India 2010 angekündigt, dass nach dem finalen Release von Ruby 1.9.2 ende August, die Arbeiten an der Version 2.0 beginnen werden. Es ist bereits abzusehen, dass die Entwicklung ähnlich lange dauern wird, wie die Arbeiten an der 1.9er. Aus dem Grund z.B. das Koichi einen Forschungsauftrag für 3 Jahre erhalten hat, in dem er ein Konzept entwickelt und implementiert, mit dem Ruby Fit für das so genannte Hochleistungsrechnen gemacht werden soll. Diesbezüglich wird desöfteren auch NArray ins Gespräch gebracht. Weiterhin sind für die 2.0 die üblichen Verdächtigen geplannt:
Einige Monate ist es her, dass Yugui den Erscheinungstermin für Ruby 1.9.2 auf unbestimmte Zeit verschoben hatte. Diese unbestimmte Zeit ist nun scheinbar angebrochen. Yusuke verkündete heute morgen, dass der Trunk nun die RubySpec besteht. Damit bat er auch darum, einen neuen Erscheinungstermin für die Version 1.9.2 zu terminieren.
Einige Monate ist es her, dass auf der RubyWorldConf 2009 die ersten Informationen bezüglich eines Standardiserungsprozesses veröffentlicht wurden. Heute wurde nun eine erste Version der Ruby Draft Specification veröffentlicht. Man kann sich das 341-Seitige PDF (zum Glück in Englisch und nicht Japanisch) auf der Seite herunterladen. Es tut sich also tatsächlich was in Bezug auf eine offizielle Spezifikation von Ruby. Die Autoren des Dokumentes bitten nun die Community um Feedback. Bleibt abzuwarten, ob es nur bei einem “Draft” bleibt.
Ich kann ja Daniel die Mine nicht ganz alleine überlassen, allerdings steckt mein nächster großer Artikel erst in den Kinderschuhen und wird demnächst nicht fertig. Daher hier ein Happen für zwischendurch.
Einer meiner liebsten Quälgeister in Ruby und allen anderen Sprachen, die Zuweisungen in Bedingungen erlauben, ist folgender:
1 2 3 |
if action = :pass #something end |
Und plötzlich wundert man sich, warum die Aussage immer wahr ist... Klar, kleiner Fehler, schnell korrigiert, aber manchmal nervig zu finden. Aber warum in die Gefahr begeben, wenn es doch so eine einfach Lösung dafür gibt?
1 2 3 |
if :pass = action #something end |
Das ist nicht nur ein Laufzeit-, sondern gleich ein Syntaxfehler. Gleichzeitig find ichs schöner, weil der wichtige Teil (der erwartete Wert) vorne steht. Obendrein unterscheidet es sich sofort von diesem Pattern, in dem die Zuweisung bewusst geschieht (wir nehmen mal an, dass die Berechnung von full_name unakzeptabel lang dauert):
1 2 3 |
if name = object.full_name puts name end |
Yugui hat gerade in Ihrem Branch eine experimentelle DTrace Unterstützung eingebaut. Bei DTrace handelt es sich eigentlich um ein Profling Tool aus dem Solaris Universum, welches aber in der Apple Welt auch schon seit einiger Zeit sein Unwesen treibt. Das DTrace nun auch in den MRI Einzug erhält, lässt sich direkt auf die JRubyConf zurückführen. Auf dieser gab es einige Diskussionen über Schwarze Löcher im JRuby Interpreter, welche Geschwindigkeit verschlingen. Um diese Hotspots zu identifizieren, war nun die Idee geboren, in JRuby eine DTrace Unterstützung einzubauen. Um einen Vergleichswert zu ermitteln, war es dann auch nicht weit, diese Unterstützung ebenfalls in den MRI einzubauen. Dadurch lassen sich sehr detailierte Vergleiche einzelner Operationen zwischen den Implementation ausmachen und analysieren. Und wenn die entsprechenden Hotspots gefunden wurden, ist es nur noch eine Frage von Zeit und Aufwand diese zu entfernen. Diversität! Eine der mächtigsten Waffen im Rubyuniversum…
Wie Laurent Sansonetti auf dem MacRuby Blog ankündigt, findet sich auf der Downloadseite nun die erste Beta zu MacRuby 0.5.
MacRuby hat sich eine nahtlose Integrierung in das Ruby-ähnliche Objective-C-Objektsystem auf die Fahnen geschrieben. Auch ansonsten ist MacRuby ein interessantes Projekt: es basiert zwar auf dem Standardinterpreter MRI, tauscht aber dessen virtuelle Maschine (YARV) gegen einen LLVM-Unterbau aus.
0.5 ist bei weitem noch keine komplette Implementierung. Während die Kernsprache inzwischen fast komplett implementiert ist, werden nur 80% der Tests der Core-Bibliothek und 72% der Standardbibliothek erfüllt.
Beim basteln bin ich wieder über einen kleinen, aber feinen Unterschied zwischen Ruby 1.9 und Ruby 1.8 gestoßen, der eventuell verwunderlich sein kann: der Lookup von Konstanten wurde geändert. Meistens wird das nicht auffallen, allerdings gibt es einige Fälle, die einen erstmal etwas ratlos zurück lassen...
Bildquelle: http://www.flickr.com/photos/piulet/ / CC BY-NC-ND 2.0
Seit ein paar Tagen gibt es eine neue Hookmethode mit dem Namen respond_to_missing? im Rubytrunk.
Yugui war scheinbar auf einem Qualitätssicherungsseminar. Nach dem sie vorgestern angekündigt hat, den Release Schedule der 1.9.2 zu verschieben, sind nun Aufräumarbeiten bei den Maintainern angesagt. So kündigte sie vor 4 Stunden an, dass für alle Core- und Standard-Bibliotheken der Maintainerstatus geprüft wird. Sollte sich herausstellen, dass sich einige Maintainer nicht melden oder in den letzten drei Monaten keine Commits durchgeführt haben, wird Ihnen der Status aberkannt und eine neue Ausschreibung durchgeführt. Der Bestätigungsprozess der Maintainer läuft nun wahrscheinlich einige Wochen. Während und nach dieser Zeit, ist jeder Interessierte dazu aufgefordert, sich für einen offenen Maintainerposten zu bewerben.
Coverity ist ein Hersteller von Tools zur statischen Codeanalyse. In Kooperation mit dem amerikanischen Department of Homeland Security prüft er unter anderem kostenlos die Qualität von Open Source-Software. Sowohl Python, Perl und Ruby liefern sich seit einiger Zeit einen freundschaftlichen Wettstreit darum, ihre Software bei Coverity-Scans bugfrei zu halten.
Die seit 2008 verstärkten Bemühungen um die Qualität des MRI-Teams scheinen sich auszuzahlen, zumindest wenn man den diesjährigen Report liest (Registrierung nötig, Zusammenfassung in der Presseerklärung). Der MRI erhält neben 3 anderen Projekten (Samba, tor und OpenPAM) eine Rung 3-Zertifizierung. Das Rung-System (Rung = Sprosse einer Leiter) ist eine Art Belohnungssystem für Entwickler: wer alle in einer Stufe gefundenen Bugs bereinigt, wird in eine höhere Stufe aufgenommen. In dieser werden andere - angeblich fortgeschrittenere - Tests ausgeführt. 3 ist die aktuell höchste Stufe.
Besonders interessant ist, dass das MRI-Projekt zwar seit 2006 an Coveritys Angebot teilnimmt, bis 2008 aber keinerlei besonderen Bestrebungen gezeigt hat, sich um die gefundenen Probleme aktiv zu kümmern. 2008 wurden die Tests dann als wichtiger Indikator gesehen und gefundene Bugs mit Nachdruck gefixed.
Ein wenig Vorsicht sollte man natürlich walten lassen: Zum einen testet Coverity nur die C-Komponenten. Große Teile der Ruby-Distribution sind in Ruby selbst geschrieben, über die keine Aussage getroffen wird. Da diese Teile jedoch auch in anderen Interpretern zum Einsatz kommen, sind sie auch keine spezielle Eigenschaft des MRI. Auch sind große Teile der Core-Api des MRI in C geschrieben, werden also durchaus erfasst.
Zuletzt ist natürlich zu sagen, dass diese Scans sich nur auf statisch erkennbare Bugs beziehen, meist Fehler in der Speicherverwaltung oder der inkorrekten Verwendung verschiedenster Low-Level-Funktionen. Die nachlässige Quellcodedokumentation und die fehlende Hackers Guide werden leider nicht erfasst.
Trotzdem an dieser Stelle von mir: herzlichen Glückwunsch an das MRI-Team zu ihrem neu gefundenen und konsequent umgesetzten Qualitätswillen.
Nachtrag: Heise berichtet auch
Yugui hat in einer Mail an die Core-Mailingliste mitgeteilt, dass die Release-Schedule von Ruby 1.9.2 abgesagt wird. Diese war bereits recht weit fortgeschritten: die dritte Preview für 1.9.2 war für den 25. September angekündigt, einhergehend mit einem Feature Freeze. Als Begründung führt sie den Entschluss des MRI-Entwicklerteams an, dass der 1.9.2-Interpreter vor dem Release die RubySpec erfüllen muss. Diese Entscheidung würde aber einiges an Arbeit nach sich ziehen und ist somit nicht innerhalb des Rahmens zu erfüllen.
Die Bedeutung dieses Ereignisses ist nicht zu unterschätzen: lange Zeit war die RubySpec eine Bemühung, das Verhalten des MRI so zu beschreiben, dass andere Implementierungen ihre Konformität zu ihm testen können. Nach dieser Entscheidung ist die RubySpec nun eine Testsuite, die Ruby interpreterunabhängig beschreibt. Zu diesem Zweck bringt sie sogar eine simple Implementierung einer Specsuite mit, die es leicht machen soll, einen unvollständigen Miniinterpreter zu erstellen, der dann zumindest die Testsuite ausführen kann - auch, wenn er bei weitem Ruby nicht komplett implementiert.
Das ist keine Arroganz (auch wenn es von unten so aussehen mag :-). Es ist einfach Genugtuung nach ewiger Bevormundung im Bereich Lokalisierung auch mal auf unserer Seite des Atlantik sich zurückzulehnen und mit den Schultern zu zucken. Ein amerikanischer Rails Anwender hat folgende Verbesserung in 1.9 für sich entdeckt:
ruby-1.8.6-p383:
1 2 |
require "date" Date.parse("01/02/2009").day # => 2 |
ruby-1.9.1-p243:
1 2 |
require "date" Date.parse("01/02/2009").day # => 1 |
Mein Beileid geht an alle diejenigen, die ASCII für das Nonplusultra halten, UTF-8 als die Lösung Ihrer nicht existenten Probleme ansehen und sich immer gefragt haben warum in einer englischsprachigen Welt Lokalisierung ein Thema sein soll.