Sunday, November 22, 2009

Rückreisebericht?

Shit happens, und zwar gern kumulativ.

Die Rückreise von Orlando nach Potsdam verlief so vollkommen ohne Komplikationen, dass es schier unglaublich war und, wäre nicht die Vorgeschichte, kaum einer Erwähnung wert wäre.

Am Ende bleibt nur noch zu sagen, dass US Airways anstandslos sämtliche Auslagen für Kleidung ersetzt hat—und das sogar mittels eines in Euro ausgestellten Schecks, so dass mir die Einreichungsgebühren erspart bleiben.

Na dann.

Monday, October 26, 2009

Reisebericht

Konferenzzeit ist Reisezeit ...

Die diesjährige OOPSLA findet in Orlando, Florida statt. Zum Wetter dort beglückwünsche ich mich nicht: zum Einen ist es dort(bzw. hier, denn dies wird geschrieben im Wartestand am Flughafen in Philadelphia bzw. am Morgen danach im Hotel)zulande Usus, Innenräume per Klimaanlage auf gefühlte minus drei Grad Celsius hinunterzutemperieren; zum Anderen steht laut Wettervorhersage eine Woche voll Gewittern und Regen bei nichtsdestotrotz dreißig Grad Celsius zu erwarten.

Dennoch: die Konferenz selbst verspricht interessant zu werden. Das Wetter und der Veranstaltungsort – das Disney Contemporary Resort Hotel, für einen, der unter etlichen Disney-Elaboraten eigentlich nur die beiden Fantasia-Epen begrüßt, fürwahr ein Ort der Schmerzen – können angesichts der zu erwartenden Begegnungen und Ereignisse gern in den Hintergrund treten.

Die Reise indes gestaltet sich, politisch korrekt und wertneutral ausgedrückt, interessant.

Berlin, Frankfurt, Philadelphia, Orlando – so die Stationen der Reise. In Berlin – Tegel ist nach wie vor einer der effizientesten mir je untergekommenen Flughäfen ob der überraschend geringen Anzahl an Laufmetern, die der Passagier dort für gewöhnlich zurückzulegen hat, ganz im Gegensatz zu Frankfurt – wurde mir sogleich die Ehre zuteil, auf einen früheren Flug nach Frankfurt umgebucht zu werden, denn es sei wegen des Wetters in Frankfurt alles verspätet.

Tatsächlich begann der erste von drei Flügen mit satten zwei Stunden Verspätung. Der Pilot klärte die Mitreisenden darüber auf, dass in Frankfurt mangels Sicht – wegen Nebels nur hundert Meter – die übliche Frequenz von sechzig Flugzeugen pro Minute um ein Drittel auf vierzig reduziert worden sei. Von den Wetterbedingungen konnte man sich dann beim Landeanflug beeindruckend selbst überzeugen: kaum war man aus den Wolken, berührten die Reifen – bei Max Frisch heißen die immer "Pneus" – schon die Landebahn. Salopp ausgedrückt landeten wir in ganz dicker Suppe.

Immerhin war der Anschlussflug nach Philadelphia auch verspätet, so dass der Reise in die US of A nichts im Wege stand. US Airways hatte vor- und fürsorglich etliche Passagiere auf spätere Anschlussflüge umgebucht. In meinem Fall bedeutete das gut und gerne fünf Stunden Aufenthalt auf dem Flughafen Philadelphia. Man riet mir, noch zu versuchen, den eigentlich vorgesehenen Anschlussflug zu erreichen. Nun hieß es also "Geschwindigkeit", denn bis zu dessen Start waren nur noch knapp fünfundvierzig Minuten Zeit.

Davor hat der Herr die Einwanderungsbehörde gesetzt. Erstaunlicherweise ging es dieses Mal nicht nur schnell, sondern ich wurde auch noch von einem gut gelaunten "Immigration Officer", sobald der meines Reisepasses ansichtig wurde, überaus freundlich auf Deutsch begrüßt. Er meinte, er sei schon hin und wieder in Deutschland gewesen, und seine dortigen Kollegen hätten alle so gut Englisch gesprochen, dass er das für eine Selbstverständlichkeit halte.

Derartig eingestimmt und willkommen geheißen – wann passiert das schon einmal? – verlief der Weg zum Gepäckband ganz beschwingt. Nur war mein Gepäck nicht da. Das lange Warten auf die letzten Koffer – die Hoffnung starb zuletzt – verhieß nichts Gutes für den Anschlussflug, und in der Tat war der dann auch nicht mehr zu schaffen.

Fünf Stunden herumsitzen in Philadelphia? Nein danke – und gottlob war ein sehr freundlicher und hilfsbereiter Mitarbeiter von US Airways in der Lage, mich auf einen früheren Flug nach Orlando umzubuchen. Der verlief dann auch problemlos und bot ein erschreckend schönes Naturschauspiel: eine nord-südlich parallel zur Route verlaufende Gewitterfront-Wolkenmasse am dunklen Himmel, darin es gespenstisch wetterleuchtete.

Endlich in Orlando angekommen, durfte natürlich der Weg zum Gepäckschalter nicht fehlen, denn ... "file a claim" heißt das hier schön bürokratisch. Nun ist der Claim also gefilet, und die nette Dame von der Gepäckabfertigung machte mir wenig Hoffnung darauf, dass mein Koffer binnen eines Tages ankommen könnte. Ich wünsche mir, dass sie bei all ihrer Expertise falsch liegt.

Hotel: in Ordnung. Draußen rauschen die Klimaanlagen. Zimmer mit Seeblick: "Black Lake". Schlaf: tief, erholsam, ausreichend trotz Jetlag. Am Morgen die Feststellung: es wird schnell hell hier, so weit südlich.

Jedenfalls trage ich nun die Sachen, die ich schon während der Reise getragen hatte, für noch einen Tag, und es ist schon ein wenig unangenehm. Sollte der Koffer bis heute Abend neun Uhr nicht da sein, darf ich mir für maximal hundertfünfzig Dollar Kleidung besorgen. Na denn. Daumen drücken.

Was von der Reise bleibt, sind – bei allem Stress – einige dankenswerte Begegnungen mit hilfsbereiten und freundlichen Menschen. Und das Hoffen auf eine Gepäcklieferung.

Nachträge am Abend. Das Wetter ist besser als vorhergesagt: keine Gewitter; schwül ist es dennoch. Der Koffer ist inzwischen in Philadelphia gesichtet worden und wird somit voraussichtlich morgen auch mich erreichen, aber ein Einkauf verschiedener Kleidungsstücke musste trotzdem sein. Der erste Konferenztag war klasse. Summa summarum geht es also recht deutlich aufwärts.

Tuesday, October 13, 2009

Nur mal so gefragt, nach den Wahlen ...

2 Fragen an die FDP:
  1. Was ist eigentlich ein "Leistungsträger"?
  2. Warum sollte ausgerechnet die FDP die Definitionshoheit dafür haben?
2 Fragen an die Union:
  1. Was ist eigentlich ein "christliches Menschenbild"?
  2. Warum sollte ausgerechnet die Union die Definitionshoheit dafür haben?
2 Fragen an Union und FDP:
  1. Was heißt eigentlich "bürgerlich"?
  2. Warum sollten ausgerechnet Union und FDP die Definitionshoheit dafür haben?
2 Fragen an die SPD:
  1. Was ist eigentlich "sozialdemokratische Politik"?
  2. Wenn die SPD schon die Definitionshoheit dafür hat, warum definiert sie den Begriff nicht mal?
Nur mal so gefragt, nach den Wahlen ...

Thursday, July 02, 2009

Two Exciting Projects Go Live

Yesterday, two exciting Squeak projects have been made available to the public—one of them has been mentioned here and there and now and then already. But enough of allusions and vague announcements!

NXTalk is there, finally. It brings Smalltalk programming to the Lego Mindstorms NXT. The NXTalk system consists of a full-fledged Smalltalk VM that runs on the NXT brick, an image, and a programming environment that is essentially just a bunch of classes in a Squeak image. The Squeak development tools can be used to program in NXTalk, and the resulting applications can even be simulated to a certain degree in the Squeak image.

The NXTalk VM is embedded in the NXOS operating system for the NXT. NXTalk has a deployment model for applications, which can be deployed as units onto an already existing NXTalk image. Entire images can be uploaded to an NXT as well. All of this is done via USB.

NXTalk was developed by Martin Beck as part of his Master thesis research, which I was happy to supervise with Prof. Robert Hirschfeld of the Software Architecture Group at HPI. The VM is open source (MIT license), and so are the NXTalk classes. At this time, the NXTalk web page is rudimentary; more documentation will appear there.

The second project is PhidgetLab, which makes Phidgets—USB-connected sensors and actuators—available in Squeak. There is a low-level API (in the form of a Squeak VM plugin) that connects the Phidgets library to Squeak and makes the functionality available in the Squeak image by means of a collection of dedicated classes.

Moreover, Phidgets have been added an Etoys representation, allowing for easily building tile scripting applications employing interaction with real-world objects.

PhidgetLab was built by a group of five students—namely Lysann Kessler, Stephanie Platz,
Thomas Klingbeil, Philipp Tessenow, and Frank Schlegel—in fulfilment of a coursework assignment in the Software Engineering 1 course I am teaching this current semester.

The PhidgetLab source code is also available under the terms and conditions of the MIT license.

Comments, suggestions, and contributions to these projects are most welcome!

Sunday, February 22, 2009

Minimal Abstraction

Ask yourself: don't you often have the feeling that your brand-new 1024-core desktop SUV with 4 TB RAM and hard disk space beyond perception takes aeons to boot or to start up some application? (If the answer is no, come back after the next one or two OS updates or so.)

I don't want to rant about any particular operating system or application—the choice is far too big. Still, honestly, one thing I am often wondering about (and I guess I'm not all alone) is why modern software is so huge and yet feels so slow even on supposedly fast hardware.

All those endless gigabytes of software (static in terms of disk space consumption and dynamic in terms of memory consumption) and all those CPU cycles must be there for a purpose, right? And what is that purpose, if not to make me a, well, productive and hence happy user of the respective software? There must be something wrong with complexity under the hood.

During that conversation about Niklaus Wirth with my friend Michael Engel in Dortmund which got me started about computer science's tendency to regard its own history too little, and during which I had also mentioned my above suspicion, Michael pointed me to an article by Wirth, titled A Brief History of Software Engineering, which appeared in the IEEE Annals of the History of Computing in its 2008 July–September issue. This article contains a reference to another of Wirth's articles titled A Plea for Lean Software, which was published in IEEE Computer in February 1995.

The older article phrases just the problem I pointed out above, in better words than I could possibly use, and it did so more than a decade ago. So it's an old problem.

Here's a quotation of two "laws" that Wirth observes to be at work: "Software expands to fill the available memory. ... [It] is getting slower more rapidly than hardware becomes faster. ..." According to Wirth, their effect is that while software grows ever more complex (and thus slow), this is accepted because of advances in hardware technology, which avoid the performance problems' surfacing too much. The primary reason for software growing "fat" is, according to Wirth, that software is not so much systematically maintained but rather uncritically extended with features; i.e., new "stuff" is added all the time, regardless of whether the addition actually contributes to the original idea and purpose of the system in question. (Wirth mentions user interfaces as an example of this problem. His critique can easily be paraphrased thus: Who really needs transparent window borders?)

Another reason for the complexity problem that Wirth identifies is that "[t]o some, complexity equals power". This one is for those software engineers, I guess, that "misinterpret complexity as sophistication" (and I might well have one or two things in stock to be ashamed about). He also mentions time pressure, and that is certainly an issue in corporate ecosystems where management does not have any idea about how software is (or should be) built, and where software developers don't have any idea about user perspective.

I must say that I wholeheartedly agree with Wirth's critique.

Digression. Wirth offers a solution, and it's called Oberon. It's an out-of-the box system implemented in a programming language of the same name, running on the bare metal, with extremely succinct source code, yet offering the full power of an operating system with integrated development tools. One of the features of the Oberon language, and also one that Wirth repeatedly characterises as crucial, is that it is statically and strongly typed.

Being fond of dynamic programming languages, I have to object to some the ideas that he has about object-oriented programming languages and typing.
  • "Abstraction can work only with languages that postulate strict, static typing of every variable and function."
  • "To be worthy of the description, an object-oriented language must embody strict, static typing that cannot be breached, whereby programmers can rely on the compiler to identify inconsistencies."
Well, no.

My understanding of abstraction (and not only in programming languages) is that it is supposed to hide away complexity by providing some kind of interface. To make this work, it is not necessary that the interface be statically known, as several languages adopting the idea of dynamic typing show. Strict and static typing in this radical sense also pretty much excludes polymorphism, which has proven to be a powerful abstraction mechanism. (Indeed, Wirth describes what is called "type extension" in Oberon, which is called "inheritance" elsewhere.) It is correct that static strict typing allows for compilers to detect (potential) errors earlier, but abstraction works well and nicely with languages that don't require this.

It is puzzling to read that an OOP language must be statically and strictly typed to be rightfully called an OOP language. Ah, no, please, come on! Even as early as 1995, there were programming languages around that one would have greatest difficulties to classify as not being OOP languages in spite of their being dynamically typed. Moreover, it is an inherent property of living systems (which the object-oriented paradigm has always strived to capture) that objects in them assume and abandon roles during their lifetimes—something which to capture statically is hard.

Finally, it is interesting to note that the successor of the Oberon system, A2, features a window manager that supports "possibly semi transparent windows". Do you see the irony in this? End of digression.

As stated above, I really share Wirth's opinion that there is too much complexity in software, and I believe this is still true today. What can be done about it? Regarding operating systems, we depend on diverse device drivers even more than a decade ago, so we need a certain degree of abstraction to allow operating systems to talk to different hardware. Regarding convenience and user experience, the occasional bit of eye candy makes working with systems undoubtedly more comfortable. We should still ask ourselves whether it's really, really necessary though, and perhaps concentrate on the really important things, e.g., responsiveness.

So what to do? I don't really have a definitive answer, but I believe that the idea of minimal abstraction is worth a look. The "minimal" in the term does not necessarily mean that systems are small. It means that the tendency to stack layers upon layers of software on top of each other is avoided.

Minimal abstraction is the principle at work in frameworks such as COLA (a tutorial is available here) or in the work on delegation-based implementations of MDSOC languages I kicked off with Hans Schippers. I also believe that the elegance and (in a manner of speaking) baffling simplicity of metacircular programming language implementations (more recently, such as Maxine) are definitely worth a look.

I am sure it is possible to avoid complexity as we have to observe it today, and to make software more simple, better understandable and maintainable, and I believe the above is a step in that direction.

Friday, February 20, 2009

Computer Science and "Geschichtsvergessenheit"

Yesterday, a friend working at a German university told me over ICQ that for most of his students the name Niklaus Wirth didn't ring a bell. I was mildly shocked, and we ranted (ironically) a bit about today's students' being undereducated and ignorant and all. Eventually, we came up with a quickly and superficially assembled list of some more persons that we think one should know if they're into computer science: Alan M. Turing, Grace Hopper, Ada Lovelace, Edsger W. Dijkstra, David L. Parnas, and Konrad Zuse. Some of these might have been chosen based on personal preference, but most of them undoubtedly have made significant contributions to computer science.

Let's face it: the practical outcomes of academic computer science tend to reoccur in cycles. Distributed systems of yore are somehow residing in the SOA/grid/cloud triangle these days, and concepts that have long been known are re-introduced and hyped with all the marketing power of globalised corporations. While this is typical for industry, it's unsettling that academia jumps on the bandwagon almost uncritically, generating massive amounts of publications at high speed that don't actually tell anything new. The seminal papers that have been published, in some cases, decades ago are mostly not even referenced in these.

I believe this is not a deliberate choice of the authors of said papers. Any academic worth their share will strive to give relevant related and previous work due credit. So what is it that brings this about? Why is computer science so geschichtsvergessen (unaware, if not ignorant, of (its own) history)?

Is it because many, too many, universities focus on teaching students the currently hyped programming language? Is it because education at academic institutions too often and too strongly concentrates on creating industry-compatible computer scientists operators? Is it because computer science education is not designed to be sustainable?

The above questions can, more or less obviously, be answered with yes—and that is sad. Not because students don't know the names of people that helped shape computer science in its early days; that, one could do with. It is much more problematic that ignorance (be it deliberate or not) of previously achieved important, crucial results leads to too much work being done over and over again. It's reinventing the wheel on a large scale.

Most academic disciplines I know of introduce their students to the historical background and development of their subject early in the curriculum. Students of economic science learn about mercantilism, Smith, Keynes, and Friedman early on; and prospective jurists are soon faced with the Roman legal system and its numerous influences on contemporary legal systems. Why does a computer science curriculum start, ironically exaggerated, with a darned Java programming course?

It's the teachers' job to change this. Still, they often themselves don't know their ancestors (and I am not an exception myself). Information is available. Two pointers that spring to mind are these:
  • Friedrich L. Bauer's small volume "Kurze Geschichte der Informatik" (sorry, I don't know if it's available in English) connects computer science to its roots in mathematics and philosophy and depicts its historic development until the early 1980s (sadly, it stops there).
  • The volume "Software Pioneers" edited by Manfred Broy and Ernst Denert collects reprints of seminal papers by various computer science pioneers. It comes with 4 DVDs (!) containing videos of talks of most of these persons, who were gathered at a Software Pioneers Conference in Bonn (Germany) in 2001.
Please, let's not forget where we come from, aye?

Wednesday, February 04, 2009

Der Vatikan etc. ... Nachtrag

Nun reagiert Rom, endlich, und mit der nötigen Konsequenz.

Die Mitteilung des vatikanischen Staatssekretariats stellt einige Dinge klar:
  • wofür die vier "Bischöfe" damals eigentlich exkommuniziert wurden,
  • warum die Exkommunikation nun aufgehoben wurde,
  • dass die Vier nach wie vor nicht voll rehabilitiert sind,
  • dass die Pius-Bruderschaft nicht als kirchliche Organisation anerkannt wird, und
  • dass, soll diese Anerkennung erwirkt werden, die Piusbrüder ihrerseits das Zweite Vatikanische Konzil anerkennen müssen.
So. Na also. Geht doch.

Diese Inhalte sollten sich nicht nur die Piusbrüder, sondern auch andere hinter die Ohren schreiben, die sich in den vergangenen Tagen oft etwas zu weit aus dem Fenster gelehnt haben.

Der Holocaust-Leugner Williamson wird dann noch sehr deutlich aufgefordert, sich, will er als Bischof anerkannt werden, von seinen beschämenden und lügnerischen Behauptungen klar zu distanzieren.

Aber. In der Mitteilung heißt es: "Der Heilige Vater kannte zum Zeitpunkt des Nachlasses der Exkommunikation die[] Positionen [Williamsons zum Holocaust] nicht." (Änderungen im Zitat von mir, zum besseren Verständnis.) Das kann ich nach wie vor nicht glauben, sind doch die Pius-Bruderschaft und auch Williamson selbst in der Vergangenheit schon antisemitisch, sogar Holocaust-leugnerisch in Erscheinung getreten.

Will man nicht zugeben, das gewusst zu haben, oder hat man es nicht gewusst? So oder so wirft es kein gutes Licht auf die Art und Weise, wie der Vatikan in dieser Sache kommuniziert (hat). Ein bitterer Nachgeschmack bleibt.

Der Vatikan, Kommunikation, Timing und die Öffentlichkeit

Viel ist derzeit die Rede von der Unbotmäßigkeit des Vorgangs der Aufhebung der Exkommunikation vierer "Bischöfe" der ultrakonservativen Pius-Bruderschaft durch Benedikt XVI. in Rom. Die öffentliche Meinung entzündet sich dabei hauptsächlich daran, dass einer der Vier sich nicht entblödete, im schwedischen Fernsehen einigen ausgemachten Schwachsinn von sich zu geben, sich damit ganz klar selbst ins Abseits stellte, und dennoch "rehabilitiert" wurde.

Leider ist die Sache wieder mal komplizierter als sie dargestellt wird, und vieles wird, vielleicht bewusst, vereinfacht, um ein paar Schlagzeilen haben zu können. Der französische Erzbischof Hippolyte Simon hat diese Dinge ganz schön zusammengefasst.

Halten wir doch mal fest: die Aufhebung der Exkommunikation ist ein kleiner Schritt in einem größeren Prozess, in dem Rom, vertreten durch den Papst, eine Art Integrationspolitik betreibt, um den ultrakonservativen Rand wieder stärker einzubinden. Das ist wirklich zunächst einmal ein rein kirchenpolitischer und kirchenrechtlicher Vorgang.

Halten wir ferner fest: die Vier sind mitnichten "rehabilitiert". Ihre "Bischofs"-Weihen sind nach wie vor ungültig. Die Aufhebung der Exkommunikation stellt lediglich die Aufhebung eines erfolgten Ausschlusses dar. (Analogien zum Vereinsrecht drängen sich auf, leiden aber daran, dass sie, wie viele Vergleiche, etwas hinken.)

Es ist auch wichtig, darauf hinzuweisen, dass der Vatikan sich sehr schnell nach Bekanntwerden der dummen Äußerungen des Holocaust-Leugners Williamson von selbigen distanziert hat. Es muss auch gesagt werden, dass nach Kirchenrecht die Leugnung des Holocausts keinen Grund für eine Exkommunikation darstellt, weswegen der oben erwähnte Prozess der kirchenpolitischen Annäherung von dem Schwachsinn, den der Piusbruder da von sich gegeben hat, aus kirchenrechtlicher Sicht nicht berührt wird.

Das mag man schlecht finden. Kirchenrecht ist eben, nun ja, Kirchenrecht und damit gewissermaßen seinsbedingt ein wenig weltfremd. Es sei aber auch daran erinnert, dass es Nationalstaaten gibt, in denen die Leugnung des Holocaust nicht unter Strafe steht. (Und deren diplomatische Beziehungen zu Israel gar nicht zur Disposition stehen.)

Rein kirchenrechtlich ist gegen das Vorgehen des Vatikans nichts einzuwenden. In seiner Wirkung auf die Öffentlichkeit ist es dennoch katastrophal, und so etwas passiert in diesem Pontifikat leider nicht zum ersten Mal. Was dahinter steckt, weiß ich nicht: Ungeschick oder Unsensibilität, oder gar kalkulierte Provokation? An der Kommunikationsfähigkeit des Vatikans darf jedenfalls gezweifelt werden.

Die Möglichkeit eines schlechten Timings drängt sich auf. Dass Williamson seinen Mist genau am Vorabend der offiziellen Verlautbarung, seine Exkommunikation werde aufgehoben, kund tut, deutet in diese Richtung.

Der Vatikan muss sich in diesem Zusammenhang aber auch fragen lassen, ob ihm unbekannt war, dass die Piusbrüder, und nicht nur Williamson, bereits seit einiger Zeit durch antisemitische Äußerungen auffallen. Glauben kann ich das nicht. (Hipployte Simons oben erwähnte Erklärung lässt diesen Aspekt auch außer Acht.) Da wäre vielleicht eine bessere Vorbereitung diverser Aktionen sinnvoll gewesen. Das jetzt vorliegende Kommunikationsdesaster ist kaum mehr zu reparieren. Die Grenzen der Sachlichkeit sind längst überschritten, und, seien wir ehrlich, auf den Vatikan einzuprügeln ist doch so schön einfach und schlagzeilenträchtig.

Die katholische Kirche ist nicht homogen, und in ihr, beziehungsweise an ihren Rändern, gibt es halt auch ultrakonservative Spinner, denen die Errungenschaften des Zweiten Vatikanischen Konzils nicht mehr als Häresien sind. Die Piusbrüder sind in der Hinsicht kein Kind von Traurigkeit, und Attribute wie "Rückwärtsgewandtheit" sind angemessen. Verteidigungsversuche, die diese Haltung als "Traditionsbewusstsein" einzuordnen suchen, sind wirklich schwach und durchsichtig.

Und der Papst? Der hat sich zur Aufgabe gemacht, diesen Haufen in die Kirche zu re-integrieren. Mal sehen, wie gut das angesichts der Marodeure in ihren Reihen gelingen kann. In seiner Haut möchte ich nicht stecken.

Monday, February 02, 2009

Convenience for Maxine in Eclipse

Isn't it a bit sad that we've got this marvellous IDE, and yet we have to switch to the command line every now and then to kick off a Maxine build, or run a Java application in Maxine, or look at its and the VM's innards in the Inspector? Yes, it is. So I decided to exploit the capabilities of Eclipse and set up some neat one-click experience facilities to make life easier.

Building Maxine and the Image

The first task I want to make easier is building Maxine. Of course, the command lines one has to use are as simple as this:

~/workspace/maxine~maxine$ bin/max build
~/workspace/maxine~maxine$ bin/max image

But still, switching to the command line is the kind of media break at least I don't like too much. I want to have one task for each of the lines above, because sometimes one wants to build the VM sources without building the image at the same time.

The Eclipse feature to use is called external tools. There is a button right next to the run button in Eclipse (it looks like the one to the right) with a menu attached; click on the black triangle to invoke the menu, and then on External Tools Configurations.... In the dialogue that appears, double-click on the Program item; this will start the creation of a new external tool configuration invoking some application external to Eclipse. (We don't care about Ant tasks.)

The settings that should be applied look like in the two images below. It is quite obvious that these settings just provide a convenient wrapper around the max script, with the path to the script and its working directory and environment settings given, and also with the command line argument (build) being passed to the script. It's that simple.


In the Main tab, I have used the workspace_loc Eclipse variable to avoid having to enter the full path to the max script. Being able to give its location relative to the Eclipse workspace is much more convenient and makes the configuration reusable. The same holds for the working directory setting, which is simply the workspace directory.

The settings in the Environment tab are important because they give the max script the environment variables it requires to be run. I set JAVA_HOME to /usr/jdk/latest, and JUNIT4_CP to ${eclipse_home}/plugins/org.junit4_4.3.1/junit.jar, which is the JUnit distribution that comes with Eclipse. Note that I have once more used an Eclipse variable, eclipse_home, which points to the root of the Eclipse installation.

After having entered all the information, clicking the Apply button will save the settings. Clicking Run will save them and run the script immediately, building the Maxine sources as requested. Note how the script's output appears in the Eclipse console window.

With the wrapper for building Maxine in place, it is very straightforward to create another one for building the image. In the external tools dialogue, just right-click on the Build Maxine entry, and select the Duplicate option from the context menu. This will create a clone of the configuration we just created, and make it available for editing. The only settings that have to be changed are the name (obviously) and the command line argument (set it to image). Once that's done, click on Apply to save, or on Run to see how it works.

Running ''Hello World''

Creating a wrapper for running the Hello World application that comes with Maxine is just as simple. Try yourself, and recall that the command line argument to be passed to max is helloworld.

Interlude: Another Java Application

Of course, it is not enough to be able to (albeit conveniently) execute the simple things from within Eclipse. I want to be able to run any given Java application in Maxine, and, what's more, I want to be able to run Java applications in the Inspector. For the rest of this tutorial, we'll need some Java application that does not come with the Maxine distribution, so we can see how Eclipse facilitates integrating tools spanning several workspace projects.

The application we'll use is deliberately simple; actually, it's just another Hello World, but one that resides outside the Maxine workspace directories and projects. Here's the source code:

public class MyHW {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}

This is all we need; just create a Java project MyHW in Eclipse, and a corresponding class containing the code above. I won't go into the details of this here.

Just one note: in Eclipse, Java projects have the default property that their source code and binary directories are separate. I haven't changed this default for the MyHW project, so all details given below are chosen to work with this, and no guarantees for other configurations are given.

Running MyHW on Maxine

In terms of the command line, the max invocation for running MyHW is as follows (note the directory I'm in):

~/workspace/MyHW$ ../maxine~maxine/bin/max vm -cp bin MyHW

In detail, this invokes the max script with the vm parameter indicating that the VM should be run, passing the VM an extension to the class path (the standard option -cp is used for this, and the class path is the bin directory of the MyHW Eclipse project), and the application to be run.

To set up a generic configuration for running Java applications on Maxine from within Eclipse, the class path and application in question need to be passed as variable parameters. The rest is rather simple.

Here's the dedicated behaviour: we want to be able to select a Java file in Eclipse's package explorer, then go to the Run External Tool menu and select a tool called Run Application on Maxine. This should trigger execution of the selected application on Maxine.

Let's start with one of our previously created external tool configurations. For instance, let's duplicate the Build Image configuration and rename it to Run Application on Maxine. The trivial thing is to replace the image parameter with vm.

The working directory should be the project directory of the Java application we're about to execute, so that setting should be ${project_loc}. The project_loc Eclipse variable contains, for any selected resource, the root folder of the project it belongs to.

After the vm parameter, we need to pass the class path and Java application name. The class path is the project location with bin/ appended (Eclipse default). The Java application is the name of the resource without the file name suffix. Here is how the full list of arguments to the max script looks:

vm -cp ${project_loc}/bin ${java_type_name}

The interesting bit about this setting is the java_type_name variable: it will, for a selected Java resource, contain that resource's fully qualified Java type. So, just what we need to pass the VM on the command line.

To summarise, the complete settings for the Run Application on Maxine configuration are given in the image below.

Running MyHW in the Inspector

Guess what, setting up a configuration for the Inspector is trivial now. Really, all you have to do is clone the run configuration we created above, and replace the vm command line argument with inspect. Bingo.

Concluding Remark

You may have noticed that running and inspecting Java applications with Maxine is not quite as convenient as usually seen in Eclipse, namely via the Run as... and Debug as... options in a Java file's context menu. While this would certainly be appreciable, it seems to require setting up Maxine as a full-fledged Java runtime environment, which I haven't (yet) figured out how to achieve. Maybe this will happen some time in the future.

For now, I'm happy with the convenience wrappers for the max script. They also relieve me of keeping track with configuration changes in Maxine command lines and things that need to be passed on the command line to get the Inspector up and running, and so forth: just having everything tucked away in the max script is very convenient. Setting up things directly would imply dealing with the gory details.

Thursday, January 15, 2009

Some Photos Taken Yonder

The Biggesee is located near to my home town Attendorn in the Sauerland region, Germany. It's a beautiful spot except for summer, when there are too many tourists. On that beautiful winter day, there was mostly no one around, though. Behold.

Tuesday, January 06, 2009

Ich bin reich!

Neulich erreichte mich eine Lieferung samt Rechnung; ich hatte per Vorkasse bezahlt. Soweit war also alles in Ordnung, aber irgend jemand hat da beim Programmieren geschlampt oder doch zumindest einige einfache Grundregeln (z. B. Nr. 48) nicht beachtet.

Die schulden mir also aus unerfindlichen Gründen 7,11 Billiarden Euro. Hier ist mein Brief an sie:

Sehr geehrte Damen und Herren,

dieser Tage erreichte mich Ihre Sendung zu meinem Auftrag Nr. 1130 vom
12.11. 2008. Der Sendung lag eine Rechnung bei, die eine ernsthafte
Frage offen lässt. Ich habe die Rechnung als PDF-Datei angehängt.

Der offene Restbetrag ist mit EUR -7,11*10^15 ausgewiesen. Da es sich
hierbei um einen negativen Betrag handelt, stehen Sie bei mir in der
Schuld. Ich hege Zweifel daran, dass Sie 7,11 Billiarden Euro auf
einen Schlag aufbringen können; wir können uns gern auf eine
Ratenzahlung einigen. Diese sollte selbstverständlich auf meine bzw.
Ihre Erben übertragen werden.

Es freut mich sehr, dass Ihnen am Wohl meiner selbst und meiner
Familie auf Generationen hinaus so viel liegt. Ich bin gerne bereit,
Ihnen und Ihren Rechtsnachfolgern Spendenquittungen auszustellen -
auch dies eine Verpflichtung, die ich meinen Erben selbstverständlich
testamentarisch auferlegen werde.

Was die Zahlungsmodalitäten angeht, bin ich flexibel - ich akzeptiere
Überweisungen sowie Schecks.

Mit sehr freundlichen und dankbaren Grüßen,
ein gesegnetes neues Jahr,

Michael Haupt

Mal sehen, was kommt...

Friday, January 02, 2009

COLA: Shared Libraries

Over the Christmas holidays, I wanted to do some programming with COLA. (See my earlier tutorial on this marvellous piece of software.) This included implementing an object library in Pepsi, which was then to be used from a Jolt program. While doing the former was as easy as programming and compiling it as a shared library, the latter would not work right away and required some twiddling. As I think it's a nice thing to be able to use Pepsi shared libraries in Jolt code, I want to share my solution.

This Does Not Work

The first thing is, as mentioned above, to implement and compile the shared library. Here's an example of a very simple hello world library, providing an object that can be sent the sayHello message:

{ import: Object }
Hello : Object ()
Hello sayHello [ 'Hello, world!' putln ]
This can be compiled to a shared library using idc -s hellolib.st. Looking at some Jolt code for Cairo bindings, I found that a shared library can be loaded and initialised like this:
(define mylibhandle (dlopen "hellolib"))
((_dlsym mylibhandle "__id__init__"))
The code above is supposed to open the library and then invoke its __id__init__() function, which is required to get all the objects it contains set up and make them visible to the "object namespace". It does not work, though, because __id__init__(), for shared libraries, requires a parameter, namely a pointer to the _libid variable representing the "object world". Failing to pass this parameter will lead to a crash when the shared library is initialised using the above code.

Patching libid

The _libid variable is normally not exported from libid, so an API extension is required that makes this feasible. Extending libid is very simple in this case, and only requires modifications in three places.

1. The API extension must be declared in id.h, located in the object/id subdirectory of the main COLA directory. This header defines struct __libid, which declares the libid interface. It is divided into several "categories", one of which is called environment, and I thought this would be the place to put a function returning the pointer to _libid. In that category, there is an entry

void *unused31;
which I replaced with the declaration of my new accessor function:
struct __libid *(*libid_p)(void);

2. Said function obviously needs to be implemented. This takes place in libid.c (found next to id.h):

struct __libid *_libid_libid_p(void) {
return &_libid;
}
It simply returns the address of the _libid variable (which is, by the way, declared static struct __libid _libid).

3. The pointer to this function in the _libid structure must be initialised. This is done by adding the following code to the _libid_init() function:

_libid.libid_p = _libid_libid_p;
That's all. Of course, everything needs to be recompiled. I decided to play safe and did a complete rebuild (using make spotless ; make in the COLA directory).

This Also Does Not Work

Some convenience functionality for loading and initialising a shared library from within Jolt can look like this:

(define libid-p ((dlsym "_libid_libid_p")))
(define dloi (lambda (libname)
(let ((libhandle (dlopen libname)))
((_dlsym libhandle "__id__init__") libid-p)
libhandle)))
The dloi function accepts a library name, opens and initialises the library, and returns the library handle.

With this available, the following should work:

(dloi "hellolib")
(define Hello (import "Hello")) ; import the Hello object
[Hello sayHello]
However, it does not. Initialisation of the library fails because it contains some references to the st80 library that the Pepsi compiler, idc, links against by default. Instead, idc must link against the Jolt object library located in the function/objects directory.

Linking Against The Jolt Object Library

Happily, it is very easy to link against the correct object library. The only requirement is to pass (via the -I command line switch) the directory where the objects are stored to idc:

idc -IMY_PATH_TO/function/objects/ -s hellolib.st
The shared library generated from this will be linked against the Jolt library, and with this library, the Jolt code for printing a hello world message finally works.