Michael Weber: Random Bits and Pieces

We recently released a new tool (LTSmin) which caused me to spend two days in autohell, the Hell (with capital "H") induced by autotools.

Raaah!!1¡! Why does this still SUCK SO MUCH?

If only Unices would have shipped with an interpreter for a sensible language instead of shell scripts, then I would not have to write macros for basic language constructs (why hasn't anybody else?!):

#   AX_LET([VAR1],[EXPR1],
#          [VAR2],[EXPR2],...
#     [...])
m4_define([AX_LET_AUX], [dnl
m4_if([$#], 2, [$1
$2], [dnl
$2="[$]ax_let_$2_[]AX_LET_counter_[]_tmp_"], m4_shiftn(3,$@))

[m4_define([AX_LET_counter_], m4_incr(AX_LET_counter_))dnl

That is all. Also, another proof that you can write Lisp in any language.

UPDATE 2008-11-07: Post Scriptum

…and don't get me started on the umpteen ways to make gcc compile with pthreads on different platforms, or what will happen when you want to combine pthreads with MPI on AIX (think cc_r vs. mpicc). Thankfully, it is unlikely that we have to support AIX anytime soon.

…or that developers appear to assume you can mix options and file arguments in the rm command. Which MacOS X's rm does not support.

LTSmin 1.0 has been released, a tool set for the minimization of large labelled transition systems (LTS) on compute clusters.

Precursors of LTSmin have been used in various case studies, see also:

Stefan Blom, Jens R. Calame, Bert Lisser, Simona Orzan, Jun Pang, Jaco van de Pol, Muhammad Torabi Dashti, Anton Wijs: Distributed Analysis with muCRL: A Compendium of Case Studies. TACAS 2007: 683–689

The main tool in this release is ltsmin-mpi, a distributed implementation of signature-based bisimulation reduction for strong bisimulation and branching bisimulation.

The source code, detailed installation instructions and manuals are available online:


LTSmin is currently being developed by the Formal Methods and Tools group at the University of Twente, The Netherlands.

Work With Me!

2008-10-20 :: /science

We offer a 4-year PhD position on Multi-Core Model Checking. This is a great opportunity to cut your teeth on multi-core software, in two ways:

  • You get to do research on cutting-edge multi-core algorithms. Find new (parallel) ways to solve problems as efficient as possible on today's and near-future hardware.
  • Find new ways how to prove multi-core algorithms correct (and apply them on in practice).

Either way, we have a stack of nice hardware ready, waiting to be exercized.

Deadline is November 1st, 2008! So, get your CV into shape and apply!

UPDATE 2008-10-20: Linked!

A big Thank You to the multicoreinfo team for picking up the story so quickly!

I collected some notes on collaborating in a small team using Git. These are mainly for the benefit of myself and my colleagues, but I would like to hear how others are using Git in similar situations.

Lisp Logo (by Conrad Barsky) Hans wrote:
I am becoming increasingly frustrated by Common Lisp's age. On the one hand, history makes it what it is: Mature, well-documented, thoroughly understood and practical. On the other, it fails to keep up with current system designs, lacking convenient native support for rich data structures, infrastructure access and parallel programming.

That reminded me of a paper by Richard C. Waters: The Survival of Lisp: Either We Share, Or It Dies (local copy), written in 1994. Here are some excerpts:

Unfortunately, the computer world around Lisp is changing so rapidly that considerable effort is required just to maintain links to the outside things that are essential, let alone all the things that are valuable.
If a programming language is little used in a given area, then there will be little reusable software written in that language, and little motivation for new programmers to start using the language in that area, which means that the reusable software in the language that does exist is unlikely to be properly maintained, which leads to even less interest in the language, etc. In contrast, if there is a critical mass of reusable software written in a given language in a particular area, then lots of programmers will be attracted to using this language in the area, which leads to an increase in the amount of reusable software, which attracts even more users, etc.

... which reminds me that I should probably dust off some code and bring it into a releasable state.

Page 8/29: « 4 5 6 7 8 9 10 11 12 »