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.
Tja nun ist es doch passiert. Shyuohei (der 1.8er Maintainer) ist mit Ruby zu Github umgezogen. Es handelt sich hierbei noch nicht um einen offiziellen Umzug sondern um einen Mirror des Subversion Trunks. Bisher ist alles noch experimenteller Natur aber genau so begann auch der Umzug von CVS nach SVN. Ich bin gespannt, gerade weil auf der RubyKaigi noch die Begründung geäußert wurde, dass ein Umzug zu GIT nicht in Frage kommt, da die Windows Unterstützung so schlecht sei.
Ruby 1.9.2 ist draußen und bringt ausser den in den News angekündigten Änderungen noch eine größere Überraschung mit.
Aufgrund eines potentiellen Sicherheitsproblems ist das Verzeichnis . nicht mehr standardmässig in $LOAD_PATH. Das bedeutet:
[ skade HIPE-Machine ~/Downloads/ruby-1.9.2-preview1 ] ls test.rb
test.rb
[ skade HIPE-Machine ~/Downloads/ruby-1.9.2-preview1 ] ./ruby --version
ruby 1.9.2dev (2009-07-18 trunk 24186) [i386-darwin9.7.0]
[ skade HIPE-Machine ~/Downloads/ruby-1.9.2-preview1 ] ./ruby -e "require 'test'"
-e:1:in `require': no such file to load -- test (LoadError)
from -e:1:in `' von WoNáDo
Nach monatelanger Pause habe ich jetzt ein bisschen Zeit den dritten Teil dieses einführenden Überblicks zu schreiben. Offen ist noch die Frage nach der Überprüfung, also ob ein Text einer vorgegebenen Beschreibung genügt. Beim Versuch der Beantwortung beschränke ich mich jetzt auf reguläre Ausdrücke und deren Erweiterungen.
Dieser Teil ist auch ein wenig subjektiver als alle anderen Beiträge. Ich habe bisher (hoffentlich) immer Beispiele und Beschreibungen gebracht und die Frage, ob ein Einsatz in bestimmten Situationen sinnvoll ist, restlos dem Leser überlassen. Das basierte auf der Voraussetzung, dass ein Benutzer regulärer Ausdrücke schon wissen wird, warum er sie einsetzen will (oder durch Dritte erzwungen einsetzen muss).
Diese Basis bleibt bestehen, nur werde ich bezüglich der Anwendung erweiterter regulärer Ausdrücke auf ein paar Probleme eingehen, die meiner Meinung nach die sinnvollen Einsatzbereiche begrenzen.
Also los...
Es ist zwar noch eine ganze Weile bis Weihnachten, aber eins ist sicher: Ruby 1.9.2 kommt. Und mit ihm ein Herzenswunsch Yehuda Katz's, der es wegen später Einreichung nicht mehr in 1.9.1 geschafft hat, aber im trunk vorhanden ist: Proc#parameters. Einen kleinen Spass, den man sich damit leisten kann, findet ihr unter dem Link.
Mit der neuen (gut, inzwischen nicht mehr komplett neuen) Ruby-Version 1.9.1 hat sich bekanntlich einiges geändert. Die vielleicht größte Veränderung ist, dass der Ruby-Mainstream nun von der mittels des Microsoft Visual C++-Compilers erstellten mswin32-Version auf die MinGW/MSYS-Schiene wechselt. Mit diesem Wechsel gehen einige Veränderungen einher, insbesondere was die Erweiterung von Ruby mitteils C betrifft. Ich habe mich in den letzten Wochen etwas damit herumgeschlagen und hoffe, dass das jemandem hilft. ;-)
von WoNáDo
Hier nun die Fortsetzung von Teil 0.0. Offen blieben noch zwei Fragen im Zusammenhang mit der Strukturbeschreibung: "In welcher Form kann man so etwas beschreiben?" und "Wie kann ich überprüfen, ob ein Text der Beschreibung genügt?".
Teil 0.1 versucht Antworten auf die erste Frage zu geben, ohne dabei zu sehr ins Detail zu gehen. Diese Themen werden umfangreich in der Literatur zur Theoretischen Informatik und zum Thema Compilerbau behandelt.
Also los...
von WoNáDo
Ich habe ein Problem. Nachdem inzwischen Teil 8 dieser Serie existiert, die bei Teil 1 begann, tauchte immer wieder mal die Frage nach einführenden Texten auf. Es wäre bestimmt verwirrend diese beispielsweise als Teil 9 bis Teil 13 zu führen, um dann als Teil 14 wieder etwas in der Preislage "wie quetsche ich das Letzte aus Oniguruma raus?" anzufügen.
Nun gibt es noch die 0, die selbstverständlich sehr geeignet für diese Zwecke ist - aber es gibt davon nur eine!
Also mache ich es ähnlich wie Ruby, indem ich einfach durch einen Punkt getrennt Unterpunkte einführe, damit ich vor der 1 noch reichlich Platz habe.
Klar? - Dann fange ich mal ganz langsam an... - ...ehe ich es vergesse: Bei den Nuller-Teilen sind Kopfschmerztabletten eher unnötig. Die Teile, die sich mit theoretischen Aspekten beschäftigen, können frei nach dem Motto "Mut zur Lücke" überlesen werden. Mit den Anwendungen regulärer Ausdrücke in Ruby wird man trotzdem zurecht kommen.
von WoNáDo
In Teil 8 dreht sich alles um die dynamischen Relativbezüge. Darunter verstehe ich die in der Beschreibung von Oniguruma unter back reference with nest level aufgeführten Möglichkeiten, dynamisch auf den Wert eines Untermusters, benannt oder unbenannt, zugreifen zu können, wobei man die gewünschte relative Stack-Position angeben kann. Alle diesbezüglichen Unklarheiten kann dieser Artikel (hoffentlich) beseitigen.
Die vollständige Beschreibung der in Oniguruma vorhandenen Möglichkeiten für reguläre Ausdrücke befindet sich hier.
Auch diesmal wieder die Anmerkung, dass die Beispiele nur als erklärende Programme für die betrachteten regulären Ausdrücke dienen. Gerade im Zusammenhang mit den dynamischen Relativbezügen lassen sich nicht leicht Beispiele finden, für die man diese Technik wirklich benötigt - aber vielleicht fällt ja jemandem, der das hier liest, eine Killer-Anwendung ein.
Nun aber los.
von WoNáDo
Die Teile 7 und 8, die nun fast zweieinhalb Jahre nach Teil 6 erscheinen, behandeln die statischen und dynamischen Relativbezüge in Oniguruma, sind also in der gerade freigegebenen Version Ruby 1.9.1 verfügbar. Die statischen Relativbezüge, die Teil 7 behandelt, wurden erst in der letzten Version von Oniguruma bereitgestellt, während die in Teil 8 behandelten dynamischen Relativbezüge schon länger existieren und von mir in eingeschränkter Form auch bei den Palindrom-Beispielen von Teil 5 berücksichtigt wurden.
Die vollständige Beschreibung der in Oniguruma vorhandenen Möglichkeiten für reguläre Ausdrücke befindet sich hier.
Etwas möchte ich noch anmerken. Die Beispiele dienen als erklärende Programme für die betrachteten regulären Ausdrücke. Wahrscheinlich lassen sich andere und einfachere Lösungen für die Aufgaben finden, die ohne die betrachteten Elemente und unter Einsatz anderer Möglichkeiten von Ruby funktionieren.
Genug der Vorrede - los gehts.
Ruby 1.9 nimmt fahrt auf. Eines der größten Probleme der neuen Interpreterversion ist die Inkompatibilität zu 1.8. Um diesem Problem entgegen zu wirken, wurde die Webseite IsItRuby19.com ins Leben gerufen. Auf dieser Seite werden Erfahrungsberichte von Ruby 1.9 Anwendern gesammelt, aus welchen sich ableiten lassen sollte, ob eine bestimmte Bibliothek bereits sorgenfrei verwendet werden kann.
Wie immer die letzten im Bunde nun auch hier die Information, dass die Erste als stabil gekennzeichnete Version von Ruby 1.9 erschienen ist. Mehr Infos gibt im Rubyforum und auf der offiziellen Website. An dieser Stelle würde ich kurz mal in die Runde die Frage werfen, ob eine Empfehlung von Ruby 1.9.1 an Neulinge empfehlenswert erscheint. Die Frage hat sich mir gestellt, als ich Gestern die offizielle Rubywebseite aktualisieren wollte. Ist es sinnvoll Ruby 1.9.1 als den “empfohlenen Download” zu kennzeichnen? Was meint Ihr?
Wie gehabt: Ruby 1.8.6 vs. Ruby 1.9.0.
Leider noch ohne Rails, da die Tests noch nicht laufen.
Veränderungen bei Ruby 1.9 gegenüber Ende Oktober:
Ansonsten erstaunlich wenig Bewegung.