---

Aggressive predictions (03 May 2008)

CoCreate Software, my employer, is merging into Parametric Technology GmbH. This is a major milestone for both CoCreate and PTC. We have good reasons to look forward to what's coming up - but it's also a perfect opportunity to look back at 25 years of CoCreate history.

I joined the company in 1991 when it was still called MDD, a division of Hewlett-Packard at their Böblingen site. Shortly after that, I heard somebody report that some sales guy from a competing company was questioning the viability of our division and our products. Apparently, customers were told something like: "Give them 2 more years, and then they're gone."

This was one of my first lessons how things are done in real bidniz: It's not just about the functionality and quality of your product, but also about how far customers will trust your company. And competitors will not hesitate to attack both on the product and the company credibility front.

Anyway - turns out that the prognosis was just a tad too aggressive. So far, we survived another seventeen years (and not just barely), way more than the two years the Cassandras gave us. And even as a part of PTC, we'll continue to serve our customers with our own product line, so the CoCreate story continues.

Memory of those days in the early 90s is hazy, and maybe I've got it all wrong. But then, I'm pretty sure somebody also mentioned which company that sales guy worked for.

It was PTC

---

This blog considered illegal (13 Apr 2008)

If you are a C++ programmer, my blog should give you the creeps. Sometimes because of what I write here, I guess - but definitely because of its name. You are not alone. The first time someone told me about that "#define private public" line which he had just found in our codebase, I didn't want to believe that someone actually did that.

But it was oh so true.

If I remember correctly, there was a reason for it - certainly not a good one, but a reason: Some experimental test code needed to access a class member which was declared private, and the author of that code wasn't supposed to change the class under test, or did not have access to it.

This disgusting hack was probably meant as a stopgap solution, but then remained in the code for way too much time - until it was re-discovered and became a part of our local programming folklore. I was actually grateful for this hack - without it, I'd probably still be searching for a name for my blog!

And then, just a few days ago, I came across the following excerpt from the standard for the C++ standard library (ISO/IEC 14882:1998(E), section 17.4.3.1.1):

A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords.

Good heavens, my blog is cursed upon by the standard! Expelled will I be from the C++ community! Never will I be on a first-name basis with Mr. Stroustrup! What have I done...

---

So long, and thanks for all the functional fish! (30 Mar 2008)

1982. I'm not even sure if I already had my first computer back then - but that's the year when Peter Henderson published an article about Functional Geometry, in which he describes how to build images from equations, and how to create big images from smaller ones using functional composition.

The original implementation was in UCSD Pascal. A while ago, part-time Lisp hacker Frank Buß ported it to Lisp and added Postscript output, and he also posted a very nice description of his approach, illustrating how this example helped him understand how valuable support for higher-order functions in a language can be.

Frank's code is clear and compact, and the platform dependencies are all in one function, which made it easy to adapt to CoCreate Modeling's dialect of Common Lisp. In fact, all that's needed to run the code is the following loader code:

;; -*-Lisp-*-
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Description:  Wrapper to run Frank Buss' functional geometry code
;;               in CoCreate Modeling
;; Author:       Claus Brod  
;; Language:     Lisp
;;
;; (C) Copyright 2008 Claus Brod, all rights reserved
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;

(in-package :clausbrod.de)
(use-package :oli)
(export '(plot-escher))

;; Allow using lambda without quoting it via #' first
;; (No longer required in CoCreate Modeling 2008 and later.)
(defmacro lambda (&rest body)
  `(function (lambda ,@body)))

(defparameter *our-loadpath* *load-truename*)
(load (format nil "~A/functional.lsp"
              (directory-namestring *our-loadpath*)))

;; Modeling-specific plotter function
(defun plot-annotation (p)
  (let ((tempfile (format nil "~A/test.mac" (oli:sd-inq-temp-dir)))
        (scale 500.0))
    (startup::activate-annotation)

    (with-open-file (s tempfile
                       :direction :output :if-exists :supersede)
      (format s "line~%")

      (dolist (line (funcall p '(0 0) '(1 0) '(0 1)))
        (destructuring-bind ((x0 y0) (x1 y1)) line
          (format s "  ~D,~D ~D,~D~%"
                  (* scale (float x0))
                  (* scale (float y0))
                  (* scale (float x1))
                  (* scale (float y1)))))

      (format s "end"))

    (oli:sd-execute-annotator-command
     :cmd (format nil "input '~A'" tempfile))
    (docu::docu_vp :fit_vp)
    (delete-file tempfile)))

;; Shortcut for the Escher fish drawing
(defun plot-escher()
  (plot-annotation *fishes*))

The loader code adds the definition for the lambda macro which is missing so far in CoCreate Modeling, loads Frank's code, and then adds a plotter function which creates output in a 2D Annotation window.

Usage instructions:

• Download Frank's code from his site and save it as functional.lsp.
• Download the loader code and save it into the same directory.
• Load the loader Lisp code into CoCreate Modeling 2007 or higher.
• In the user input line, enter (clausbrod.de:plot-escher)

Thanks to Frank for this cute demo code!

---

CLR? To me, that's "Common Lisp Runtime"! (12 Mar 2008)

Alright, so I can no longer keep this to myself. I've been fantasizing about it for too long: I want a true Common Lisp implementation running on top of, and integrated with, Microsoft's CLR, and I want it badly.

It took a while, but after all those years at CoCreate (where we write a lot of Lisp code), I fell in love with the language. I want to work on projects which use Common Lisp, and I want the language to be successful and popular in lots of places - if only so that I have a choice of cool jobs should the need ever arise

In other words, I want Common Lisp to become a mainstream language - which it arguably isn't, even though pretty much everybody agrees about its power and potential.

One way to acquire mainstream super-powers is to team up with one of the planet's most potent forces in both software development and marketing: Microsoft. This is the strategic reason for my proposal. Yes, I know, many Lisp gurus and geeks out couldn't care less about Microsoft and the Windows platform, or even shudder at the thought. But there are also tactical and technical reasons, so bear with me for a minute before you turn on your flamethrowers.

When I say Microsoft, I really mean .NET and its Common Language Runtime. Well, that's what they say is how to spell out CLR. But I claim that the L could just as well stand for Lisp, as the CLR, particularly in conjunction with the Dynamic Language Runtime extensions which Microsoft is working on, is a suspiciously suitable platform to build an implementation of Common Lisp upon: Not only does it provide a renowned garbage collector (designed by former Lisp guru Patrick Dussud) and a rich type system, it also has extensive reflection and code generation support, and - through the DLR - fast dynamic function calls, AST processing and compilation, debugger integration, REPL support, and all that jazz. It's no coincidence that languages such as C# and even VB.NET are picking up new dynamic language features with every new release, and that Microsoft has even added a new functional language, F#, to the set of languages which are (or will be) fully integrated into Visual Studio. The wave is coming in, and we better not miss it!

Best of all, it's not just about Windows anymore: The DLR and IronPython also run on top of Mono. Mono is available for Linux, Solaris, Mac OS X, various BSD flavors as well as for Windows, so layering Common Lisp on top of the CLR doesn't limit us to the Windows platform at all!

Note that I explicitly said "Common Lisp". I think that it's vital for an implementation on top of the CLR/DLR to be truly standards-compliant. I am not alone in this belief: In the IronPython and IronRuby projects, Microsoft went to great lengths to make sure that the implementations are true to the original language.

What would this buy us? Well, one recurring and dominant theme in discussions about the viability of Lisp as a mainstream language is the perceived or real lack of actively maintained libraries and tools. With the approach I'm outlining, we could still run all those excellent existing Common Lisp libraries and projects out there, but we'd also be able to use the huge body of code both in the .NET framework itself and in third-party .NET components. Common Lisp code could seamlessly call into a library written in, say, C#, and VB.NET programmers would be able to consume Common Lisp libraries!

Taking it a little further, we could also integrate with Visual Studio. Where I work, it would make all the difference in the world if we could edit, run and debug our Lisp code from within Visual Studio. I'm convinced that this would attract a large new group of programmers to Common Lisp. Hordes of them, in fact

Yes, I know about SLIME and Dandelion and Cusp, and I'm perfectly aware that Emacs will simultaneously iron your shirts, whistle an enchanting tune, convincingly act on your behalf in today's team phone conference, and book flights to the Caribbean while compiling, debugging, refactoring and possibly even writing all your Lisp code for you in the background. Still, there's a whole caste of programmers who never felt any desire to reach beyond the confines of the Visual Studio universe, and are perfectly happy with their IDE, thank you very much. What if we could sell even those programmers on Common Lisp? (And yes, of course you and I could continue to use our beloved Emacs.)

Now, all these ideas certainly aren't original. There are a number of projects out there born out of similar motivation:

• L Sharp .NET - a Lisp-based scripting language for .NET by Rob Blackwell
• Yarr - Lisp-based scripting language for .NET based on L Sharp
• dotLisp - a Lisp dialect for .NET, written by Rich Hickey (of Clojure fame)
• Rich Hickey mentioned in a presentation that the original versions of Clojure were actually written to produce code for the CLR
• IronLisp - Lisp on top of the DLR, initiated by Llewellyn Pritchard, who later decided to tackle IronScheme instead
• There's a even a toy Common Lisp implementation by Microsoft which they shipped as a sample in the .NET Framework SDK (and now as part of the Rotor sources)
• Joe Marshall has an interesting project which looks like Lisp implemented in C#.
• LispSharp is a CLR-based Lisp compiler (Mirko Benuzzi)
• ClearLisp is another CL dialect written in C# by Jan Tolenaar.
• A LISP/Scheme language for .NET (Adam Milazzo)
• CLearSharp, by Ola Bini
• Joe Duffy's Sencha project
• VistaSmalltalk may not sound like Lisp, but it actually contains a Lisp engine (implemented in C#), and according to the architecture notes I found, Smalltalk is implemented on top of Lisp.
• CLinNET, by Dan Muller
• CarbonLisp, by Eric Rochester
• MBase, a "metaprogramming framework" providing a Lisp-like definition language
• Sohail Somani experiments with .NET IL generation from Lispy syntax
• RDNZL - .NET interop layer for Common Lisp (Edi Weitz)
• FOIL - Foreign object interface for Lisp (i.e. an interop layer) on top of both the JVM and the CLR, by Rich Hickey (again!) and Eric Thorsen

Unfortunately, some of those projects are no longer actively maintained, others implement just a small subset of Common Lisp or even made design decisions which may conflict with the standard, or they are "merely" interop layers which allow Common Lisp code to call code written in managed languages, but don't provide full CLR integration. Don't get me wrong: Most of those projects produced impressive results - I don't mean to bash any of them, quite to the contrary.

What we learn from this project list is that there are quite a number of brilliant Lisp hackers out there who are both interested in such a project and capable of working on it. Most encouraging!

So maybe it isn't just me. Or am I really the only remaining Lisp programmer with such weird cravings? Be brutally honest with me: Am I a freak?

PS: I did not explicitly look for them while researching this article, but I know there are also a number of similar endeavours in the Scheme world, such as Common Larceny, Bigloo.NET, Dot-Scheme and Tachy.

PS/2: A few days after posting this article, I found that Toby Jones already coined the term "Common Lisp Runtime" three years ago...

---

In the presence of genius (06 Mar 2008)

The company I work for, CoCreate Software, was recently acquired by PTC. As we are going through the integration process, I noticed with awe that as a result of the acquisition, apparently I now work for the same company as Kent Pitman! Wow.

For those of you with a Lisp background, that name should ring a couple of bells. Kent was the project editor for the ANSI Common Lisp standard and creator of the Common Lisp HyperSpec. He also made numerous other contributions to the Lisp community. For example, he headed the committee which designed Lisp's condition system.

Lisp is still big at CoCreate, and we have a number of Lisp programmers ourselves. While Lisp's core ideas and design principles have all become mainstream recently, Lisp as a language still isn't, and so it's great to find that there are other Lisp holdouts in the same company. Particularly if they happen to harbor a legend like Kent Pitman... I sure hope I'll have a chance to meet Kent one day!

---

Sniffing for crashes (09 Jan 2008)

A few months ago, I blogged about crash reporting under Windows XP and Vista. The protocol between Windows and Microsoft's Watson servers is undocumented, but contains useful hints on how the mechanism works. Back then, I hinted that I had intercepted the crash reporting traffic to learn more about it, but I didn't fully describe how I did that.

If only I could remember, that is

Well, I remember the basic approach, and I even took some notes back then which I will regurgitate here and now. However, don't expect step-by-step instructions.

My goal was to take control of the crash reporting process in my application. When an application crashes, Microsoft's official recommendation is that it should not try to catch the fatal exception, but instead simply bail out, let Windows perform its crash reporting rites, and then terminate. For various reasons, we needed more control over the process, and so I set out on a discovery tour through the Windows Error Reporting APIs which Microsoft introduced in Windows Vista. The details of this epic saga can be found at:

• The end is nigh (for my process)
• Crashing with style on Vista
• Crashing with style on Vista, part II
• Think globally, dump locally
• Don't dump Vista just yet; let Vista do the dumping!
• Elementary, my dear Watson!

For a long time, I simply couldn't get crash reporting to work as I expected it to. I had pretty much exhausted most of the official documentation, so I needed to dig deeper.

When an application crashes and the user agrees to send the crash data to Microsoft, Windows contacts Microsoft's Watson servers. For some reason, my crash reports weren't accepted there, while the usual plain vanilla crashme.exe could successfully dump its debris to Microsoft's servers. Hence, the idea was to look at the network traffic and find the differences between my crash reports and those produced by the proverbial crashme.exe.

I could have run the usual network sniffing suspects to decode LAN traffic including all the email exchanged between my boss and his boss, of course. But there is an even easier and less controversial approach: For corporate environments, where admins often need more control over the crash reporting process, Microsoft introduced corporate error reporting (CER), where crashing systems can contact a local server rather than sending all those confidential access violations to Microsoft.

There are registry entries to set the server name and port for corporate error reporting:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\CorporateWERServer: Name of the local crash reporting server
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\CorporateWERPortNumber: Port number to be used for communication

On my Vista system, I modified CorporateWERServer so that it referred to my laptop. I did not set the port number explicitly; using procmon, I found that the default port is 1273.

On my laptop, I installed netcat and had it listen to input from port 1273 (nc -l273 or something like that). Once the port was open, Vista started to send HTTP POST requests to it - so the CER server really is a specialized HTTP server listening to port 1273! Here's a typical request (slightly polished and anonymized) following a crash in a sample app I was writing back then:

POST /stage2.htm HTTP/1.1
User-Agent: MSDW
Host: mylaptop:1273
Content-Length: 1110
Connection: Keep-Alive

<?xml version="1.0" encoding="UTF-16"?>
<WERREPORT xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <MACHINEINFO machinename="myvistabox" os="6.0.6000.2.0.0.256.16" lcid="1033"/>
   <USERINFO username="myvistabox\clausb"/>
   <APPLICATIONINFO appname="werapitest.exe" apppath="C:\tmp\werapitest.exe"/>
   <EVENTINFO reporttype="1" eventtime="128267449141252896" eventtype="werapitest (eventType)" 
      friendlyeventname="werapitest (friendly event name)" eventdescription="Critical runtime problem"/>
   <SIGNATURE>
   </SIGNATURE>
</WERREPORT>

By comparing this kind of payload with the traffic generated by a plain vanilla crashme.exe program, I could experiment with the various WER APIs and settings until I had finally figured out how to use them. Without crash report sniffing, I'd probably still be experimenting...

---

Entendämmerung (02 Jan 2008)

Ich bin aufgewachsen mit den Werken von Carl Barks, und auch heute noch halte ich ihnen die Treue. Die Verehrung fuer Carl Barks war so gross, dass ich Mitglied der D.O.N.A.L.D. wurde. Die "Deutsche Organisation Nichtkommerzieller Anhänger des Lauteren Donaldismus" widmet sich der hinreissend zweckfreien Betrachtung der Barksschen Werke auf so amüsante Weise, dass es mir ganz und gar nichts ausmachte, dass meine Mitgliedsbeiträge bei sympathisch improvisiert wirkenden Maifeiern, Zwischenzeremonien und Kongressen verprasst wurden.

Man lernt in diesem Verein übrigens auch schnell, dass die Republik donaldistisch unterwandert ist: Die geistigen Kinder von Carl Barks und seiner kongenialen deutschen Übersetzerin Erika Fuchs sind längst den Watschelgang durch die Institutionen angetreten. Das Feuilleton der Frankfurter Allgemeine Zeitung beispielsweise ist vollständig in der Hand von Federviehfetischisten. Und auch die Stuttgarter Zeitung veröffentlicht in schöner Unregelmässigkeit Beiträge oder auch nur Bilder mit verdächtig anatidem Hintergrund.

Nicht nur, dass Barks meinen Geschmack für gut erzählte Geschichten geprägt hat, er hat auch meine Berufswahl entscheidend beeinflusst: Der Herr Ingeniör, dem nichts zu schwör war - das war der Held meiner Kindheit.

Und doch bin ich jetzt aus der D.O.N.A.L.D. ausgetreten und habe dazu auch noch mein Abo der Tollsten Geschichten von Donald Duck gekündigt. Ein wenig traurig ist das schon - aber es war denn doch unvermeidlich.

Zum einen habe ich "meinen Barks" inzwischen schon mehrfach beisammen, die Regale biegen sich. Zum anderen aber fiel mir vor einigen Jahren - auf der Suche nach amerikanischen Donald-Duck-Heften - in einen Comicladen in den USA ein Exemplar von "V for Vendetta" in die Hände, eine düstere, provokante, gewalttätige und verwirrende graphic novel von Alan Moore und David Lloyd.

Barks ist seither die Lektüre für die hellen Stimmungen geworden - in den dunklen Zeiten aber versinke ich in den verblüffenden Hirngespinsten von Alan Moore. Oder in Serien wie "Y - The Last Man", in der Brian K. Vaughan seine Hauptfigur in eine Welt setzt, in der er das letzte männliche Wesen ist. Oder DMZ, in dem Manhattan zwischen die Fronten eines Bürgerkriegs gerät. Oder ich grüble über Sin City, in dem Frank Miller so heftig Gewaltphantasien frönt, dass ich immer noch nicht so richtig weiss, ob ich das für gefährlich oder für erstaunlich halten soll...

Alle diese tollen Geschichten sind also hiermit wärmstens empfohlen - aber zumindest im Falle von DMZ und Sin City nur für Leser mit guten Nerven. Und für alle anderen gibt es immer noch die geliebten Vierfingler und Schnabelträger aus Duckburg.

---

---

to top