xscDevBlog - LastSharp & Co. » Software

Scripe. Oder: Warum eine Scriptsprache auch nur eine Suppe ist.

WordPress — Wed, 02 Sep 2009 20:40:33 +0000

Es ist wohl aufgefallen, ich erwähne es trotzdem: Seit einiger Zeit arbeite ich an einem Prinzip, dass es jedem Interessierten ermöglichen soll, eine eigene Script- oder Programmiersprache zu entwerfen. Meine theoretischen Überlegungen, so langweilig sie auch manches Mal seien mögen, habe ich in einer Reihe von Artikeln festgehalten; damit ich diese Texte aber auch schreiben konnte, musste ich immer ein kleines Stückchen vorausdenken und einiges an implementierungstechnischer Vorarbeit leisten.

Und heute war ich dann soweit, dass ich eine gar nicht so üble Version vor mir hatte, die ich nun (nicht detailliert, eher angeberischerweise ) präsentieren will. Vorhang auf für Scripe!

(Der Name hat mehrere Hintergründe: zum einen wäre da der Schreibfehler, der schonmal beim Wort “Scripte” auftaucht, zum anderen findet sich ein Ursprung im englischen “to scribe”, was soviel wie “vorzeichnen” bedeutet. Zuguterletzt sagt einem das allwissende Urban Dictionary, das “scripe” das Äquivalent von “a load of rubbish”, also etwas nicht ganz hochwertigem ist. Das ist auch in Ordnung so: Scripe ist der Weg, den ich einschlagen würde, wenn ich eine Scriptsprache zu entwickeln hätte. Zwar sind Grundkonzepte, die sich auch im professionelleren Einsatz finden, vorhanden, aber Scripe erhebt in dieser Hinsicht keinerlei Anspruch auf Vollständigkeit oder übermäßige Effizienz. “Quick and Dirty” wäre dennoch übertrieben, dann doch eher “Quick and Not-So-Clean“…)

Die Suppe im Titel lässt das Prinzip erahnen: Suppen brauchen Gewürze, um zu schmecken, und hierbei ist es wichtig auf die Mischung zu achten. Ebenso wird jeder seine Suppe anders würzen, je nach Vorlieben oder Vorhaben. Eine Scriptsprache ist da nicht anders: hier eine Prise Variablenverwaltung, dort ein Löffel Arithmetik. Voilà.

Dieses Suppenprinzip findet man heutzutage überall, hauptsächlich in der Unix/Linux-Welt, wo man je nach Bedarf auf einfachste Art und Weise ein Paket nachladen kann und das Gesamtsystem somit bis ins letzte Eck modifizierbar bleibt. Auch Scripe verwendet solche Pakete, allerdings eben für die Features der Programmiersprache!

Folgender C#-Code erzeugt einen Prozessor, der den Shunting-Yard-Algorithmus verwendet, um die Eingabe zu parsen. Anschließend erhält er vier Pakete: eines für arithmetische Operationen, eines für String-Operationen, eines für Ein- und Ausgabe, und eines für Variablendefinition und -verwaltung. Anschließend wird eine Eingabe-Auswertungs-Schleife gestartet.

// Create processor
Processor p = new Processor(
    new ShuntingYardAlgorithm()
);

// Add packages
p.AddPackage(new Scripe.Evaluators.Arithmetic.ArithmeticPackage(true));
p.AddPackage(new Scripe.Evaluators.Strings.StringPackage("&", "$"));
p.AddPackage(new Lapicon.Evaluators.InputOutput.InputOutputPackage());
p.AddPackage(new Lapicon.Evaluators.Variables.VariablePackage());

// Empty codebase
Codebase c = new Codebase(new Scripe.Env.Environment());

// Read-Eval-Print-Loop
string r = "";
while (true)
{
    try
    {
        Console.Write("Calc: ");
        if ((r = Console.ReadLine()) == "exit") break;
        c.Add(r);
        Console.WriteLine(" ==> " + c.Execute(p).ReturnValue);
    }
    catch (Exception ex)
    {
        Console.WriteLine(" ERROR: " + ex.Message);
    }
}

In nur 5 Zeilen haben wir hier (mithilfe der Scripe-internen und zweier für Lapicon geschriebenen Pakete) einen Prozessor geschaffen, der jede der folgenden Eingaben auswerten kann:

1+(4-6)*(3-4^5)+e
def variable = 7*8
def variableDurchZwei = /2
echo "(7*8)/2 = " & $()

Und nun stelle man sich eine Internetseite vor, die eine gewisse Anzahl solcher Pakete anbietet. Scriptsprachen entwickeln einfach gemacht.

Soviel also von mir. Wann Scripe letztlich ganz fertig ist (und ich mich wieder den anderen Projekten wie LastSharp widmen kann), kann ich nur schätzen. Ist ein Monat in Ordnung?

SerienjunkiesGML

Tue, 07 Jul 2009 16:10:56 +0000

First of all: wie es mit der Legalität der Seite serienjunkies.org aussieht, weiß ich nicht. Ich selbst kannte sie bis vorgestern nicht und alles, was nun folgt, ist für mich nur eine programmiertechnische Fingerübung – wenn auch womöglich mit einem gewissen Nutzen.

Das Problem, auf das ich hingewiesen wurde, als ich mich nach online verfügbaren Episoden von Flight of the Conchords erkundigt und die o.g. Seite als Quelle empfohlen bekommen habe, war, dass man, um an Downloadlinks zu kommen (ohnehin nicht das, was ich wollte), für jede Episode ein Captcha lösen und anschließend für jede einzelne Teil-Datei eine Serie von Klick-Copy-Paste ausführen musste. Und da kam mir die Idee, dass ganze in ein Programm zu packen: SerienjunkiesGML (Get My Links!)

Man gibt einfach die URL einer Serienjunkies-Seite in das dafür vorgesehene Textfeld ein (alternativ kann man auch direkt nach irgendetwas suchen), lässt das Programm die verfügbaren Episoden laden und startet mit einem Doppelklick auf die jeweilige Episode das Holen der Links.

Das Lösen des Captchas konnte ich nicht automatisieren (da sind schon viel größere Kaliber als ich dran gescheitert), aber die darauf folgenden Operationen, die zu den eigentlichen Links führen. D.h.: Hoster auswählen, Captcha lösen, warten, fertig!

Man kann auch gleich von vornherein mehrere Episoden auswählen und mit einem Klick auf “Go!” nacheinander abarbeiten.

Ein Hinweis noch: das Holen der Links funktioniert in einer Vielzahl der Fälle reibungslos, nur manchmal scheitert es. Dann muss man die entsprechenden URLs (die mit “download.serienjunkies.org”) beginnen, eben von Hand in den Browser eingeben.

Herausforderungen an mich waren: Untersuchung einer HTML-Seite, Simulieren einer POST-Request, Entwicklung einer intuitiven Benutzeroberfläche.

Download: http://dev.xscheme.de/wp-content/uploads/2009/07/serienjunkiesgml.exe

Vom Gedankenspiel zum Versuch: Universal Version Description (UVD)

Fri, 01 May 2009 22:24:43 +0000

Das Problem der Updates

Ich bin in meinem vorletzten Artikel zum Thema Update-Check bereits darauf eingegangen: Versionsänderungen sind nicht immer leicht zu verfolgen und die Überprüfung auf Updates erfordert meist einen nicht zu unterschätzenden Programmier- und Verwaltungsaufwand. Weiterhin bedeutet es für den Entwickler selbst auch, dass er auf mehreren Hochzeiten tanzen muss: er stellt meist eine eigene Downloadseite bereit, die Links zu verschiedenen Versionen enthält, er aktualisiert gleichzeitig die Dateien, die für die Versionsüberprüfung zuständig sind, er kümmert sich um die Daten, die in irgendwelchen Softwareverzeichnissen (heise, chip.de, etc…) stehen, usw., usw… Als verantwortungsvoller Entwickler mit der Ambition, sein Programm unter die Leute zu bringen, hat man richtiggehend die Pflicht, diese Schritte durchzuführen – und das regelmäßig und mit äußerster Genauigkeit.

Hier nun also das (absolut logische und vernünftige) Konzept, das die meisten Beispiele, die man im Web zu dem Thema “Update-Check” findet, implementieren:

Augenscheinliche Probleme hierbei:

Die Verwaltung der Programmdaten läuft (beim Otto-Normal-Programmierer) meist von Hand ab, d.h. man bearbeitet die Update-Datei (die nicht, wie im Beispiel, im XML-Format vorliegen kann), lädt sie von Hand auf den eigenen Webserver und ist aus Kompatibilitätsgründen meist an ein (demnach schwer erweiterbares) Format und an einen bestimmten Dateinamen gebunden.
Je nachdem, wie detailliert die Update-Informationen sind (nur Versionsnummer vs. Versionsnummer, Änderungsdatum, Changelog, …), kann das Bearbeiten der Versionsdatei eine Heidenarbeit bedeuten.
Der Entwickler muss das Programm erst einmal dazu bringen, einen funktionierenden Versions-Check durchzuführen.
Und was passiert bei Programmen, die mehrsprachig funktionieren und beworben werden?

Die Idee im erwähnten Artikel war es also, den “Update Notification Server” nicht mehr als Eigentum des Entwicklers zu sehen, sondern als über ein API zugängliche Plattform im Internet, die Verwaltungsfunktionen komfortabel bereitstellt. Gleichzeitig wären verschiedene Bibliotheken für das API nötig, um dem Programmierer die Implementierung der Versionsprüfung fast gänzlich abzunehmen.

Was folgte, war ein Einspruch.

Es sei nicht garantierbar, dass der verantwortliche zentrale Server auch in zwei Jahren noch erreichbar sein würde, wurde argumentiert. Man könne das bei einem eigenen Server viel eher kontrollieren – und außerdem habe heutzutage ohnehin jeder Entwickler zumindest ein bisschen Webspace.

Dem kann man nicht widersprechen. Zwar würde eine zentrale Plattform den Komfort steigern, allerdings unvermeidbar auch das Risiko. Was also tun?

Unvereinbarkeit

Ein großes Problem bei den vielen Versionsprüfungsimplementierungen (was für ein Wort!) im Web ist die Unvereinbarkeit. Die meisten basieren auf verschiedenen Dateiformaten, die wiederum unterschiedlichen Informationsgehalt bieten. Eine reine Textdatei mit der Versionsnummer mag dem einen reichen, der andere benötigt aber vllt. auch schon den Downloadlink für die aktuelle Version dazu. Oder gar den Namen des Programms und Zusatzmeldungen. Kann passieren.

Wenn einem schließlich keine der Lösungen des World Wide Webs zusagt, dann bleibt nichts anderes zu tun, als eine bestehende Lösung anzupassen. Oder from scratch, also komplett neu zu beginnen. Das wiederum kostet Zeit und Energie, Schweiß und Kaffee, von den Nerven gar nicht erst zu sprechen. Was also tun? (Zweimal haben wir uns das jetzt schon gefragt!)

Eine Lösung, die es allen recht macht, wird es vermutlich nie geben, aber das heißt nicht, dass man nicht versuchen darf, in ihre Nähe zu kommen. Was benötigt wird, ist ein standardisiertes Dateiformat für Softwarebeschreibungen.

Standards

Es gibt so etwas bereits unter dem Namen Portable Application Description (PAD), nachzulesen beispielsweise in Wikipedia oder der Association of Shareware Professionals, anzusehen u.a. hier. Der Vorteil: das ist in der Tat ein Standard; der Nachteil: er wurde für den Vertrieb von Shareware entworfen. Außerdem wird ein alternatives XML-Namensraumkonzept verwendet, was sich für einen solchen Standard meiner Meinung nach nicht gehört.

Aber ganz allgemein hat das Format in meinen Augen signifikante Schwächen:

Erweiterbarkeit: Man darf genau einen Screenshot angeben, eine Informations-URL, usw…
Es findet keine Unterscheidung nach unterstützen Betriebsystemen statt. Angenommen, es gäbe einen Installer, der das Programm auf den neueren Windows-Versionen einrichtet, sowie einen, der es sogar auf Windows 95 zum Laufen bringt: PAD bietet keine Möglichkeit, diese Dateien zu unterscheiden bzw. überhaupt erst vernünftig gemeinsam anzubieten.
Wir leben in einer multilingualen Welt. Die meisten Programme sind für mehrere Sprachen ausgelegt, doch würde man versuchen, Informations/Download-URLs nach Sprache anzubieten, würde man an PAD absolut insane werden.
Überhaupt fehlt so etwas wie Hinweise auf Support im Web in PAD. Man kann Telefonnummern angeben, aber das Leben und die Lebenshilfe findet heutzutage nun einmal zu größeren Teilen im Internet statt als noch früher. Und E-Mail-Adressen bedeuten bloß Wartezeit.
Man kann in PAD genau einen Entwickler angeben. Was macht man bei heutzutage weit verbreiteten Entwickler-Teams?
Das Format hat eine Struktur, die das Verständnis manchmal erschwert. Aber es wird ja von Computern verarbeitet, also ist das akzeptabel. Andererseits: auch Suchmaschinencrawler sind Computerprogramme, und PAD (ein Standard!) wird von denen so gut wie ignoriert!
Was Nutzer oftmals interessiert, ist die Entwicklung eines Programms: Was gibt es neues? Was wurde entfernt, was verbessert?

Es ist vielleicht etwas hochgegriffen, aber für die Softwarebeschreibung der heutigen Zeit muss ein neuer Standard erarbeitet werden. Und hier wird aus dem Gedankenspiel der Versuch.

Was macht Software aus?

Um welche Punkte müsste sich ein neues Format kümmern, was sind seine Prämissen und Ziele? Und was genau will ich eigentlich? Ein Brainstorming:

Sprachenunterstützung
Änderungsverfolgung
Autorenliste
Firmenkontaktdaten
Lizenzinformationen
Suchmaschinen-Metadaten
Installationsanweisungen
Abhängigkeiten: Was brauche ich, damit das Programm läuft?
Einfacher Zugang zu Support-Quellen (Foren, Anleitungen, FAQ)

Es entwickelt sich vor meinem inneren Auge also langsam eine XML-Struktur, die das alles mit sich bringt: XML Application Description (XAD), veranschaulicht durch ein Beispiel (Rechtsklick >> Quelltext), das verwendete XSLT-Stylesheet und die DTD (das Dokument ist valide, ich weiß nicht, warum Firefox und der IE da rumspinnen).

Ein Gedanke

Dann kam mir ein Gedanke: nicht nur Programme unterliegen Änderungen, auch Dokumente, Filme, Serien lassen sich einem Versionskonzept unterordnen. Zwei Beispiele: die FAZ vom 30.04.2009 könnte ebensogut die Versionsnummer 2009.119 (der 30.04. ist der 119. Tag des Jahres 2009) tragen, und die Special Extended Edition von “Herr der Ringe: Die zwei Türme” könnte auch “Herr der Ringe 2.1″ heißen (wenn man keinen Wert auf Gewinn legen würde). Mit ein wenig Phantasie überträgt man das ganze auf Autos, CPUs, kurz gesagt: alles, was sich irgendwie als bildlicher Entwicklungsstrom darstellen lässt.

Wichtig hierbei ist die Möglichkeit, stets auf die früheren Versionen eines Objektes zugreifen zu können, weil im Idealfall Verweise auf diese vorhanden sind.

Wenn man also das oben erwähnte Format weiterentwickelt, verallgemeinert und anpasst, dann hat man ein mächtiges Werkzeug für weit mehr als bloß Software. Und hier wären wir.

Universal Version Description (UVD)

Da die Verwendung nicht mehr nur auf Programme beschränkt ist, ist es wichtig, anzugeben, was genau in einem Dokument beschrieben wird. Die Nomenklatur hierfür wäre idealerweise etwas wie “Kategories:Unterkategorie” oder “Kategorie” allein. Beispiele:

media:tv-episode
software:utility
paper:specification
paper:mathematics
…

Folgendes wäre ein Beispiel für das kleinstmögliche UVD-Dokument:




  
    WinAmp

Nicht sehr aussagekräftig, aber jetzt bauen wir noch Informations-Links (in verschiedenen Sprachen), sowie Beschreibungstexte (in verschiedenen Sprachen und Längen; die unterstützen Längenangaben sind 100, 255, 2000 und “any”) ein:




  
    WinAmp
    
      http://www.winamp.com/
      http://de.winamp.com/
    
    
      
        WinAmp is a multimedia player, supporting (...)
      
      ...

Deutsch und Englisch vorhanden, alles andere beliebig nachtragbar. Weitere Informationen wären: Lizenz, Keywords, Screenshots, etc…Anschließend könnte in einem neuen Abschnitt “release” die aktuelle Version (inkl. Downloadlinks nach Sprache und OS) beschrieben, in “contributors” alle Beteiligten aufgelistet und in “company” Informationen zum Firmenkontakt bereitgestellt werden.

Eine komplette Dokumentation des Formats würde den Rahmen aber noch mehr sprengen, deswegen wird hier auf die folgenden Dokumente verwiesen:

“Spezifikation” zu UVD: http://dev.xscheme.de/uvd/Universal%20Version%20Description.txt
DTD: http://dev.xscheme.de/uvd/uvd-1.dtd (Validate)
Beispiele:

Fazit

Meistens ist der eigene Blick von Selbstherrlichkeit getrübt, wenn man etwas in den eigenen Augen neues und tolles geschaffen hat. Deswegen brauche ich Meinungen hierzu.

Um das anfangs erwähnte Argument noch einmal aufzugreifen, man könne seinen eigenen Webspace besser kontrollieren, will ich hier erwähnen, dass ein UVD-Dokument natürlich überall liegen kann. Was bisher fehlt, sind Programme zur Verwaltung und Erstellung, sowie Bibliotheken zur Verarbeitung.

Vielleicht überschätze ich auch den Nutzen des ganzen. Kein Grund allerdings, den Stein nicht ins Rollen zu bringen.

Update (02.05.2009)

Ich will an dieser Stelle noch demonstrieren, wie sich das Format für einfache Versionsprüfung, sowie Update-Verarbeitung eignet.

Für einen normalen Versionscheck würde schon so etwas reichen:

Und folgende Datei könnte von einem Updater automatisch verarbeitet werden:


  
    LastSharp
  
  
    
      20
      4
      2009
    
    
      0
      4
      1
    
    
      
        
          http://download.server.tld/LastUtility.dll
        
      
      
        
          http://download.server.tld/LastSharp.exe
        
      
      
      
        
          http://download.server.tld/LastSharp041.zip
        
        
          
            Das vollständige Paket mit allen Dateien von LastSharp 0.4.1.

Wenn man genau hinsieht, erkennt man die Anweisungen an den Updater:

Lade die Datei “LastUtility.dll” von der angegebenen URL herunter und überschreibe ihre Entsprechung im Unterverzeichnis “.inc”.
Tue dasselbe mit der Datei “LastSharp.exe”, allerdings diesmal im Hauptverzeichnis. (“update-path” fehlt)
Lösche die Datei “settings.xml” im Hauptverzeichnis.

Der letzte “file”-Eintrag enthält das Gesamtpaket, das beim automatischen Update ignoriert wird. (“update-action=’ignore’”) Gleichzeitig wird es aber dem User im Gegensatz zu den Dateien zuvor direkt zugänglich gemacht. (“direct-download=’no’” soll verhindern, dass evtl. Clients die so markierten Links dem User zeigen)

Wenn man jetzt bedenkt, dass ein wichtiger Punkt von UVD die Verlinkung mit den früheren Versionen ist (Der “release”-Tag bietet das Attribut “previous”, das auf das entsprechende UVD-Dokument verlinkt!), sieht man schnell, dass man mit diesem Format jede beliebige Version aktualisieren kann, wenn man sich in der Versionsgeschichte “zurückhangelt”.

Ich hoffe, diese kleine Demonstration hat noch einmal verdeutlicht, worin ich u.a. den Nutzen des Formats sehe.