Aus verschiedenen Programmiersprachen kennt man die Notation von Hash-Arrays mittels ‚=>‘. Bislang habe ich das immer als eine Art Zeiger verstanden. Also bildlich.
Ich beschäftige mich gerade mit Puppet. Das ist zwar keine Programmiersprache, die Konfiguration sieht aber trotzdem so aus:
file {'/tmp/test1':
ensure => present,
content => "Hi.",
}
Das — übrigens sehr schön geschriebene — Learning Puppet hat mir gerade beigebracht dass man dieses ‚=>‘ als Hash Rocket bezeichnet. War mir auch neu. 
Unter Programmierern gibt es den Begriff ‚Code Poetry‘, eine Bezeichnung für besonders gelungenen Code. Sowas in Buchform zu veröffentlichen ist eine nette Idee.
Diesen Artikel habe ich erst 2015 aus dem alten CMS übernommen, der war 2012 noch nicht im Blog.
Ich weiß ehrlich gesagt nicht woher mein Faible für Taschenrechner kommt. Ich bin kein Mathematiker, und ehrlich gesagt kann ich mir auch nur den Bruchteil der Funktionen eines ‚großen‘ Taschenrechners schlüssig erklären. Aber die Dinger verarbeiten Einsen und Nullen, also muss auch da mal programmiert werden.
Auf Rechner des Herstellers Hewlett Packard bin ich seinerzeit durch einen Emulator auf meinem Nokia N800 aufmerksam geworden. Der heißt Free42, und den gibt es für jedes halbwegs gängige Betriebssystem. Ungewohnt war erstmal die umgekehrte polnische Notation (RPN), das war ein Konzept das ich verstehen wollte. Der Gedanke mir so einen Rechner als Original zuzulegen ist in dem Moment gestorben als ich gesehen habe dass das emulierte Modell — ein HP-42S — immer noch für weit über 150 Euro den Besitzer wechselt. Gebraucht, wohlgemerkt. Der wird seit 1990 nicht mehr hergestellt. Das macht neugierig…
Nun denn, zum Spielen reicht sicher auch die Emulation. Und da ich — außer einem Basic-programmierbaren Sharp PC-1402 Anfang der 90er — nie einen programmierbaren Taschenrechner hatte musste auch das mal ausprobiert werden.
Free42 auf Linux
Auf dem Gerät arbeitet man in der Programmiersprache FOCAL, also giesse ich das Problem in ein Programm:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
01 LBL "GELD" 02 0 03 STO 01 04 LBL B 05 RCL 01 06 100 07 + 08 STO 01 09 2 10 + 11 26 12 / 13 1 14 MOD 15 X!=0? 16 GTO B 17 RCL 01 18 100 19 / 20 .END. |
Dieses Programm ist alles andere als perfekt, reichte aber um mir zu zeigen wie man auf so einer merkwürdigen Hardware programmiert. Zur Funktionsweise: zunächst wird die Zahl 0 in Speicher 01 gespeichert. ‚LBL B‘ ist eine Sprungmarke. Dann wird der Wert aus Speicher 01 geholt, um 100 inkrementiert und wieder zurückgeschrieben. Der Wert steht jetzt noch bereit. Mit ‚2 +‘ wird 2 addiert (wir erinnern uns: umgekehrte polnische Notation. Zur Zahl 2 später mehr.), mit ’26 /‘ wird durch 26 Cent geteilt. Vom Ergebnis wird Modulo 1 gezogen. Ist das Ergebnis ungleich 0 wird zu Label B gesprungen, ansonsten wird der aktuelle Wert aus Speicher 01 geholt und durch 100 geteilt. Übrig bleibt der zu ladende Betrag in Euro.
Sicher kann man hier vieles verbessern. Die Zahl 2 ist der Restbetrag in Cent den ich noch auf der Karte habe, so eine ‚Magic Number‘ im Programm ist nicht schön. Außerdem kann es passieren — wenn ich beispielsweise doch mal 25 Cent am Parkautomaten investiert habe — dass mein Restbetrag eine ungerade Zahl ist. Da kann ich Euros addieren bis ich schwarz werde: es wird keine Summe rauskommen die glatt durch 26 Cent teilbar ist.
Aber immerhin: ich kann behaupten, schon einen Taschenrechner programmiert zu haben.
Mein HP-48G
Der 48G hat gegenüber dem 42S eine Reihe von Vorteilen, einer der gewichtigsten dürfte der weitaus geringere Anschaffungswiderstand der Hardware sein. Das Ding wurde zwischen 1990 und 2003 produziert, 2012 habe ich 30 Euro für einen gebrauchten bezahlt.
Also das gleiche Problem nochmal:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
< < "Restguthaben:" "" INPUT OBJ-> 0 26 -> rest betrag tasse < < DO betrag 100 + 'betrag' STO UNTIL betrag tasse 100 * >= rest betrag + tasse MOD 0 == OR END IF rest betrag + tasse MOD 0 == THEN betrag "Aufladen" ->TAG rest betrag + "Guthaben neu" ->TAG rest betrag + tasse / "Tassen" ->TAG ELSE "Keine Loesung" END |
Na das sieht doch schon deutlich weniger nach Assembler aus. Die Sprache nennt sich Reverse Polish LISP (RPL) und wirkt auf den ersten Blick wesentlich erwachsener. Auf den zweiten Blick fallen Zeilen auf in denen sehr merkwürdige Folgen von Variablen, Konstanten und Operatoren stehen. Aber auch eine Abbruchbedingung wie
|
1 |
betrag tasse 100 * >= rest betrag + tasse MOD 0 == OR |
lässt sich erklären. Wenn man die umgekehrte polnische Notation im Hinterkopf hat und lange genug drüber nachdenkt kommt man in etwa bei sowas raus (mit reichlich Klammern, um wirklich eindeutig zu sein:
|
1 |
(betrag >= (tasse * 100)) OR (((rest + betrag) MOD tasse) == 0) |
Wenn also in der Schleife der zu ladende Betrag grösser als 100 Tassen wird, oder die Summe aus Rest- und Ladebetrag ohne Rest durch 100 teilbar ist wird abgebrochen.
Zugegeben: ich hätte vielleicht auch übersichtlicher programmieren können. Aber etwas Spaß muss ja auch dabei sein, oder?
Mein TI-Nspire
Als erstes fällt wenn man das Ding in die Hand nimmt das Display auf. Riesengroß, und mit einer Auflösung von 320×240 Punkten. Das schreit geradezu danach, darauf Grafiken zu plotten. Diese Auflösung macht auch eine richtige grafische Benutzeroberfläche möglich. Die ist zwar etwas gewöhnungsbedürftig, funktioniert aber nach einiger Zeit wirklich gut. Darin enthalten sind dann sogar komplexere Anwendungen, wie zum Beispiel eine Tabellenkalkulation.
Auf dem Foto ist auch zu sehen dass dieses Modell über zwei Tastaturen verfügt. Wenn man gerade mal einen ‚einfachen‘ wissenschaftlichen Taschenrechner vorzieht steckt man einfach die zweite Tastatur in das Gerät. Deren Layout ist dem TI-84 plus nachempfunden, und sobald man einschaltet wird eben dieser emuliert. Vollständig. Einschliesslich der vergleichsweise dürftigen Displayauflösung.
Programmiert habe ich diesen Taschenrechner noch nicht. Dabei verspricht das, spannend zu werden: als TI-84 plus unterstützt das Ding TI-Basic, als TI-Nspire sogar die ausgewachsene Skriptsprache Lua — die der eine oder andere vielleicht sogar vom großen Computer her kennt…
Mein HP-48G
Heute habe ich mal was zu dem Thema auf der Schatenseite veröffentlicht. Das ist — ähnlich wie Mikrocontroller oder Smartphone — wieder eine komplett neue Plattform zum Programmieren. Andere Sprachen, andere Herangehensweise. Ich bin da alles andere als ein Experte. Bis jetzt zumindest. Aber was ich bislang gesehen habe hat mir schon gefallen.
Seit ich davon gehört habe bin ich davon überzeugt dass Test Driven Development eine sehr gute Sache ist. Gerade habe ich mir eine halbstündige Videopräsentation namens ‚Malen nach Zahlen‘ angesehen in der der Ansatz sehr schön gezeigt wird. Insbesondere der letzte Teil hat mich begeistert. Von Selenium hatte ich schon gehört. Webrat war mir neu, und Cucumber sieht geradezu aus wie Science Fiction — der utopischen Sorte…
Dummerweise hatte ich noch nicht die Gelegenheit, mal wirklich Erfahrungen in dem Bereich zu sammeln. Beruflich beschäftige ich mich seit ein paar Jahren mit einem System das alles andere als testbar ist. Und privat sind die meisten meiner Entwicklungen kleinere Skripte, oder kleine Änderungen an bestehenden Projekten. Die größeren Sachen sind Mikrocontroller-Projekte, wenn mir jemand sagt wie man da (sinnvoll) TDD anwenden kann waere ich sehr dankbar.
Ich schiebe schon länger zwei Ideen für Projekte vor mir her die sich vielleicht eignen… mal sehen ob und wann ich dazu komme…
Ich nutze den Blog mal um eine Frage in die Runde zu stellen. Hier lesen ja einige Elektronik-Bastler, vielleicht kann mir einer einen Tip geben.
Ich bin wieder einmal dabei eine Schaltung zu planen. Nichts kompliziertes. Wieder was mit USB, basierend auf einem ATmega8. Die Herausforderung: das Ergebnis sollte möglichst klein sein. Den Controller habe ich im TQFP-32-Gehäuse. Da würde ich gerne auf den ISP-Stecker zum programmieren verzichten. Auf dem Controller kann man auch einen Bootloader unterbringen, so dass ich den später per USB programmieren können sollte.
Die Frage ist: wie kriege ich den Bootloader elegant auf den Controller?
Ich habe Gestern schon probiert ob ich so ein Klemmen-Kabel vom Bus Pirate oder vom Logic Sniffer an den Controller anschließen kann. Also bevor der eingelötet ist. Sieht nicht nach einer guten Methode aus: getestet habe ich das nicht, aber ich glaube dass ich mit den Klemmen nicht nur einen einzelnen Pin erwische. Außerdem ist die Gefahr ziemlich hoch die Pins damit abzubrechen.
Ich habe gesehen dass es Adapter mit ZIF-Sockel für TQFP-Gehäuse gibt, das ist wohl der professionelle Weg. Die kosten aber auch professionell — zwischen 130 und 200 Euro. Selbst wenn ich sowas per eBay direkt in China bestelle sind es noch 30 Euro, das ist reichlich wenn ich nur zwei Controller damit versorgen will. Und dann könnte ich immer noch nur die eine Gehäuseform damit verarbeiten, wenn ich mal einen Tiny programmieren will stehe ich wieder vor dem Problem.
Also:
Oder wie? Ich bin für jeden Tip dankbar…
Da sich Gestern jemand über zu seltene Postings beschwert hat (Herzlichen Glückwunsch nochmal, Andreas 
), und da ich gerade mal wieder an einem kleinen Python-Projekt bastele: ein aktuelles Fundstück. Wenn man sich — wie ich — nichts merken kann, und zudem — wie ich — dauernd zwischen verschiedenen Programmiersprachen hin- und herspringt findet man so eine Sammlung mit Codeschnipseln sehr praktisch, stelle ich gerade fest. Hinweise auf bessere Schnipselsammlungen nehme ich dankend entgegen!
Das erinnert mich daran warum ich die Sprache C nach Möglichkeit nur auf Mikrocontrollern benutze:
rschaten% cat array.c
#include <stdio .h>
int main(int argc, char **args) {
char *string = "abc";
printf("%c %c %cn", string[0], string[1], string[2]);
printf("%c %c %cn", 0[string], 1[string], 2[string]);
return 0;
}
rschaten% gcc -o array array.c
rschaten% ./array
a b c
a b c
rschaten%
Das habe ich aus dem Unix Haters Handbook, ich hätte nicht gedacht dass das wirklich funktioniert…
Wie schon erwähnt muss ich mich bei der Arbeit mit Windows rumschlagen. Um Sehnenscheidenentzündungen vorzubeugen verschlägt es mich da bisweilen auch in die Kommandozeile. OK, das ist nicht der einzige Grund. Manchmal will man ja aus einem Skript (leider in diesem Fall kein Perl) heraus einfach mal ein system() aufrufen, und da muss man dann halt DOS-Kommandos absetzen.
Jetzt wollte ich etwas kluges basteln, das testet ob ich eine Datei (schreiben|lesen|löschen) kann. Auf anderen Systemen hätte ich dazu auf etwas in der Form
kommando; echo $?
gesetzt, die Ausgabe könnte ich parsen. Ein Kollege hat für DOS
kommando && echo ok || echo nein
vorgeschlagen, das sollte funktionieren. Prima, Exitcodes kann ich dann offenbar auswerten. Oder?
Um Vielleicht mehr Infos zu kriegen als (tut’s|tut’s nicht) versuche ich folgendes:
kommando & echo %ERRORLEVEL%
Und jetzt bin ich verwirrt (siehe Screenshot):
Das mit && funktioniert scheinbar, die Ausgabe von %ERRORLEVEL% bringt aber nicht sinnvolles? Was wird denn dann von && bzw. || ausgewertet? Und wie zur Hölle kriege ich den wirklichen Exit-Code?!?
Nach etwas mehr Spielerei stelle ich fest, dass in einigen Konstellationen der %ERRORLEVEL% tatsächlich gesetzt wird. Leider immer ein Kommando zu spät, wie man am zweiten Screenshot erkennen kann. Komischerweise funktioniert das aber — wenn man da von ‚funktionieren‘ sprechen kann — auch nur bei Programmaufrufen.
echo > . & echo %ERRORLEVEL%
führt zwar jedes Mal zu einer Fehlermeldung, gibt aber trotzdem nur 0 aus…
Ich beschließe einfach erstmal, das nicht zu verstehen. Mein eigentliches Problem kann ich offenbar unter Windows nicht elegant lösen, also muss ich mir da was anderes ausdenken… 
Im Moment bin ich wie schon erwähnt dazu gezwungen, beruflich viel auf Windows zu machen. Leider knirscht es dabei an allen Ecken und Enden, wenn man wie gewohnt produktiv sein will. Eine Menge Werkzeuge fehlen einfach, mal eben schnell eine elegante Shell- oder Perl-Zeile abschicken geht nicht. Von ganzen Skripten ganz zu schweigen.
Klar gibt es mit Cygwin oder ActiveState auch die Möglichkeit, einen Werkzeugkasten auf Windows nachzuinstallieren. Aber das ist lästig, und das würde ich auch nicht auf hunderten produktiver Server bei meinem aktuellen Kunden machen wollen. Geschweige denn: dürfen.
Ich habe jetzt eine Lösung gefunden die zwar kein hundertprozentiger Ersatz für eine anständige Umgebung ist, aber die an einigen Stellen schon echt hilfreich war: PAR::Packer.
Auf meinem Arbeitsplatz habe ich ein ActiveState-Perl installiert, darin das genannte Modul. Jetzt kann ich beispielsweise folgendes eingeben:
pp -e "print time();"
Die Maschine kaut eine Weile auf dem Kommando rum und spuckt dann eine a.exe aus, die ab sofort den aktuellen Unix-Timestamp ausspuckt wenn man sie aufruft. Und das auch auf Systemen auf denen keine Perl-Umgebung installiert ist, man braucht also keine zusätzlichen DLLs oder so, nur die jeweilige EXE.
Leider ist es nicht so, dass pp das Kommando wirklich compiliert. Es ist vielmehr so, dass pp ein Archiv zusammenpackt in dem alles drin steckt was zur Ausführung des Befehls nötig ist. Die Ausgabe des entstehenden Executables ist zwar die gleiche, aber oben genanntes a.exe ist 1.844.011 Bytes groß und braucht auf meiner Kiste über eine Sekunde bevor sie wirklich ausgeführt wird. Klar, muss ja erst entpackt werden.
Die gute Nachricht ist, dass lediglich der Start so lange dauert. Das enthaltene Programm läuft — nach dem Entpacken — praktisch genauso schnell wie in einer ‚richtigen‘ Perl-Umgebung.
Wer es etwas schicker haben will kann übrigens auch direkt folgendes machen:
pp --output=timestamp.exe -e "print time();"
Und komplexe Skripte werden wie folgt gepackt:
pp --output=weltherrschaft.exe weltherrschaft.pl
Die Größe der entstehenden Datei steigt übrigens nicht derartig an dass für jede Zeile wieder 1,8MB dazu kommen. Ich habe hier ein Skript von 5.308 Bytes übersetzt, das EXE ist 2.493.292 Bytes groß. Immer noch eine Menge, aber für einen schnellen Hack ist das durchaus tauglich.