karltk's neck of the woods

Yesterday, a tornado swept by the north end of the road where the Hawthorne research lab lies. I go by there every day on way to and from work. The tornado shred a warehouse to pieces, smashed a police car (with driver -- he surived unscathed), caused havoc at my favourite gas station and broke hundreds of trees in the nearby forest. It also hammered the hotel I stayed at after my eccentric landlord unceremoniously threw me out a few weeks ago. It even caused a short power outage that resulted in me losing one of my e-mails, so indeed, I was hit pretty hard, too.

The tornado hit just around 16:00 local time, just before the commute started. An hour later, I could very well have been in the middle of it. Getting home turned out to be rather difficult that evening, since most of the roads going north were closed for hours afterwards.

I met up with Lisa yesterday. She stays in NYC with Laura, a friend of her, pending a hearing of her complaint about her UK visa refusal. After some general hanging about in galleries, and even more general watching the old (Dutch) masters, we waded through Central Park and I got to see fireflys for the first time. Fireflys must be one of the coolest inventions in nature ever. It's even more spectacular when you run into a tiny swarm (though they don't appear to be the swarming kind of insects, in general).

A bit later, we went to a piano bar near Times Square where some of the Broadway washouts are reputed to hang out. As one might expect, they were rather excellent (and funny!) singers. Most of the songs were Broadway classics, and most of the singalongs were entirely unknown to me, but smiling and mumling melodically gets you a long way when you don't know the words.

The US is a big place. Canada is even bigger. This fact has not be lost upon its inhabitants, who have a penchant for spreading their homes and cities over large areas. The corrollary being that the distance between their workplaces and their homes is often rather long.

Though long commutes are not uncommon in Europe either, there is a marked difference in the availibility of public transportation, and also the people who use it. Even compared to Norway, the buses here are few and far between, they follow the longest and oddest routes, and it is evident that buses are mostly for the lower social classes. (I'm still not over how visibible the difference in social class is, over here.)

I am happy to report that I am almost completely installed over here. (For those who joined the story late: this summer I'm working for IBM Research at the Watson Research Center in Hawthorne, New York, hacking on compilers.)

My first week was extremely taxing, mostly due to rather unexpected housing problems: my landlord decided to throw me out without prior notice one night after I had voiced concerns over the privacy of my room. Juicy details available on request.

I rushed off to an extremely enjoyable hotel and stayed for a couple of nights, and I'm now staying in an... interesting motel until I get to move into a new apartment on Monday. Apart from that little road bump, the stay has been very good so far.

The final version of the article Stratego: A Programming Language for Program Manipulation is now online on the ACM Crossroads site. It is a very lightweight introduction to program transformation, why we do it, and how it works.

Abstract

Programming languages have a dual role in the construction of software. The language is both our substrate (the stuff we make software from), and our tool (what we use to construct software). Program transformation (PT) deals with the analysis, manipulation and generation of software. Therefore a close relationship exists between program transformation and programming languages, to the point where the PT field has produced many domain-specific languages for manipulating programs. In this article, I will show you some interesting aspects from one of these languages : Stratego.

Just after leaving Waterloo, I co-wrote a paper with Chang Hwan Peter Kim and Krzysztof Czarnecki on the relationship between feature models and ontologies,
titled Feature Models are Views on Ontologies, that has been accepted for SPLC'06.

Abstract

Feature modeling has been proposed as an approach for describing variable requirements for software product lines. In this paper, we explore the relationship between feature models and ontologies. First, we examine how previous extensions to basic feature modeling move it closer to richer formalisms for specifying ontologies such as MOF and OWL. Then, we explore the idea of feature models as views on ontologies. Based on that idea, we propose two approaches for the combined use of feature models and ontologies: view derivation and view integration. Finally, we give some ideas about tool support for these approaches.

bib - pdf

Between the end of June and the end of September this summer, it appears that I will be working at IBM Research's Sensor and Acuator Solutions Department at the TJ Watson Research Center in Hawthorne, New York. At least that's what my contract says.

I'm rather excited, as this is the coolest summer job I've landed so far. Though for the record, my previous summer job was a paper boy temp when I was fourteen...

The project I'll be working on contains the usual goodies: compiler construction, program transformation, language extensions and development environment implementation. Plenty of Eclipse development, is what I've been told.

The downside is that as a non-US citizen, working in the US is rather cumbersome. I had to fill in DS-156, DS-157, DS-158, obtain DS-2019, provide a SEVIS fee recipt ($100), hand in a stamped, self-addressed envelope and show up for a personal interview at the US Embassy, at an additional cost of $100.

These forms contain a few funny entries. For example, DS-157 required me to fill in my "Clan or Tribe Name". Also, I had to list all countries I had visited in the last ten years, together with the years of visit. In a 5x2cm space. Sure...

They also required me to list all professional, social and charitable organisations to which I belong(ed), contribute(d) to or work(ed) for. Not to forget that I had to mention whether I had special training with firearms, explosives, or any nuclear, biological or chemical experience.

Additionally, DS-158 required me, since I'm male, and between 16 and 45, to list all close relatives with contact information, as well as two non-family "character witnesses" who could corroborate my story.

My personal favourite, however, is found in the DS-156:

Do you seek to enter the United States to engage in export control violations, subversive or terrorist activities, or any other unlawful purpose? Are you a member or representative of a terrorist organization as currently designated by the U.S. Secretary of State? Have you ever participated in persecutions directed by the Nazi government of Germany; or have you ever participated in genocide?

Fortunately, I don't parttake in such activity, but I'm left wondering if practicing terrorists and genociders would be barred by their own conscience from answering "no".

However, the absolutely worst part of the entire visa experience was when the embassy security demanded that I turn off my laptop during x-raying. Over 52 days of portable uptime down the drain. Those bastards! However, contrary to previous experience in Newark, the US civil servants in Oslo were both kind and well spoken -- and in Norwegian, no less.

At any rate, all that is over and done with now. I have my visa; they issued it on the same day, and all that's left is to book the plane ticket. I'll do so tomorrow.

Ble oppringt av NRK Dagsnytt i dag. De lurte på om jeg kunne bekrefte denne historien (fra Sydsvenskan). Det kunne jeg ikke, men ba dem forsøke FFII.

Ble oppringt av en journalist i Klassekampen i dag. Han ville ha et slags intervju etter mine utspill om EUs sporingsdirektiv i vinter. Dessverre kommer artikkelen trolig kun i trykk, ellers kunne det være greit å linke til den. Får satse på at biblioteket fører Klassekampen, for jeg abonnerer ikke på papiraviser lengre.

I set out to do some minor code changes and updates today, and ran into my old nemesis: the Stratego/XT build system. What should have been a ten minute job, quickly turned into several hours of hacking to get all the build system details settled.

Granted, the stuff I was working on involved invoking a custom version of the compiler during the build process, which relied on native code in C that needed to be compiled and installed before my compiler could run.

Even in more usual circumstances, I tend to find the Stratego/XT build system very complicated, time consuming to use as a developer, and always very brittle once it's seemingly operating properly.

This is both sad and frustrating, because I'm well aware of how much blood, sweat and tears Martin has sunk into it, to get everything working. Given that Martin is probably one of the most meticulous people I know, I suspect the problem is not the skill of the developer, but rather the quality of the underlying build system technology.

Since Stratego/XT is a compiled language, and relies on gcc to produce the native binaries, the build system is based around GNU Autotools. This should be a safe bet, since the majority of open-source projects written with C/C++ use Autotools. But in this case, popularity doesn't seem to have helped in coming up with a slick and flexible result.

When I compare the Autotools and C/C++ state of things to other alternatives, such as Perl, Python or even Java, the difference is striking. While the latter languages have automatic dependency calculation coupled intelligent interpreters/compilers that know how to deal with dependencies spread across directories, the whole program-like compiler approach used by C/C++ (and even Stratego) is very painful to deal with.

Admittedly, the Autotools have to deal with the fact that C-style languages have a terrible module system to begin with, and that the binding time of most settings is at compile time; for example the default search paths for applications are in practically all cases hardwired into the application when it is compiled. This is also true for Stratego.

Even though the build system appears to be a chronic ailment of Stratego, I think it's outside the scope of the project itself to invent a new build system. Also, I don't immediately see any useful replacements that will help us noticeably.

I'm just a bit pensive about the situation. I suspect that the worst thing may not be the productivity loss of the developers of Stratego, but rather the users of Stratego, who also need to fight with similar issues when they develop and deploy software written with Stratego. A depressing amount of calls for help on our mailing lists and IRC channel are about build system issues.

If some bright and inventive reader has a spare panacea or two that may be applicable in our case, please step forward.