You are hereblogs
Zooming past Haugesund this weekend as Lisa and Anne are visiting.
We went to Avaldnes on Karmøy and took some pictures (well, Lisa did). Haugesund , as seen from Karmøy.
Nice to see family, drop off old books and have over visitors.
I whooshed by Enschede last Friday with Einar. We met up with a former classmate of his, named Silje, who showed us her favourite clothes outlet and her favourite tattoo parlor on our way through the town.
Einar, always the Man Ray among us, captured the compulsory town shots
We also had the experience of fixing Silje's computer (note to self again: Present yourself as a pathologist), then eating a tasty American hamburger at Jimmy's.
This makes my "visit all towns > 100K inhabitants"-project 23% complete.
The latter was a workshop about software transformation systems. The topic this year was how to apply STSes to generative programming, and problems that may occur in this setting.
There was some debate, but mainly about technical details inside a particular transformation system (much confusion about dynamic rules in Stratego was displayed) or old-time favourites such as CSTs vs ASTs.
The only big, new and productive debate, in my opinion, was about a benchmarking framework for STSes, to allow both ourselves and outsiders to evaluate the merits of a given STS for a given task. There was some agreement that unbiased comparisons is necessary, but no concensus could be reached on how to achieve this. A few ideas were tossed up:
- everybody should implement a Java compiler to prove their system can be used for non-trivial projects
- we can arrange some sort of one-day programming contest to demonstrate the expressivity of the system
Needless to say, no conclusion was reached.
In retrospect, there have however been some comments about at least creating a feature matrix to allow quick (but not so in-depth) comparisons between the various systems.
Highly relevant topics such as interoperability between STSes and traceability of domain knowledge through the transformation pipeline were not really touched on, and I had the impression some attendees actually considered them non-topics.
The only tangible result of the workshop was the creation of a mailing list where all participants have been subscribed. I've always assumed one existed some obscure place, and I just haven't come across it. Now this obscure place is at urchin.earth.li;)
In my race to visit all Dutch cities with inhabitant count >= 100K people, I visited the city of Amersfoort (~128K) today. It was only 15 minutes by train from Utrecht.
I also incidentally stumbled across Glenn in front of the trainstation, so we decided to explore the city together (or, it may be that Glenn was on his way to a C64 scene party near Hengelo, and Amersfoort was the easiest place for both of us to meet up).
We visited such world-renown cites in Amersfoort as Onze-Lieve-Vrouwetoren, Sint-Joris church, Muurhuizen, Koppelpoort, the Observant and of course The Flint.
Since I still have no camera, I will upload the pictures that turned out semi-well from my mobile when get the time.
I've written a proposal in concert with Anya and Martin about namespaces in Stratego.
I think we have most things ironed out so that it is both backwards compatible, supports separate compilation and is rather clean, nor does it require extensive changes to the Stratego compiler.
The troublesome spots are dynamic rules and parameterised modules. I am not entirely convinced that we have solved the dynamic rules issue sufficiently, but a few more days and I may be convinced.
Parameterised modules, however, may not make it into the first public proposal. The main issue with parameterised modules is as follows:
- I want every module to be compiled separately, to an .o file
- I want some modules to be higher-order: they should accept another module as a parameter at import time. I.e. imports lib[linux] will import the generic Stratego library instantiated for the linux platform.
- Inside the lib module, I will not care which platform implementation I receive, as long as it follows the correct interface, and is provided to me before final compilation.
- The same module can be instantiated multiple times, each time with a different value for its parameters
- No changes to the runtime should be necessary. Most specifically, I don't want to pass around context state between modules.
- All intermodule references should be resolved at compilation time.
- A module may exist as a .so, as an .o
- The module that imports a parameterised module may eventually be compiled into either a .so or a binary program.
- I want as little code duplication as possible
I have solved most of these issues with some recent ELF hacks, but it only works reliably in the absence of .so files. These are non-issues for the JVM, and will be available directly there when we get the JVM backend running.
A way back I proposed that a refactoring command language may be a good idea. Unfortunately, I'm not so far ahead yet that it is possible to use my prototype for anything, but one of the ideas would of course be doing interactive scripting of source code manipulation, especially, well, duh, for refactoring.
I noticed that the Harmonia people over at Berkeley have been thinking about the idea of disposable scripting for doing refactoring and software transformations as well. In their STSW'04 extended abstract, they discuss the idea of scriptable, interactive refactorings that can be replayed, and allude to an Eclipse plugin they are working on.
Good to see that somebody is already actually working on these crazy ideas I get when I can't sleep;)
Wednesday afternoon, we went off to 's-Hertogenbosch, which is a thoroughly enjoyable little town, walked the streets and ate the local cuisine.
Thursday, NS didn't want our money and even went so far as to hold a nationwide strike for us to drive the point home, so we trawled Oudegracht and tasted some Utrecht cuisine.
Friday, it was off to the Tivoli, errr, I mean Amsterdam, a town best described as a Circus Trip on bad acid. It was certainly an unforgettable experience, however.
One's supposed to learn something new every day, and the lesson of that day was to look out for the inconspicuous word "Acther". It turns out the trainset from Utrecht to Rotterdam - the first leg of our journey - was a multiset. The front part was destined for Den Haag and the aft part for Rotterdam. So we got to swish through Delft as well that morning on the way back to Rotterdam, giving us an extra hour to wake up.
Among other generous gestures from by Belgian friends, we were treated to the best fish I've had in quite some time. Sadly, we forgot to do the compulsory keysigning.
photos by Tilde.
As you all know, the place is pretty liberal.
But as even the camera shows, the world doesn't look quite as straight afterwards...
Peeing, however, is heavily regulated.
photos by Einar
Pulling a fast one always comes around to bite you on the end. This time, it was the ppp-over-ssh hack I borrowed from Vidar that failed on me, resulting in a down period of almost a week until I got it sorted out somewhat.
The sorting out, however, was quite enlightening. I got to learn about IPV6, and IPV6-in-IPV4 tunneling. I added a *.ipv6.boblycat.org wildcard DNS entry and an IPV6 address to storm (through freenet6).
We still have no fixed IPV4 address for storm, so I've had to fortify the ppp-over-ssh script a bit, in the hopes that it will function satisfactorily for at least a few more weeks, thus buying us a bit more time to decide on a permanent solution.
Okay, forgive my short blurby rave. In fact, just disregard it.
This afternoon I handed in the final assignment for this course, which means I have completed all the compulsory education for my PhD. The only thing that remains is hacking code, writing papers, and doing presentations. Wee!;)